Exchange DNS Kayıtları Nedir?

Domain doğrulama, MX ve Autodiscover farklı görevleri yerine getirir

Microsoft 365’e özel alan adı eklendiğinde hizmet önce DNS’e verilen TXT kaydıyla domain sahipliğini doğrular. Bu doğrulama postayı henüz Microsoft 365’e yönlendirmez. Kullanıcı ve posta kutuları hazırlanıp geçiş planı tamamlandığında MX kaydı, yeni gelen iletileri Exchange Online Protection hedeflerine gönderecek şekilde değiştirilir. MX önceliğinde düşük sayı genellikle daha yüksek önceliği ifade eder; birden fazla MX varsa eski veya istenmeyen hedefin hâlâ seçilip seçilemeyeceği kontrol edilir. Microsoft 365 yönetim merkezinin her tenant ve domain için gösterdiği gerçek hedef değer kopyalanmalıdır; internetteki örnek domain değerleri kullanılmaz. DNS sağlayıcısındaki host alanının kök domaini nasıl ifade ettiği de sağlayıcıya göre değişebilir.

Autodiscover CNAME, desteklenen Outlook istemcilerinin kullanıcı e-posta adresinden hizmet yapılandırmasını bulmasına yardımcı olur. MX doğru olsa bile Autodiscover yanlışsa kullanıcı posta alabilir ancak profil oluşturma, serbest/meşgul veya mobil kurulum sorunları yaşayabilir. Microsoft 365 bağlantısı sırasında Teams, Intune veya başka hizmetler için ek CNAME ve SRV kayıtları gösterilebilir; yalnızca kullanılan hizmetlerin güncel yönetim merkezi değerleri uygulanır. DNS kayıtları public authoritative nameserver üzerinde değiştirilir; yalnızca şirket içi DNS’e eklenen kayıt internet posta akışını değiştirmez. Split DNS veya hibrit yapı varsa iç ve dış çözümleme sonuçları ayrı test edilir. Her kayıt için ad, tür, hedef, öncelik, TTL, mevcut değer ve değişiklik sahibi tablo halinde tutulur.

TXT doğrulama

Alan adının Microsoft 365 tenantına eklenmesine yetki veren sahiplik kanıtıdır.

MX

İnternetten gelen e-postanın teslim edileceği posta güvenlik ve alıcı sistemini belirler.

Autodiscover

Desteklenen istemcilerin posta kutusu hizmet ayarlarını otomatik bulmasına yardımcı olur.

TTL

Resolverların bir DNS yanıtını yeniden sorgulamadan önce ne kadar önbellekte tutabileceğini belirtir.

Authoritative DNS

Alan adı için internetin güvenilir kabul ettiği gerçek kayıt kaynağıdır.

SPF, DKIM ve DMARC birlikte gönderen alan adının güvenini oluşturur

SPF, alan adı adına hangi sunucu ve servislerin e-posta göndermesine izin verildiğini TXT kaydıyla açıklar. Domain kökünde birden fazla ayrı SPF kaydı yayınlamak geçerli bir birleştirme yöntemi değildir; Microsoft 365, web sitesi, CRM, bilet sistemi ve toplu gönderim servisleri tek politika içinde dikkatle toplanır. Include zinciri ve DNS sorgu sayısı SPF standardının sınırlarına ulaşabilir. Gereksiz eski kaynaklar kaldırılır, sabit IP ile gönderim yapan sistemlerin gerçekten o IP’den çıkıp çıkmadığı doğrulanır. SPF yalnızca envelope sender veya return-path alanını değerlendirir; kullanıcının gördüğü From başlığıyla hizalama sağlamadığında DMARC için tek başına yeterli değildir. Shared servislerde tenantın veya sağlayıcının güncel SPF yönergesi kullanılmalıdır.

DKIM, gönderilen mesaj başlık ve gövdesinin bir bölümünü özel anahtarla imzalar; alıcı, public DNS’te yayınlanan seçici kaydıyla imzayı doğrular. Exchange Online’da tenant için gösterilen selector CNAME değerleri eklenir ve ardından imzalama etkinleştirilir. Anahtar rotasyonu ve iki selector kullanımı operasyon planına dahil edilir. DMARC, görünen From domaini ile SPF veya DKIM kimliğinin hizalanmasını değerlendirir; none, quarantine veya reject politikası yanında rapor adresleri ve alt domain davranışı tanımlanabilir. Güçlü politikaya doğrudan geçmeden önce meşru gönderim kaynakları raporlarla bulunur, SPF ve DKIM düzeltilir, ardından politika kademeli sıkılaştırılır. DMARC rapor adresi dış domaindeyse ek yetkilendirme kaydı gerekebilir. Raporlar kişisel posta kutusunda unutulmamalı, merkezi analiz ve sahiplik süreciyle izlenmelidir.

• Microsoft 365 dışında alan adınız adına gönderen web, CRM, yazıcı ve toplu gönderim servislerini envanterleyin.
• Tek SPF politikasında yalnızca aktif kaynakları tutun ve include zincirinin DNS sorgu etkisini ölçün.
• Exchange Online yönetim merkezinin verdiği gerçek DKIM selector hedeflerini kullanın.
• DMARC politikasını rapor gözlemi, kaynak düzeltmesi ve kontrollü sıkılaştırma aşamalarıyla ilerletin.
• SPF, DKIM ve DMARC sonuçlarını yalnız test e-postasıyla değil gerçek başlık ve rapor verisiyle doğrulayın.

Geçiş sırası ve TTL planı posta kesintisini önler

MX değişikliği, bütün yeni postanın yönünü etkileyen canlı bir kesimdir. Önce kullanıcı hesapları, lisanslar, primary ve alias adresleri, shared mailboxlar, distribution grupları, transport kuralları, connectorlar ve mevcut arşiv gereksinimleri hazırlanır. DNS TTL değeri geçişten makul süre önce planlanan seviyeye indirilebilir; değişiklik anında düşürmek eski önbellekleri geriye dönük kısaltmaz. Eski sağlayıcı geçiş süresince posta kabul etmeye devam ediyorsa iki taraftaki teslimat ve forward davranışı netleştirilir. MX’in iki platforma aynı öncelikle bırakılması posta kutularının rastgele bölünmesine yol açabilir. Cutover sonrasında yalnız web tabanlı MX sorgusu değil, farklı resolverlardan DNS yanıtı, Exchange message trace ve dış kaynaklı gerçek gönderim testleri kontrol edilir.

Hibrit Exchange yapısında Autodiscover, accepted domain, connector, sertifika, OAuth ve merkezi posta akışı gibi bağımlılıklar vardır; yalnız MX değişimiyle hibrit tasarım tamamlanmaz. Üçüncü taraf secure email gateway kullanılıyorsa MX önce gateway’e, gateway ise doğrulanmış connector üzerinden Microsoft 365’e yönlenebilir. SPF politikasına gerçek outbound çıkış kaynağı eklenir; DKIM imzasını hangi sistemin attığı ve DMARC hizalaması test edilir. Yazıcı ve uygulamaların eski SMTP sunucusuna veya doğrudan relay’e bağlı olduğu görülürse modern kimlik doğrulama, connector veya uygun relay modeli ayrıca planlanır. Geçiş geri dönüşü; eski MX hedefi, gerekli TTL, posta kutusu senkron durumu ve iki sistemde oluşabilecek yeni iletilerin nasıl birleştirileceğiyle birlikte yazılmalıdır.

Hazırlık

Kullanıcı, adres, grup, connector ve gönderim kaynaklarının MX değişiminden önce tamamlanmasıdır.

TTL penceresi

DNS önbelleğinin geçiş ve geri dönüş süresine etkisinin önceden planlanmasıdır.

Cutover

Yeni gelen postanın kontrollü biçimde hedef platforma yönlendirildiği kesim adımıdır.

Message trace

Microsoft 365 içindeki kabul, işleme ve teslimat adımlarını kayıt üzerinden doğrular.

Rollback

DNS, posta akışı ve yeni veri etkisini birlikte geri alabilecek belgeli plandır.

DNS değişiklik yönetimi ve sürekli izleme, sessiz posta kayıplarını erken yakalar

DNS kayıtları bir kez eklenip unutulacak ayarlar değildir. Domain yenileme tarihi, nameserver değişikliği, DNSSEC durumu, MX hedefi, Autodiscover cevabı, SPF geçerliliği, DKIM selectorları ve DMARC politikası periyodik olarak izlenir. Servis sağlayıcısı değiştiğinde eski SPF include veya DKIM kayıtları kaldırılmadan önce gönderim trafiği ve saklama ihtiyacı doğrulanır. CNAME hedefinin kaldırılması ya da tenant domaininin değişmesi, kayıt görünürken işlevi bozabilir. DNS yönetim hesabı MFA ile korunur, değişiklik yetkisi sınırlanır ve zone export veya kayıt envanteri ayrı saklanır. Kritik domainlerde beklenmeyen MX, TXT veya nameserver değişikliği için alarm oluşturulur. Domain ele geçirilmesi yalnız web sitesini değil, e-posta kimliğini ve parola sıfırlama akışlarını da etkiler.

Operasyon testi farklı bir dış sağlayıcıdan gönderim ve alım, Outlook Autodiscover, SPF/DKIM/DMARC header sonucu, DMARC aggregate rapor trendi, bounce kodu ve message trace verisini kapsar. Bir test aracının yeşil sonuç vermesi bütün gönderim kaynaklarının doğru olduğu anlamına gelmez. Özellikle fatura, rezervasyon, ERP, web formu ve kampanya servisleri farklı return-path veya imza domaini kullanabilir. Teslimat sorunu oluştuğunda DNS değişim zamanı, TTL, message ID, gönderen IP, authentication-results başlığı ve alıcı hata kodu aynı olay kaydında toplanır. Böylece “mail gitmiyor” şikayeti tahminle değil, yönlendirme, kimlik doğrulama, reputation veya alıcı politikası katmanında somut kanıtla ayrıştırılır.

• MX, Autodiscover, SPF, DKIM, DMARC, nameserver ve domain sürelerini merkezi envanterde izleyin.
• DNS yönetim hesabını MFA ve rol ayrımıyla koruyun; zone değişikliklerini denetim kaydına alın.
• Beklenmeyen MX, TXT, DKIM veya nameserver değişikliklerinde otomatik uyarı üretin.
• Gerçek gönderim kaynaklarını DMARC raporu ve mail header sonuçlarıyla düzenli karşılaştırın.
• Sorun kaydında message ID, gönderen IP, DNS cevabı, authentication sonucu ve bounce kodunu birlikte tutun.