MTA-STS ve TLS-RPT: adım adım kurulum

MTA-STS'in çözdüğü sorun

Bir posta sunucusu başka bir sunucuya teslimat yaparken alıcı alan adının MX kayıtlarını sorgular, 25 numaralı porta bağlanır ve alıcı taraf sunuyorsa STARTTLS ile bağlantıyı TLS'e yükseltir. STARTTLS yoksa ya da sertifika geçersizse gönderenlerin çoğu mesajı yine de düz metin olarak teslim eder. Bu davranış postanın akmaya devam etmesini sağlar, ancak bağlantıya ya da DNS'e müdahale edebilen bir saldırganın STARTTLS teklifini kaldırıp mesajı okuyabilmesi anlamına da gelir. Klasik SMTP'de alıcının şifrelemeyi gerçekten desteklediğini önceden bildiren hiçbir işaret bulunmadığı için gönderen taraf, gördüğü bağlantının düşürülmüş olup olmadığını ayırt edemez. Eksik olan şey şifrelemenin kendisi değil, şifrelemenin zorunlu olduğunu önceden söyleyen bir beyandır.

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) bir alıcı alan adının TLS desteklediğini ve hangi MX sunucularının meşru olduğunu yayımlamasını sağlar. Bunu uygulayan gönderen sunucular politikayı önbelleğe alır ve politika enforce modundayken şifrelenmemiş ya da kimliği doğrulanmamış bir bağlantı üzerinden teslimat yapmayı reddeder. TLS-RPT (RFC 8460) ise bunun raporlama tarafındaki tamamlayıcısıdır: gönderenler size başarılı ve başarısız TLS bağlantılarının günlük özetlerini gönderir. İkisi birlikte hem bir beyan hem de o beyanın sahadaki karşılığını gösteren bir geri bildirim kanalı oluşturur. Politikayı yayımlamak DNS ve HTTPS dışında hiçbir altyapı gerektirmediği için mevcut posta kurulumunuzu değiştirmeden eklenebilir.

Başlamadan önce

MTA-STS yalnızca her MX sunucusu, MX kaydındaki ad için geçerli ve herkesçe güvenilen bir sertifikayla STARTTLS'i zaten kabul ediyorsa işe yarar. Barındırılan posta kutusu sağlayıcıları kendi MX adları için bu koşulu sağlar. Kendi posta sunucunuzu işletiyorsanız önce bunu kontrol edin; kendinden imzalı ya da başka bir ad için verilmiş bir sertifika enforce modunda başarısız olur. Bu kontrolü politikayı yayımlamadan önce yapmak önemlidir, çünkü enforce moduna geçtikten sonra ortaya çıkan bir sertifika sorunu doğrudan teslimat kaybına dönüşür. Aynı kontrolü yedek MX sunucularınız için de yapın; en az kullanılan sunucu çoğu zaman gözden kaçandır.

1. MX sunucularınızı MX ve SMTP aracıyla listeleyin.
2. Her MX sunucu adının kendi sertifikası tarafından kapsandığını doğrulayın. TLS Kontrolü sertifikayı 443 numaralı porttan okur; 25 numaralı port için aşağıda gösterildiği gibi openssl s_client kullanın.
3. Politika dosyasını nerede barındıracağınıza karar verin: küçük bir statik site, HTTPS arkasındaki bir nesne deposu ya da mevcut web sunucunuz.
4. TLS raporları için bir adres ya da HTTPS uç noktası seçin; tercihen bunun için ayrılmış bir posta kutusu olsun.

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_return_error </dev/null | openssl x509 -noout -subject -issuer -enddate -ext subjectAltName

Adım 1: TLS-RPT yayımlayın

İşe raporlamayla başlayın, çünkü hiçbir maliyeti yoktur ve siz henüz hiçbir şeyi zorunlu kılmadan sorunları gösterir. Kayıt, alan adınızın altında _smtp._tls adresinde duran bir TXT kaydıdır. rua değeri bir mailto: ya da https: URI'sidir; birden fazla hedef virgülle ayrılır. Bu kaydı yayımlamak posta akışında hiçbir şeyi değiştirmez, yalnızca gönderenlere raporları nereye göndereceklerini söyler. Bu yüzden MTA-STS planınız ne olursa olsun ilk adım olarak güvenle eklenebilir.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Raporlar JSON belgeleridir; genellikle gzip ile sıkıştırılır ve TLS-RPT destekleyen sağlayıcılar tarafından günde bir kez gönderilir. Her rapor gönderenin bulduğu politikayı, başarılı oturum sayısını ve türlerine göre gruplanmış hataları listeler. MTA-STS olmadan bile raporlar, gönderenlerin MX sunucularınızla TLS anlaşması yapıp yapamadığını gösterir. Bu nedenle TLS-RPT'yi tek başına, posta altyapınız için sürekli çalışan bir sağlık kontrolü olarak da okuyabilirsiniz.

Adım 2: politika dosyasını barındırın

Politika, tam olarak https://mta-sts.<alan adınız>/.well-known/mta-sts.txt adresinden sunulan kısa bir metin dosyasıdır. mta-sts.example.com sunucusunun web sunucunuzu gösteren bir DNS kaydına ve bu ad için herkesçe güvenilen bir sertifikaya ihtiyacı vardır. Gönderenler politikayı çekerken HTTP yönlendirmelerini izlememelidir (RFC 8461 §3.3), bu yüzden dosyayı 200 durum koduyla doğrudan sunun. Dosyanın içeriği düz metin olmalı ve satırları alan adınızın MX kalıplarını olduğu gibi yansıtmalıdır.

version: STSv1
mode: testing
mx: mail.example.com
mx: *.mx.example.net
max_age: 86400

*.mx.example.net gibi bir joker kalıp mx1.mx.example.net ile eşleşir; mx.example.net adının kendisiyle ya da a.b.mx.example.net ile eşleşmez. MX kayıtlarınızın kullandığı her kalıbı listeleyin; eksik bir kalıp enforce modunda teslimatı başarısız kılar. Başka alan adları altında duran yedek MX sunucularını da unutmayın, çünkü bunlar yalnızca birincil sunucu erişilemez olduğunda devreye girer ve eksik kalıp ancak o anda fark edilir.

server {
    listen 443 ssl;
    server_name mta-sts.example.com;
    ssl_certificate     /etc/ssl/mta-sts.example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/mta-sts.example.com/privkey.pem;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        return 200 "version: STSv1\nmode: testing\nmx: mail.example.com\nmax_age: 86400\n";
    }

    location / {
        return 404;
    }
}

Dosyayı dışarıdan doğrulayın: curl -sS https://mta-sts.example.com/.well-known/mta-sts.txt komutu politikayı hiçbir yönlendirme olmadan yazdırmalı, TLS Kontrolü ise bu sunucu adı için geçerli bir sertifika göstermelidir. Kontrolü kendi ağınızın dışından yapın, çünkü iç DNS kayıtları ya da vekil sunucular sonucu kolayca yanıltıcı hâle getirir.

Adım 3: _mta-sts kaydını yayımlayın

TXT kaydı bir politikanın var olduğunu duyurur ve bir id taşır. Gönderenler bu kimliği önbelleklerindeki politikayla karşılaştırır ve kimlik değiştiğinde dosyayı yeniden çeker. Kimlik 1 ila 32 harf ve rakamdan oluşur; zaman damgası kullanmak her güncellemede kimliği değiştirmeyi kolaylaştırır. Kimliğin değerinin kendisi bir anlam taşımaz, önemli olan tek şey dosya her değiştiğinde farklı olmasıdır.

_mta-sts.example.com. IN TXT "v=STSv1; id=20260915T0900"

Kaydı, _mta-sts.example.com için TXT kayıt türüyle DNS Sorgulama aracından kontrol edin. v=STSv1 ile başlayan tam olarak bir kayıt bulunmalıdır.

Adım 4: raporları okuyun, sonra zorunlu kılın

Politikayı en az birkaç hafta boyunca testing modunda bırakın ve TLS-RPT raporlarını okuyun. Görmek istediğiniz tablo, büyük gönderenlerden gelen istikrarlı bir başarılı oturum sayısı ve ara sıra yaşanan tekil ağ hataları dışında hiç hata bulunmamasıdır. certificate-host-mismatch ya da sts-policy-fetch-error türündeki hatalar zorunlu kılmadan önce mutlaka giderilmelidir. Raporların birkaç farklı büyük sağlayıcıdan gelmesini beklemek de önemlidir, çünkü tek bir kaynaktan gelen veri resmin yalnızca bir bölümünü gösterir.

Raporlar temiz olduğunda mode değerini enforce yapın, max_age değerini yükseltin (bir ila birkaç hafta yaygındır, örneğin yedi gün için 604800) ve DNS'teki kimliği güncelleyin. O andan itibaren bunu destekleyen gönderenler, TLS doğrulamasından geçemeyen bir bağlantı üzerinden alan adınıza teslimat yapmayı reddeder ve düz metne düşmek yerine daha sonra yeniden dener. Bu yeniden deneme davranışı sayesinde geçici bir sorun mesaj kaybına değil yalnızca gecikmeye yol açar.

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mx.example.net
max_age: 604800

Bir TLS-RPT raporunu okumak

Rapor, tek bir gönderen kuruluşun bir günlük teslimat denemelerini anlatan bir JSON belgesidir. policies dizisi, gönderenin değerlendirdiği her politika için bir girdi içerir ve her girdide başarılı ile başarısız oturumların özeti bulunur. Her şey yolundayken total-failure-session-count sıfırdır ve failure-details dizisi hiç yer almaz. Belge ayrıca gönderen kuruluşun adını ve rapor aralığını taşır, böylece hangi günün verisine baktığınızı kesin olarak bilirsiniz.

{
  "organization-name": "Sender Example Inc.",
  "date-range": { "start-datetime": "2026-09-14T00:00:00Z", "end-datetime": "2026-09-14T23:59:59Z" },
  "contact-info": "smtp-tls-reporting@sender.example.net",
  "report-id": "2026-09-14T00:00:00Z_example.com",
  "policies": [{
    "policy": {
      "policy-type": "sts",
      "policy-string": ["version: STSv1", "mode: testing", "mx: mail.example.com", "max_age: 86400"],
      "policy-domain": "example.com"
    },
    "summary": { "total-successful-session-count": 1480, "total-failure-session-count": 12 },
    "failure-details": [{
      "result-type": "certificate-expired",
      "receiving-mx-hostname": "mail.example.com",
      "receiving-ip": "192.0.2.10",
      "failed-session-count": 12
    }]
  }]
}

Önce policy-string alanını okuyun: gönderenin tam olarak hangi politikayı kullandığını gösterir ve hâlâ eski bir önbellek sürümünü elinde tutan gönderenleri ortaya çıkarır. Ardından her hata girdisine tek tek bakın. receiving-mx-hostname ve receiving-ip alanları hangi sunucunuzun başarısız olduğunu, result-type alanı ise bunun nedenini söyler.

no-policy-found değerindeki bir policy-type, gönderenin alan adınız için MTA-STS ya da DANE politikası bulamadığı anlamına gelir. Bu, MTA-STS'i yayımlamadan önce beklenen bir durumdur; sonrasında görülmesi ise bir DNS ya da barındırma sorununun işaretidir. Tek bir gönderenden gelen ara sıra ve düşük hata sayıları ağ gürültüsü olabilir; birden fazla büyük gönderenden gelen tekrarlayan hatalar gerçek sorunlardır. Şüphe duyduğunuzda aynı sunucuyu elle test edin, çünkü rapordaki hata türü hangi kontrolün düştüğünü zaten doğrudan söyler.

Sık yapılan hatalar

Bunların çoğu bir gün içinde TLS-RPT raporlarında görünür; test aşaması tam da bu yüzden vardır. Zorunlu kılmaya geçtikten sonra da raporların akmasını ve okunmasını sürdürün, çünkü sertifika süresinin dolması ve MX değişiklikleri tek seferlik kurulum sorunları değil, süreklilik taşıyan risklerdir. Raporları düzenli olarak bakılan bir posta kutusuna ya da bir panoya yönlendirmek, bu riski kalıcı biçimde küçültür.

Güvenle işletmek

MX sunucularını değiştirmek

Yeni bir MX sunucusu eklemeden ya da yeni bir sağlayıcıya geçmeden önce o sunucunun kalıbını politikaya ekleyin, kimliği değiştirin ve en az eski max_age süresi kadar bekleyin; böylece her gönderen yeni politikayı çekmiş olur. MX kayıtlarını ancak ondan sonra değiştirin. Bunu ters sırada yapmak, elinde önbellekli politika bulunan gönderenlerin yeni sunucuya teslimatı reddetmesine yol açar.

Sertifikalar

enforce modunda bir MX sunucusundaki süresi dolmuş sertifika, destekleyen gönderenlerden gelen teslimatı tamamen durdurur. Hem MX sunucularınız hem de mta-sts.example.com için yenilemeyi otomatikleştirin ve bitiş tarihlerini izleyin. TLS-RPT certificate-expired hatalarını raporlar, ama o noktaya gelindiğinde posta zaten gecikmiş durumdadır.

MTA-STS'i kapatmak

Kayıtları öylece silmeyin: gönderenler önbellekteki politikanın süresi dolana kadar onu uygulamayı sürdürür. Dosyayı mode: none ile yayımlayın, kimliği değiştirin, eski max_age süresinin geçmesini bekleyin ve TXT kaydı ile dosyayı ancak ondan sonra kaldırın.

version: STSv1
mode: none
max_age: 86400

MTA-STS ve DANE

SMTP için DANE (RFC 7672) aynı downgrade sorununu, MX sunucusunun sertifikasını ya da anahtarını DNS üzerinde sabitleyen TLSA kayıtlarıyla çözer. Bu kayıtların güvenilir olması için DNSSEC'e dayanır; MTA-STS ise HTTPS'e ve herkesçe tanınan sertifika otoritesi sistemine dayanır. Gönderenlerin bir bölümü birini, bir bölümü diğerini, bazıları da her ikisini destekler. Dolayısıyla bu ikisi birbirinin yerine geçen seçenekler değil, farklı gönderen kitlelerine ulaşan iki ayrı yoldur.

Alan adınız DNSSEC ile imzalıysa ve posta sağlayıcınız DANE destekliyorsa ikisini birden yayımlamak makuldür. DNSSEC bir seçenek değilse MTA-STS, sıradan DNS ve web barındırmayla korumanın büyük bölümünü size verir. DNSSEC rehberi bir bölgeyi imzalamanın neleri gerektirdiğini anlatır.

İkisi hiçbir çakışma olmadan bir arada var olabilir. DANE destekleyen ve geçerli TLSA kayıtları bulan bir gönderen DANE kullanır; yalnızca MTA-STS destekleyen bir gönderen sizin politikanızı kullanır. TLS-RPT raporları her ikisini de kapsar ve policy-type alanı bir gönderenin hangisini uyguladığını size söyler.

SSS

Kaynaklar

• RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
• RFC 8460: SMTP TLS raporlama
• RFC 7672: Fırsatçı DANE TLS ile SMTP güvenliği
• RFC 3207: TLS üzerinden güvenli SMTP için servis uzantısı (STARTTLS)
• Google Workspace: MTA-STS ve TLS raporlama hakkında