Şifreleme yazımızda bir cümle kurmuştuk: "TLS yolu korur, S/MIME/PGP zarfı mühürler." O yazı zarfı mühürlemeyi anlattı. Bu yazı, geride bıraktığımız yarıyı tamamlıyor: yolun kendisini. Çünkü TLS'in sinsi bir sorunu var — e-posta dünyasında TLS çoğu zaman "fırsatçı"dır (opportunistic). Yani iki sunucu şifreli konuşmayı deneyebilir, ama araya giren bir saldırgan "ben TLS bilmiyorum" numarası yaparsa, sunucular çoğu zaman sessizce şifresiz iletişime düşer. Kimse hata görmez, kimse uyarılmaz — ve mail, açık kartpostal gibi yol alır.
Mail Teknolojileri Serimizin bu üçüncü yazısında, TLS'i "denenebilir" olmaktan çıkarıp zorunlu kılan iki standardı ele alıyoruz: MTA-STS (TLS'i şart koşar) ve TLS-RPT (TLS'in ne zaman başarısız olduğunu size raporlar). İkisi birlikte, gelen e-postalarınızın taşıma güvenliğini "umarım şifrelenmiştir"den "şifrelenmek zorundadır"a taşır.
1. Önce Sorun: "Fırsatçı TLS" ve Downgrade Saldırısı
İki mail sunucusu birbirine bağlanırken, gönderen sunucu "TLS destekliyor musun?" diye sorar (STARTTLS komutu). Karşı taraf "evet" derse şifreli devam ederler. Sorun şu: bu el sıkışma, saldırının hedefi olabilir.
- Downgrade (düşürme) saldırısı: Araya giren aktif bir saldırgan (man-in-the-middle), STARTTLS yanıtını bozar; gönderen sunucu "karşı taraf TLS bilmiyor" sanıp şifresiz gönderir. İçerik açığa çıkar.
- Sertifika doğrulanmaması: Fırsatçı TLS çoğu zaman sertifikayı sıkı doğrulamaz; sahte bir sunucu araya girip trafiği okuyabilir.
- Sessizlik: En kötüsü — bunların hiçbiri size raporlanmaz. Downgrade olduğunu bilmezsiniz bile.
MTA-STS bu düşürmeyi engeller; TLS-RPT ise sessizliği bozar.
2. MTA-STS — TLS'i Şart Koşmak
MTA-STS (Mail Transfer Agent Strict Transport Security), alan adınıza gelen mailler için "benimle konuşacaksan TLS zorunlu, sertifikam da geçerli olmalı; değilse maili teslim etme" politikası yayınlamanızı sağlar. Bir saldırgan STARTTLS'i düşürmeye çalışsa bile, gönderen sunucu politikanızı gördüğü için şifresiz teslimatı reddeder.
Nasıl kurulur? (üç parça)
- Politika dosyası:
https://mta-sts.alanadiniz.com/.well-known/mta-sts.txtadresinde bir metin dosyası yayınlarsınız. İçinde mod (testingya daenforce), geçerli mail sunucularınız (mx) ve ömür (max_age) bulunur. - DNS TXT kaydı:
_mta-sts.alanadiniz.comaltına bir TXT kaydı:v=STSv1; id=...— bu kayıt, politikanın güncellendiğini gönderen sunuculara haber verir. - HTTPS ve sertifika: Politika dosyasının sunulduğu
mta-stsalt alanı geçerli bir TLS sertifikasıyla HTTPS üzerinden erişilebilir olmalıdır.
Sık yapılan hatalar → doğrusu
- Hata: Doğrudan
enforceile başlamak. Politikada bir MX eksikse ya da sertifika sorunu varsa, gelen mailleriniz sessizce reddedilmeye başlar. Doğrusu: Öncemode: testingile başlayıp TLS-RPT raporlarını izlemek, temiz olduğundan emin oluncaenforce'a geçmek. - Hata: MX listesini eksik/yanlış yazmak. Politikadaki
mxsatırları gerçek mail sunucularınızla birebir uyuşmalı (Microsoft 365 için*.mail.protection.outlook.comgibi). Doğrusu: MX kayıtlarınızı politika dosyasıyla senkron tutmak; sağlayıcı değişince ikisini birlikte güncellemek. - Hata: Politika değişince
id'yi güncellememek. Gönderen sunucular değişikliğiidalanındaki değişimden anlar; güncellemezseniz eski politika önbellekte kalır. Doğrusu: Her politika değişikliğindeid'yi yenilemek (ör. tarih damgası).
3. TLS-RPT — Sessizliği Bozmak
MTA-STS TLS'i şart koşar ama tek başına "bir şey ters gitti mi?" sorusunu yanıtlamaz. TLS-RPT (SMTP TLS Reporting) tam bunu yapar: alan adınıza mail göndermeye çalışan sunucular, TLS el sıkışmasında yaşadıkları başarı/başarısızlıkları size günlük özet raporlar hâlinde gönderir. Böylece "geçen hafta 12 mail TLS kurulamadığı için düşürüldü" gibi bir gerçeği kör kalmadan görürsünüz.
Nasıl kurulur?
Tek bir DNS TXT kaydı yeterlidir: _smtp._tls.alanadiniz.com altına v=TLSRPTv1; rua=mailto:... (ya da bir HTTPS uç noktası). Raporlar buraya akar.
Sık yapılan hata → doğrusu (tanıdık geliyor mu?)
İlk yazımızdaki DMARC hatasının aynısı burada da geçerli: rua adresini kişisel bir kutuya ya da kendi alan adınızdaki yönetici hesabına yazmak. TLS-RPT raporları da JSON formatında gelir ve tek tek incelenmez; kimse bakmaz. Doğrusu: Raporları DMARC raporlarıyla aynı yönetim panelinde toplamak — çalıştığınız güvenlik üreticisinin raporlama servisi (ör. Check Point tarafındaki e-posta güvenlik yönetimi) TLS-RPT'yi de DMARC ile aynı çatı altında görselleştirir. Kural yine aynı: raporu insana değil sisteme okutun.
4. MTA-STS ve DANE: Kısa Bir Not
TLS'i zorunlu kılmanın bir diğer yolu DANE'dir (DNSSEC üzerine kuruludur). İkisi aynı sorunu farklı yoldan çözer: DANE, DNSSEC imzalı bir altyapı gerektirir ve daha katıdır; MTA-STS ise DNSSEC'siz çalışır ve devreye alması daha kolaydır — bu yüzden Microsoft 365 ve Google gibi büyük sağlayıcılar MTA-STS'i yaygın destekler. Çoğu Türkiye kurumu için pratik başlangıç MTA-STS + TLS-RPT'dir; DNSSEC altyapınız olgunsa DANE'i de değerlendirebilirsiniz. İkisi bir arada da kullanılabilir.
5. Bu Katman Kimliği Değil, Gizliliği Korur
Netleştirelim: MTA-STS/TLS-RPT, mailin yolda okunmasını/değiştirilmesini zorlaştırır (taşıma gizliliği). SPF/DKIM/DMARC ise "gönderen gerçekten siz misiniz" sorusunu çözer (kimlik). İkisi farklı katmanlardır ve birbirini tamamlar — MTA-STS phishing'i durdurmaz, DMARC de downgrade saldırısını durdurmaz. Tam koruma için ikisi birlikte kurulur. Bir kurumun e-posta güvenlik olgunluğu tam da bu katmanların hepsinin birden var olmasıyla ölçülür.
Sıkça Sorulan Sorular
Microsoft 365 / Google Workspace kullanıyorum; bunlar zaten TLS yapmıyor mu?
Evet, TLS'i desteklerler — ama fırsatçı modda. MTA-STS politikanız olmadan, size mail gönderen bir sunucu downgrade saldırısına uğrarsa yine şifresiz teslimat olabilir. MTA-STS, bu sağlayıcıların üstüne sizin alanınıza gelen maillerde TLS'i zorunlu kılan katmandır. Hem Microsoft 365 hem Google, MTA-STS'i destekler.
MTA-STS gelen maillerimi mi, giden maillerimi mi korur?
Yayınladığınız MTA-STS politikası, size mail gönderen sunucuları bağlar — yani alan adınıza gelen mailleri korur. Giden maillerinizin korunması, karşı tarafın MTA-STS politikası yayınlamasına bağlıdır. Bu yüzden standart ne kadar yaygınlaşırsa herkes o kadar kazanır; siz politikanızı yayınlayarak hem kendinizi korur hem ekosisteme katkı yaparsınız.
Yanlış kurulum maillerimi kaybettirir mi?
Doğrudan enforce moduna geçip politikada bir MX'i eksik bırakırsanız, evet — o rota reddedilebilir. Bu yüzden her zaman testing modunda başlanır ve TLS-RPT raporları temiz görünene kadar orada kalınır. Doğru sırayla kurulduğunda risk yok denecek kadar azdır.
Durumumu nasıl kontrol ederim?
MXToolbox ve benzeri araçlar MTA-STS politikanızı ve TLS-RPT kaydınızı sorgulayabilir; birçok "e-posta sağlık" testi bu iki kaydı da kapsar. Dilerseniz ücretsiz saha denetimimizde SPF/DKIM/DMARC karnenizle birlikte MTA-STS/TLS-RPT durumunuzu da raporlarız.
Şimdi Ne Yapmalı?
Kimlik katmanınızı (SPF/DKIM/DMARC) kurduysanız, taşıma katmanı bir sonraki mantıklı adımdır. İki soruyla başlayın: (1) Alan adınızın bir MTA-STS politikası var mı? (2) TLS başarısızlıklarını raporlayan bir TLS-RPT kaydınız var mı?
- Ücretsiz Saha Denetimi: SPF/DKIM/DMARC karnenizin yanında MTA-STS/TLS-RPT durumunuz da raporlanır.
- Yönetilen kurulum: MTA-STS'i
testing'denenforce'a güvenli geçişle kurar, TLS-RPT raporlarını DMARC ile aynı panelde toplarız.
Bu yazı hakkında: Mail Teknolojileri Serimizin üçüncü yazısıdır; şifreleme yazımızdaki "TLS yolu korur" cümlesinin devamıdır. Bir sonraki yazı, forwarding'de kimliğin nasıl korunduğunu (ARC) ele alacak. Kinetik Bilişim, Check Point Software Technologies'in Advanced Partner 2026 seviyesindeki Türkiye iş ortağıdır; Email, Endpoint & Browser, Mobile ve SASE Solution Specialization akreditasyonlarına sahiptir. Yazar Kemal Özleyen, Check Point Workspace Security Expert sertifikalı bir siber güvenlik mühendisidir.
