Mail Sunucusu için DNS Ayarları: MX Kaydı Yapılandırması

yazar

Mail sunucusu kuruyorsun, SPF ayarladın, DKIM sertifikasını oluşturdun, ama gelen kutusuna tek bir mail düşmüyor. Sonunda fark ediyorsun: MX kaydın ya yanlış, ya eksik, ya da hiç yok. Bu durumu yaşayan tek sysadmin sen değilsin ve bu yazıda bu acıyı bir daha yaşamamak için DNS ayarlarını en ince ayrıntısına kadar ele alacağız.

MX Kaydı Nedir ve Neden Bu Kadar Önemli

MX (Mail Exchanger) kaydı, bir domain için gelen e-postaların hangi sunucuya teslim edileceğini tanımlayan DNS kaydı türüdür. Bir mail sunucusu sana e-posta göndermek istediğinde ilk yaptığı şey hedef domainin MX kaydını sorgulamaktır. Bu kayıt yoksa ya da yanlışsa, gönderilen mail karşı tarafın kuyrucunda bekler, sonunda “delivery failed” hatasıyla geri döner.

Active Directory ortamında mail yönetimi biraz daha katmanlı hale gelir. Hem internal DNS zone’larında hem de external (public) DNS sağlayıcında MX kayıtlarını doğru yönetmen gerekir. Şirket içi Exchange Server ya da üçüncü parti bir mail sunucusu kullanıyor olsan da temel mantık değişmez: doğru MX kaydı, doğru sunucuya, doğru öncelikle işaret etmelidir.

DNS Mimarisini Anlamak: Internal vs External

Active Directory kullanan bir ortamda genellikle iki farklı DNS katmanı vardır:

  • Internal DNS (AD entegre): Domain controller’ların barındırdığı, iç ağ için kullanılan DNS. Örneğin company.local veya split-brain DNS kullanıyorsan company.com‘un iç versiyonu.
  • External DNS: İnternete bakan, MX, A, CNAME gibi public kayıtların tutulduğu DNS. Bu genellikle domain kayıt şirketinizin (Cloudflare, GoDaddy, AWS Route53 vb.) panelinde yönetilir.

Yaygın bir hata, internal DNS’e eklenen MX kaydının external’dan da görüleceğini sanmak. Bu iki ortam birbirinden tamamen bağımsız çalışır. External mail trafiği için kaydı dış DNS’e eklemeyi unutursan, dışarıdan mail alamazsın.

Temel MX Kaydı Yapısı

MX kaydının söz dizimi şu şekildedir:

# Format: domain TTL IN MX priority mailserver_hostname
company.com.    3600    IN    MX    10    mail.company.com.

Bu örnekteki her alanın anlamı:

  • company.com.: Kaydın ait olduğu domain (sonundaki nokta önemli, FQDN gösterir)
  • 3600: TTL (Time To Live) saniye cinsinden, 3600 = 1 saat
  • IN: Internet sınıfı, her zaman böyle yazılır
  • MX: Kayıt tipi
  • 10: Öncelik değeri (priority), düşük sayı = yüksek öncelik
  • mail.company.com.: Mail sunucusunun FQDN’i

Windows DNS Manager ile MX Kaydı Oluşturma

Active Directory ortamında Windows Server üzerindeki DNS Manager (dnsmgmt.msc) kullanarak MX kaydı nasıl eklenir, adım adım bakalım.

Öncelikle zone’un mevcut durumunu kontrol edelim. PowerShell’den:

# DNS zone'larını listele
Get-DnsServerZone -ComputerName "dc01.company.com"

# Belirli bir zone'daki tüm kayıtları görüntüle
Get-DnsServerResourceRecord -ZoneName "company.com" -ComputerName "dc01.company.com"

Şimdi MX kaydını PowerShell ile ekleyelim. Bu yöntem GUI’ye göre çok daha hızlı ve scriptlenebilir:

# MX kaydı ekleme - PowerShell
Add-DnsServerResourceRecordMX `
    -ZoneName "company.com" `
    -Name "@" `
    -MailExchange "mail.company.com" `
    -Preference 10 `
    -ComputerName "dc01.company.com" `
    -TimeToLive 01:00:00

# Eklenen kaydı doğrula
Get-DnsServerResourceRecord `
    -ZoneName "company.com" `
    -RRType "MX" `
    -ComputerName "dc01.company.com"

Burada -Name "@" root domain için kayıt eklediğimizi belirtir. Bir subdomain için mail kullanıyorsan (örneğin mail.company.com değil, company.com‘un kendisi için) @ kullanırsın.

Mail Sunucusu için A Kaydı Zorunluluğu

MX kaydı bir hostname’e işaret eder, IP adresine değil. Bu yüzden MX kaydındaki hostname için mutlaka bir A kaydı (veya AAAA kaydı) olmalıdır. MX kaydının bir CNAME’e işaret etmesi RFC standartlarına göre önerilmez ve bazı mail sunucuları tarafından reddedilir.

# Mail sunucusu için A kaydı ekle
Add-DnsServerResourceRecordA `
    -ZoneName "company.com" `
    -Name "mail" `
    -IPv4Address "203.0.113.25" `
    -ComputerName "dc01.company.com" `
    -TimeToLive 01:00:00

# Reverse lookup için PTR kaydı (bu kritik!)
Add-DnsServerResourceRecordPtr `
    -ZoneName "113.0.203.in-addr.arpa" `
    -Name "25" `
    -PtrDomainName "mail.company.com." `
    -ComputerName "dc01.company.com"

PTR kaydı (reverse DNS) özellikle önemli. Birçok mail sunucusu, gelen bağlantıda IP’nin PTR kaydını sorgular. PTR kaydı yoksa ya da MX kaydıyla eşleşmiyorsa, maillerin spam olarak işaretlenmesi ya da doğrudan reddedilmesi çok olası. PTR kaydını genellikle ISP’inden ya da hosting sağlayıcından talep etmen gerekir.

Öncelik Değerleri ve Yedek Mail Sunucusu Kurgusu

Büyük ortamlarda tek bir mail sunucusuna güvenmek risklidir. Birden fazla MX kaydı tanımlayarak yedeklilik sağlayabilirsin. Mail gönderen sunucu en düşük priority değerine sahip sunucuyu önce dener, o yanıt vermezse bir sonrakine geçer.

# Birincil mail sunucusu (öncelik 10)
Add-DnsServerResourceRecordMX `
    -ZoneName "company.com" `
    -Name "@" `
    -MailExchange "mail1.company.com" `
    -Preference 10 `
    -ComputerName "dc01.company.com"

# Yedek mail sunucusu (öncelik 20)
Add-DnsServerResourceRecordMX `
    -ZoneName "company.com" `
    -Name "@" `
    -MailExchange "mail2.company.com" `
    -Preference 20 `
    -ComputerName "dc01.company.com"

# Tüm MX kayıtlarını listele
Get-DnsServerResourceRecord `
    -ZoneName "company.com" `
    -RRType MX `
    -ComputerName "dc01.company.com" | `
    Select-Object HostName, @{N="MailExchange";E={$_.RecordData.MailExchange}}, `
    @{N="Priority";E={$_.RecordData.Preference}}, TimeToLive

Yaygın öncelik değeri örüntüleri:

  • 10 ve 20: En basit yedekli kurulum
  • 10, 20, 30: Üç kademeli yedeklilik
  • 5 ve 10: Eşit ağırlıklı load balancing istiyorsan aynı değer vermen yeterli (örneğin ikisi de 10)

nslookup ve dig ile MX Kaydı Doğrulama

Kaydı ekledikten sonra her zaman doğrulama yapmalısın. DNS önbelleği (cache) bazen can sıkıcı olur, bu yüzden birden fazla noktadan test etmek iyi bir alışkanlık.

# Windows'ta nslookup ile MX sorgusu
nslookup -type=MX company.com
nslookup -type=MX company.com 8.8.8.8

# Belirli DNS sunucusunu kullanarak sorgula
nslookup
> set type=MX
> server dc01.company.com
> company.com

# Linux/WSL ortamında dig kullanımı
dig MX company.com
dig MX company.com @8.8.8.8
dig MX company.com +short

# Tüm DNS kayıtlarını görüntüle
dig company.com ANY

Doğrulama sırasında dikkat etmen gereken çıktı örneği:

# Beklenen dig çıktısı
company.com.     3600    IN    MX    10 mail1.company.com.
company.com.     3600    IN    MX    20 mail2.company.com.

# mail hostname'inin A kaydı da çözümlenmeli
mail1.company.com.   3600    IN    A    203.0.113.25

Split-Brain DNS Senaryosu: İç ve Dış Trafiği Yönetmek

Orta ve büyük ölçekli şirketlerde split-brain DNS (ya da split-horizon DNS) çok yaygındır. Bu senaryoda aynı domain adı için iç ve dış DNS sunucularında farklı kayıtlar tutulur.

Örneğin, company.com için:

  • Dış DNS: MX kaydı internet üzerindeki mail sunucusuna işaret eder (veya Microsoft 365, Google Workspace MX kayıtlarına)
  • İç DNS: MX kaydı internal Exchange Server’a işaret eder

Bu kurulum hem güvenlik hem de performans açısından mantıklıdır; iç kullanıcılar mail gönderirken internete çıkmak zorunda kalmaz.

Active Directory’de internal zone’u güncellemek için:

# Internal zone'daki MX kaydını güncelle (Exchange için)
Set-DnsServerResourceRecord `
    -ZoneName "company.com" `
    -OldInputObject (Get-DnsServerResourceRecord -ZoneName "company.com" -RRType MX -Name "@") `
    -NewInputObject (New-DnsServerResourceRecordMX `
        -MailExchange "exchange.company.com" `
        -Preference 10) `
    -ComputerName "dc01.company.com"

Microsoft 365 veya Exchange Online ile MX Entegrasyonu

Şirket içi Exchange’den Microsoft 365’e geçiş yapıyorsan ya da hybrid ortam kuruyorsan, MX kayıtlarını güncellemen gerekir. Microsoft 365, her tenant için benzersiz bir MX hostname sağlar.

# Microsoft 365 MX kaydı genellikle şu formatta olur:
# company-com.mail.protection.outlook.com

# External DNS'te bu kaydı eklemen gerekir (bu komutu external DNS API üzerinden veya
# doğrudan sağlayıcı panelinden yaparsın, örneğin Cloudflare API ile):

# Cloudflare API örneği (curl ile)
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" 
     -H "Authorization: Bearer API_TOKEN" 
     -H "Content-Type: application/json" 
     --data '{
       "type": "MX",
       "name": "@",
       "content": "company-com.mail.protection.outlook.com",
       "priority": 0,
       "ttl": 3600
     }'

Microsoft 365 geçişi sırasında kritik bir nokta: Geçiş tamamlanana kadar eski MX kaydını silme. Önce yeni kaydı düşük öncelikle ekle, geçiş bittikten sonra öncelikleri değiştir.

TTL Değeri Stratejisi: Değişiklik Öncesi ve Sonrası

DNS değişikliklerinde TTL yönetimi çok önemli. Eğer MX kaydını değiştirmeyi planlıyorsan, değişiklikten önceki gün TTL değerini düşürmelisin. Böylece değişiklik sonrasında DNS önbelleklerinin temizlenmesi çok daha hızlı olur.

# Değişiklikten 24-48 saat önce TTL'i düşür (300 saniye = 5 dakika)
$oldRecord = Get-DnsServerResourceRecord `
    -ZoneName "company.com" `
    -RRType MX `
    -Name "@" `
    -ComputerName "dc01.company.com"

$newRecord = $oldRecord.Clone()
$newRecord.TimeToLive = [System.TimeSpan]::FromSeconds(300)

Set-DnsServerResourceRecord `
    -ZoneName "company.com" `
    -OldInputObject $oldRecord `
    -NewInputObject $newRecord `
    -ComputerName "dc01.company.com"

# Değişiklik tamamlandıktan sonra TTL'i normale döndür (3600 saniye)
# Aynı prosedürü 3600 ile tekrar uygula

Genel TTL tavsiyeleri:

  • Değişiklik öncesi: 300-600 saniye (5-10 dakika)
  • Stabil ortamda: 3600-7200 saniye (1-2 saat)
  • Çok stabil kayıtlar için: 86400 saniye (1 gün)

Gerçek Dünya Senaryosu: Şirket Birleşmesi Sonrası Mail Geçişi

Bir şirketi devraldığını düşün. Yeni şirketin yenifirma.com domaini var ve bu domain için mail altyapısını kendi Exchange ortamına taşıman gerekiyor.

Mevcut durum: yenifirma.com MX kayıtları üçüncü parti bir mail servisine işaret ediyor. Hedef durum: Tüm mail, kendi Exchange ortamındaki exchange.sirket.com‘a gelecek.

# 1. Adım: Mevcut durumu belgele
nslookup -type=MX yenifirma.com 8.8.8.8

# 2. Adım: External DNS'te yeni domaini hazırla
# (Exchange'de Accepted Domain ekle)
# Exchange Management Shell:
New-AcceptedDomain `
    -Name "yenifirma.com" `
    -DomainName "yenifirma.com" `
    -DomainType "Authoritative"

# 3. Adım: Test amacıyla geçici A kaydı ve MX kaydı ekle
# Bu değişikliği external DNS sağlayıcından yapman gerekir

# 4. Adım: Windows DNS'e internal zone ekle
Add-DnsServerPrimaryZone `
    -Name "yenifirma.com" `
    -ReplicationScope "Forest" `
    -ComputerName "dc01.sirket.com"

# 5. Adım: Internal MX kaydını ekle
Add-DnsServerResourceRecordMX `
    -ZoneName "yenifirma.com" `
    -Name "@" `
    -MailExchange "exchange.sirket.com" `
    -Preference 10 `
    -ComputerName "dc01.sirket.com"

# 6. Adım: Doğrulama
Resolve-DnsName -Name "yenifirma.com" -Type MX -Server "dc01.sirket.com"

Yaygın Hatalar ve Çözümleri

Yıllar içinde defalarca karşılaştığım hataları sıralayalım:

MX kaydı IP adresine işaret ediyor: MX hostname alır, IP adresi almaz. mail.company.com yazman gereken yere 203.0.113.25 yazdıysan gelen mailler büyük ihtimalle reddedilecek ya da sorun yaşayacak. Hemen düzelt.

Trailing dot eksikliği: Zone dosyasında FQDN yazarken sonuna nokta koymayı unutursan, DNS bunu zone adıyla birleştirir. mail.company.com yazarsan mail.company.com.company.com olur. Nokta kritik.

PTR kaydı yok: Yukarıda bahsetmiştim ama tekrar vurgulamak gerekiyor. PTR kaydı olmayan mail sunucularına büyük provider’lar (Gmail, Outlook, Yahoo) mail kabul etmeyebilir ya da spam olarak işaretler.

AD Replication gecikmesi: Bir DC’de yaptığın değişiklik diğer DC’lere hemen yansımayabilir. Kritik değişikliklerden sonra replikasyonu manuel tetikle:

# AD replication'ı manuel tetikle
repadmin /syncall /AdeP

# Replication durumunu kontrol et
repadmin /replsummary

# DNS zone transfer durumunu kontrol et
dnscmd dc02.company.com /ZoneRefresh company.com

Yanlış zone’a MX kaydı ekleme: Internal zone’a eklenen MX kaydı external trafiği yönlendirmez. Hangi zone’da çalıştığını her zaman double-check et.

MX Kaydını Online Araçlarla Test Etme

Sadece nslookup ile kalmayın. Şu online araçlar sysadmin’in vazgeçilmezi olmalı:

  • MXToolbox (mxtoolbox.com): MX, SPF, DKIM, DMARC kontrolü için tek durak
  • Mail Tester (mail-tester.com): Test maili gönderip spam skorunu görmek için
  • DNSChecker (dnschecker.org): Değişikliklerin farklı coğrafyalardaki DNS sunucularına yayılıp yayılmadığını görmek için
# PowerShell ile basit bir MX doğrulama scripti
$domain = "company.com"
$mxRecords = Resolve-DnsName -Name $domain -Type MX -Server "8.8.8.8"

foreach ($mx in $mxRecords) {
    Write-Host "MX: $($mx.NameExchange) - Öncelik: $($mx.Preference)"
    
    # Her MX hostname için A kaydını da kontrol et
    $aRecord = Resolve-DnsName -Name $mx.NameExchange -Type A -Server "8.8.8.8" -ErrorAction SilentlyContinue
    if ($aRecord) {
        Write-Host "  -> A Kaydı: $($aRecord.IPAddress)" -ForegroundColor Green
    } else {
        Write-Host "  -> A Kaydı BULUNAMADI!" -ForegroundColor Red
    }
}

SPF, DKIM ve DMARC ile MX İlişkisi

MX kaydı tek başına yeterli değil. Günümüzde deliverability için şu kayıtların da eksiksiz olması gerekiyor:

  • SPF (TXT kaydı): Hangi IP’lerin bu domain adına mail gönderebileceğini tanımlar
  • DKIM (TXT kaydı): Mail imzalama için public key’i yayınlar
  • DMARC (TXT kaydı): SPF ve DKIM başarısız olduğunda ne yapılacağını tanımlar
# SPF kaydı örneği
# _spf.company.com TXT "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all"

# DMARC kaydı örneği
# _dmarc.company.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100"

# Bu kayıtları PowerShell ile sorgula
Resolve-DnsName -Name "_dmarc.company.com" -Type TXT
Resolve-DnsName -Name "company.com" -Type TXT | Where-Object {$_.Strings -like "v=spf1*"}

Sonuç

MX kaydı mail altyapısının bel kemiği. Doğru kurulmuş bir MX yapısı; doğru A kaydı, PTR kaydı ve tutarlı TTL yönetimiyle desteklendiğinde mail trafiği sorunsuz akar. Active Directory ortamında internal ve external DNS ayrımına özellikle dikkat etmek, split-brain kurgusunu doğru yönetmek ve AD replikasyon gecikmelerini göz önünde bulundurmak gerekiyor.

Değişiklik yapmadan önce her zaman mevcut durumu belgele, TTL’i erkiden düşür ve değişiklik sonrasında birden fazla araçla doğrulama yap. Mail altyapısında “sanırım çalışıyor” yeterli değil, “test ettim, çalışıyor” olmalı. PTR kaydını unutma, MX’i CNAME’e yönlendirme ve her zone değişikliğinde replikasyonu kontrol et. Bu üç altın kuralı uygularsan mail altyapısı kaynaklı gece yarısı çağrılarından büyük ölçüde kurtulursun.

Yorum yapın