Exchange Server’da Send Connector Yapılandırması
Mail altyapısında en çok göz ardı edilen ama bir o kadar kritik olan konu, giden mail akışının doğru yapılandırılmasıdır. Exchange ortamında “neden mail gitmiyor?” sorusunun cevabı çoğunlukla Send Connector’da saklıdır. Yıllar içinde onlarca Exchange kurulumunda gördüm ki, bu bileşen ya hiç yapılandırılmamış ya da yarım bırakılmış. Bu yazıda Send Connector’ı sıfırdan, gerçek dünya senaryolarıyla ele alacağız.
Send Connector Nedir ve Neden Bu Kadar Önemlidir
Exchange Server, gelen ve giden mail trafiğini farklı connector bileşenleriyle yönetir. Receive Connector gelen trafikten sorumluyken, Send Connector kurumunuzdan dışarıya giden tüm mail trafiğinin kapısıdır. Hiç Send Connector tanımlamamışsanız Exchange, internete doğrudan DNS MX kaydı sorgulayarak mail göndermeye çalışır. Bu bazen işe yarar, ama production ortamında asla bu şekilde bırakmamalısınız.
Kurumsal ortamlarda genellikle iki senaryo karşımıza çıkar: Birincisi, Exchange’in doğrudan internete açık olduğu ve kendi başına MX kayıtlarına göre mail ilettiği senaryo. İkincisi, önünde bir smarthost (relay sunucu, güvenlik gateway’i veya ISP’nin mail sunucusu) olan senaryo. Her iki durumda da Send Connector yapılandırması şarttır ve birbirinden farklı parametreler gerektirir.
Exchange Management Shell ile Temel Send Connector Oluşturma
Exchange yönetiminde GUI her zaman yeterli gelmez. Özellikle birden fazla Exchange sunucusu olan ortamlarda ve otomasyon ihtiyacı duyduğunuzda PowerShell kaçınılmaz olur. Önce en temel Send Connector oluşturma komutuna bakalım:
New-SendConnector -Name "Internet Send Connector" `
-AddressSpaces "SMTP:*;1" `
-Internet `
-SourceTransportServers "MAILSERVER01"
Bu komut ile tüm dış domainlere (*) mail gönderebilecek, cost değeri 1 olan bir connector oluşturursunuz. -Internet parametresi, Exchange’in hedef sunuculara doğrudan DNS üzerinden bağlanacağını belirtir.
Peki smarthost kullanacaksanız:
New-SendConnector -Name "Smarthost Send Connector" `
-AddressSpaces "SMTP:*;1" `
-SmartHosts "mail-relay.sirketiniz.com" `
-SmartHostAuthMechanism None `
-SourceTransportServers "MAILSERVER01","MAILSERVER02"
Burada -SmartHosts parametresine dikkat edin. Birden fazla smarthost tanımlayabilirsiniz, Exchange aralarında load balancing yapar. -SmartHostAuthMechanism None ise hedef relay sunucunun kimlik doğrulaması gerektirmediği durumlarda kullanılır.
Mevcut Send Connector’ları Görüntüleme ve Durum Kontrolü
Sisteminizde halihazırda ne var, görmeden ilerlemek olmaz. Mevcut connector’ları listelemek için:
Get-SendConnector | Select-Object Name, AddressSpaces, SmartHosts, `
SourceTransportServers, Enabled, MaxMessageSize | Format-List
Belirli bir connector’ın tüm özelliklerine bakmak istiyorsanız:
Get-SendConnector -Identity "Internet Send Connector" | Format-List *
Bu komutun çıktısında DNSRoutingEnabled, RequireTLS, UseExternalDNSServersEnabled gibi kritik parametreleri mutlaka kontrol edin. Production ortamında onlarca kez gördüm, birisi daha önce bir şeyler değiştirmiş ama kimse farkında değil.
Kimlik Doğrulama Gerektiren Smarthost Yapılandırması
ISP’ler veya bazı mail güvenlik servisleri (Mimecast, Proofpoint gibi) relay için kimlik doğrulaması isteyebilir. Bu durumda önce bir credential nesnesi oluşturmanız gerekir:
$Credential = Get-Credential
New-SendConnector -Name "Authenticated Smarthost" `
-AddressSpaces "SMTP:*;1" `
-SmartHosts "smtp.mailfiltreservisi.com" `
-SmartHostAuthMechanism BasicAuth `
-AuthenticationCredential $Credential `
-RequireTLS $true `
-SourceTransportServers "MAILSERVER01"
-SmartHostAuthMechanism parametresi için kullanabileceğiniz değerler:
- None: Kimlik doğrulama yok
- BasicAuth: Kullanıcı adı ve şifre ile temel kimlik doğrulama
- BasicAuthRequireTLS: TLS üzerinden temel kimlik doğrulama (önerilen)
- ExchangeServer: Exchange Server kimlik doğrulama mekanizması
- ExternalAuthoritative: Harici yetkili sunucular için
Genellikle dışarıdaki servislerle BasicAuthRequireTLS kombinasyonu kullanmak en güvenli seçenektir.
TLS ve Güvenlik Yapılandırması
Modern mail altyapısında TLS zorunluluk haline geldi. 2024 itibarıyla birçok büyük mail sağlayıcısı TLS olmadan gelen mailleri reddediyor veya spam olarak işaretliyor. Send Connector’da TLS ayarlarını doğru yapmak kritik öneme sahip:
Set-SendConnector -Identity "Internet Send Connector" `
-RequireTLS $false `
-TlsAuthLevel CertificateValidation `
-TlsDomain $null
Burada önemli bir nüans var: -RequireTLS $false demek TLS kullanmayacağı anlamına gelmez. Bu parametre, karşı sunucu TLS desteklemiyorsa bağlantıyı kesip kesmeyeceğinizi belirler. $false iken, karşı taraf TLS sunmuyorsa şifresiz bağlantıya düşer (opportunistic TLS). Belirli bir domain’e TLS zorunlu kılmak istiyorsanız:
Set-SendConnector -Identity "Internet Send Connector" `
-RequireTLS $true `
-TlsAuthLevel DomainValidation `
-TlsDomain "hedef-domain.com"
Bu konfigürasyon yalnızca hedef-domain.com‘a giden maillerde zorunlu TLS ister. Genel bir connector için bu yaklaşım yerine, belirli domainler için ayrı connector açmak daha yönetilebilir bir yapı sunar.
Domain’e Özel Send Connector Yapılandırması
Diyelim ki iş ortağınızla özel bir mail ilişkisi var. Onlara giden mailler farklı bir IP’den çıkacak, farklı bir relay kullanılacak veya zorunlu TLS ile gidecek. Bu durum için domain’e özel connector açmak gerekir:
New-SendConnector -Name "Partner Firma Ozel Connector" `
-AddressSpaces "SMTP:partnerfirma.com.tr;1" `
-SmartHosts "10.20.30.40" `
-RequireTLS $true `
-TlsAuthLevel CertificateValidation `
-SourceTransportServers "MAILSERVER01" `
-MaxMessageSize 50MB
-AddressSpaces parametresindeki cost değerine (sonundaki ;1) dikkat edin. Exchange birden fazla connector aynı adres alanını kapsıyorsa, düşük cost değerine sahip olanı tercih eder. Genel internet connector’ınızın cost değeri 1 ise, bu özel connector için de 1 koyarsanız çakışma yaratabilirsiniz. Özel connector’lara düşük değer, genel connector’a daha yüksek değer vermek daha yönetilebilir bir hiyerarşi oluşturur.
Send Connector’da Maksimum Mesaj Boyutu ve Performans Ayarları
Gerçek dünyada “müşterimize 30MB’lık dosya gönderemedik” şikayeti her kurumda yaşanır. Send Connector seviyesinde boyut sınırlamasını kontrol etmek için:
Get-SendConnector "Internet Send Connector" | Select-Object MaxMessageSize
Değiştirmek için:
Set-SendConnector -Identity "Internet Send Connector" `
-MaxMessageSize 25MB `
-ConnectionInactivityTimeOut 00:10:00 `
-ConnectionTimeOut 00:10:00 `
-SourceIPAddress "0.0.0.0"
Burada şunu hatırlatmak isterim: Send Connector’daki boyut sınırı tek başına yeterli değildir. Exchange’de mesaj boyutu üç farklı katmanda kontrol edilir: Transport servisi, connector seviyesi ve mailbox seviyesi. Birini değiştirip diğerlerini unutmak sık yapılan bir hatadır.
-SourceIPAddress parametresi, Exchange sunucunuzda birden fazla IP adresi varsa önemli hale gelir. Hangi IP’den mail gönderileceğini buradan belirlersiniz. 0.0.0.0 tüm IP’leri kullan anlamına gelir.
Exchange Admin Center (EAC) Üzerinden Send Connector Yapılandırması
Her ne kadar PowerShell tercihim olsa da, yeni başlayan sysadmin’ler için GUI’yi de açıklayalım. Exchange Admin Center’da Mail flow > Send connectors yolunu izleyerek yeni connector oluşturabilirsiniz. Wizard sizi adım adım yönlendirir:
İlk ekranda connector adını ve türünü seçersiniz. Tür olarak genellikle Internet seçmeniz yeterlidir. Sonraki adımda smarthost mi yoksa DNS routing mi kullanacağınızı belirtirsiniz. Kaynak sunucuları seçtiğiniz ekranda, DAG (Database Availability Group) ortamında tüm mailbox sunucularını eklemeniz gerektiğini unutmayın. Tek bir sunucu seçerseniz, diğer sunucular üzerinden geçen mail trafiği bu connector’ı kullanamaz.
Send Connector Sorunlarının Teşhisi
“Mail gitmiyor” dediğinizde bakılacak ilk yer message tracking log’larıdır:
Get-MessageTrackingLog -ResultSize Unlimited `
-Start (Get-Date).AddHours(-2) `
-EventId "FAIL" | Select-Object Timestamp, Source, EventId, `
MessageSubject, Recipients, RecipientStatus | Format-List
SMTP protokol seviyesinde neler olduğunu görmek için:
Get-MessageTrackingLog -ResultSize 50 `
-Start (Get-Date).AddHours(-1) `
-Sender "[email protected]" | Format-List
Transport servisinin gerçek zamanlı durumunu kontrol etmek için:
Test-SendConnector -Identity "Internet Send Connector"
Bu komut connector’ın çalışıp çalışmadığını test eder. Ancak asıl SMTP bağlantı testini yapmak için Telnet veya Test-NetConnection daha doğrudan sonuç verir:
Test-NetConnection -ComputerName "hedef-mail-sunucusu.com" -Port 25
Bağlantı başarılıysa ama mail yine de gitmiyorsa, problem genellikle TLS anlaşmasında veya kimlik doğrulamadadır. Bu durumda Protocol Log’ları devreye girer.
Protocol Logging Aktif Etme ve Analiz
Protocol log, SMTP konuşmasının kelimesi kelimesine kaydıdır. Sorun giderirken altın değerindedir. Send Connector için protokol log açmak:
Set-SendConnector -Identity "Internet Send Connector" `
-ProtocolLoggingLevel Verbose
Log’ların nerede tutulduğunu öğrenmek için:
Get-TransportService | Select-Object SendProtocolLogPath, `
SendProtocolLogMaxAge, SendProtocolLogMaxDirectorySize
Log dizinine gidip son log dosyasını incelediğinizde EHLO, STARTTLS, AUTH, MAIL FROM, RCPT TO, DATA komutlarını ve sunucudan gelen yanıt kodlarını göreceksiniz. 530 5.7.1 Authentication required görüyorsanız smarthost kimlik doğrulaması istiyor demektir. 550 5.1.1 User unknown ise alıcı adreste sorun var demektir.
Sorun giderdikten sonra loglama seviyesini geri almayı unutmayın, disk alanını hızla tüketebilir:
Set-SendConnector -Identity "Internet Send Connector" `
-ProtocolLoggingLevel None
Çoklu Exchange Sunucusu Olan Ortamlarda Send Connector Yönetimi
DAG veya multi-server Exchange ortamında Send Connector’lar Active Directory seviyesinde saklanır ve tüm sunucular tarafından görülebilir. Ancak bir connector hangi sunucuların üzerinden çalışacağını -SourceTransportServers parametresiyle belirler.
Yeni bir Exchange sunucusu ortama eklediğinizde, mevcut connector’lara bu sunucuyu eklemeniz gerekir:
$ExistingServers = (Get-SendConnector "Internet Send Connector").SourceTransportServers
$NewServer = Get-TransportService "MAILSERVER03"
Set-SendConnector "Internet Send Connector" `
-SourceTransportServers ($ExistingServers + $NewServer)
Bu adımı atlamak çok yaygın bir hata. Yeni sunucu kurulumu tamamlandıktan sonra test ediyorsunuz, kendi başına mail gönderemiyor. Sonra bakıyorsunuz, connector’a eklenmemiş. Saatler kaybedilmesine sebep olan basit bir ihmal.
Edge Transport Sunucusu ile Send Connector Entegrasyonu
Bazı ortamlarda perimeter ağına Edge Transport sunucusu konur ve internet trafiği bu sunucu üzerinden geçer. Edge Subscription yapılandırıldıktan sonra Send Connector otomatik senkronize edilir. Ancak elle yapılandırma gerekiyorsa:
New-SendConnector -Name "EdgeSync - Outbound to Internet" `
-AddressSpaces "SMTP:*;100" `
-DNSRoutingEnabled $true `
-UseExternalDNSServersEnabled $false `
-SourceTransportServers "EDGESERVER01" `
-Internet
Edge sunucusunda Send Connector oluştururken -SourceTransportServers ile Edge sunucusunu belirtmeyi ve Internal (Hubsite) connector’lardan farklı bir cost değeri kullanmayı tercih edin. Cost değeri yüksek tutularak, iç connector’ların öncelikli olması sağlanır.
Gerçek Dünya Senaryosu: Mimecast Entegrasyonu
Bir kurumda Mimecast veya benzeri bir mail güvenlik servisi kullanıyorsanız, tüm giden trafiği Mimecast üzerinden yönlendirmeniz gerekir. Bu tam klasik bir smarthost senaryosudur:
New-SendConnector -Name "Mimecast Outbound" `
-AddressSpaces "SMTP:*;1" `
-SmartHosts "eu-smtp-outbound-1.mimecast.com","eu-smtp-outbound-2.mimecast.com" `
-SmartHostAuthMechanism BasicAuthRequireTLS `
-AuthenticationCredential (Get-Credential) `
-RequireTLS $true `
-SourceTransportServers "MAILSERVER01","MAILSERVER02" `
-MaxMessageSize 100MB
Bu yapılandırmada dikkat edilmesi gereken noktalar:
- Mimecast iki farklı outbound endpoint sunar, her ikisini de ekleyin
BasicAuthRequireTLSkullanın çünkü credential bilgisi aktarılıyor- MaxMessageSize değerini Mimecast hesabınızda tanımlı olan sınırla eşleştirin
- Mimecast portalında Exchange sunucularınızın IP’lerini authorized IP olarak eklemeyi unutmayın
Send Connector’ı Devre Dışı Bırakma ve Etkinleştirme
Bakım penceresinde veya test sırasında connector’ı geçici olarak durdurmak gerekebilir:
# Devre disi birakma
Disable-SendConnector -Identity "Internet Send Connector"
# Tekrar etkinlestirme
Enable-SendConnector -Identity "Internet Send Connector"
# Durumu kontrol etme
Get-SendConnector | Select-Object Name, Enabled
Connector devre dışıyken kuyruktaki mailler ne olur? Exchange mesajları kuyrukta tutar ve connector aktif olduğunda göndermeye devam eder. Ancak kuyruk büyümesini izlemek için:
Get-Queue | Where-Object {$_.Status -eq "Retry" -or $_.Status -eq "Active"} | `
Select-Object Identity, Status, MessageCount, NextRetryTime | Format-Table
Sonuç
Send Connector, Exchange’in dışa açılan kapısıdır. Yanlış veya eksik yapılandırılmış bir connector hem mail akışını duraksatır hem de güvenlik açıklarına yol açabilir. TLS olmadan giden mailler, yanlış kimlik doğrulama mekanizması veya unutulan kaynak sunucu eklentisi gibi basit görünen hatalar production’da ciddi sorunlara dönüşür.
Bu yazıda anlattıklarımı özetlersek: Ortamınıza uygun tipte connector oluşturun (DNS routing mu, smarthost mi), TLS ayarlarını ihmal etmeyin, çoklu sunucu ortamında her sunucuyu connector’a ekleyin, sorun giderirken önce message tracking ardından protocol log’lara bakın.
Exchange’in diğer bileşenleri gibi Send Connector da bir kez kurup unutulacak bir yapılandırma değildir. Mail altyapısı değiştikçe, yeni servisler entegre edildikçe connector’ları gözden geçirmek düzenli bakımın parçası olmalıdır. Özellikle IP değişiklikleri, sertifika yenilemeleri ve yeni sunucu eklemeleri sonrasında Send Connector’ları kontrol etmeyi alışkanlık haline getirin.
