Smart Host

İkincil MX ve E-posta Kesinti Planı: İletiler Nereye Gider?

Protokolün doğal dayanıklılığı, yedek kuyruk sunucusunun riskleri, giden posta yedekliliği ve operasyonel kesinti planı. İkincil MX ve E-posta Kesinti Planı…

İkincil MX ve E-posta Kesinti Planı: İletiler Nereye Gider?
İçindekiler
  1. Protokolün Doğal Dayanıklılığı
  2. İkincil MX Kaydı
  3. Yedek Kuyruk
  4. Tam Yedek Sistem
  5. Hangisi Gerekli?
  6. Gönderim Tarafında Yedeklilik
  7. İkincil MX Kurarken
  8. Kesinti Planı
  9. Dış Hizmet Kullanmak
  10. Sonuç
  11. Sıkça Sorulan Sorular (SSS)
  12. Posta sunucum çökerse iletiler kaybolur mu?
  13. İkincil MX kaydı gerekli mi?
  14. Yedek MX sunucusu neden risk üretebilir?
  15. Giden posta için ne yapmalıyım?

İkincil MX ve E-posta Kesinti Planı: İletiler Nereye Gider?

Posta sunucunuz çöktü. Gelen e-postalara ne oluyor? Kayboluyorlar mı, bekliyorlar mı, gönderene geri mi dönüyorlar?

Cevap, e-posta protokolünün en değerli özelliklerinden birinde saklı. Bu yazı, e-posta altyapısında kesinti dayanıklılığını anlatıyor.

Protokolün Doğal Dayanıklılığı

E-posta, kesintiye dayanıklı olacak şekilde tasarlanmıştır. Alıcı sunucu ulaşılamaz olduğunda gönderen sunucu iletiyi atmaz — kuyruğa alır ve tekrar dener.

Bu nedenle kısa süreli kesintiler genellikle veri kaybı üretmez:

  • Gönderen sunucu tekrar dener. Artan aralıklarla, genellikle günlerce.
  • İletiler kaybolmaz. Gönderen tarafta bekler.
  • Gönderici bilgilendirilir. Gecikme uzarsa bilgi iletisi alır.

Ancak bu dayanıklılığın sınırları vardır ve bilinmesi gerekir: deneme süresi dolduğunda ileti gönderene geri döner ve kaybolur. Ayrıca bu süre boyunca müşterileriniz size ulaşamamış olur.

İkincil MX Kaydı

MX kayıtlarına öncelik değeri verilebilir. Birden fazla kayıt tanımladığınızda, birincil sunucu ulaşılamazsa ikincisi denenir.

İkincil sunucunun iki farklı rolü olabilir:

Yedek Kuyruk

İkincil sunucu iletileri kabul eder, saklar ve birincil sunucu geri döndüğünde ona teslim eder.

Avantajı: gönderen açısından teslimat başarılıdır, iletiler güvende bekler.

Dikkat edilecek nokta: yedek kuyruk sunucusu spam filtrelemesi yapmıyorsa, spam için bir arka kapı hâline gelir. Spam gönderenler kasıtlı olarak ikincil sunucuları hedefler çünkü genellikle daha gevşek yapılandırılmışlardır.

Tam Yedek Sistem

İkincil sunucu, birincil sunucunun tam bir kopyası olarak çalışır. Kullanıcılar kesintisiz posta kutularına erişebilir.

Bu, gerçek yüksek erişilebilirliktir ama daha karmaşık ve maliyetlidir: posta kutularının senkronize edilmesi gerekir.

Hangisi Gerekli?

İhtiyaç Çözüm
Kısa kesintide ileti kaybetmemek Protokolün kendisi yeterli
Uzun kesintide ileti kaybetmemek Yedek kuyruk sunucusu
Kesintisiz erişim Tam yedek sistem
Gönderim sürekliliği Yedek gönderim yolu

Birinci satır önemli bir gerçeği söyler: kısa kesintiler için ek bir yapı gerekmez — protokol zaten bu işi yapar. İkincil MX kurmadan önce, gerçekten hangi soruna çözüm aradığınızı netleştirin.

Dördüncü satır sıkça atlanır: gelen posta için yedeklilik kurulur ama giden posta düşünülmez. Sunucunuz çöktüğünde uygulamanız da e-posta gönderemez hâle gelir — şifre sıfırlama ve sipariş onayı iletileri durur.

Gönderim Tarafında Yedeklilik

Uygulamanızın e-posta gönderemez hâle gelmesi, gelen posta kesintisinden çoğu zaman daha kritiktir. Müşteri kaydolamaz, şifre sıfırlayamaz, sipariş onayı alamaz.

Yedeklilik seçenekleri:

  1. Yedek gönderim sunucusu tanımlayın. Uygulamanız birincil sunucuya ulaşamazsa ikincisini denesin.
  2. Kendi kuyruğunuzu tutun. Gönderilemeyen iletiler yerel bir kuyrukta beklesin, sonra gönderilsin.
  3. Farklı sağlayıcı kullanın. Yedek yol, birincil ile aynı altyapıda olmamalı.
  4. Kritik iletileri önceliklendirin. Kısıtlı kapasitede şifre sıfırlama, bültenin önüne geçsin.

İkinci madde en pratik ve en çok atlanan önlemdir: uygulamanız gönderim sunucusuna ulaşamadığında iletiyi kaybediyorsa, kesinti süresince üretilen tüm bildirimler yok olur. Küçük bir yerel kuyruk bu boşluğu tamamen kapatır.

İkincil MX Kurarken

Yedek kuyruk sunucusu kuracaksanız dikkat edilecekler:

  • Aynı spam filtrelemesini uygulayın. Aksi hâlde spam için arka kapı olur.
  • Geçerli alıcı listesini bilmelidir. Var olmayan adreslere gelen iletileri kabul edip sonra geri döndürmek, itibar sorunu üretir.
  • Farklı bir ağda olmalı. Aynı veri merkezindeki bir yedek, elektrik veya ağ kesintisinde işe yaramaz.
  • Kuyruk kapasitesi yeterli olmalı. Uzun bir kesintide birikecek iletileri tutabilmeli.
  • Düzenli test edilmeli. Yıllardır devrede olmayan bir yedek, ihtiyaç anında çalışmayabilir.

İkinci madde ince bir teknik detaydır ama önemlidir: yedek sunucu geçerli adresleri bilmiyorsa, spam gönderenlerin rastgele adreslere yolladığı iletileri kabul eder ve ardından geri dönüş üretir. Bu geri dönüşler sizin adınıza gönderildiği için itibarınıza zarar verir.

Kesinti Planı

Teknik yedekliliğin yanında, operasyonel bir plan da gerekir:

  1. Kesintiyi nasıl fark edeceksiniz? Dışarıdan izleme kurulu mu?
  2. Kim müdahale edecek? Ve mesai dışında ulaşılabilir mi?
  3. Alternatif iletişim kanalı nedir? Müşteriler size nasıl ulaşacak?
  4. Kritik bildirimler nasıl gönderilecek? Alternatif bir yol var mı?
  5. Kesinti sonrası ne kontrol edilecek? Bekleyen iletiler teslim edildi mi?

Üçüncü madde sıkça atlanır: e-posta kesintisinde müşterileriniz size ulaşamaz. Sitenizde görünür bir telefon numarası veya alternatif iletişim kanalı, bu boşluğu doldurur.

Beşinci madde de önemlidir: kesinti çözüldükten sonra bekleyen iletilerin gerçekten teslim edildiğini doğrulayın. Yedek kuyruktaki iletiler otomatik iletilir ama bunu kontrol etmek gerekir.

Dış Hizmet Kullanmak

Kendi posta altyapınızı yedeklemek yerine, bu işi üstlenen hizmetler kullanılabilir:

  • Gelen posta filtreleme hizmetleri. Genellikle yedek kuyruk özelliği de sunar.
  • Bulut posta hizmetleri. Yedeklilik hizmetin kendisinde vardır.
  • Gönderim hizmetleri. Giden posta için yüksek erişilebilirlik sağlar.

Üçüncü seçenek, uygulama gönderimleri için özellikle pratiktir: kendi sunucunuz çökse bile uygulamanız dış bir gönderim altyapısı üzerinden e-posta göndermeye devam eder. Bu, şifre sıfırlama ve sipariş onayı gibi kritik iletileri kesintiden korur.

Sonuç

E-posta protokolü kesintiye dayanıklıdır: gönderen sunucu iletiyi atmaz, kuyruğa alır ve günlerce tekrar dener. Bu yüzden kısa kesintiler için ek bir yapı kurmanız gerekmez — ikincil MX kurmadan önce hangi soruna çözüm aradığınızı netleştirin. Yedek kuyruk sunucusu kuracaksanız iki kural kritiktir: aynı spam filtrelemesini uygulayın ve geçerli alıcı listesini bilmesini sağlayın, aksi hâlde spam için arka kapı olur. Ve sıkça atlanan tarafı unutmayın: gelen posta için yedeklilik kurulurken giden posta düşünülmez — oysa şifre sıfırlama iletilerinin durması çoğu zaman daha kritiktir.

Sıkça Sorulan Sorular (SSS)

Posta sunucum çökerse iletiler kaybolur mu?

Kısa kesintilerde hayır. Gönderen sunucu iletiyi kuyruğa alır ve artan aralıklarla genellikle günlerce tekrar dener. Ancak deneme süresi dolduğunda ileti gönderene geri döner ve kaybolur — ayrıca bu süre boyunca müşterileriniz size ulaşamamış olur.

İkincil MX kaydı gerekli mi?

Kısa kesintiler için gerekmez; protokol zaten bu işi yapar. Uzun kesintilerde ileti kaybını önlemek istiyorsanız yedek kuyruk sunucusu, kesintisiz erişim istiyorsanız tam yedek sistem gerekir. Önce hangi soruna çözüm aradığınızı netleştirin.

Yedek MX sunucusu neden risk üretebilir?

Aynı spam filtrelemesini uygulamıyorsa spam gönderenler için arka kapı olur — kasıtlı olarak ikincil sunucular hedeflenir. Ayrıca geçerli alıcı listesini bilmiyorsa, olmayan adreslere gelen iletileri kabul edip geri dönüş üretir ve bu itibarınıza zarar verir.

Giden posta için ne yapmalıyım?

Bu taraf sıkça atlanır ama çoğu zaman daha kritiktir. Uygulamanızda kendi gönderim kuyruğunuzu tutun — sunucuya ulaşılamadığında iletiler yerel kuyrukta beklesin. Ayrıca yedek bir gönderim yolu tanımlayın; tercihen birincil ile farklı bir altyapıda olsun.