MTA-STS ve TLS-RPT ne işe yarar?
Kurumsal e-postada çoğu şirket, kullanıcıların posta kutusuna bağlantısını (IMAP/SMTP submission) TLS ile korumaya odaklanır. Ancak e-postanın iki sunucu arasında taşındığı “aktarım” aşaması da (server-to-server SMTP) en az bunun kadar kritiktir. Bu aşamada TLS genellikle “fırsatçı” (opportunistic) şekilde kullanılır: Alıcı sunucu TLS destekliyorsa şifreli gider, desteklemiyorsa şifresiz devam edebilir. Bu davranış, ağ üzerinde araya girme (downgrade veya MITM) gibi senaryolarda riski artırabilir.
MTA-STS (Mail Transfer Agent Strict Transport Security), alan adınız adına e-posta gönderen sunuculara şunu söyler: “Bu domaine e-posta iletirken TLS kullan ve sertifika doğrulaması yap; TLS yoksa veya doğrulama başarısızsa teslim etmeyi dene ama düz metne düşme.” TLS-RPT (TLS Reporting) ise bu TLS teslimat denemeleriyle ilgili raporların, belirlediğiniz adrese gönderilmesini sağlar. Bu ikili, e-posta aktarım güvenliğini artırırken aynı zamanda görünürlük kazandırır: Hangi gönderici hangi hatayı görüyor, sertifika veya DNS tarafında nerede sorun var gibi.
MTA-STS hangi problemi çözer, hangi problemi çözmez?
Çözdüğü temel sorunlar
- TLS downgrade riskini azaltma: Saldırganın STARTTLS’yi devre dışı bırakıp trafiği şifresiz hale getirmesine karşı daha güçlü bir duruş sağlar.
- Yanlış hedefe teslimat riskini azaltma: Politika, doğru MX hedeflerinin neler olduğunu da tarif ederek bazı yönlendirme/MX manipülasyonu senaryolarına karşı ek kontrol sunar.
- Sertifika doğrulaması: TLS kullanılsa bile sertifika doğrulanmıyorsa güven zayıflar. MTA-STS ile gönderen, sertifikayı doğrulamaya zorlanır.
Çözmediği veya sınırlı olduğu alanlar
- Uçtan uca şifreleme değildir: MTA-STS, sunucular arası aktarımı korur. İleti alıcı sunucuya ulaştıktan sonra (saklama, erişim, yedek) ayrı kontroller gerekir.
- Kimlik doğrulama yerine geçmez: SPF/DKIM/DMARC sahteciliği azaltmaya odaklanır; MTA-STS farklı bir katmanı korur.
- Tüm göndericileri zorunlu olarak kapsamaz: Birçok büyük sağlayıcı destekler, ancak desteklemeyen gönderenlerde politika etkili olmaz.
MTA-STS nasıl çalışır? Bileşenler ve akış
MTA-STS’nin iki ana bileşeni vardır: DNS tarafında bir işaret (TXT kaydı) ve web üzerinde yayınlanan bir politika dosyası. Gönderen sunucu, alıcı domainin MTA-STS kullandığını DNS’ten anlar, sonra HTTPS ile politika dosyasını indirir ve belirli bir süre cache’ler. Bu sayede her mesajda tekrar tekrar kontrol etmeden politika uygulanır.
1) DNS’te _mta-sts TXT kaydı
Domaininizin DNS’ine “_mta-sts” isimli bir TXT kaydı eklenir. Bu kayıt, politikanın versiyonunu ve modunu belirtir. Versiyon alanı genellikle “STSv1” olur. En önemli kısım “id” değeridir; politika dosyasında değişiklik yaptığınızda bu id’yi değiştirerek gönderenlerin yeni politikayı çekmesini tetiklersiniz.
2) HTTPS’te politika dosyası
Politika dosyası, “mta-sts” alt alan adında HTTPS ile yayınlanır ve standart bir dosya yolunda sunulur. İçerikte üç önemli alan bulunur: mod, mx ve max_age. “mx” satırları, kabul edeceğiniz MX hedeflerini listeler (wildcard kullanımları, sizin altyapınıza göre dikkatle planlanmalıdır). “max_age” ise gönderenin politikayı kaç saniye saklayacağını belirler.
3) Zorlama modları: none, testing, enforce
- none: Pratikte devre dışı. Genellikle kullanılmaz.
- testing: Gönderenler politikayı kontrol eder ve raporlar üretir, ancak TLS başarısız olduğunda teslimatı kesmek yerine çoğunlukla fırsatçı davranmaya devam eder. Yayına almadan önce gözlem için uygundur.
- enforce: TLS/sertifika doğrulaması başarısızsa teslimat başarısız olur. Gerçek güvenlik kazanımı bu modla gelir.
TLS-RPT nedir ve raporlar ne anlatır?
TLS-RPT, MTA-STS (ve ayrıca DANE TLSA gibi mekanizmalar) kapsamında oluşan TLS teslimat sorunlarını raporlamak için geliştirilmiştir. DNS’te “_smtp._tls” isimli bir TXT kaydıyla raporların hangi e-posta/URL adresine gönderileceği bildirilir. Raporlar genellikle günlük periyotlarla özet halinde gelir.
Raporlarda görebileceğiniz tipik durumlar
- STARTTLS not supported: Alıcı tarafın TLS sunmaması veya aradaki bir cihazın TLS’i düşürmesi.
- Certificate validation failure: Sertifika süresi dolmuş, ara sertifika eksik, isim eşleşmiyor gibi hatalar.
- Policy fetch failures: Politika dosyasına HTTPS erişilemiyor, sertifika geçersiz, dosya formatı hatalı.
- MX mismatch: E-posta teslim edilmeye çalışılan MX, politika dosyasında izin verilenlerle uyuşmuyor.
Bu raporlar, “bazı göndericilerden mail gelmiyor” gibi belirsiz problemlerde teşhis süresini ciddi şekilde kısaltabilir. Ayrıca değişiklik sonrası (sertifika yenileme, MX geçişi, CDN/WAF ayarları) beklenmedik yan etkileri erken yakalamanıza yardımcı olur.
Kurulum öncesi kontrol listesi (en kritik noktalar)
MX ve sertifika mimarisini netleştirin
MTA-STS, politikada tanımladığınız MX hedeflerine bağlıdır. Bu nedenle domaininizin MX kayıtları stabil olmalı ve TLS sertifikası, bu MX’lerin karşılığındaki sunucu isimleriyle uyumlu olmalıdır. Eğer mail altyapınız birden fazla hostname kullanıyorsa, politikadaki “mx” satırlarını buna göre planlamalısınız.
mta-sts alt alan adı için HTTPS yayınını hazırlayın
Politika dosyası HTTPS ile sunulacağından “mta-sts.sirketiniz.com” için geçerli bir TLS sertifikası ve erişilebilir bir web servisi gerekir. En sık sorunlar: yanlış yönlendirme, HSTS/HTTPS zorlaması yanlış kurgusu, güvenilir sertifika zincirinin eksik olması, dosyanın yanlış içerikle dönmesi.
Önce testing ile başlayın
Doğrudan “enforce” moduna geçmek, özellikle sertifika/hostname mimarisi karmaşık olan kurumlarda e-posta kaybına yol açabilir. Testing ile rapor toplayıp sorunları giderdikten sonra enforce’a geçmek daha güvenli bir ilerleme sağlar.
Adım adım uygulama yaklaşımı
1) Politika taslağını hazırlayın
Hangi MX’lere izin verileceğini belirleyin. Çok geniş wildcard kullanımları esneklik sağlasa da yanlış hedefleri de kapsayabilir; çok dar tanım ise gelecekteki değişikliklerde teslimatı bozabilir. Değişiklik yönetimi açısından, MX değişikliği planlı yapılıyorsa id güncellemesini de aynı değişiklik paketine eklemek faydalıdır.
2) DNS TXT kaydını ekleyin
_mta-sts TXT kaydınızı yayınlayın ve id değerini belirleyin. id, bir “versiyon numarası” gibi düşünülmelidir: Politika dosyasında her anlamlı değişiklikte id’yi değiştirin.
3) Politika dosyasını HTTPS üzerinden yayınlayın
Dosyanın her yerden erişilebilir olduğundan emin olun. Kurumsal güvenlik cihazları veya WAF kuralları, bu dosyaya erişen bot benzeri istekleri yanlışlıkla engelleyebilir. Bu tarz bloklar, göndericilerin politikayı çekememesine ve raporlarda “policy fetch” hatalarına neden olabilir.
4) TLS-RPT’yi etkinleştirip raporları takip edin
_smtp._tls TXT kaydıyla rapor adresinizi belirleyin. Raporları toplayacağınız posta kutusunu düzenli izleyin; ideal olarak filtreleme/etiketleme yapın çünkü raporlar hacimli olabilir.
5) Sorunları giderip enforce’a geçin
Raporlarda tekrar eden sertifika doğrulama hataları, MX uyumsuzlukları veya politika erişim problemleri kalmadığında enforce moduna geçebilirsiniz. Enforce’a geçiş, güvenliği artırır ama aynı zamanda yanlış bir yapılandırmayı da “keskin” hale getirir; bu yüzden değişiklikleri kontrollü yapın.
Yaygın hatalar ve pratik ipuçları
- Politika dosyası format hatası: Satır sonları veya beklenmeyen karakterler, bazı gönderenlerde politikanın reddedilmesine neden olabilir.
- mta-sts subdomain sertifikası: “mta-sts.” alt alan adı için sertifika yoksa veya güvensizse politika indirilemez.
- MX değiştirip id’yi unutmamak: Politika güncellendiğinde id değişmezse, bazı gönderenler eski politikayı cache’te tutup yeni MX’e teslimatı reddedebilir.
- Çok uzun max_age ile acele etmek: İlk geçişte makul bir max_age seçip, her şey stabil olunca artırmak geri dönüşleri kolaylaştırır.
MTA-STS, SPF/DKIM/DMARC ile birlikte nasıl konumlanır?
SPF, DKIM ve DMARC; gönderenin yetkili olup olmadığını ve iletinin sahtecilikle oynanıp oynanmadığını doğrulamaya yardımcı olur. MTA-STS ise “iletim kanalı”nın şifreli olmasını ve TLS’in doğrulanmasını hedefler. Bu nedenle birbirinin alternatifi değil, tamamlayıcısıdır. Sağlıklı bir kurumsal e-posta altyapısında kimlik doğrulama (SPF/DKIM/DMARC) ve aktarım güvenliği (MTA-STS/TLS-RPT) birlikte düşünülmelidir.
Sonuç: Güvenli aktarım için ölçülebilir bir standart
MTA-STS, e-posta aktarımında TLS kullanımını daha güvenilir hale getirerek şifreleme downgrade riskini azaltır; TLS-RPT ise bunun sahada gerçekten nasıl çalıştığını raporlayarak sorunları görünür kılar. Doğru yaklaşım, testing ile başlayıp raporları izlemek, sertifika ve MX tutarlılığını sağlamak ve ardından enforce’a geçmektir.
Eğer MX1Mail gibi yönetilen bir kurumsal e-posta altyapısı kullanıyorsanız, MTA-STS/TLS-RPT planlamasını DNS ve alan adı yönetimi süreçlerinizle birlikte ele almak, geçiş ve değişiklik dönemlerinde kesinti riskini azaltır. En önemlisi, her değişikliği raporlarla doğrulayarak ilerlemek, e-posta teslimatını korurken güvenliği artırmanıza yardımcı olur.