Microsoft 365 DNS Kayıtları: MX, SPF, DKIM ve Autodiscover Kurulumu

Microsoft 365 yönetim merkezinde alan adınızın satırında turuncu bir uyarı duruyor: "Kurulum tamamlanmadı." Kayıtları eklediğinizden eminsiniz — MX yerinde, SPF yerinde — sihirbaz yine de yeşile dönmüyor. Ya da daha sinsi olan ikinci tablo: kurulum yeşil, mailler gidip geliyor, ama Defender portalındaki DKIM ekranında alan adınızın karşısında "Etkinleştirilmedi" yazıyor ve dışarı çıkan her ileti imzasız gidiyor. Üçüncüsü klasiktir: yeni çalışan Outlook'a hesabını ekler, program "hesap ayarlarınız bulunamadı" der ve sunucu adı sorar.

Üçü de Microsoft 365'in DNS tarafında Google Workspace'ten ayrıldığı noktalarda yoğunlaşıyor. En çok yanlış anlaşılan dört fark şunlar: doğrulama kaydı MS= ile başlayan kendine özgü bir TXT'dir, MX hedefi alan adınıza özel üretilir ve tahmin edilmemelidir, DKIM bir TXT değil iki CNAME'dir ve yayınlandıktan sonra ayrıca panelden açılması gerekir, autodiscover CNAME'i ise istemci kurulumunu neredeyse tek başına taşır.

Aşağıda bu kayıtları sırayla, hangi alana tam olarak ne yazacağınız düzeyinde ele alacağız; ardından sihirbazın listelediği hâlde çoğu kurumda gereksiz olan kayıtları ayıklayıp dig ile uçtan uca doğrulama yapacağız.

Microsoft 365'in İstediği Kayıtlar ve Hangileri Gerçekten Zorunlu#

Kayıtları hangi panele yazacağınız ayrı bir konu ve cevabı tek satırdır: alan adının nameserver'ları nereyi gösteriyorsa kayıtlar orada yaşar. dig NS ornek.com +short çıktısındaki sunucular hangi firmaya aitse DNS bölgeniz o firmanın panelindedir. Panel seçiminin ayrıntısı ve "ekledim ama görünmüyor" senaryosu Google Workspace DNS kurulumu yazısında var; burada doğrudan Microsoft'a özgü kayıtlara giriyoruz.

Microsoft'un dokümantasyonu MX dışındaki her şeyi "isteğe bağlı" diye işaretler. Teknik olarak doğrudur — posta yalnızca MX ile de akar — ama operasyonel olarak yanıltıcıdır: SPF ve DKIM olmadan gönderdiğiniz iletiler Gmail ve Outlook.com tarafında spam'e düşer. Tablodaki ilk yedi satırı zorunlu kabul edin.

MS= ile Başlayan Doğrulama TXT Kaydı Nasıl Eklenir#

Microsoft, alan adının gerçekten sizin olduğunu görmeden hiçbir hizmeti bağlamaz. Admin merkezi size MS= önekiyle başlayan kısa bir dize verir; bunu kök alan adına TXT olarak eklersiniz.

ornek.com.   3600  IN  TXT  "MS=ms12345678"

Dikkat edilecek iki nokta var. Birincisi, tırnak işaretlerini siz yazmayın — değeri tırnaklamak panelin işidir, elle eklediğinizde bazı paneller tırnağı değerin parçası sayar ve doğrulama sonsuza kadar başarısız olur. İkincisi, doğrulama tamamlandıktan sonra kaydı silmeyin; Microsoft sahipliği periyodik olarak yeniden kontrol eder ve kayıt yoksa alan adı doğrulanmamış duruma düşerek kullanıcı ekleme gibi işlemleri kilitler.

Bu aşamada kiracınızın ornek.onmicrosoft.com biçimindeki başlangıç alan adını da not alın; DKIM adımında bu ad hedef değerin içinde geçecek.

# Doğrulama kaydı yayında mı?
dig TXT ornek.com +short | grep -i 'MS='

Doğrulama yönteminin genel mantığı ve alternatifleri için TXT ile alan adı doğrulama yazısına bakabilirsiniz.

MX Kaydı: Hedef Size Özel, Öncelik 0, TTL 6 Saatin Altında#

Microsoft her müşteri alan adı için otomatik bir MX hedefi üretir. Kural basittir: alan adındaki noktalar tireye çevrilir ve sonuna .mail.protection.outlook.com eklenir. ornek.com için hedef ornek-com.mail.protection.outlook.com, ornek.com.tr için ornek-com-tr.mail.protection.outlook.com olur.

ornek.com.tr.   3600  IN  MX  0  ornek-com-tr.mail.protection.outlook.com.

Kuralı bilmek hedefi elle yazmanız gerektiği anlamına gelmez. Değeri her zaman Ayarlar → Etki alanları → alan adınız → DNS kayıtları ekranından kopyalayın; üretilen ad bu kalıptan sapabilir ve tek harflik fark tüm postayı düşürür.

İki ayar sık atlanır:

• Öncelik 0 olmalı. MX'te düşük sayı yüksek önceliktir; 0 "en yüksek öncelik" demektir. Panel öncelik alanını boş bırakmanıza izin veriyorsa yine de 0 yazın, boş bırakılan alan bazı panellerde 10 olarak kaydedilir.
• TTL 6 saatin altında olmalı. Exchange Online, 21.600 saniyeden (6 saat) büyük TTL değerlerini desteklemez. Birçok panelin varsayılanı 86.400'dür (24 saat); bu değeri düşürmeden bıraktığınızda kurulum kaydı kabul etse bile Microsoft tarafında uyarı görürsünüz.

Eski sağlayıcının MX kayıtlarını silin. İkisini bir arada bırakıp eski kayda daha yüksek bir sayı vermek geçici bir yöntem olarak anlatılır; pratikte bölünmüş teslimat üretir — bazı gönderenler yedek MX'i dener ve o kullanıcının postası eski sunucuda kalır. MX önceliğinin nasıl çalıştığını MX kaydı nedir yazısında ayrıntılı bulabilirsiniz.

Sunucunuz cPanel ise DNS'i düzeltmek tek başına yetmez: cPanel postayı yerel teslim etmeye devam eder ve alan adı için bir hesap varsa mesaj sunucudan hiç çıkmaz. E-posta yönlendirmesini uzak sunucuya alma adımı Google Workspace DNS kurulumu yazısındakiyle birebir aynıdır.

dig MX ornek.com.tr +short
# beklenen: 0 ornek-com-tr.mail.protection.outlook.com.

SPF'te En Sık Yapılan Hata: İkinci Bir Kayıt Açmak#

Microsoft 365 geçişlerinde görülen bir numaralı DNS hatası budur. Alan adında zaten bir SPF kaydı vardır — hosting firmasının, e-fatura sağlayıcısının ya da eski mail sunucusunun. Sihirbaz "şu TXT kaydını ekleyin" der, siz de eklersiniz ve bölgede iki tane v=spf1 kaydı oluşur.

Bir alan adında yalnızca bir SPF kaydı olabilir. İki kayıt bulan doğrulayıcı bunları birleştirmez; sonucu permerror olarak işaretler ve SPF artık ne geçer ne kalır — DMARC değerlendirmesinde de başarısız sayılır. Yani ikinci kaydı eklediğiniz anda çalışan SPF'inizi de bozarsınız.

Yanlış:

ornek.com.  3600  IN  TXT  "v=spf1 include:_spf.eskisaglayici.com ~all"
ornek.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Doğru — tek kayıt, iki include:

ornek.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:_spf.eskisaglayici.com -all"

Birleştirirken iki kurala uyun. Kayıtta yalnızca bir tane all mekanizması bulunur ve en sonda durur; ortada kalan ~all mutlaka silinmelidir. İkincisi ve daha önemlisi: SPF'in 10 DNS sorgusu limiti vardır, her include en az bir sorgu harcar ve spf.protection.outlook.com kendi içinde de dallanır. Limit dolduğunda kayıt yine permerror verir; sayımı ve çözüm yollarını SPF 10 DNS lookup limiti yazısında anlatıyoruz.

Geçiş sırasında -all yerine ~all ile başlamak makul bir seçimdir: unuttuğunuz bir gönderen varsa iletiler reddedilmek yerine işaretlenir. İki hafta sürpriz çıkmıyorsa -all seviyesine sertleştirin.

# Kaç tane SPF kaydı var? Cevap 1 olmalı.
dig TXT ornek.com +short | grep -c 'v=spf1'

DKIM Neden TXT Değil de İki CNAME? selector1 ve selector2#

Google Workspace'te DKIM tek bir TXT kaydıdır ve açık anahtarı (p=...) siz yayınlarsınız. Microsoft 365 bu modeli tersine çevirir: anahtar çifti Microsoft tarafında durur, siz yalnızca ona işaret eden iki CNAME yayınlarsınız. İki tane olmasının sebebi anahtar rotasyonudur — imza selector1 ile atılırken selector2 bir sonraki anahtarı taşır, rotasyon anında hiçbir ileti imzasız kalmaz.

Kayıt adları her kiracıda aynıdır:

• selector1._domainkey
• selector2._domainkey

Hedef değerler ise değişir ve burada 2025'te bir kırılma yaşandı:

Yeni biçimdeki dinamik bölüm tahmin edilemez, kiracıya göre atanır. Bu yüzden hedefi asla kalıptan türetmeyin. İnternetteki eski örneklerin çoğu birinci satırdaki biçimi gösterir ve yeni eklenen alan adlarında doğrudan yanlıştır. Değeri ya admin merkezinin DNS kayıtları ekranından kopyalayın ya da Exchange Online PowerShell'den okuyun:

Connect-ExchangeOnline -UserPrincipalName [email protected]
Get-DkimSigningConfig -Identity ornek.com |
    Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Alan adı için hiç DKIM yapılandırması oluşturulmamışsa komut boş döner. Bu durumda önce yapılandırmayı kapalı hâlde oluşturur, sonra CNAME değerlerini okursunuz:

New-DkimSigningConfig -DomainName ornek.com -Enabled $false

Değerleri aldıktan sonra kayıtlar şu şekilde yayınlanır:

selector1._domainkey.ornek.com.  3600  IN  CNAME  selector1-ornek-com._domainkey.ornek.onmicrosoft.com.
selector2._domainkey.ornek.com.  3600  IN  CNAME  selector2-ornek-com._domainkey.ornek.onmicrosoft.com.

CNAME'leri Yayınlamak Tek Başına Yetmez#

Bu, Microsoft 365 kurulumunun sessizce atlanan adımıdır ve "DNS'te her şey doğru ama mailler hâlâ imzasız" şikâyetinin kaynağıdır. CNAME'ler yayına girdikten sonra imzalamayı ayrıca açmanız gerekir:

Microsoft Defender portalı → E-posta ve iş birliği → İlkeler ve kurallar → Tehdit ilkeleri → E-posta kimlik doğrulama ayarları → DKIM → alan adınızı seçin → "Bu alan adı için iletileri DKIM imzalarıyla imzala" anahtarını açın.

Aynı işlemin PowerShell karşılığı:

Set-DkimSigningConfig -Identity ornek.com -Enabled $true

Sıra önemlidir: CNAME'ler yayılmadan etkinleştirmeyi denerseniz portal CNAME record does not exist for this config benzeri bir hata verir. Kayıtları yayınlayın, dig ile göründüklerini doğrulayın, sonra açın.

Bir ayrıntı daha: yıllar önce açılmış yapılandırmalar hâlâ 1024 bit anahtarla imzalıyor olabilir. Alıcılar bunu bugün kabul ediyor ama standart 2048 bit; rotasyonu tek komutla yaparsınız.

Rotate-DkimSigningConfig -Identity ornek.com -KeySize 2048

Microsoft tarafında anahtar CNAME ile geldiği için TXT kayıtlarının 255 karakter sınırı sizi ilgilendirmez. Ancak hibrit bir kurulumda ya da üçüncü parti bir gönderim servisinde kendi anahtarınızı TXT olarak yayınlıyorsanız o sınır geri gelir; ayrıntısı DKIM TXT kaydı 255 karakter sınırı yazısında.

dig CNAME selector1._domainkey.ornek.com +short
dig TXT   selector1._domainkey.ornek.com +short   # CNAME izlenerek anahtar görünmeli

Autodiscover CNAME'i Atlarsanız Outlook Kurulumu Elle Kalır#

Autodiscover, istemcinin sunucu adını, portunu ve protokolünü kendi bulmasını sağlayan mekanizmadır. Microsoft dokümantasyonunda "isteğe bağlı ama şiddetle önerilir" olarak geçer; sahada ise yeni kullanıcı kurulumunu tek başına taşıyan kayıt budur.

autodiscover.ornek.com.  3600  IN  CNAME  autodiscover.outlook.com.

Bu kayıtta Microsoft'a özgü üç tuzak var ve üçü de "kaydı ekledim, yine olmuyor" ile sonuçlanır.

Tuzak 1 — joker A kaydı, eksik CNAME'i maskeler. Bölgede * (wildcard) A kaydı varsa autodiscover.ornek.com sizin web sunucunuzun IP'sine çözülür; CNAME hiç eklenmemiş olsa bile bir cevap döner ve hiçbir şey eksik görünmez. Outlook o adrese HTTPS ile bağlanır, karşısında alan adını kapsamayan bir sertifika bulur ve kullanıcıya sertifika uyarısı gösterir. Belirti sertifika hatasıdır, sebep ise joker kayıttır.

Tuzak 2 — cPanel'in kendi kayıtları. cPanel bölgeye otomatik olarak autodiscover, autoconfig ve mail A kayıtlarını, ayrıca _autodiscover._tcp SRV kaydını ekler. Aynı adda hem A hem CNAME duramayacağı için CNAME eklemeniz ya reddedilir ya da eski kayıt kazanır. Microsoft 365'e geçerken bu dördünü de temizleyin.

Tuzak 3 — kök alan adı denemesi. Outlook https://ornek.com/autodiscover/autodiscover.xml adresini de dener. Web sunucunuz burada 404 dönerse sorun yok; ancak isteği askıya alan bir WAF varsa kurulum yarım dakikadan uzun sürer ve kullanıcı "donuyor" der.

dig CNAME autodiscover.ornek.com +short
# 401 dönmesi normaldir: uç nokta kimlik doğrulaması istiyor demektir
curl -s -o /dev/null -w '%{http_code}\n' https://autodiscover.ornek.com/autodiscover/autodiscover.xml

İstemci tarafındaki elle kurulum ayarlarına ihtiyaç duyarsanız Outlook ve Thunderbird kurulumu yazısı port ve SSL kombinasyonlarını içeriyor.

SRV ve Diğer Kayıtlar: Sihirbazın Listelediği Her Şey Gerekli Değil#

Admin merkezinde "Gelişmiş seçenekler"i açtığınızda karşınıza bir kayıt yığını çıkar. Çoğu kurumda bunların yarısı gereksizdir ve gereksiz kayıt, ileride hata ayıklarken sizi yanlış yöne sürükler.

SRV kaydını gerçekten eklemeniz gerekiyorsa Türkiye'deki panellerin çoğunda alan yapısı Microsoft'un anlattığından farklıdır. İki yaygın durum:

• Panelde ayrı Service ve Protocol alanları yoksa ikisini ad alanına birleştirerek yazın: _sipfederationtls._tcp
• Panelde Priority, Weight ve Port alanları yoksa hepsini hedef alanına sırayla yazın: 100 1 5061 sipfed.online.lync.com

DMARC Kaydını Baştan Ekleyin, Sonradan Değil#

SPF ve DKIM yayına girdiğinde DMARC'ı da aynı gün ekleyin; aylar sonra eklemek, o zamana kadar biriken teslimat sorunlarını hiç göremeden geçirmek demektir.

_dmarc.ornek.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

p=none hiçbir iletiyi engellemez, yalnızca rapor toplar — geçiş döneminin doğru başlangıcı budur. Raporlarda tüm meşru gönderenlerinizin hizalandığını gördükten sonra p=quarantine, ardından p=reject seviyesine çıkın. Gmail ve Yahoo'nun zorunlu tuttuğu şartlar için yeni gönderici kuralları, rapor XML'lerini okumak için DMARC raporu nasıl okunur yazılarına bakın.

dig ile Uçtan Uca Doğrulama ve Admin Merkezindeki Durum Ekranı#

Tüm kayıtları tek geçişte kontrol eden kısa bir betik:

D=ornek.com

echo "== Dogrulama ==" ;    dig TXT   "$D"                      +short | grep -i 'MS='
echo "== MX ==" ;           dig MX    "$D"                      +short
echo "== SPF ==" ;          dig TXT   "$D"                      +short | grep 'v=spf1'
echo "== DKIM 1 ==" ;       dig CNAME "selector1._domainkey.$D" +short
echo "== DKIM 2 ==" ;       dig CNAME "selector2._domainkey.$D" +short
echo "== Autodiscover ==" ; dig CNAME "autodiscover.$D"         +short
echo "== DMARC ==" ;        dig TXT   "_dmarc.$D"               +short

Panel tarafında Ayarlar → Etki alanları → alan adınız → DNS kayıtları ekranı beklenen değerle bulunan değeri yan yana gösterir. İki uyarıyı ayırt edin: "Olası hizmet sorunları" bir kaydın eksik olduğunu, "Yanlış değer" ise kaydın var olup içeriğinin uyuşmadığını söyler. İkincisi neredeyse her zaman sona eklenen bir boşluktan ya da panelin alan adını değere ikinci kez eklemesinden kaynaklanır — kaydı listede gördüğünüz hâliyle okuyun, girerken yazdığınız hâliyle değil.

Sihirbaz kaydı bulamıyorsa bir saat bekleyip tekrar deneyin; olumsuz cevaplar da önbelleğe alındığı için hemen tekrarlanan kontrol eski sonucu görebilir. Mekanizması DNS propagasyon süresi yazısında.

Son bir uyarı: admin merkezindeki yeşil tik DKIM'in açık olduğu anlamına gelmez. O ekran yalnızca DNS kayıtlarının varlığına bakar; imzalama anahtarı Defender portalında ayrı bir yerde durur. Kurulumu bitirdiğinizi düşündüğünüz gün mutlaka bir dış adrese test maili atın ve ileti başlıklarında dkim=pass gördüğünüzü doğrulayın.

Belirti → Sebep → Çözüm Tablosu#

Site bir sunucuda, posta Microsoft'ta duracaksa mail ve site farklı sunucuda DNS ayarı yazısı A ve MX kayıtlarının nasıl ayrıştığını gösteriyor.

Sıkça Sorulan Sorular#

Microsoft 365 DKIM kaydı neden TXT değil de CNAME?#

Çünkü anahtar çiftini Microsoft üretir ve kendi tarafında saklar; siz yalnızca ona işaret edersiniz. CNAME olması iki avantaj sağlar: anahtar rotasyonu sizin DNS bölgenize hiç dokunulmadan yapılabilir ve uzun anahtar değerleri panellerin TXT karakter sınırlarına takılmaz. İki selector bulunmasının sebebi de rotasyondur — biri aktif imzayı, diğeri sıradaki anahtarı taşır.

selector1 hedefini alan adımdan kendim türetebilir miyim?#

Mayıs 2025 öncesinde eklenmiş alan adlarında kalıp genellikle tutar, ama sonrasında eklenenlerde hedef kiracıya özel dinamik bir bölüm içerir ve tahmin edilemez. Doğru yaklaşım her durumda değeri admin merkezinden kopyalamak ya da Get-DkimSigningConfig çıktısındaki Selector1CNAME ve Selector2CNAME alanlarını okumaktır. Elle türetilen hedef, etkinleştirme sırasında "CNAME yok" hatası verir.

Alan adımda zaten SPF kaydı var, Microsoft'unkini nasıl ekleyeceğim?#

Yeni bir TXT kaydı açmayın. Mevcut kaydın içine include:spf.protection.outlook.com ifadesini ekleyin ve sondaki tek all mekanizmasını koruyun. Bölgede iki v=spf1 kaydı bulunması SPF sonucunu permerror yapar, yani hem yeni hem eski gönderenleriniz doğrulamayı geçemez. Ayrıca toplam DNS sorgu sayısının 10'u aşmadığını kontrol edin.

Autodiscover kaydı olmadan Microsoft 365 çalışır mı?#

Posta akışı çalışır; teslimat için MX kaydı yeterlidir. Çalışmayan şey istemci kurulumudur: Outlook, telefon uygulamaları ve üçüncü parti istemciler sunucu ayarlarını bulamaz ve kullanıcıdan elle giriş ister. Bu kaydın maliyeti tek bir CNAME, karşılığı ise her yeni kullanıcıda kazanılan bir destek çağrısıdır. Eklemeyi atlamak için pratik bir sebep yoktur.

SRV kayıtlarını eklemem gerekiyor mu?#

Yalnızca Teams'i kendi alan adınızla dış federasyonda kullanıyorsanız _sipfederationtls._tcp kaydı anlam taşır; bulut-yalnız kiracıların çoğunda Teams bu kayıt olmadan da sorunsuz çalışır. Eski rehberlerde geçen sip ve lyncdiscover CNAME'leri ise Skype Kurumsal Online'ın 2021'de kapanmasıyla tamamen işlevsiz kaldı; bugün eklemenin hiçbir karşılığı yoktur.

Kayıtları ekledim ama sihirbaz hâlâ göremiyor, ne kadar beklemeliyim?#

Kayıtların TTL'ini 3600 saniye tuttuysanız pratikte bir saat içinde görünürler. Sihirbaz kaydı daha önce sorguladıysa olumsuz cevap da önbelleğe alınmış olabilir, bu yüzden hemen tekrar denemek aynı sonucu verir. Bir saat sonra hâlâ görünmüyorsa beklemeyi bırakıp dig ile kendiniz sorgulayın: kayıt dig çıktısında yoksa sorun yayılma değil, kaydın yanlış panelde ya da yanlış adla durmasıdır.