Yedek MX Kaydı (Secondary MX) Nedir, Nasıl Kurulur?

E-posta altyapınızda tek bir MX kaydına güvenmek, sunucu kesintilerinde tüm gelen postanın kaybolması anlamına gelir. Yedek MX kaydı (Secondary MX), birincil posta sunucunuz erişilemez olduğunda e-postalarınızı geçici olarak kabul eden ikinci bir katmandır ve e-posta teslimatta sürekliliği sağlamanın en temel yollarından biridir.

MX Kaydı Öncelik Sistemi Nasıl Çalışır?

DNS'deki MX (Mail Exchanger) kaydı, bir alan adı için e-posta alacak sunucuyu ve bu sunucunun önceliğini tanımlar. RFC 5321, §5.1 uyarınca gönderen SMTP ajanı, hedef alan adı için MX kayıtlarını sorgular ve en düşük öncelik sayısına sahip sunucuya önce bağlanmayı dener. Bağlantı kurulamazsa bir sonraki en düşük öncelik değerine geçilir.

Örneğin aşağıdaki yapıda birincil sunucu mail1.ornekfirma.com, yedek ise mail2.ornekfirma.com'dur:

ornekfirma.com.  IN MX 10 mail1.ornekfirma.com.
ornekfirma.com.  IN MX 20 mail2.ornekfirma.com.

Gönderen sunucu önce öncelik 10'u dener; eğer Connection refused (SMTP 421 veya 450 hata kodu) ya da zaman aşımı alırsa öncelik 20'ye döner. Bu mekanizma sayesinde birincil sunucunuzun kısa süreli kesintilerinde e-postalar kaybolmaz; yedek sunucuda kuyruklanır ve birincil yeniden ayağa kalktığında iletilir.

Birincil ve Yedek MX: Temel Farklar

Yedek MX Kurulumu: Adım Adım

1. Yedek Posta Sunucusunu Hazırlayın

Yedek MX görevi üstlenecek sunucunun Postfix, Exim veya ticari bir relay hizmeti üzerinde çalışıyor olması gerekir. Postfix kullananlar için /etc/postfix/main.cf dosyasında aşağıdaki ayarların yapılması zorunludur:

relay_domains = ornekfirma.com
relay_recipient_maps = hash:/etc/postfix/relay_recipients
maximal_queue_lifetime = 5d
bounce_queue_lifetime = 1d

relay_recipient_maps ayarı önemlidir: yedek MX sunucusu geçerli alıcıları bilmezse var olmayan adreslere gelen e-postaları kabul edip birincile iletmeye çalışır; bu durum backscatter (geri saçılma) sorununa yol açar. Geçerli alıcı listesini LDAP, veritabanı ya da statik dosya ile senkronize tutun.

2. DNS'e Secondary MX Kaydı Ekleyin

DNS yönetim panelinizde (cPanel, Cloudflare, Route53 vb.) yeni bir MX kaydı oluşturun:

Ad (Host): @  veya  ornekfirma.com.
Tür: MX
Öncelik: 20
Değer: mail2.ornekfirma.com.

Yedek sunucunun A kaydının da doğru IP'yi gösterdiğinden emin olun. DNS TTL değerini 300-600 saniye olarak ayarlamak, kesinti anında hızlı geçiş yapılabilmesini sağlar.

3. Tersine DNS (PTR) Kaydını Kontrol Edin

Büyük e-posta sağlayıcıları (Gmail, Outlook/Hotmail, Yahoo) SMTP bağlantısı kabul ederken gönderen IP'nin PTR kaydını kontrol eder. Yedek MX sunucunuzun IP'si için de uygun bir PTR kaydı tanımlanmış olmalıdır; aksi hâlde yedek sunucudan relay yapılan e-postalar alıcı tarafta spam olarak işaretlenebilir.

4. SPF Kaydını Güncelleyin

RFC 7208 kapsamında tanımlanan SPF kaydı, hangi sunucuların alan adınız adına e-posta gönderebileceğini belirtir. Yedek MX sunucusu gelen postaları birincile iletirken (relay) kendi IP'sini kaynak gösteriyorsa SPF kaydınıza bu IP'yi eklemeniz gerekir:

v=spf1 mx ip4:203.0.113.50 ~all

mx mekanizması tüm MX kaydı IP'lerini otomatik olarak kapsadığından ayrıca ip4 eklemenize gerek kalmayabilir; ancak NAT veya farklı çıkış IP'si durumlarında açıkça belirtmek daha güvenlidir.

5. Kurulumu Test Edin

Kurulum tamamlandıktan sonra aşağıdaki araçlarla doğrulama yapın:

• MXToolbox (mxtoolbox.com): Alan adınızın MX kayıtlarını ve öncelik değerlerini listeler.
• dig komutu: dig MX ornekfirma.com +short ile terminalde sorgulayabilirsiniz.
• Telnet testi: telnet mail2.ornekfirma.com 25 ile yedek sunucunun SMTP portunu dinleyip dinlemediğini kontrol edin. Sunucu 220 banner'ı dönmeliyse bağlantı başarılıdır.
• mail-tester.com veya Google Admin Toolbox: SPF, DKIM ve genel posta yapılandırmasını kontrol eder.

Yedek MX ile Spam Tuzağından Kaçının

Yedek MX sunucusu, spam filtresi olmaksızın yapılandırılırsa önemli bir güvenlik açığına dönüşebilir. Spam göndericiler zaman zaman birincil MX'i atlayarak daha zayıf filtreye sahip yedek MX'e doğrudan bağlanır; bu teknik literatürde "MX backup abuse" olarak bilinir.

Bu riski azaltmak için:

• Yedek MX sunucusuna da birincil ile eşdeğer spam filtresi (SpamAssassin, Rspamd veya bulut tabanlı e-posta güvenlik hizmeti) kurun.
• Yedek sunucuda da DNSBL (DNS Blocklist) sorgulamasını etkin hâle getirin: Postfix'te reject_rbl_client zen.spamhaus.org kural satırı yeterlidir.
• RFC 5321 §4.5.3.1 kapsamında tanımlanan bağlantı sınırlarını uygulayın; aşırı bağlantı açan IP'leri smtpd_client_connection_rate_limit ile kısıtlayın.

Bulut Tabanlı Yedek MX Hizmetleri

Kendi sunucunuzu yönetmek istemiyorsanız, üçüncü taraf yedek MX hizmetleri kısa sürede devreye alınabilir. Bu hizmetler genellikle gelen postaları belirli bir süre (24-120 saat) kuyruğunda tutarak birincil sunucu yeniden erişilebilir olduğunda teslim eder. Connect365 gibi kurumsal e-posta platformları, alan adı doğrulaması tamamlandıktan sonra yedek MX işlevini entegre olarak sunabilir ve bu sayede ayrı bir sunucu yönetimi ihtiyacı ortadan kalkar.

Bulut tabanlı hizmetlerde dikkat edilmesi gereken noktalar şunlardır:

• Hizmetin SLA'sı (Servis Seviyesi Anlaşması) ve kuyruk tutma süresi
• Şifreli iletim için TLS zorunluluğu (STARTTLS veya SMTPS)
• DKIM imzasının relay sırasında korunup korunmadığı (RFC 6376)
• DMARC uyumluluğu ve raporlama (RFC 7489)

Yedek MX Olmadığında Ne Olur?

Birincil MX sunucunuz çevrimdışı kaldığında gönderen SMTP sunucusu, RFC 5321 §4.5.4 uyarınca belirli bir yeniden deneme süresi boyunca (genellikle 4-5 gün, varsayılan olarak 72 saat) tekrar bağlanmayı dener ve e-postayı kendi kuyruğunda bekletir. Bu süre dolduğunda gönderen, alıcıya bir teslimat hatası (bounce) bildirimi gönderir ve e-posta kalıcı olarak kaybolur.

Uzayan kesintilerde veya gönderen sunucunun kuyruk tutma süresinin kısa olduğu durumlarda (bazı büyük sağlayıcılar 24 saate kadar düşürür) yedek MX bulunmaması kritik e-posta kayıplarına neden olabilir. Bu durum özellikle iş sürekliliği açısından kabul edilemez bir risk oluşturur.

Sık Sorulan Sorular