Mail Sunucusu Taşırken DNS Kesintisi Nasıl Önlenir?
Mail sunucusu geçişleri, web sitesi geçişlerinden farklı bir risk profili taşır. Web trafiği birkaç saniyelik DNS önbellek uyuşmazlığını tolere edebilir; ama yanlış zamanda değiştirilen bir MX kaydı, gönderilmeye çalışılan e-postaların kuyruğa takılmasına ya da kalıcı olarak kaybolmasına yol açabilir. DNS geçişini adım adım planlamak bu riski büyük ölçüde azaltır.
Mail trafiğinin e-posta gönderen sunucudan (SMTP relay) alıcı domain'e ulaşma yolu DNS üzerinden geçer. Gönderen sunucu, alıcı domain'in MX kaydını sorgular, dönen değere bağlanır ve mesajı teslim etmeye çalışır. MX kaydı hatalı, eksik ya da geçiş sırasında tutarsız durumdaysa gönderen sunucu ya farklı bir mail sunucusuna bağlanır ya da bağlantı kuramayıp mesajı kuyruğa alır. Kuyruktaki mesajlar genellikle 4-5 gün boyunca yeniden denenir; bu süre aşılırsa mesaj kalıcı olarak geri döner.
Bu mekanizmayı anlamak, geçişin hangi adımda neden bu sırada yapılması gerektiğini netleştirir.
MX kaydı geçişinin doğru sıralaması
Mail sunucusu taşımanın temel kuralı şudur: yeni sunucu hazır ve test edilmiş olmadan MX kaydı değiştirilmez. MX kaydı değiştirildiği anda posta trafiği yeni sunucuya akmaya başlar; yeni sunucu o anda posta kabul edemiyorsa mesajlar ya reddedilir ya da kuyruğa alınır.
Doğru sıralama şu şekilde işler. İlk olarak yeni mail sunucusu kurulur, test edilir ve posta kabul edip iletebilir duruma getirilir. Ardından mevcut MX kaydının TTL değeri düşürülür. TTL yayıldıktan sonra — bu süre mevcut TTL değeri kadardır — MX kaydı yeni sunucuya güncellenir. Paralel çalışma dönemi tamamlanınca eski sunucu devre dışı bırakılır.
; 1. Başlangıç durumu (geçiş öncesi):
sirket.com. 3600 IN MX 10 mail.eskisunucu.com.
; 2. TTL düşürme (geçişten 48 saat önce):
sirket.com. 300 IN MX 10 mail.eskisunucu.com.
; 3. Paralel dönem — ikinci MX eklenir (opsiyonel):
sirket.com. 300 IN MX 10 mail.eskisunucu.com.
sirket.com. 300 IN MX 20 mail.yenisunucu.com.
; 4. Geçiş — öncelik tersine çevrilir:
sirket.com. 300 IN MX 10 mail.yenisunucu.com.
sirket.com. 300 IN MX 20 mail.eskisunucu.com.
; 5. Geçiş tamamlandı — eski MX kaldırılır:
sirket.com. 3600 IN MX 10 mail.yenisunucu.com.MX öncelik değeri (bu örnekte 10 ve 20) önemlidir. Düşük sayı daha yüksek öncelik anlamına gelir. Gönderen sunucular önce en düşük öncelik değerine sahip MX'e bağlanmayı dener; başarısız olursa bir sonrakine geçer. Paralel dönemde eski sunucuyu yedek (priority 20) olarak tutmak, yeni sunucuya ulaşılamayan nadir senaryolarda postanın yine de teslim edilmesini sağlar.
TTL yönetimi: propagasyon penceresini doğru hesaplamak
MX kaydını değiştirmeden önce mevcut TTL değerini düşürmek, geçişi geri alabilme kapısını açık tutar. Yüksek TTL'li bir kayıt değiştirildiğinde, dünyanın farklı noktalarındaki DNS önbellekleri bu değişikliği TTL süresi dolana kadar görmez. Yüksek TTL ile yapılan bir geçişte sorun çıkarsa geri dönmek saatler alabilir.
Standart yaklaşım: geçişten en az 48 saat önce TTL'i 300 saniyeye (5 dakika) düşürün. Bu değişikliğin yayılması için mevcut TTL kadar bekleyin — eğer mevcut TTL 86400 (24 saat) ise, düşürme işlemi yapıldıktan sonra 24 saat geçmeden MX kaydı değiştirmeyin. 300 saniyelik TTL yayıldıktan sonra artık geçişi hızla geri alabilirsiniz; bir şeyler yanlış giderse 5 dakika içinde eski değere dönmek mümkün olur.
# Farklı DNS sunucularından MX TTL kontrolü:
$ dig @8.8.8.8 sirket.com MX +ttl
sirket.com. 287 IN MX 10 mail.eskisunucu.com.
$ dig @1.1.1.1 sirket.com MX +ttl
sirket.com. 293 IN MX 10 mail.eskisunucu.com.
# TTL 300'e yakınsa propagasyon tamamlanmış demektir.
# Hâlâ 3600 döndüren sunucular varsa biraz daha bekleyin.DNS propagasyonu tek bir merkezi sistemden değil, dağıtılmış önbelleklerden geçer. Farklı coğrafi noktalardaki DNS sunucuları aynı anda güncellenemez. Bu nedenle birden fazla genel çözümleyiciyi (8.8.8.8, 1.1.1.1, 9.9.9.9) ayrı ayrı sorgulamak ve hepsinin yeni TTL değerini döndürdüğünü görmek, propagasyonun büyük ölçüde tamamlandığının göstergesidir.
Eski ve yeni sunucunun paralel çalışma dönemi
MX kaydı değiştirildikten hemen sonra tüm posta trafiği yeni sunucuya akmaz. TTL süresi dolmamış önbellekler eski MX değerini kullanmaya devam eder. Bu geçiş penceresinde hem eski hem de yeni sunucu posta alıyor olabilir.
Bu nedenle eski sunucunun MX kaydı değiştirildikten sonra en az 48-72 saat daha aktif tutulması önerilir. Bu süre zarfında eski sunucuya gelen postalar alınmalı, okunmayan mesajlar yeni sunucuya aktarılmalı ya da kullanıcılara yönlendirilmelidir. Eski sunucu bu dönemde posta reddeden değil, kabul eden durumda olmalıdır.
Eski sunucuyu MX değişikliğiyle eş zamanlı kapatmak ciddi posta kaybına yol açabilir. Özellikle TTL düşürme adımı atlandıysa, yüksek TTL nedeniyle önbellekte kalan eski MX değeri hâlâ yönlendirme yapıyor olabilir. Bu durumda eski sunucu kapalıysa bu sorgular başarısız olur ve gönderen sunucu mesajları kuyruğa alır ya da reddeder. Eski sunucuyu en erken, MX geçişinden 72 saat sonra ve yeni sunucunun stabil çalıştığını doğruladıktan sonra kapatın.
Mail kuyruğu ve teslim gecikmesi: ne zaman sorun vardır
SMTP protokolü, geçici hatalara karşı kuyruklama mekanizmasıyla donatılmıştır. Gönderen sunucu hedef mail sunucusuna bağlanamadığında ya da geçici bir hata (4xx yanıt kodu) aldığında mesajı kuyruğa alır ve belirli aralıklarla yeniden denemeye devam eder. Bu yeniden deneme penceresi çoğunlukla 4-5 gün olup sunucu konfigürasyonuna göre değişir.
Geçiş sırasında bu mekanizma koruyucu bir tampon görevi görür. Kısa süreli erişilemezlik durumunda mesajlar kaybolmaz; kuyruğa alınır ve sunucu tekrar erişilebilir olduğunda teslim edilir. Ancak bu tamponun sınırlı olduğunu bilmek gerekir: 5. günde hâlâ teslim edilemeyen mesajlar kalıcı olarak geri döner (bounce).
Geçiş sırasında kuyruk davranışını izlemek için yeni sunucunun mail loglarını takip etmek en doğrudan yöntemdir. postqueue -p (Postfix) ya da eşdeğer komutlar kuyruktaki mesajları listeler. Gelen mesaj akışı normalleştikten ve kuyruk boşaldıktan sonra geçişin sorunsuz tamamlandığı söylenebilir.
Geçiş sonrası doğrulama: MX, A ve ilgili kayıtlar
MX kaydı değiştiğinde yalnızca MX'i kontrol etmek yeterli değildir. Mail trafiğini etkileyen birden fazla DNS kaydı vardır ve bunların tutarlı olması gerekir.
MX kaydının işaret ettiği hostname'in A kaydı da güncel olmalıdır. MX kaydı mail.yenisunucu.com'a işaret ediyorsa bu hostname'in A kaydı yeni sunucunun IP'sine çözümlenmelidir. MX değiştirilip A kaydı güncellenmezse posta yanlış sunucuya yönlenebilir.
# MX kaydı kontrolü:
$ dig sirket.com MX +short
10 mail.yenisunucu.com.
# MX hostname'inin A kaydı:
$ dig mail.yenisunucu.com A +short
93.184.216.50 ; yeni sunucu IP'si
# Reverse DNS (PTR) kontrolü:
$ dig -x 93.184.216.50 +short
mail.yenisunucu.com. ; doğru PTR kaydı
# SMTP bağlantı testi:
$ telnet mail.yenisunucu.com 25
220 mail.yenisunucu.com ESMTP readyPTR (reverse DNS) kaydı da kontrol edilmelidir. Birçok mail sunucusu gelen bağlantıda PTR kaydı yoksa ya da MX hostname'iyle eşleşmiyorsa posta spam olarak işaretler ya da reddeder. PTR kaydı genellikle IP bloğunu tahsis eden ISP ya da hosting sağlayıcı tarafından yönetilir; yeni sunucunun IP'si için doğru PTR kaydının oluşturulduğunu mutlaka doğrulayın.
Geçiş tamamlandıktan sonra farklı harici domain'lerden test e-postaları göndermek pratik bir doğrulama yöntemidir. Gmail, Outlook ve başka bir servis üzerinden gönderilen test mesajlarının yeni sunucuya ulaştığını ve spam klasörüne düşmediğini teyit etmek, geçişin işlevsel olarak başarılı olduğunu gösterir. Mesajlar ulaşıyorsa ama spam'e gidiyorsa sorun DNS'te değil, SPF, DKIM ya da DMARC yapılandırmasındadır — bunlar MX geçişinden bağımsız olarak ayrıca ele alınması gereken konulardır.
Mail sunucusu taşıma sürecinde DNS katmanı doğru yönetildiğinde geçiş kullanıcılar açısından neredeyse fark edilmez. Tüm mesajlar teslim edilir, kuyrukta bekleme süresi kısalır ve eski sunucudan yeni sunucuya geçiş kontrollü biçimde tamamlanır. Bu kontrolün anahtarı, MX kaydını değiştirmeden önce hazırlık adımlarını — TTL düşürme, yeni sunucu testi, propagasyon beklemesi — eksiksiz uygulamaktır.