MTA-STS ile Kurumsal E-posta İletişiminizde Tam Şifreleme ve Güvenlik Kalkanı

E-posta iletişimi, şirketler için kritik bir iş aracı olmasının yanı sıra, siber saldırganların da başlıca hedefidir. Özellikle aktarım halindeki e-postaların güvenliği, hem veri gizliliği hem de yasal uyumluluk açısından büyük önem taşır. MTA-STS (Mail Transfer Agent Strict Transport Security), e-posta aktarım aracılarının (MTA) güvenli bir şekilde iletişim kurmasını sağlayan, RFC 8461 ile standartlaşmış bir protokoldür.

Geleneksel olarak, e-posta sunucuları TLS şifrelemesi kullanmaya çalışsa da (opportunistic TLS), bu zorunlu değildir. Eğer hedef sunucu TLS'i desteklemiyorsa veya bir saldırgan iletişimi bozarak TLS'i devre dışı bırakırsa (TLS downgrade attack), e-postalar şifresiz, açık metin olarak gönderilmeye devam eder. Bu durum, araya girme (Man-in-the-Middle - MITM) saldırganlarının e-posta içeriğini okumasına, değiştirmesine veya hassas verileri ele geçirmesine olanak tanır.

MTA-STS, bu güvenlik açığını kapatmak için tasarlanmıştır. Bir domain için MTA-STS politikası tanımlandığında, gönderen MTA'lar, alıcı domainin yalnızca TLS 1.2 ve üzeri sürümlerle şifrelenmiş bağlantıları kabul ettiğini ve belirli MX kayıtlarını kullandığını bilir. Bu sayede, saldırganlar TLS'i devre dışı bırakamaz, e-posta yönlendirmesini manipüle edemez ve iletişimi şifresiz hale getiremez. Kurumsal e-postalarınızın iletim güvenliğini en üst seviyeye çıkarmak için MTA-STS entegrasyon hizmetlerimizden yararlanabilirsiniz.

Bu protokol, özellikle şirket içi ve şirketler arası hassas veri alışverişlerinde, KVKK ve GDPR gibi veri koruma mevzuatlarına uyum sağlamada kritik bir rol oynar. MTA-STS, e-posta güvenliğini DNS tabanlı bir yaklaşımla güçlendirirken, Kurumsal E-posta İçin Sürekli DNS Güvenlik Denetimi Rehberi gibi diğer güvenlik katmanlarıyla birlikte kullanıldığında tam bir koruma kalkanı oluşturur.

MTA-STS'nin temelinde iki ana bileşen bulunur: bir DNS TXT kaydı ve bir HTTPS üzerinden erişilebilen politika dosyası (`mta-sts.txt`).

• DNS TXT Kaydı: Gönderen bir MTA, bir domain için e-posta göndermeden önce o domainin MTA-STS politikasını sorgular. Bu sorgu, hedef domainin DNS kayıtlarında `_mta-sts.` formatında bir TXT kaydını arar. Bu kayıt, politikanın mevcut olduğunu ve sürüm numarasını (v=STSv1; id=) belirtir. id alanı, politika dosyasının her güncellenişinde değişmesi gereken bir benzersiz tanımlayıcıdır. DNS güvenliğinin bu noktadaki önemi için E-posta Güvenliği: DNS Saldırıları, Tünelleme ve Önbellek Zehirlenmesi Kalkanı makalemizi inceleyebilirsiniz.
• Politika Dosyası (`mta-sts.txt`): DNS TXT kaydında belirtilen id ile eşleşen politika dosyası, https://mta-sts./.well-known/mta-sts.txt adresinde HTTPS üzerinden yayınlanmalıdır. Bu dosya, aşağıdaki gibi anahtar-değer çiftlerinden oluşur:
  • version: STSv1: Politika sürümünü belirtir.
  • mode: enforce | testing | none: Politikanın nasıl uygulanacağını belirler. testing modunda hatalar raporlanır ancak bağlantılar zorlanmaz. enforce modunda politikaya uymayan bağlantılar reddedilir. none ise MTA-STS'i devre dışı bırakır.
  • mx: , mx: : Politikanın geçerli olduğu MX kayıtlarını listeler. Bu kayıtlar, DNS'teki MX kayıtlarınızla eşleşmelidir.
  • max_age: : Politikanın gönderen MTA'lar tarafından ne kadar süreyle önbelleğe alınacağını belirtir (genellikle 604800 saniye = 7 gün).

Çalışma Prensibi:

1. Gönderen MTA, alıcı domain için bir e-posta gönderecekken, ilk olarak alıcı domainin _mta-sts. TXT kaydını sorgular.
2. Eğer bir kayıt bulunursa ve geçerliyse, gönderen MTA https://mta-sts./.well-known/mta-sts.txt adresinden politika dosyasını indirir.
3. Politika dosyasındaki mode değeri enforce ise, gönderen MTA yalnızca HTTPS üzerinden belirtilen MX kayıtlarına, TLS 1.2+ şifrelemesi kullanarak ve geçerli bir sertifikayla bağlantı kurmaya çalışır. Eğer bu şartlar sağlanamazsa, e-posta gönderimi reddedilir veya geçici olarak ertelenir.
4. Politika dosyası testing modunda ise, uyumsuzluklar raporlanır ancak e-posta gönderimi yine de gerçekleştirilebilir, bu da dağıtım öncesi testler için idealdir.

Bu süreç, e-posta trafiğinin her zaman şifreli ve yetkili sunucular üzerinden akmasını sağlayarak, özellikle SMTP port 25 üzerinden yapılan opportunistic TLS bağlantılarındaki zafiyetleri ortadan kaldırır. Kurumsal e-posta altyapınızı bu seviyede güvence altına almak için uzman ekibimizden destek alabilirsiniz. Unutmayın, doğru yapılandırılmış bir MTA-STS, kurumsal e-posta güvenliğinizin temel taşlarından biridir.

MTA-STS'in kurulumu, teknik detaylara dikkat gerektirdiğinden bazı yaygın hatalara yol açabilir. Bu hataların farkında olmak ve doğru çözümleri uygulamak, e-posta güvenliğinizin kesintisiz devamı için elzemdir.

• Politika Dosyasına (mta-sts.txt) Erişim Sorunları:

  Hata: Politika dosyasının https://mta-sts./.well-known/mta-sts.txt adresinden erişilebilir olmaması veya HTTPS yerine HTTP üzerinden sunulması. Yanlış dizin yapısı veya SSL sertifikası eksikliği de sıkça görülür.

  Çözüm: Alan adınız için mta-sts. alt alan adının oluşturulduğundan, bu alt alan adına geçerli bir SSL sertifikası (Let's Encrypt gibi ücretsiz seçenekler de mevcut) atandığından ve dosyanın tam olarak belirtilen yolda (.well-known/mta-sts.txt) erişilebilir olduğundan emin olun. Tarayıcınızdan bu URL'i ziyaret ederek erişilebilirliğini test edin.

• Yanlış DNS TXT Kaydı Yapılandırması:

  Hata: _mta-sts. TXT kaydının yanlış formatta olması, id değerinin politika dosyasındaki son güncellemeyle eşleşmemesi veya kaydın hiç oluşturulmaması.

  Çözüm: TXT kaydının v=STSv1; id= formatında olduğundan emin olun. id değeri, politika dosyasının her güncellenişinde (küçük bir değişiklik bile olsa) mutlaka değiştirilmelidir. Aksi takdirde, gönderen MTA'lar eski politikayı önbellekten okumaya devam edebilir. DNS kayıtlarınızın doğru ve güncel olduğundan emin olmak için Kurumsal E-posta İçin Sürekli DNS Güvenlik Denetimi Rehberi'mizden faydalanabilirsiniz.

• MX Kaydı Uyumsuzluğu:

  Hata: mta-sts.txt dosyasında belirtilen mx kayıtlarının, domainin gerçek MX kayıtlarıyla tam olarak eşleşmemesi veya eksik olması.

  Çözüm: Politika dosyasındaki mx girişlerinin, DNS'te tanımlı olan tüm MX kayıtlarınızla (tam nitelikli alan adı - FQDN olarak) birebir aynı olduğundan emin olun. Örneğin, DNS'teki MX kaydınız mail.domain.com ise, politika dosyasında da mx: mail.domain.com şeklinde yer almalıdır.

• TLS Yapılandırma Sorunları:

  Hata: E-posta sunucularınızın TLS 1.2 veya üzeri sürümleri desteklememesi, sertifikalarının geçersiz olması, süresinin dolması veya zincirinin eksik olması.

  Çözüm: E-posta sunucularınızın TLS yapılandırmasını kontrol edin. Tüm sunucuların güncel TLS standartlarını (tercihen TLS 1.2 veya 1.3) desteklediğinden ve geçerli, güvenilir bir sertifika kullandığından emin olun. Sertifika yenilemelerini düzenli takip edin.

• max_age Değerinin Yanlış Ayarlanması:

  Hata: max_age değerinin çok kısa veya çok uzun ayarlanması. Çok kısa olması, sık sık politika sorgulamasına yol açarak performansı etkileyebilir; çok uzun olması ise politika değişikliklerinin geç yayılmasına neden olabilir.

  Çözüm: Genellikle max_age için 604800 saniye (7 gün) veya 1209600 saniye (14 gün) gibi değerler önerilir. Politika dosyasını ilk devreye alırken mode: testing ile başlayarak, gözlem süresi sonrasında enforce moduna geçmek en güvenli yaklaşımdır. Bu geçiş sırasında max_age değerini kademeli olarak artırabilirsiniz.

Bu hataların üstesinden gelmek için teknik bilgi ve dikkat gereklidir. kurumsaleposta.app olarak, MTA-STS entegrasyonu ve e-posta güvenliği danışmanlığı konusunda uzman ekibimizle yanınızdayız. 0850 885 09 55 numaralı hattımızdan bize ulaşarak destek alabilirsiniz.