MTA-STS ve TLS-RPT Kurulumunda Hedeflenen Sonuç
Bu rehberin sonunda yayımlanacak parçalar bellidir: alan adınız için doğrudan erişilebilen MTA-STS politika dosyası, onun DNS keşif kaydı ve çalışan bir TLS-RPT rapor hedefi. Ardından gerçek MX uçlarını doğrulayacak, rapordaki hata türünü bağlantı günlükleriyle eşleştirecek ve enforce geçişinin koşullarını belirleyeceksiniz. Örnekler temsili alan adları ve veriler kullanır; üretimde yapılmış test sonuçları değildir.
MTA-STS politikasını destekleyen gönderen uygular; TLS-RPT raporunu da yalnız katılan gönderenler üretir. Bu nedenle kayıtların yayımlanması bütün trafiğin doğrulandığını göstermez. SMTP bağlantısının doğru çalışması, SPF/DKIM/DMARC sonucu veya gelen kutusu yerleşimiyle aynı ölçüt değildir. DANE kullanıyorsanız DNSSEC ve TLSA kontrollerini bu kurulumun ayrı bağımlılığı olarak izleyin.
Önce DNS, HTTPS ve MX yönetim yetkilerini kontrol edeceğiz; sonra iki MX’li testing politikasını ve rapor kaydını hazırlayacağız. Varsayımsal JSON üzerinden hata alanlarını okuyup sertifika, STARTTLS, politika erişimi ve önbellek sorunlarını ayıracağız. DANE bulunan kurulumlar için anahtar değişimi ve sağlayıcı sorumluluğu da kontrol listesine dahildir.
Hangi protokolün hangi güven kaynağını kullandığını ve başarısız DANE doğrulamasının neden MTA-STS ile aşılamayacağını karşılaştırmak için MTA-STS ve DANE güven modelleri rehberini okuyabilirsiniz.
Kurulum Öncesi: DNS, HTTPS ve Bütün MX Uçları
Alan adınızın aktif ve yedek MX adlarını, her birinin IPv4/IPv6 adreslerini ve posta sağlayıcısını listeleyin. DNS TXT kayıtlarını kimin yayımlayabildiğini, mta-sts alt alanının HTTPS ucunu kimin yönettiğini ve MX sertifikalarını kimin dağıttığını belirleyin. Yalnız web barındırma paneline erişim, paylaşımlı MX hizmetini değiştirme yetkisi sağlamayabilir.
Her MX’te STARTTLS desteğini ve fiilen sunulan sertifikayı kontrol edin. MTA-STS için sertifika SAN’ı seçilen MX adını kapsamalı, sertifika geçerli olmalı ve gönderenin güvendiği zinciri sunmalıdır. Fırsatçı STARTTLS tek başına bu koşulları her teslimatta zorunlu kılmaz. Birincil sunucunun başarılı olması yedek sunucuların da hazır olduğunu göstermez.
İlk testing politikasında MX eşleştirmesi veya sertifika doğrulama hataları nedeniyle MTA-STS teslimatı engellemez; katılan TLS-RPT gönderenleri bunları raporlayabilir. Enforce aynı hatada o sunucuya teslimatı engeller. Bu farkı bakım planında açık tutun; testing gözlemini bitirmeden enforce’a geçişi yalnız dosya değişikliği olarak değerlendirmeyin.
MTA-STS: MX ve TLS politikasını yayımlamak
MTA-STS iki parçadan oluşur: DNS’te politikanın varlığını ve değişiklik kimliğini duyuran bir TXT kaydı, HTTPS üzerinden alınan bir politika dosyası. Dosya kabul edilen MX hostname’lerini ve uygulanacak modu belirtir. Bunu yayımlamak, bütün göndericilerin desteklediği veya hemen aynı politikayı kullanacağı anlamına gelmez.
Politika dosyasının adresi ve alanları
example.com için dosya adresi https://mta-sts.example.com/.well-known/mta-sts.txt şeklindedir. HTTPS GET isteği geçerli sertifikayla doğrudan 200 yanıtı ve düz metin politika döndürmelidir; MTA-STS istemcileri HTTP yönlendirmelerini izlemez ve HTTP önbelleklemesini kullanmaz. Aşağıdaki örnekte her izin verilen MX ayrı satırdadır. 604800 saniye, örnek politikanın yedi günlük önbellek ömrüdür; testing’de geçirilmesi gereken süre değildir. Alan adlarını ve süreyi kendi kurulumunuza göre değerlendirin.
version: STSv1
mode: testing
mx: mail1.example.com
mx: mail2.example.com
max_age: 604800Politika sunucusunun sertifikası mta-sts hostname’ini doğrulamalıdır. MTA-STS kapsamındaki alıcı MX sertifikası da ilgili MX adını SAN alanında kapsamalı, geçerli olmalı ve gönderenin güvendiği bir köke zincirlenmelidir. ACME kullanıyorsanız yenileme kadar sertifikanın doğru hizmete dağıtılmasını da kontrol edin. ACME challenge türleri rehberi, HTTP-01 veya DNS-01 gibi doğrulama yöntemlerini ortama göre değerlendirmenize yardımcı olur.
DNS keşif kaydı ve politika değişikliği
example.com alanı için keşif TXT kaydı _mta-sts.example.com adında yayımlanır. v=STSv1 protokol sürümünü, id ise politika örneğini ayırt eden değişiklik kimliğini belirtir; id bir URL veya zorunlu tarih değildir. Önce HTTPS dosyasını yayımlayıp doğrulayın, sonra keşif kaydını yayımlayın. Gövde değiştiğinde id’yi de değiştirin; DNS ve politika önbellekleri bütün gönderenlerin aynı anda güncelleneceği anlamına gelmez. Aşağıdaki satır DNS bölge dosyası gösterimidir; sağlayıcı paneli ad, TTL ve değeri ayrı alanlarda isteyebilir.
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=policy1"CAA, sertifika otoritelerinin hangi alan adları için sertifika düzenleyebileceğine ilişkin yetkilendirmeyi belirtir; MTA-STS keşfinin yerini tutmaz. Kullanıyorsanız CAA kayıtlarını sertifika otomasyonunda seçtiğiniz otoritelerle uyumlu tutun ve yenileme hatalarını izleyin.
Testing’den enforce’a geçiş koşulları
Önce testing modunda gözlem yapın ve TLS-RPT raporlamasını ayrı olarak etkinleştirin. Bütün aktif ve yedek MX adları politikayla eşleşiyor mu, STARTTLS çalışıyor mu, sertifika adı ve zinciri doğru mu kontrol edin. Raporları sunucu günlükleriyle birlikte değerlendirin. Belirli sayıda gün geçmiş olması veya hiç rapor gelmemesi, enforce için hazır olunduğunu tek başına göstermez.
Kontrol listesine IPv4/IPv6 uç noktalarını, sertifika dağıtımını ve SNI davranışını ekleyin. MTA-STS istemcisi politika alırken politika hostname’ini, SMTP bağlantısında MX hostname’ini SNI ile gönderir. SMTP sunucusu SNI kullanımını zorunlu tutmamalıdır. İstemci SNI göndermiyorsa veya desteklenmeyen bir sunucu adı gönderiyorsa bağlantıyı yalnızca bu nedenle reddetmek yerine varsayılan bir sertifika zinciri sunmalıdır. Değişiklikleri dış ağdan yapılan bağlantı kontrolleriyle de doğrulayın.
TLS-RPT: TLS sonuçlarını toplu raporlarla izlemek
TLS-RPT, destekleyen göndericilerin politika ve TLS bağlantısı sonuçlarını alıcı alan adına toplu olarak bildirmesine olanak verir. Raporlar oturum sayılarını ve hata kategorilerini gösterir; tek tek mesajların gelen kutusuna teslim edildiğini kanıtlayan kayıtlar değildir. Raporlayan göndericilerin kapsamı da bütün e-posta trafiğinizle aynı olmayabilir.
Rapor hedefini yalnızca bir posta kutusu açarak duyurmuş olmazsınız. example.com için _smtp._tls.example.com adında TXT kaydı yayımlanır; v=TLSRPTv1 sürümü, rua ise rapor hedefini belirtir. Örneğin rua=mailto:tlsrpt@example.com çalışan ve izlenen bir kutuyu gösterir. Standart, HTTPS üzerinden rapor alan bir uç noktayı ve virgülle ayrılmış birden fazla URI’yi de destekler. Kendi alan adınızı ve gerçekten yönettiğiniz alıcıyı kullanın; gelen raporların işlenebildiğini doğrulayın. E-posta ile gelen raporlarda raporlayan alan adının geçerli DKIM imzasını doğrulayın; bu imzayı taşımayan raporları işleme almayın. Rapor eklerinin ayrıştırılmasını ve işleme hatalarını izleyin.
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"Rapor hangi bilgileri içerir?
Standart raporda politika türü ve alan adı, başarılı/başarısız TLS oturum sayıları ve hata ayrıntıları yer alır. MTA-STS için mx-host, uygulanan politikadaki MX desenlerini; receiving-mx-hostname ise bağlantı denenmiş alıcı MX sunucusunu belirtir. Bunlar aynı alan değildir. Şema, denenmiş TLS sürümlerinin veya seçilen şifre takımlarının listesini vermez. Aşağıdaki varsayımsal raporda 100 başarılı oturum ve birbirinden ayrı 25 başarısız oturum vardır: 17 ad uyuşmazlığı, 8 STARTTLS eksikliği. Sayılar ölçüm değildir; örnekte iki ayrıntı girdisi bütün başarısızlıkları kapsar. policy nesnesi iç içedir, policy-string ve mx-host dizi olarak yazılmıştır.
{
"organization-name": "Example Sender",
"date-range": {
"start-datetime": "2025-01-01T00:00:00Z",
"end-datetime": "2025-01-01T23:59:59Z"
},
"contact-info": "postmaster@example.net",
"report-id": "example-report-1",
"policies": [
{
"policy": {
"policy-type": "sts",
"policy-string": [
"version: STSv1",
"mode: testing",
"mx: mail1.example.com",
"mx: mail2.example.com",
"max_age: 604800"
],
"policy-domain": "example.com",
"mx-host": [
"mail1.example.com",
"mail2.example.com"
]
},
"summary": {
"total-successful-session-count": 100,
"total-failure-session-count": 25
},
"failure-details": [
{
"result-type": "certificate-host-mismatch",
"sending-mta-ip": "203.0.113.44",
"receiving-mx-hostname": "mail1.example.com",
"receiving-ip": "192.0.2.10",
"failed-session-count": 17,
"failure-reason-code": "Certificate identity does not match MX hostname"
},
{
"result-type": "starttls-not-supported",
"sending-mta-ip": "198.51.100.22",
"receiving-mx-hostname": "mail2.example.com",
"receiving-ip": "192.0.2.20",
"failed-session-count": 8,
"failure-reason-code": "STARTTLS not advertised"
}
]
}
]
}Bu yaklaşım, web tarafında CSP raporlamasıyla benzer bir çalışma düzeni sunar: politikayı tanımlayın, raporu alın, belirli hatayı inceleyip düzeltin ve sonraki sonuçları karşılaştırın. Raporlama protokollerinin veri biçimleri ve hata anlamları farklıdır; birini diğerinin yerine kullanmayın.
Tekrarlayan hataları sınıflandırmak
certificate-host-mismatch: rapordaki MX adını DNS yanıtı ve fiilen sunulan sertifikanın SAN alanıyla karşılaştırın. starttls-not-supported: ilgili MX’in STARTTLS duyurusunu ve ağ yolunu kontrol edin. certificate-not-trusted: sunulan zinciri ve gönderenin hata ayrıntısını inceleyin. Bu etiketlerden biri tek başına kesin kök neden değildir. Zaman aralığı, gönderen IP ve hedef IP’yi günlüklerle eşleştirin. Başarısızlıkları toplam oturum hacmiyle değerlendirin; gerçek raporlarda bir bağlantı birden çok hata kategorisinde yer alabileceğinden ayrıntı sayılarını benzersiz kayıp mesaj sayısı olarak toplamayın.
DANE Kullanılan Kurulumlarda Ek DNSSEC ve TLSA Kontrolleri
DANE zaten kullanılıyorsa veya ayrıca planlanıyorsa MX keşfinin DNSSEC doğrulamasını ve her MX hostname’inin TLSA bölgesini envantere ekleyin. Dış sağlayıcının MX adı için ilgili TLSA kaydını sağlayıcı yönetebilir; alıcı alanınıza benzer adlı kayıt eklemek aynı işi yapmaz. MTA-STS’in önce kurulması DANE için gereklilik değildir.
DANE kontrolünü iki ayrı sonuca ayırın: DNSSEC veriyi doğruluyor mu, gönderilen sertifika veya açık anahtar kullanılabilir TLSA kaydıyla eşleşiyor mu? Gönderen DNSSEC, DANE ve STARTTLS desteklemeli; alıcı STARTTLS ile uygun kimliği sunmalıdır. DNSSEC hatasını geçerli TLSA yokluğuyla karıştırmayın ve uygulanabilir DANE başarısızlığını başarılı MTA-STS sonucu ile aşmayın.
Doğru TLSA Adını ve Sunulan Kimliği Kontrol Etme
TLSA kaydı; sertifika kullanımı, seçici, eşleştirme türü ve sertifika/açık anahtar ilişkilendirme verisinden oluşur. Örneğin SMTP için 25 numaralı portta çalışan mail1.example.com MX sunucusunun TLSA adı _25._tcp.mail1.example.com olur. Gönderici en az bir kullanılabilir, DNSSEC ile doğrulanmış TLSA kaydı bulduğunda sunucuyu bu kayıtlara göre doğrulamalıdır. Doğrulama başarısızsa iletiyi o sunucu üzerinden teslim etmemelidir. Bu hata, DNSSEC doğrulamasıyla sertifika eşleştirmesinin ayrı ayrı incelenmesini gerektirir.
DNSSEC doğrulama zinciri ve ilgili TLSA kayıtları sağlıklı olmalıdır. İmzaların süresini, delegasyonları, MX değişikliklerini ve sertifika/anahtar yenilemelerini birlikte yönetin. DANE doğrulamasının ayrıntısı TLSA kullanımına bağlıdır; örneğin DANE-EE(3), MTA-STS’in kamuya açık CA ve sertifika adı kontrolüyle aynı kuralları uygulamaz.
Sağlayıcı ve Anahtar Değişimini Doğrulama
Önce yönetebildiğiniz bir deneme alanında DNSSEC ve TLSA eşleşmesini doğrulayın. Sağlayıcı MX sunucularını veya onların DNS bölgesini siz yönetmiyorsanız, TLSA yayını için sağlayıcının desteği gerekebilir. Deneme, gerçek sertifika ve anahtar değişikliğinin nasıl yapılacağını ve hata halinde hangi kayıtların kontrol edileceğini de kapsamalıdır.
TLSA güncelleme ihtiyacı, seçilen kayıt türüne ve yenilemede neyin değiştiğine bağlıdır. Örneğin 3 1 1 kaydı, yaprak sertifikanın SubjectPublicKeyInfo (SPKI) verisinin SHA-256 özetini eşleştirir; aynı açık anahtarla sertifika yenilenmesi bu özeti değiştirmez. Anahtar değişiyorsa eski ve yeni eşleşmeleri birlikte önceden yayımlayın. Sunucunun anahtarını değiştirmeden önce önceki TLSA kayıt kümesinin ve ilgili imza kayıtlarının DNS önbelleklerinden çıkması için gereken süreyi bekleyin. Yeni anahtarı dağıtıp eşleşmeyi doğruladıktan sonra eski ilişkilendirmeyi kaldırın. Yalnızca sertifika değiştikten sonra DNS’e yeni özet yazmak yeterli bir geçiş planı değildir.
Testing’den Enforce’a Geçiş Kaydı
Enforce kararı için kontrol kaydında her aktif/yedek MX’in adı, IP’si, STARTTLS sonucu, sertifika SAN/zinciri ve gözlem zamanı bulunsun. Rapor alımının çalıştığını ve beklenen gönderenlerin görünürlüğünü ayrıca doğrulayın. HTTPS gövdesini enforce olarak yayımlayıp doğruladıktan sonra keşif id’sini yenileyin. Bu işlem her gönderenin mevcut önbelleğini anında yenilemez; kuyruklar, bağlantı günlükleri ve sonraki rapor dönemleri izlenmelidir.
TLS aktarımı, gönderici itibarından ayrı değerlendirilmelidir. Spam sınıflandırması, adres hataları veya engelleme listeleri için e-posta itibarını inceleme adımlarına başvurabilirsiniz. MTA-STS, TLS-RPT veya DANE kurulumu bu sorunları kendiliğinden çözmez; doğru soruna uygun veriyi kullanın.
DANE kullanılacaksa DNSSEC zinciriyle her MX’in TLSA eşleşmesini doğrulayın. Sertifika otomasyonunda ACME challenge seçimini, sertifikanın posta hizmetine dağıtımını ve TLSA geçiş sırasını birlikte planlayın. DNS yönetimi ile sunucu yönetimi farklı ekiplerdeyse değişikliği ortak bir takvimle yürütün.
Web origin bağlantıları için mTLS ve kaynak doğrulaması farklı bir kullanım alanıdır. Ortak nokta, hangi kimliğin hangi güven kaynağına göre doğrulandığını açıkça belirlemektir; web için verilen mTLS yapılandırmasını SMTP’ye doğrudan taşımayın.
Politika Erişimi, Önbellek ve MX Değişikliğinde Teşhis
Politika alınamıyorsa: mta-sts hostname’inin DNS yanıtını, sertifikasını ve tam well-known yolundaki dışarıdan görülen yanıtı kontrol edin. HTTPS ucu doğrudan 200 ve politika gövdesi sunmalıdır; yönlendirme, oturum açma ekranı veya CDN doğrulaması uygun değildir. Yeni dosyayı doğrulamadan id değiştirmeyin. Önceki max_age ve DNS TTL değerlerini kaydedin; bugün azaltılan değer dün önbelleğe alınmış veriyi anında geçersiz kılmaz.
Yeni veya yedek MX hata veriyorsa: DNS’teki hostname’i politika satırı ve sertifika SAN’ıyla karşılaştırın. Sunucuyu hazır edin, eski ve yeni adları kabul eden politika gövdesini yayımlayıp doğrulayın, sonra id’yi değiştirin. DNS’e geçiş sırasında eski politikaların kabul ettiği kullanılabilir yolları koruyun. DANE kapsamı varsa yeni sunucunun TLSA ve gerçek anahtar eşleşmesini de kontrol edin.
Enforce sonrası teslimat gecikiyorsa: önce hata kategorisini, etkilenen MX’i ve zaman aralığını belirleyin; raporu bağlantı günlükleriyle karşılaştırın. İşletim kararıyla testing’e dönülse bile yeni gövde ve id, önbellekteki enforce politikasını hemen silmez. Tam çıkışta none politikası ve yeni id yayımlanır; önceki tüm politikalar sona erene kadar TXT/HTTPS uçları korunur. Gerekirse sağlayıcıya hostname, IP ve hata özetiyle başvurun.
CAA kayıtlarının yönetimi, kamuya açık CA üzerinden düzenlenen sertifikaların yenileme planıyla uyumlu olmalıdır. CAA, sertifika düzenleme yetkisini sınırlar; DNSSEC bütünlüğü veya TLSA eşleştirmesi yerine geçmez. Bu mekanizmaların her birini kendi kontrol listesinde izleyin.
Kurulumun Teslimi ve Bakım Kontrolü
Kurulumu yalnız DNS kaydının görünmesiyle tamamlanmış saymayın. Politika doğrudan HTTPS’ten alınabilmeli, her gerçek MX uygun TLS kimliğini sunmalı ve raporlar doğrulanıp ayrıştırılabilmelidir. Örnek JSON’un başarı sayısı, üretimdeki teslimatınıza ilişkin kanıt değildir; gerçek raporları kendi zaman aralıkları ve günlükleriyle değerlendirin.
Politika, sertifika, MX veya anahtar değişiminden sonra dış bağlantı kontrollerini ve rapor alımını yeniden gözden geçirin. DANE varsa DNSSEC ve TLSA geçişini ayrıca doğrulayın. Sorun TLS katmanında değilse itibar inceleme adımlarını ilgili teslimat yanıtlarıyla birlikte uygulayın.
Kalıcı bakım için DNS, politika dosyası, sertifika dağıtımı ve rapor alımının sorumlularını belirleyin. Yeni MX eklerken veya anahtar değiştirirken aynı kontrolleri tekrarlayın; rapor eksikliğini sorunsuz çalışma kanıtı olarak kabul etmeyin.
Teknik ayrıntılar için MTA-STS: RFC 8461, TLS-RPT rapor biçimi: RFC 8460 ve SMTP için DANE: RFC 7672 başvuru kaynaklarıdır. Uygulama belgelerini bu protokol gereksinimleriyle birlikte değerlendirin.
