MX Kaydı Değişti Ama E-Postalar Hâlâ Eski Sunucuya Geliyor

DNS üzerinde MX kaydını güncellediniz, yeni e-posta sunucunuzu devreye aldınız; ancak gelen iletiler hâlâ eski altyapıya düşüyor. Bu durum, kurumsal e-posta geçişlerinde karşılaşılan en yaygın ve en sinir bozucu sorunlardan biridir. Nedenini ve nasıl çözüleceğini adım adım inceliyoruz.

Sorunun Kökeni: DNS Önbelleği ve TTL

MX kaydı, bir alan adına gönderilen e-postaların hangi posta sunucusuna yönlendirileceğini tanımlar. RFC 5321 (SMTP protokolü), bir ileti teslim edilmeden önce gönderen MTA'nın (Mail Transfer Agent) hedef alan adının MX kayıtlarını sorgulaması gerektiğini açıkça belirtir. Ancak bu sorgunun sonucu, TTL (Time to Live) değeri süresince DNS sunucuları tarafından önbellekte tutulur.

Örneğin eski MX kaydınızın TTL değeri 86.400 saniye (24 saat) olarak ayarlıysa, siz kaydı güncelleseniz bile dünya genelindeki DNS çözümleyicileri bu süre dolana kadar eski değeri kullanmaya devam eder. Bu nedenle büyük geçişlerden önce TTL değerini 300–600 saniyeye (5–10 dakika) düşürmek, sektörün kabul görmüş en iyi uygulamasıdır. Google'ın G Suite geçiş kılavuzları ve Microsoft'un Exchange Online belgeleri de bu adımı açıkça önermektedir.

DNS Yayılımı Neden Bu Kadar Uzun Sürer?

İnternet üzerinde merkezi bir "DNS güncelleme" mekanizması yoktur. Kök DNS sunucularından yetkili (authoritative) sunuculara, oradan özyinelemeli (recursive) çözümleyicilere ve son olarak son kullanıcının ISS DNS'ine kadar uzanan hiyerarşik bir yapı söz konusudur. Her katman kendi TTL süresini dolduruncaya dek eski kaydı önbellekte tutar.

Buna ek olarak bazı İnternet Servis Sağlayıcıları, RFC standartlarına aykırı biçimde TTL değerini görmezden gelerek kendi belirlediği sürelerde kayıtları önbellekler. Bu durum özellikle bazı Türk ISS altyapılarında gözlemlenmiştir. IETF'in RFC 1034 ve RFC 1035 belgelerinde tanımlanan standart davranıştan sapma, geçiş sürecini tahmin edilemez hale getirebilir.

Gönderen Sunucular Ne Zaman Tekrar Dener?

Gönderen bir MTA, iletim sırasında geçici bir hata (4xx SMTP kodu) alırsa mesajı kuyruğa alır ve belirli aralıklarla yeniden deneme yapar. RFC 5321, ilk yeniden denemenin en az 30 dakika sonra yapılmasını önermektedir; çoğu kurumsal posta sunucusu bu süreyi 1 saat ya da daha uzun tutar. Bu davranış şu anlama gelir: Geçiş anında kuyrukta bekleyen iletiler, eski MX'i bir kez daha sorgulayabilir ve hâlâ önbellekte varsa eski sunucuya ulaşmaya devam eder.

Yaygın Hata Senaryoları ve Teşhis Yöntemleri

Aşağıdaki tablo, geçiş sonrası e-postaların eski sunucuya gelmeye devam ettiği başlıca senaryoları ve her birinin nasıl teşhis edileceğini özetlemektedir:

Adım Adım Teşhis Süreci

1. Yetkili DNS'i Doğrulayın

İlk adım, değişikliğin yetkili DNS sunucusuna ulaşıp ulaşmadığını kontrol etmektir. Terminalde şu komutu çalıştırın:

dig MX alanadi.com @ns1.yetkili-dns-sunucunuz.com

Çıktıda yeni MX kaydını görüyorsanız değişiklik yetkili sunucuya işlenmiştir; sorun yayılım gecikmesindedir. Görmüyorsanız DNS panelinizde kayıt doğru kaydedilmemiş demektir.

2. Genel DNS Çözümleyicilerini Test Edin

Farklı DNS çözümleyicileri üzerinden sorgu yaparak yayılımın ne kadar ilerlediğini ölçün:

dig MX alanadi.com @8.8.8.8
dig MX alanadi.com @1.1.1.1
dig MX alanadi.com @208.67.222.222

Yanıtlar farklılık gösteriyorsa yayılım henüz tamamlanmamıştır. MXToolbox'ın "MX Lookup" aracı da dünya genelindeki 15'ten fazla konumdan eş zamanlı sorgu yaparak görsel bir yayılım haritası sunar.

3. SMTP Başlıklarını İnceleyin

Eski sunucuya ulaşan bir iletinin ham başlıklarında (headers) Received: satırlarını takip edin. Bu satırlar, iletinin hangi MTA'lardan geçtiğini zaman damgasıyla birlikte gösterir. Örneğin:

Received: from mail.gondericisunucu.com (mail.gondericisunucu.com [203.0.113.10])
        by eskisunucu.alanadi.com (Postfix) with ESMTPS id A1B2C3D4
        for <kullanici@alanadi.com>; Mon, 01 Jun 2026 08:23:11 +0300 (TRY)

Bu çıktı, gönderici MTA'nın eski sunucunuzun IP adresine (eskisunucu.alanadi.com) bağlandığını kanıtlar; yani o sunucu DNS önbelleğinde hâlâ eski MX'i görüyordur.

Geçiş Sürecinde Eski Sunucuyu Aktif Tutun

En kritik ve çoğu zaman göz ardı edilen kural şudur: TTL süresi tam olarak dolana kadar eski sunucuyu kapatmayın. Bazı gönderen sistemler, özellikle RFC 5321'e sıkı sıkıya uyan kurumsal MTA'lar, önceki başarılı bağlantının IP adresini kısa süreli olarak önbellekleyebilir. Eski sunucu kapalıysa bu durum 550 ya da 421 hataları üreterek iletilerin kaybolmasına veya bounce (geri dönme) mesajlarına yol açar.

Daha güvenli bir geçiş için eski sunucuyu "relay" moduna alın; yani gelen iletileri kabul edip yeni sunucuya iletmesini sağlayın. Postfix üzerinde bu yapılandırma transport_maps ve relay_domains direktifleriyle, Microsoft Exchange'de ise "Send Connector" düzenlemeleriyle gerçekleştirilir.

SPF, DKIM ve DMARC Kayıtlarını Unutmayın

MX geçişi sırasında yalnızca MX kaydını güncellemek yetmez. RFC 7208 (SPF), RFC 6376 (DKIM) ve RFC 7489 (DMARC) ile tanımlanan e-posta kimlik doğrulama kayıtları da yeni sunucuyu yansıtacak şekilde güncellenmelidir. Aksi hâlde yeni sunucudan gönderilen iletiler, SPF "fail" veya DMARC "reject" politikalarına takılarak alıcı tarafında reddedilebilir ya da spam klasörüne düşebilir. Google Postmaster Tools ve Microsoft'un JMRP (Junk Mail Reporting Program) platformları, bu tür teslim edilebilirlik sorunlarını izlemek için ücretsiz araçlar sunar.

Önleyici Tedbirler: Geçiş Kontrol Listesi

Bir sonraki geçişte bu sorunla karşılaşmamak için aşağıdaki adımları planlı biçimde uygulayın: Geçişten en az 48 saat önce mevcut MX kaydının TTL değerini 300 saniyeye (5 dakika) düşürün. Geçiş gününe kadar bu değerin tüm çözümleyicilere yayılmasını bekleyin. Yeni MX kaydını eklerken eski kaydı silmeden önce her iki kaydın bir süre paralel çalışmasına izin verin. Yeni sunucunun MX öncelik değerini (priority) eski sunucunkinden daha düşük bir rakamla (örneğin 10 vs. 20) tanımlayarak yeni sunucuyu birincil yapın. Trafik tamamen yeni sunucuya geçtikten sonra eski MX kaydını silin ve TTL'yi yeniden 3.600–86.400 saniye aralığına çekin.

Sık Sorulan Sorular