TLS-RPT Kaydı ve Raporlarını Okuma

MTA-STS politikanı yayınladın, enforce moduna geçtin ve artık kimsenin sana şifresiz mail gönderemeyeceğini biliyorsun. Peki birinin TLS el sıkışması sırasında hata alıp maili teslim edemediğini nereden öğreneceksin? Gönderen taraf sana bunu haber vermez; mail sessizce kuyrukta bekler, sonunda geri döner ve sen ancak müşteri telefon ettiğinde durumu fark edersin. TLS-RPT kaydı tam olarak bu kör noktayı kapatır: gönderen sunuculara "bana bağlanırken TLS tarafında ne yaşadıysan günlük bir raporla anlat" demenin standart yoludur.

Bu rehberde TLS-RPT kaydını nasıl kuracağını, gelen JSON raporlarının hangi alanlardan oluştuğunu ve her hata tipinin gerçekte neye işaret ettiğini anlatacağım. Raporları elle okumak yerine nasıl otomatik işleyeceğine, hangi sayıların alarm verdiğine ve tipik senaryolarda hangi düzeltmenin yapılacağına da değineceğim. TLS-RPT'yi MTA-STS'ten önce kurmanı öneririm; böylece politikayı sıkılaştırmadan önce elinde gerçek veri olur.

TLS-RPT Ne İşe Yarar#

TLS-RPT, MTA-STS ve DANE gibi zorunlu TLS mekanizmalarının gözü kulağıdır. Politikan var ama teslimatlar başarısız oluyorsa, bu başarısızlık gönderen tarafta yaşanır ve senin log'unda hiç iz bırakmaz — çünkü bağlantı zaten kurulamamıştır. TLS-RPT, gönderen sunucuların bu deneyimi günlük olarak toplayıp sana JSON biçiminde göndermesini sağlar.

Raporlar toplu (aggregate) niteliktedir; tek tek maillerin içeriğini değil, "şu gönderen sunucu, senin şu MX sunucuna 1420 başarılı, 37 başarısız oturum denedi ve başarısızlıkların hepsi sertifika isim uyuşmazlığıydı" tarzı istatistikleri taşır. Kişisel veri içermez, bu yüzden gizlilik açısından DMARC'ın forensic raporlarından çok daha rahattır.

Dikkat: TLS-RPT ile DMARC raporları farklı şeyleri ölçer ve birbirinin yerine geçmez. DMARC raporları kimlik doğrulamayı, TLS-RPT ise taşıma katmanı şifrelemesini kapsar. İkisini birlikte kurmak, mail altyapının iki ayrı katmanını da görünür kılar; DMARC raporlarını okumanın ayrıntısı DMARC raporu nasıl okunur yazısında.

Kaydı Nasıl Kurulur#

TLS-RPT kurulumu tek bir DNS TXT kaydından ibarettir. Kayıt, _smtp._tls alt alan adında yayınlanır.

; Raporları bir posta adresine gönder
_smtp._tls.firmaniz.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

; Birden fazla hedef tanımlayabilirsin (virgülle ayrılır)
_smtp._tls.firmaniz.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected],https://rapor.firmaniz.com/tlsrpt"

Kayıt yalnızca iki etiketten oluşur: v sürümü belirtir ve her zaman TLSRPTv1 olmalıdır, rua ise raporun gönderileceği hedefi tanımlar. Hedef bir mailto: adresi ya da bir https:// uç noktası olabilir; HTTPS seçeneğinde raporlar POST ile gönderilir.

Kaydın yayında olduğunu doğrula:

dig _smtp._tls.firmaniz.com TXT +short
# "v=TLSRPTv1; rua=mailto:[email protected]"

Rapor adresi olarak ayrı bir posta kutusu kullan. Raporlar günlük gelir ve her gönderenden ayrı bir mail alırsın; Gmail, Microsoft, Yahoo ve büyük kurumsal sağlayıcılar hepsi ayrı ayrı rapor gönderir. Bunları kişisel kutuna düşürürsen bir hafta içinde okumayı bırakırsın. Raporların bir başkasının alan adına gönderilmesini istiyorsan, o alan adında bir yetkilendirme kaydı gerekir — bu, DMARC'taki harici rapor yetkilendirmesiyle aynı mantıktır.

Rapor JSON Yapısı: Alan Alan#

Raporlar .json.gz biçiminde sıkıştırılmış ek olarak gelir. Açtığında karşılaşacağın yapı şudur:

{
  "organization-name": "Ornek Mail Saglayicisi",
  "date-range": {
    "start-datetime": "2026-08-24T00:00:00Z",
    "end-datetime": "2026-08-24T23:59:59Z"
  },
  "contact-info": "[email protected]",
  "report-id": "2026-08-24T00:00:00Z_firmaniz.com",
  "policies": [
    {
      "policy": {
        "policy-type": "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.firmaniz.com",
          "max_age: 604800"
        ],
        "policy-domain": "firmaniz.com",
        "mx-host": ["mail.firmaniz.com"]
      },
      "summary": {
        "total-successful-session-count": 1420,
        "total-failure-session-count": 37
      },
      "failure-details": [
        {
          "result-type": "certificate-host-mismatch",
          "sending-mta-ip": "203.0.113.45",
          "receiving-mx-hostname": "mail2.firmaniz.com",
          "failed-session-count": 37
        }
      ]
    }
  ]
}

Okuma sırası şöyle olmalı: önce summary bloğuna bak ve başarısızlık oranını hesapla. total-failure-session-count sıfırsa o gün için yapacak bir şey yok. Sıfır değilse failure-details dizisine geç; her eleman bir hata tipini, o hatayı yaşayan gönderen IP'sini ve kaç oturumda yaşandığını söyler.

receiving-mx-hostname alanı en değerli bilgidir çünkü sorunun hangi MX sunucunda olduğunu doğrudan söyler. Yukarıdaki örnekte tüm başarısızlıklar mail2.firmaniz.com üzerinde toplanmış; yani birincil sunucun sağlıklı, yedek sunucunun sertifikası sorunlu. Bu tek satır, saatlerce sürebilecek bir aramayı bitirir.

Hata Tiplerini Okumak#

result-type alanı, sorunun tam olarak ne olduğunu standart bir sözcükle söyler. Aşağıdaki tablo, en sık göreceğin tipleri ve her birinin gerçek karşılığını içeriyor.

En sık gördüğüm üç tip certificate-host-mismatch, certificate-expired ve sts-webpki-invalid. Üçü de aynı kök sebepten çıkar: sertifika yenilendi ama servis reload edilmedi, ya da yedek bir sunucu sertifika otomasyonunun dışında kaldı. starttls-not-supported görürsen sorun sertifikada değil yapılandırmadadır; Postfix'te smtpd_tls_cert_file ve smtpd_tls_key_file satırlarının doğru dosyaları gösterdiğini kontrol et — ayrıntısı Postfix main.cf yapılandırması yazısındaki TLS bölümünde.

sts-policy-fetch-error ise MTA-STS tarafındaki bir sorunu işaret eder ve genellikle politika dosyasının HTTP'den HTTPS'e yönlendiriliyor olmasından kaynaklanır; MTA-STS kaydı yazısında bu şartı ayrıntılı anlattım.

Raporları Toplama ve İşleme Pratiği#

İlk hafta raporları elle açıp okumak öğretici olur ama bu sürdürülebilir değildir. Günde beş-on rapor gelir ve her birini sıkıştırmadan çıkarıp JSON içinde gezmek zaman kaybıdır. jq kurulu bir sunucuda tek satırlık bir özet, günlük kontrolü saniyelere indirir:

# Tüm raporlardan yalnızca başarısızlık içerenleri özetle
for f in /var/mail/tlsrpt/*.json.gz; do
  gunzip -c "$f" | jq -r '
    .["organization-name"] as $org
    | .policies[]
    | select(.summary["total-failure-session-count"] > 0)
    | "\($org) -> \(.summary["total-failure-session-count"]) basarisiz oturum",
      (."failure-details"[]?
        | "    \(."result-type") x\(."failed-session-count") @ \(."receiving-mx-hostname")")
  '
done

Örnek çıktı şuna benzer ve tek bakışta hangi sunucunun sorunlu olduğunu söyler:

Ornek Mail Saglayicisi -> 37 basarisiz oturum
    certificate-host-mismatch x37 @ mail2.firmaniz.com
Baska Saglayici -> 4 basarisiz oturum
    validation-failure x4 @ mail.firmaniz.com

Raporları arşivlemeyi de ihmal etme. Bir sorunun ne zaman başladığını bilmek, onu çözmenin yarısıdır; ham .json.gz dosyalarını tarihe göre klasörleyip en az altı ay saklamanı öneririm. Rapor kutusuna gelen mailleri otomatik olarak diske yazmak için Dovecot tarafında basit bir Sieve kuralı ya da getmail gibi bir araç yeterlidir.

İzleme pratiğinde şu eşikleri kullanmanı öneririm: başarısızlık oranı binde birin altındaysa gürültü kabul et ve not al; yüzde birin üstüne çıktıysa aynı gün incele; belirli bir MX sunucusunda art arda iki gün aynı result-type görünüyorsa bu geçici bir sorun değil, bir yapılandırma hatasıdır. Toplam oturum sayısındaki ani düşüş de dikkat çekici bir sinyaldir; genellikle bir gönderenin sana mail göndermeyi tamamen bıraktığı anlamına gelir.

Bir başka faydalı alışkanlık, raporlardaki gönderen IP'lerini kendi log'unla karşılaştırmaktır. Rapor "37 oturum başarısız" diyorsa senin /var/log/mail.log dosyanda o IP'den gelen hiçbir bağlantı görünmemesi normaldir — çünkü bağlantı TLS aşamasında koptu ve mail hiç kabul edilmedi. Bu karşılaştırma, sorunun gerçekten taşıma katmanında olduğunu doğrulamanın en hızlı yoludur.

Sık Karşılaşılan Senaryolar ve Çözümleri#

Senaryo 1: Yedek MX sunucusunda sürekli certificate-host-mismatch. Birincil sunucun sertifikası otomatik yenileniyor ama yedek sunucu bu otomasyonun dışında kalmış. Çözüm, yedek sunucuya da kendi ismine ait geçerli bir sertifika kurmak ya da her iki ismi kapsayan tek bir sertifika (SAN) kullanmaktır. MTA-STS politikandaki mx: satırlarının da her iki ismi içerdiğini doğrula.

Senaryo 2: Belirli bir gönderende starttls-not-supported, diğerlerinde temiz. Bu genellikle senin sunucunda değil, aradaki bir ağ cihazında sorun olduğunu gösterir. Bazı güvenlik duvarları SMTP trafiğini denetlerken STARTTLS reklamını kaldırır. Karşı taraftan bir traceroute isteyebilir ya da o gönderenin farklı bir çıkış IP'si üzerinden denemesini talep edebilirsin.

Senaryo 3: Sertifika yenilendikten hemen sonra certificate-expired yağmuru. Sertifika dosyası diskte yenilenmiş ama Postfix ya da Dovecot bellekteki eskisini sunmaya devam ediyor. Çözüm, yenileme kancasına servis reload komutlarını eklemektir:

# /etc/letsencrypt/renewal-hooks/deploy/mail-reload.sh
#!/bin/sh
systemctl reload postfix
systemctl reload dovecot
systemctl reload nginx

Senaryo 4: Raporlar hiç gelmiyor. Önce TXT kaydını dig ile doğrula. Kayıt doğruysa rapor kutusunun mail alabildiğinden emin ol; spam filtresi .json.gz ekli mailleri karantinaya alıyor olabilir. Ayrıca yeni kurulan bir kayıtta ilk raporun gelmesi bir güne kadar sürebilir, çünkü raporlar günlük periyotlarla üretilir.

Sıkça Sorulan Sorular#

TLS-RPT kaydı olmadan MTA-STS çalışır mı#

Evet, MTA-STS TLS-RPT olmadan da çalışır ve politikan uygulanmaya devam eder. Ancak politikanın ihlal edildiği durumları göremezsin; teslim edilemeyen mailler senin tarafında hiç iz bırakmadan gönderende kuyrukta bekler. Bu yüzden sıralamayı tersine çevirmeni öneririm: önce TLS-RPT kaydını kur, birkaç hafta veri topla, sonra MTA-STS politikanı enforce moduna al.

TLS-RPT raporları ne sıklıkla gelir#

Raporlar günlük periyotlarla üretilir; her gönderen sunucu bir önceki gün için tek bir toplu rapor gönderir. Yani sana mail gönderen sağlayıcı sayısı kadar günlük rapor alırsın. Küçük bir alan adında bu günde birkaç mail demektir, büyük hacimli bir kurumda ise on-yirmi rapora çıkabilir. Yeni kurulan bir kayıtta ilk raporun ulaşması 24 saati bulabilir.

Rapor gelmiyorsa nereden başlamalıyım#

İlk adım dig _smtp._tls.firmaniz.com TXT +short komutuyla kaydın gerçekten yayında olduğunu doğrulamaktır; kayıt adındaki alt çizgiler ve nokta konumları sık hata kaynağıdır. Kayıt görünüyorsa rapor kutusunun mail alabildiğini kontrol et ve spam klasörüne bak; sıkıştırılmış ekli mailler bazı filtrelerde karantinaya düşer. Son olarak, sana hiç kimse mail göndermiyorsa rapor da üretilmez.

TLS-RPT raporları kişisel veri içerir mi#

Hayır, TLS-RPT raporları tamamen toplu istatistiklerden oluşur. Gönderen ve alıcı e-posta adresleri, konu satırları veya mesaj içerikleri raporda yer almaz. Rapor yalnızca gönderen MTA'nın IP adresini, alıcı MX sunucusunun adını, hata tipini ve oturum sayılarını taşır. Bu, DMARC'ın forensic rapor türünden farklı olarak gizlilik açısından rahat kullanılabilir olmasını sağlar.

Başarısızlık oranı ne zaman alarm vermeli#

Binde birin altındaki oranlar genellikle geçici ağ sorunlarından kaynaklanır ve not almak yeterlidir. Yüzde birin üzerine çıkan bir oran aynı gün incelenmelidir. Asıl kritik sinyal tekrarlanmadır: aynı MX sunucusunda art arda iki gün aynı result-type görünüyorsa bu bir yapılandırma hatasıdır ve kendiliğinden düzelmez. Toplam oturum sayısındaki ani düşüşü de izle, bu bir gönderenin sana mail göndermeyi bıraktığına işaret edebilir.

DMARC raporlarıyla TLS-RPT raporlarını aynı adrese yönlendirebilir miyim#

Teknik olarak mümkündür ama önermem. İki rapor türü farklı biçimlerde gelir ve farklı sorunları anlatır; aynı kutuda karışmaları hangisini ne zaman okuyacağını belirsizleştirir. Ayrı adresler kullanmak, her rapor türü için ayrı bir işleme betiği yazmanı ve farklı eşiklerle alarm kurmanı kolaylaştırır. Rapor hacmi arttıkça bu ayrım daha da değerli hâle gelir.

Kapanış#

TLS-RPT, mail altyapındaki en sinsi sorun sınıfını görünür kılar: senin log'unda hiç iz bırakmayan, karşı tarafta yaşanan teslimat hatalarını. Kurulumu tek bir TXT kaydından ibarettir ama kazancı büyüktür. Aklında tutman gereken dört alışkanlık: raporları ayrı bir kutuya yönlendir, MTA-STS'i sıkılaştırmadan önce en az iki hafta veri topla, receiving-mx-hostname alanını sorunu daraltmak için ilk bakılacak yer olarak kullan ve sertifika yenileme kancalarına servis reload komutlarını mutlaka ekle.

Kendi posta altyapını kurup bu kayıtları yönetmek istiyorsan VDS sunucularımızda tam root erişimiyle çalışabilirsin. Sertifikası kurulu, TLS yapılandırması hazır bir gönderim altyapısı istersen SMTP sunucu paketlerimiz bu iş için hazırlandı; sertifika ihtiyacın varsa SSL sertifikası sayfamıza, tüm bu izleme ve bakım işini devretmek istersen sunucu yönetimi hizmetimize göz atabilirsin.