Yedek MX, MX Önceliği ve CAA: Posta Akışını Kıran Sessiz Zincir
20 öncelikli yedek MX'iniz aylardır sessizce spam kabul ediyor olabilir ve MTA-STS'i enforce moduna aldığınız gün tüm postanız bounce'lanabilir. MX önceliği, yedek MX riskleri ve CAA/MTA-STS/DANE'yi tek bir güven zinciri olarak ele alıyor; doğru kilitleme için kayıt ve config veriyoruz.
EvilMail Team21 Temmuz 202612 dk okuma
Alan adınıza yıllar önce "dayanıklılık için" bir yedek MX (MX 20 backup.example.com) eklediniz ve unuttunuz. O sunucu o günden beri alıcı adreslerini doğrulamadan mail kabul ediyor, birincildeki DKIM/DMARC/greylisting kontrollerinin yarısını çalıştırmıyor ve spam botları tam da bu yüzden onu hedefliyor. Sonra bir gün MTA-STS'i enforce moduna alıyorsunuz; birincil MX bakıma giriyor; gönderenler yedeğe düşmek istediğinde politika dosyanızda o hostname yazmadığı için tüm postanız reddediliyor.
Bu üç konu — MX önceliği, yedek MX ve CAA/TLS — genelde ayrı ayrı anlatılır. Oysa tek bir zincirdir: gönderen MTA, MX kaydını çözer, en düşük öncelik değerini dener, TLS el sıkışmasında sunucunun sertifikasını doğrular ve o sertifikayı kimin verebileceğini CAA belirler. Zincirin en zayıf halkası neredeyse her zaman o unutulmuş yedek MX'tir.
MX önceliği: düşük sayı kazanır, gerisi efsane
RFC 5321'in tarif ettiği davranış nettir. Gönderen MTA, alan adının MX kayıtlarını çözer ve en düşük preference değerini önce dener. Eşit değerdeki kayıtlar arasında rastgele seçim yapar — kaba bir dağıtım. Yüksek sayı son çaredir, teslimat için sağlıklı bir hedef değildir.
Buradaki iki yaygın yanılgı posta mimarilerinin çoğunu bozuyor:
"Yedek MX teslimatı iyileştirir." Hayır. Modern MTA'lar birincil hedef ulaşılamazsa maili saatlerce, hatta günlerce kuyrukta tutar ve tekrar dener. Postfix'te maximal_queue_lifetime varsayılanı 5 gün, bounce_queue_lifetime de 5 gündür. Birincil MX'iniz birkaç saat, hatta bir gün düşse bile mail kaybolmaz — gönderen tarafta kuyrukta bekler ve sunucu geri geldiğinde teslim edilir. "Mail kaybolmasın diye yedek MX" argümanı bugün büyük ölçüde geçersizdir.
"Priority, round-robin yük dengeleme sağlar." Sadece eşit preference değerlerinde, o da zayıf biçimde. MX 10 a ve MX 10 b verirseniz gönderenler ikisi arasında rastgele dağılır. 10 ve 20 verdiğinizde 20'ye trafik gitmesinin tek yolu 10'un tamamen erişilemez olmasıdır. Gerçek yük dağıtımı istiyorsanız eşit öncelik + sağlayıcı düzeyinde HA (anycast, çoklu A kaydı) kullanın; farklı öncelikli yedek değil.
Yedek MX'in karanlık tarafı
Yedek MX koymak, çoğu kurulumda dayanıklılık değil yeni bir saldırı yüzeyi eklemektir. İki somut sorun var.
Backscatter (geri saçılım). Yedek MX alıcı adres listesini bilmiyorsa maili önce kabul eder, sonra teslim edemeyince bounce üretir. O bounce sahte gönderen adresine gider — yani spam kurbanlarının kutusuna. Sunucunuz backscatter kaynağına döner ve RBL'lere düşer. Çözüm, yedekte de alıcı doğrulaması yapmaktır:
ini
# Postfix, yedek MX üzerinde
smtpd_reject_unlisted_recipient = yes
relay_recipient_maps = hash:/etc/postfix/relay_recipients
# Ya da birincile canlı callout (recipient address verification)
Filtre atlatma. Spam botları en yüksek preference sayılı — yani en zayıf — MX'i kasıtlı hedefler. Neden? Çünkü yedekler genelde aynı greylisting'i, aynı RBL sorgularını, aynı DKIM/DMARC/SPF politikasını ve aynı içerik filtresini çalıştırmaz. Botun mantığı basit: en gevşek kapıdan gir. Yedek MX koyacaksanız birincil ile birebir aynı anti-spam politikasını çalıştırması şarttır; farklı bir kutu değil, birincilin aynası olmalıdır.
Pratik görüş: kurulumların çoğu için tek sağlam MX + sağlayıcı düzeyinde yüksek erişilebilirlik, iki farklı öncelikli MX'ten daha güvenlidir. Yedek MX'i yalnızca gerçekten ayrı bir yönetim ve ağ alanında (farklı veri merkezi, farklı ekip, aynı politika) çalıştırabiliyorsanız koyun.
CAA (RFC 8659), hangi sertifika otoritesinin alan adınız için sertifika basabileceğini DNS'te tanımlar. Üç property önemlidir: issue, issuewild, iodef.
dns
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:[email protected]"
issuewild ";" wildcard sertifika basılmasını tamamen yasaklar — MX hostları için wildcard'a ihtiyacınız yoksa bunu kapatın. iodef, politika ihlali durumunda CA'nın sizi nasıl uyaracağını söyler. Daha da sıkabilirsiniz:
dns
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345; validationmethods=dns-01"
Bu, yalnızca belirli bir ACME hesabının ve yalnızca dns-01 doğrulamasıyla sertifika basabilmesini sağlar; çalınmış bir sunucudan http-01 ile sertifika üretilmesini engeller.
İki kritik nokta genelde atlanır:
Ağaç tırmanma (tree climbing). CA, sertifika basmadan önce hostname'in kendisinde CAA arar, bulamazsa üst label'lara çıkar. mail.example.com için sorgu sırası mail.example.com → example.com şeklindedir. Yani zone apex'indeki tek bir CAA, altındaki tüm MX hostlarını da kapsar — eğer o hostlar için ayrı bir CAA tanımlamadıysanız.
CAA sertifikadaki hostname'i yönetir, zarf alanını değil. SMTP TLS'te sunucunun sunduğu sertifika MX hostunun FQDN'i (mail.example.com) için geçerlidir. Yedek MX farklı bir alt alan ya da tamamen farklı bir alan adındaysa (backup.otherdomain.net) o alan için de doğru CAA gerekir; aksi halde yedeğin sertifikası yenilenemez.
Let's Encrypt CAA'yı her issue işleminde canlı sorgular — cache'lemez, TTL'e uymaz, DNSSEC varsa doğrular. Bu iyi bir şey: değiştirdiğiniz an geçerli olur; karşılığında DNS'inizin issue anında erişilebilir olması gerekir.
MX + CAA + SMTP TLS kesişimi: MTA-STS ve DANE
CAA yanlış CA'yı engeller, ama sertifikanın gerçekten sunulup doğrulanmasını zorunlu kılmaz. Bunu iki mekanizma yapar.
MTA-STS (RFC 8461) bir TXT kaydı ile HTTPS üzerinden yayınlanan bir politika dosyasından oluşur:
dns
_mta-sts.example.com. IN TXT "v=STSv1; id=20260704T120000;"
Kritik tuzak burada: mode: enforce iken yedek MX mx: satırlarında yoksa, gönderen MTA yedeğe teslimatı reddeder. Priority listesine bir yedek eklediniz ama MTA-STS politikasına eklemeyi unuttuysanız, birincil düştüğü anda tüm postanız bounce'lanır. Priority hatası doğrudan teslimat kaybına dönüşür.
DANE TLSA (RFC 7672) DNSSEC üzerine kuruludur ve sertifikayı DNS'te pinler:
dns
_25._tcp.mail.example.com. IN TLSA 3 1 1 <mail-sertifikasinin-sha256'si>
_25._tcp.backup.example.com. IN TLSA 3 1 1 <backup-sertifikasinin-sha256'si>
Her MX hostu için ayrı TLSA gerekir. CAA sertifikanın hangi CA'dan geleceğini kısıtlarken TLSA o sertifikanın tam pinini zorunlu kılar — ikisi birbirini tamamlar. Postfix tarafında:
ini
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
Doğrulama:
bash
posttls-finger -c -l dane mail.example.com
Son olarak TLS-RPT ile başarısız TLS/politika olaylarını raporlatın; yoksa sessizce kaybedersiniz:
dns
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
Zincirin özeti tek cümle: CAA yanlış CA'yı engeller → MTA-STS/DANE geçerli sertifikayı zorunlu kılar → priority hangi hostun hangi sırayla deneneceğini belirler. Bir yedek MX bu üçünden birini karşılamıyorsa halka kırılır.
Uçtan uca kurulum
Tam kayıt seti, birincil 10 ve yedek 20 örneğiyle:
dns
; MX
example.com. IN MX 10 mail.example.com.
example.com. IN MX 20 backup.example.com.
; CAA (apex tüm hostları kapsar)
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issuewild ";"
example.com. IN CAA 0 iodef "mailto:[email protected]"
; MTA-STS
_mta-sts.example.com. IN TXT "v=STSv1; id=20260704T120000;"
; TLS-RPT
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"
; DANE (her MX için ayrı, DNSSEC imzalı)
_25._tcp.mail.example.com. IN TLSA 3 1 1 <hash1>
_25._tcp.backup.example.com. IN TLSA 3 1 1 <hash2>
Canlı test komutları:
bash
# Sertifikayı ve STARTTLS'i gör
openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com
# Gerçek bir mesajla TLS teslimatı dene
swaks --to [email protected] --server mail.example.com --tls
# TLSA'nın DNSSEC ile imzalı geldiğini doğrula (ad flag'i bekle)
dig +dnssec TLSA _25._tcp.mail.example.com
# CAA'yı kontrol et
dig CAA example.com
swaks çıktısında 220 ... STARTTLS ve ardından 250 görüyorsanız, posttls-finger de Verified TLS connection ... matched TLSA diyorsa zincir sağlamdır.
Devreye almadan önce kontrol listesi
Her MX (birincil ve yedek) birebir aynı anti-spam politikasını mı çalıştırıyor? (greylisting, RBL, DKIM/DMARC/SPF, içerik filtresi)
Yedek MX'te alıcı doğrulaması açık mı? (smtpd_reject_unlisted_recipient=yes ya da relay_recipient_maps) — backscatter üretmemesi için şart.
Her MX FQDN'i CAA zincirine dahil mi? Farklı alan adındaki yedeğin kendi CAA'sı var mı?
MTA-STS mx: listesinde tüm MX hostları var mı? Yeni yedek eklerken politikayı da güncellediniz mi?
mode: enforce'a geçmeden önce testing modunda en az 2 hafta bekleyip TLS-RPT raporlarını izlediniz mi?
Her MX için TLSA kaydı var ve DNSSEC ile imzalı mı? (dig +dnssec çıktısında ad flag'i görünüyor mu)
iodef adresi gerçekten çalışan, izlenen bir kutu mu?
Postfix'te smtp_tls_security_level = dane ve smtp_dns_support_level = dnssec ayarlı mı; posttls-finger doğrulamayı geçiyor mu?
Yedek MX'e gerçekten ihtiyacınız var mı, yoksa tek sağlam MX + sağlayıcı HA daha mı güvenli? Cevap "emin değilim" ise yedeği koymayın.
Sertifika yenileme otomasyonu her MX hostu için ayrı ayrı çalışıyor ve CAA accounturi kısıtınıza uyuyor mu?
