DNS ekranında birden fazla MX satırı görmek, e-postanın otomatik yedeklendiği izlenimini verebilir. Oysa MX önceliği alıcı sunucunun seçilmesiyle ilgilidir; posta kutusunun bağımsız kopyasını oluşturmaz. Yeni bir hizmete geçerken eski sağlayıcının kaydını da bırakmak, hesaplar ve yönlendirme planı hazırlanmadıysa beklenmedik teslimat sorunlarına yol açabilir.
Öncelik sayısı neyi belirler?
RFC 5321'in hedef sunucu seçimi bölümü, düşük sayısal MX tercihinin önce değerlendirildiğini açıklar. Bu kayıtlar otomatik çift teslimat talimatı değildir. İkinci bir satırın gerçek yedek alıcı hizmeti olarak kullanılabilmesi, o hedefte uygun yapılandırmanın bulunmasına bağlıdır. Sırf ekranda ikinci adres olsun diye farklı bir firmanın sunucusunu yazmayın.
Her hedef alan adınızı kabul ediyor mu?
MX hedefini vermiş olan sağlayıcının alan adını ve alıcı hesaplarını tanıdığını doğrulayın. Ekip, hangi kutuların nerede bulunduğunu yazılı olarak listelemelidir. Hosting taşırken MX kontrolü, web sitesi ile e-postanın ayrı hizmetler olabileceğini anlatır. Web sunucusunun değişmesi, MX hedefinin de mutlaka değiştirilmesini gerektirmez.
Teslimat sürekliliği ile veri yedeğini ayırın
Bir sunucunun geçici erişilemezliğine yönelik plan ile silinen mesajı geri getirmek farklı ihtiyaçlardır. E-posta arşivleme ve yedekleme rehberinde bağımsız kopya ihtiyacını ayrıca değerlendirin. Yönlendirme de yedekle aynı şey değildir; yönlendirme farkı rehberi bu karışıklığı ayırır. DNS satırını artırmak geçmiş iletileri korumaz.
Geçişten sonra farklı dış adreslerden sınayın
Yeni hedef hazır olduğunda kontrollü dış gönderim ve yanıt testleri planlayın. Gelen mesajın hangi kutuda bulunduğunu ve kullanıcının beklenen yerden erişebildiğini kontrol edin. DNS sorgusunun doğru görünmesi tek başına bütün alıcıların çalıştığı anlamına gelmez. Hata çıkarsa önce tam yanıtı ve saati kaydedin; tekrar tekrar yeni MX satırı eklemeyin.
Kurumsal e-posta geçişinde sorumluluk listesini açık tutun: DNS'i yöneten kişi, yeni hesapları hazırlayan kişi ve sonucu doğrulayan kişi belli olsun. Önceki kayıtları geri dönüş için saklayın. Başarı ölçütü panelde hatasız kayıt görmek değil, beklenen alıcıların doğru hizmette güvenli biçimde mesaj alıp yanıtlayabilmesidir. Bu düzen, bir sonraki sağlayıcı değişiminde aynı belirsizliklerin yeniden oluşmasını azaltır.
Yedek hizmetin gerçek görevini yazın
Bir sağlayıcı yedek MX hizmeti sunuyorsa bunun ne yaptığı, mesajı nerede tuttuğu ve ana hizmet geri geldiğinde nasıl davranacağı yazılı olarak anlaşılmalıdır. Bu işleyişi yalnız DNS öncelik sayısından çıkaramayız. Hesap oluşturma, alıcı kabulü ve sorumluluklar belirsizken ikinci hedefi eklemeyin. Kurumun beklediği şey geçmiş postayı geri getirmekse bunu ayrı yedek ihtiyacı olarak tanımlayın. Beklenen şey yeni mesajların geçici kesintide yönetilmesiyse o hizmetin koşullarını ayrıca sorun. Aynı kelimeyle farklı ihtiyaçları ifade etmek yanlış satın alma kararına neden olabilir. Değişiklik öncesi hedefi açık yazmak, test sonunda neyin başarılı sayılacağını da netleştirir.
Sıkça Sorulan Sorular
Daha büyük sayı daha öncelikli mi?
Hayır. MX değerlendirmesinde daha düşük sayısal değer tercih edilir. Hizmet sağlayıcınızın verdiği değerleri kendi mantığınızla ters çevirmeyin.
İki sağlayıcının MX'ini eklersem yedek oluşur mu?
Kendiliğinden oluşmaz. Her hedefin alan adını, alıcıları ve ilgili yönlendirmeyi desteklemesi gerekir; posta yedeği ayrıca planlanmalıdır.
Eşit öncelik ile bütün mesajlar iki yere mi gelir?
Hayır. MX kayıtları bir iletiyi otomatik olarak iki posta kutusuna çoğaltma aracı değildir. Kopya saklama ihtiyacı için ayrı ve desteklenen çözüm gerekir.
Eski MX'i hemen kaldırayım mı?
Geçişin tamamlandığını, hesapların hazır olduğunu ve eski hizmete bağımlılığı doğrulamadan değiştirmeyin. Kayıtların önceki hâlini saklayın.