Teknik·
25 Mayıs 2026
E-posta iletimi onlarca yıldır SMTP protokolü üzerine inşa edilmiştir; ancak RFC 5321 ile standartlaşan bu protokol, tasarımı itibarıyla şifrelemeyi zorunlu kılmaz. Ortadaki adam (MITM) saldırıları ve aktarım sırasındaki dinleme riski, özellikle kurumsal göndericiler için ciddi bir tehdit olmaya devam etmektedir. MTA-STS ve TLS-RPT, bu açığı kapatmak amacıyla IETF tarafından geliştirilen ve 2018 yılında RFC 8461 ile RFC 8460 olarak yayımlanan iki tamamlayıcı standarttır.
SMTP sunucuları arasındaki bağlantılar, 1999'dan bu yana RFC 2487 ile tanımlanan STARTTLS uzantısıyla şifrelenebilir hale gelmiştir. Ancak STARTTLS bir fırsatçı (opportunistic) mekanizmadır: karşı sunucu TLS'i desteklemiyorsa ya da sertifikası geçersizse, mesaj yine de düz metin olarak iletilir. Bu "indirgeme" (downgrade) saldırısına kapı aralayan bir davranıştır ve MX kayıtlarının sahte bir sunucuya yönlendirilmesiyle birleştiğinde ciddi veri sızıntısı riskine yol açar. Google Postmaster Tools verileri, 2013 yılında Gmail'in şifreli SMTP trafiğini kamuoyuyla paylaşmaya başlamasından bu yana şifreli iletim oranının belirgin biçimde arttığını ortaya koymaktadır; bununla birlikte STARTTLS'in fırsatçı yapısı nedeniyle bu oran hiçbir zaman güvence altına alınamamıştır.
Mail Transfer Agent Strict Transport Security (MTA-STS), RFC 8461 ile tanımlanmış bir politika mekanizmasıdır. Alıcı alan adı yöneticileri, iki bileşen yayımlayarak gönderen MTA'lara "bize yalnızca geçerli TLS üzerinden bağlan" mesajını verir:
_mta-sts.<alanadi> altında politikanın varlığını ve sürümünü belirten bir TXT kaydı (v=STSv1; id=<politika-id>).https://mta-sts.<alanadi>/.well-known/mta-sts.txt adresinde yayımlanan, izin verilen MX ana bilgisayarlarını, modu ve önbellek süresini (max_age) içeren düz metin dosya.Gönderen bir MTA bu alana e-posta iletmek istediğinde şu adımları izler: DNS kaydını kontrol eder, politika dosyasını HTTPS üzerinden indirir, hedef MX sunucusunun politikada belirtilen ana bilgisayar adlarıyla eşleştiğini doğrular ve bağlantı TLS korumalı değilse ya da sertifika geçersizse iletiyi reddeder. Bu sayede fırsatçı STARTTLS'in aksine, şifreleme bir zorunluluk haline gelir.
Politika dosyasındaki mode alanı üç değer alabilir:
enforce: TLS doğrulaması başarısız olursa mesaj reddedilir ve hata kaydı tutulur.testing: Politika ihlalleri raporlanır ancak mesaj yine de iletilir. Geçiş aşamasında kullanım için idealdir.none: Politika devre dışı bırakılmıştır; yalnızca politikayı geri çekmek amacıyla kullanılır.TLS Reporting (TLS-RPT), RFC 8460 ile tanımlanmış bir raporlama mekanizmasıdır. DMARC'ın (RFC 7489) toplam raporlamasına (aggregate reporting) benzer şekilde çalışır: gönderen MTA'lar, TLS bağlantı denemelerinde karşılaştıkları başarı ve hata bilgilerini JSON formatında özetleyerek belirtilen adrese iletir. TLS-RPT etkinleştirmek için alıcı alan adının _smtp._tls.<alanadi> altında şu biçimde bir TXT kaydı yayımlaması yeterlidir:
v=TLSRPTv1; rua=mailto:tls-raporlar@sirket.com
Raporlar genellikle 24 saatlik pencereler için gönderilir ve başarılı bağlantı sayısı, hata türü ile hata sayısını içerir. Google ve Microsoft, MTA-STS ve TLS-RPT'yi destekleyen büyük posta sağlayıcıları arasındadır; Microsoft 365 belgeleri bu standartların Exchange Online için nasıl uygulandığını ayrıntılı biçimde aktarmaktadır.
MTA-STS'ye benzer bir amaç güden DANE (DNS-based Authentication of Named Entities, RFC 7671), MX sunucularının TLS sertifikalarını doğrudan DNSSEC korumalı DNS'e bağlar. Ancak DANE, DNSSEC'in yaygın olarak benimsenmesini gerektirir; bu nedenle büyük posta sağlayıcılarında DANE desteği sınırlı kalmıştır. MTA-STS ise HTTPS altyapısını kullandığından mevcut CA (Sertifika Otoritesi) ekosistemiyle uyumludur ve DNSSEC zorunluluğu olmaksızın uygulanabilir.
| Özellik | MTA-STS (RFC 8461) | TLS-RPT (RFC 8460) |
|---|---|---|
| Temel işlev | TLS şifreleme zorunluluğu politikası | TLS bağlantı hatalarının raporlanması |
| DNS kaydı | _mta-sts.<domain> TXT |
_smtp._tls.<domain> TXT |
| Politika/yapılandırma dosyası | HTTPS üzerinden mta-sts.txt |
Yalnızca DNS kaydı yeterli |
| Mod seçeneği | enforce / testing / none | — |
| Rapor formatı | — | JSON (gzip sıkıştırılmış) |
| Bağımlılık | Geçerli TLS sertifikası, HTTPS altyapısı | Geçerli rua e-posta adresi |
| DNSSEC zorunlu mu? | Hayır | Hayır |
| İlişkili standart | IETF RFC 8461 (2018) | IETF RFC 8460 (2018) |
MTA-STS ve TLS-RPT uygulaması şu sırayla yapılması önerilen bir süreçtir:
mta-sts.<alanadi> için bir A/CNAME kaydı ve sunucuda HTTPS erişimini etkinleştirin.https://mta-sts.<alanadi>/.well-known/mta-sts.txt adresine version: STSv1, mode: testing, mx: mail.<alanadi> ve max_age: 86400 satırlarını içeren dosyayı yerleştirin.enforce olarak güncelleyin ve id değerini değiştirerek sürümü artırın.MTA-STS ve TLS-RPT, e-posta kimlik doğrulaması için geliştirilmiş diğer standartlarla birlikte bir bütün oluşturur. SPF (RFC 7208), gönderen IP adreslerini yetkilendirir; DKIM (RFC 6376), mesaj bütünlüğünü imzayla güvence altına alır; DMARC (RFC 7489) ise bu ikisini politika ve raporlama katmanıyla birleştirir. MTA-STS bu zincire aktarım katmanı şifreleme güvencesini ekler. Connect365 gibi yüksek hacimli e-posta gönderim platformlarında bu standartların tümünün uygulanması, hem teslim edilebilirliği hem de kurumsal güvenlik duruşunu doğrudan etkiler. Google Postmaster Tools ve Microsoft SNDS (Smart Network Data Services) üzerinden izleme bu sürecin vazgeçilmez parçasıdır.
STARTTLS kullanıldığında şifreleme olanakları mevcuttur, ancak zorunlu değildir. Gönderen MTA TLS bağlantısı kuramadığında mesajı düz metin olarak iletebilir. MTA-STS, bu fırsatçı davranışı ortadan kaldırarak şifrelemeyi politika düzeyinde zorunlu kılar. Özellikle kurumsal ve hassas içerikli iletişimlerde MTA-STS'nin enforce modunda uygulanması önerilir.
Politika dosyasındaki max_age değeri saniye cinsinden belirlenir. Önerilen değer 604800 (7 gün) ile 31557600 (1 yıl) arasıdır. Enforce moduna geçişten önce testing modunda düşük bir max_age (örneğin 86400, yani 1 gün) kullanmak, olası sorunları hızla düzeltme imkânı tanır. Politikanın güncellenmesi için DNS TXT kaydındaki id değerinin değiştirilmesi gerekir; bu sayede gönderen MTA'lar yeni politikayı yeniden indirir.
RFC 8460'a göre TLS-RPT raporları; raporlama dönemini, politika türünü (MTA-STS veya DANE), başarılı bağlantı sayısını ve hata özetlerini JSON formatında içerir. Hata türleri arasında sertifika hatası, MX uyuşmazlığı ve bağlantı zaman aşımı gibi kategoriler yer alır. Bu bilgiler, yapılandırma sorunlarını tespit etmek için değerli bir tanılama kaynağıdır.
Teknik altyapı hazırsa (geçerli TLS sertifikası, HTTPS erişimi olan alt alan adı), DNS TXT kayıtlarının ve politika dosyasının oluşturulması birkaç saat içinde tamamlanabilir. DNS yayılımı genellikle TTL değerine bağlı olarak 24-48 saat sürer. Testing modunda bir hafta izleme sonrası enforce moduna geçiş önerilir; dolayısıyla toplam süreç yaklaşık 1-2 haftalık bir pencereye yayılır.
Alıcı sunucunuzun TLS yapılandırması doğruysa enforce modu sorun yaratmaz. Ancak MX sunucunuzun sertifikası süresi dolmuşsa veya geçersizse, gönderen MTA'lar mesajı reddedebilir. Bu nedenle enforce moduna geçmeden önce MX sunucularının sertifika durumunu ve politika dosyasındaki MX listesinin güncelliğini doğrulamak kritik önem taşır.
Evet, çünkü bu iki standart farklı güvenlik katmanlarını ele alır. DMARC (RFC 7489), gönderenin kimliğini SPF ve DKIM üzerinden doğrular; MTA-STS ise aktarım sırasındaki şifrelemeyi güvence altına alır. DMARC'ın uygulanmış olması, iletim sırasında bir MITM saldırısını önlemez. Kapsamlı bir e-posta güvenliği için SPF, DKIM, DMARC ve MTA-STS'nin birlikte kullanılması gerekir.
MTA-STS'nin teknik gereksinimleri (HTTPS altyapısı, alt alan adı, DNS kaydı) küçük ölçekli yapılar için de erişilebilir düzeydedir. Özellikle müşteri verisi veya finansal bilgi içeren e-postalar gönderen işletmeler için uygulanması önerilir. Birçok yönetilen hosting ve e-posta güvenliği sağlayıcısı bu yapılandırmayı panel üzerinden sunmaktadır.
Politika dosyası, https://mta-sts.<alanadi>/.well-known/mta-sts.txt adresinde geçerli bir HTTPS sertifikasıyla sunulmalıdır. Content-Type başlığının text/plain olması RFC 8461 gereğidir. Dosya, CDN veya statik hosting üzerinde barındırılabilir; önemli olan URL yapısının ve HTTPS sertifikasının doğru olmasıdır.
TLS-RPT raporlarını, e-postayı gönderen taraftaki MTA'lar üretir ve iletir. Google (Gmail), Microsoft (Exchange Online/Outlook.com) ve diğer büyük posta sağlayıcıları RFC 8460 uyumlu raporlama motorlarına sahiptir. Dolayısıyla alanınıza e-posta gönderen büyük sağlayıcıların MTA'larından rapor alırsınız; kendi göndericilerinizden değil.
Çeşitli çevrimiçi araçlar MTA-STS yapılandırmasını test etmek için kullanılabilir. MXToolbox, Hardenize ve internet.nl gibi platformlar DNS kayıtlarını ve politika dosyasının erişilebilirliğini doğrular. Ayrıca curl -s https://mta-sts.<alanadi>/.well-known/mta-sts.txt komutuyla politika dosyasını doğrudan kontrol edebilirsiniz. TLS-RPT raporlarının ulaşıp ulaşmadığını anlamak için de rua adresindeki gelen kutusu izlenmelidir.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.