Microsoft 365 DNS kurulumu: MX, SPF, DKIM, autodiscover ve DMARC

Adımlar

1. Alan adını ekleyip doğrulayın. Microsoft 365 yönetim merkezinde alan adını ekleyin ve gösterdiği doğrulama TXT kaydını (MS= ile başlar) yayımlayın.
2. Posta kutularını oluşturup lisans atayın. E-posta alacak her adres için MX taşınmadan önce bir posta kutusu, paylaşılan posta kutusu, grup ya da takma ad bulunmalıdır.
3. MX kaydını yayımlayın. MX sunucu adını yönetim merkezinden kopyalayın. Alan adınızdan türetilir ve mail.protection.outlook.com ile, gelen postada DNSSEC koruması açık alan adlarında ise mx.microsoft ile biter. Öncelik 0 olmalı, başka MX kaydı kalmamalıdır.
4. SPF’i yayımlayın. Alan adının köküne tek bir TXT kaydı ekleyin: v=spf1 include:spf.protection.outlook.com -all. Diğer göndericileri aynı kayda ekleyin.
5. DKIM’i açın. selector1._domainkey ve selector2._domainkey adlı iki CNAME kaydını, Defender portalının alan adınız için gösterdiği hedeflerle yayımlayın; çözümlendiklerini görünce alan adı için imzalamayı etkinleştirin.
6. Autodiscover ve DMARC ekleyin, kontrol edin. Outlook’un posta kutusunu bulabilmesi için autodiscover CNAME kaydını yayımlayın, p=none ile bir DMARC kaydı ekleyin, ardından bu sayfadaki kontrolleri çalıştırın.

DMARC

DMARC her sağlayıcıda aynıdır: _dmarc.example.com adında tek bir TXT kaydı. p=none ve bir rapor adresiyle başlayın; böylece teslimatı etkilemeden rapor almaya başlarsınız.

Raporları birkaç hafta okuyun. Adınıza e-posta gönderen bütün meşru kaynaklar alan adınızla hizalı biçimde SPF ya da DKIM’den geçiyorsa önce p=quarantine, sonra p=reject’e geçin. Meşru e-postaların kaybolmasının en sık nedeni, bütün göndericilerde DKIM açılmadan reject’e geçilmesidir.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

İsteğe bağlı: MTA-STS, TLS-RPT ve BIMI

MTA-STS, size e-posta teslim eden sunuculara TLS’i zorunlu tutmalarını söyler. Bir TXT kaydı ve mta-sts.example.com adresinde HTTPS ile sunulan bir politika dosyası gerekir; politikada sağlayıcınızın MX sunucuları birebir yazmalıdır.

TLS-RPT, göndericilerden TLS teslimat hatalarını seçtiğiniz adrese raporlamalarını ister. Tek bir TXT kaydıdır, teslimatı etkilemez.

BIMI, bazı e-posta sağlayıcılarının logonuzu göstermesini sağlar. DMARC’ın quarantine ya da reject olması gerekir; sağlayıcıların çoğu ayrıca doğrulanmış marka sertifikası ister.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

E-posta istemcileri: autodiscover ve autoconfig

Outlook, posta kutusunu autodiscover.example.com → autodiscover.outlook.com CNAME kaydı üzerinden bulur. Bu kayıt yoksa masaüstü Outlook sunucu ayarlarını sorabilir ya da o ad altında hâlâ yanıt veren eski bir yerel sunucuya bağlanabilir.

TTL önerisi

Hâlihazırda e-posta alan bir alan adında MX kayıtlarını değiştirmeden önce TTL değerini 300 saniyeye indirin ve eski TTL süresinin dolmasını bekleyin. Böylece çözümleyiciler yeni kayıtları dakikalar içinde alır.

Yeni kurulum birkaç gün sorunsuz çalıştıktan sonra TTL’i yeniden yükseltin; 3600 saniye yaygın bir değerdir. SPF, DKIM ve DMARC kayıtları seyrek değişir, 3600 onlar için uygundur.

Değişiklikler ne kadar sürede görünür?

DNS sağlayıcınız kaydı yayımladığı anda yetkili nameserver’larınız yeni yanıtı verir. Eski yanıtı önbelleğine almış bir çözümleyici onu eski TTL dolana kadar tutar; daha önce hiç var olmamış bir ad ise SOA kaydınızdaki negatif önbellek süresi boyunca "yok" olarak hatırlanabilir.

Bir değişikliğin her yerde aynı anda geçerli olduğu bir an yoktur. Yayılım aracı, belirli bir genel çözümleyici kümesinin kontrol anında ne yanıt verdiğini "12 çözümleyiciden 9’u" gibi bir sayıyla gösterir; bundan fazlasını söylemez.

Sağlayıcılar kayıtlarınızı kendi takvimlerine göre yeniden kontrol eder; bu yüzden DNS doğru olduğu hâlde paneldeki doğrulama bir süre daha kırmızı kalabilir.

Sık yapılan hatalar

• MX sunucu adını ya da DKIM hedeflerini elle oluşturmak. Tek karakterlik fark doğrulamanın başarısız olmasına yeter.
• İki CNAME kaydı çözümlenmeden DKIM’i etkinleştirmeye çalışmak: portal reddeder ve e-postalar onmicrosoft.com alan adıyla imzalanmaya devam eder; bu da DMARC için hizalanmaz.
• İki SPF kaydı. Bir alan adında v=spf1 ile başlayan yalnızca bir TXT kaydı olabilir; ikincisi SPF’in kalıcı hatayla başarısız olmasına yol açar. include: ifadelerini tek kayıtta birleştirin.
• Eski sağlayıcının MX kayıtlarını yenilerin yanında bırakmak. E-posta o zaman önceliğe ve şansa göre ikisinden birine teslim edilir.
• Alan adını kendisi ekleyen bir ad alanına tam adı yazmak; sonuç google._domainkey.example.com.example.com olur. Kaydı kaydettikten sonra sorgulayıp bakın.
• Yarıda kesilmiş DKIM anahtarı. Uzun TXT değerleri en çok 255 karakterlik tırnaklı parçalara bölünmelidir; DNS panellerinin çoğu bunu kendisi yapar, bazıları yapmaz.
• Birkaç include: ekledikten sonra SPF’te onu aşan DNS sorgusu. SPF kontrol aracı bunları sayar.
• Bir CNAME’e ya da IP adresine işaret eden MX kaydı. MX, A ya da AAAA kaydı olan bir sunucu adına işaret etmelidir.