Microsoft 365 için MX ve SPF Kayıtları Nasıl Yapılandırılır?

Microsoft 365'e geçiş yaparken posta akışının kesintisiz çalışması, doğru sırayla yapılandırılmış DNS kayıtlarına bağlıdır. MX kaydını yanlış öncelikte eklemek ya da SPF sözdizimini eksik bırakmak, gelen iletilerin kaybolmasına veya giden iletilerin spam klasörüne düşmesine neden olabilir. İki kayıt birbirinden bağımsız çalışmaz; MX trafiği yönlendirirken SPF gönderen sunucuyu yetkilendirir.

Yeni bir Microsoft 365 aboneliği başlatırken yönetim merkezi hangi DNS kayıtlarını eklemeniz gerektiğini listeler. Bu listeye MX, SPF (TXT kaydı biçiminde), DKIM için iki CNAME ve Autodiscover için bir CNAME girer. Sıralama önemlidir; özellikle mevcut bir posta sistemi varken geçiş yapıyorsanız, yanlış adım sırası posta akışında boşluk yaratır.

MX yönü belirler, SPF gönderen IP'yi yetkilendirir. İkisini aynı anda, yanlış sırayla değiştirmek posta kuyruğunu iki taraftan da keser. DKIM ile DMARC da kısaca değinilecek; ancak bu iki kayıt ayrı bir yapılandırma konusudur.

MX kaydı ne yapar ve Microsoft 365 değeri nedir?

MX (Mail Exchanger) kaydı, bir domain'e gelen postaların hangi sunucuya iletileceğini belirtir. Bir ileti gönderildiğinde alıcı sunucu önce MX kaydını sorgular ve bulduğu adresi hedef olarak kullanır. Kaydın içinde iki alan önemlidir: öncelik (priority) değeri ve sunucu adresi.

Microsoft 365 için MX kaydı şu biçimi alır:

MX 10 <domain>.mail.protection.outlook.com

Buradaki <domain> kısmı, yönetim merkezinde size özel olarak atanan değerdir; contoso-com gibi nokta yerine tire kullanılmış bir ad olur. Öncelik değeri olarak 10 yaygın kullanılır. Başka bir MX kaydı yoksa sayının önemi yoktur; birden fazla MX varsa en düşük sayı birincil sunucu anlamına gelir.

Bazı kuruluşlar spam filtresi gibi bir ara ağ geçidi kullanır ve bu geçidin MX kaydını birincil yaparak Microsoft 365 adresini ikincil konuma çeker. Bu mimari çalışır; ancak ara katman doğru yapılandırılmazsa SPF doğrulamasını bozabilir. Ara katmansız bir kurulumda Microsoft 365 MX kaydını tek giriş noktası olarak tutmak daha sorunsuz bir yapı sağlar.

SPF kaydı: Microsoft 365 için doğru sözdizimi

SPF (Sender Policy Framework), bir domain adına posta göndermeye yetkili sunucuları listeleyen TXT kaydıdır. Alıcı sunucu gelen iletinin geldiği IP adresini SPF kaydındaki listeyle karşılaştırır; eşleşme yoksa iletiyi şüpheli işaretleyebilir ya da reddedebilir.

Microsoft 365 için minimum SPF kaydı şudur:

v=spf1 include:spf.protection.outlook.com -all

include:spf.protection.outlook.com ifadesi Microsoft'un sunucu havuzunu SPF'ye dahil eder. Sonundaki -all etiketi listede olmayan her kaynağı reddeder (hard fail). ~all yazmak da yaygındır; bu yumuşak bir başarısızlık bildirir ve iletiyi reddetmek yerine şüpheli olarak etiketler. Güvenlik açısından -all daha kesindir, ancak altyapınızda listelenmeyen meşru bir kaynak varsa iletiler kaybolabilir.

Mevcut bir SPF kaydı varsa yeni include direktifini oraya ekleyin, ayrı bir TXT kaydı oluşturmayın. Bir domain için birden fazla SPF TXT kaydı tanımlamak RFC standardına aykırıdır ve doğrulama başarısızlığına yol açar; tüm kaynaklar tek kayıt içinde birleştirilmelidir.

Üçüncü taraf bir servis de bu domain adına ileti gönderiyorsa o servisin SPF bloğunu aynı kayda ekleyin. Örneğin bir e-posta pazarlama aracı kullanıyorsanız o araçtan alacağınız include ifadesini Microsoft 365'inkiyle yan yana yerleştirin. SPF kaydındaki toplam DNS sorgu sayısı 10'u aşmamalıdır; aksi halde lookup limiti kaydı sessizce düşürür; bu sınır aşılırsa doğrulama başarısız olur.

Geçiş öncesi TTL yönetimi

TTL'yi önceden düşürün. Mevcut bir posta sisteminden Microsoft 365'e geçiyorsanız, MX kaydını değiştirmeden birkaç gün önce TTL değerini düşürün; çoğu DNS sağlayıcısında varsayılan TTL 3600 saniye veya daha uzundur, bunu 300 saniyeye (beş dakika) indirin ve mevcut TTL süresi kadar bekleyerek bir propagasyon döngüsünün tamamlanmasını sağlayın.

TTL düşük haldeyken MX kaydını değiştirin. Bir sorun çıkarsa eski kaydı hızla geri alabilirsiniz çünkü değişiklik beş dakika içinde yayılır. Geçiş tamamlandıktan sonra TTL'yi tekrar yükseltin.

Bu adımı atlamak neden sorun yaratır? Yüksek TTL'de çalışan bir DNS önbelleği eski MX kaydını bir saate kadar tutabilir ve bu süre boyunca bazı iletiler eski sunucuya gelir. Posta sunucusu taşınırken DNS kesintisini önlemek için bu propagasyon penceresini iyi hesaplamak gerekir; özellikle iş saatleri içindeki geçişlerde zamanlama kritiktir.

Geçiş sırası: hangi kaydı önce değiştirirsiniz?

SPF kaydını MX'ten önce ekleyin. Mantık şudur: SPF, gönderilen iletilerin kimliğini doğrular. Siz Microsoft 365 üzerinden ileti göndermeye başlar başlamaz alıcı sunucular SPF'yi kontrol eder; MX henüz değişmemiş olsa bile kullanıcılar Microsoft 365'ten ileti gönderebilir ve SPF eksikse o iletiler spam damgası yiyebilir.

Sıralama şöyle işler:

1. TTL'yi düşürün ve propagasyon için bekleyin.
2. SPF kaydını TXT olarak ekleyin ya da güncelleyin.
3. DKIM'i Microsoft 365 yönetim merkezinden etkinleştirin.
4. MX kaydını Microsoft 365 adresine yönlendirin.
5. Eski MX kaydını silin ya da önceliğini düşürün.
6. Geçiş sonrası doğrulama yapın.

Bazı yöneticiler eski ve yeni MX kaydını eş zamanlı bırakır; eski kaydın önceliğini yükselterek (sayıyı artırarak) onu ikincil yapar. Bu yaklaşım ileti kayıplarını önler, ancak eski sunucuya gelen iletileri Microsoft 365'e aktarma sorumluluğu da doğurur. DNS geçiş planlaması konusunda benzer ilkeler geçerlidir: eski ve yeni sistemi çakışma yaratmadan aynı anda işletebilmek iyi bir hazırlık ister.

DKIM ve DMARC: SPF'nin yetmediği durumlar

SPF tek başına kimlik sahteciliğine karşı yeterli değildir. SPF yalnızca zarfın "From" adresini (MAIL FROM) kontrol eder, başlıktaki "From" alanını değil. Bu fark, bir iletinin SPF doğrulamasından geçmesine karşın kullanıcının gördüğü gönderici adresinin sahte olmasına izin verir.

DKIM (DomainKeys Identified Mail) iletiyi kriptografik imzayla doğrular. Microsoft 365 yönetim merkezinde DKIM'i etkinleştirdiğinizde size iki CNAME kaydı verilir; bu kayıtları DNS'e ekledikten sonra DKIM otomatik olarak çalışmaya başlar. CNAME kullanımı, Microsoft'un imzalama anahtarını döndürmesine ve sizin herhangi bir işlem yapmaksızın güncel kalmasına olanak tanır.

DMARC ise SPF ve DKIM'i bir araya getiren üst katman politikasıdır; bir iletinin SPF ya da DKIM ile hizalanıp hizalanmadığını kontrol eder ve başarısız durumlarda ne yapılacağını belirler: yalnızca rapor al, karantinaya al veya reddet. DMARC kaydı da TXT tipinde eklenir:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none ile başlamak güvenlidir; raporları izlersiniz, posta akışına dokunmazsınız. Raporlarda sorun görmezseniz politikayı quarantine ya da reject seviyesine çekebilirsiniz.

Kayıtlar yayıldı mı? Doğrulama adımları

MX kaydını değiştirdikten sonra yayılımın tamamlanıp tamamlanmadığını sorgulamalısınız. Komut satırında nslookup -type=MX example.com veya dig MX example.com çalıştırarak Microsoft 365 adresini görüyor musunuz diye bakın. Farklı ağlardan ya da farklı DNS sunucularından aynı sorguyu yapmak propagasyonun hangi noktada olduğunu gösterir.

SPF için dig TXT example.com çalıştırın ve dönen TXT kayıtlarında v=spf1 ile başlayan bir satır olduğunu doğrulayın. Birden fazla SPF kaydı görmemelisiniz; varsa bunları tek kayıtta birleştirin.

DKIM doğrulaması için Microsoft 365 yönetim merkezindeki DKIM sayfasına bakın; CNAME kayıtları doğru eklendikten sonra durum "Etkin" olarak görünür. Durum bekleme gösteriyorsa propagasyonun tamamlanması için birkaç saat daha bekleyin. Anycast DNS altyapısı kullanan büyük sağlayıcılarda propagasyon çoğu durumda çok hızlı tamamlanır, ancak TTL süresi belirleyici olmaya devam eder.

Gerçek dünya testi en güvenilir doğrulamadır: Microsoft 365 hesabından harici bir adrese ileti gönderin ve alıcı sunucunun başlıklarında dkim=pass ile spf=pass ifadelerini arayın. Gmail gibi servisler "Ham mesajı göster" seçeneğiyle tam başlığı sunar.

Sık yapılan hatalar ve etkileri

İlk yaygın hata, eski posta sisteminin SPF kaydını silmeden Microsoft 365'inkini eklemektir. Geçiş döneminde eski sistemi de kullanmayı planlıyorsanız eski sunucu bloğunu SPF'de tutun; sildiğinizde eski sistemden gönderilen iletiler SPF'den geçemez.

İkinci hata, -all yerine +all kullanmaktır. Herhangi bir sunucunun bu domain adına ileti göndermesine izin veren bu değer SPF'yi işlevsiz kılar; genellikle test sırasında yazılır ve sonradan düzeltilmez.

Üçüncü hata, DNS sağlayıcısının TXT arayüzünde gereksiz tırnak işareti ya da fazladan boşluk bırakmaktır. Bazı paneller SPF değerini otomatik olarak tırnak içine alır; siz de el ile tırnak eklerseniz çift katmanlı tırnak oluşur ve kayıt geçersizleşir.

Split-horizon DNS kullanan kuruluşlarda iç ağdaki istemciler farklı bir MX kaydı görüyor olabilir. Microsoft 365'e geçişte bu yapıyı göz ardı etmek, iç kullanıcıların iletilerinin eski sunucuya yönlenmeye devam etmesine neden olabilir; iç DNS zone'undaki MX kaydını da güncellemeniz gerekir.

CNAME flattening desteği olmayan sağlayıcılarda apex domain için CNAME ekleyemezsiniz. Microsoft 365'in Autodiscover CNAME kaydı autodiscover.example.com için eklenir, yani alt domain düzeyindedir ve apex kısıtından etkilenmez. Ancak bazı sağlayıcıların kendi sınırları olduğundan, CNAME ekleme adımında sorunla karşılaşırsanız sağlayıcınızın destek dökümanlarını inceleyin.

Microsoft 365 için MX ve SPF kayıtlarını doğru sırayla yapılandırmak, geçiş sırasındaki posta akışını güvence altına alır. SPF'yi önce ekleyip TTL'yi önceden düşürmek, hataları hızla düzeltme imkânı tanır; DKIM ve DMARC eklenmeden yapı tamamlanmış sayılmaz, bu iki katman özellikle domain sahteciliğine karşı koruma sağlar.

Yapılandırma tamamlandıktan sonra en az bir tam TTL döngüsü boyunca posta başlıklarını izleyin. SPF ya da DKIM başarısızlıkları genellikle geçiş sonrası ilk 24 saat içinde ortaya çıkar ve başlık incelemesiyle hızla tespit edilebilir.