SMTP’de Şifreleme ile Kimlik Doğrulama Arasındaki Fark
SPF, DKIM ve DMARC e-posta kimlik doğrulaması ve alan adı politikasını ele alır. Sunucular arasındaki SMTP bağlantısının şifrelenmesi ve karşı ucun doğrulanması ise ayrı bir konudur. MTA-STS gelen posta için TLS politikasını, TLS-RPT taşıma sorunlarının raporlanmasını, DANE/TLSA ise DNSSEC’e dayalı TLS kimlik doğrulamasını sağlar.
Bu rehber, gönderen MTA’nın alıcı alan adının MX sunucusuna posta teslim ettiği bağlantıyı ele alır. Normal fırsatçı STARTTLS her zaman doğrulanmış ve zorunlu TLS anlamına gelmez. Politika yayımlayan alıcı alan adı hangi güvenli teslim koşullarını istediğini belirtir; bunları uygulayıp uygulamama yeteneği gönderen MTA’dadır. Kullanıcının 465/587 üzerinden submission bağlantısı ve mesajın uçtan uca şifrelenmesi farklı kapsamlardır.
Buradaki karar, hangi kaydı önce yayımlayacağınızdan önce gelir: Gönderen, doğru alıcı sunucuya bağlandığını hangi güven kaynağıyla anlayacak? MTA-STS’in HTTPS/PKIX modeli ile DANE’in DNSSEC/TLSA modelini, başarısızlıkta uygulanacak önceliği ve dış posta sağlayıcısıyla paylaşılan sorumlulukları karşılaştıracağız. DNS ve politika örnekleri bu ilişkileri açıklayan referanslardır.
MTA-STS: Gelen Posta İçin TLS Politikası
MTA-STS, alan adınıza gelen postanın nasıl teslim edilmesini istediğinizi açıklar. Politikayı destekleyen gönderen MTA, geçerli enforce politikası altında teslim edeceği MX adını, STARTTLS desteğini ve alıcı sunucu sertifikasını denetler. Bu kayıt kendi sunucunuzun bütün giden postalarına otomatik TLS zorunluluğu getirmez; giden teslimat, hedef alanın politikası ve gönderen MTA yapılandırmasına bağlıdır.
Keşif Kaydı ile Güvenilen Politikanın Ayrılması
_mta-sts.example.com TXT kaydı politikanın varlığını ve değişiklik kimliğini duyurur; güvenilen politika gövdesinin kendisi değildir. Gövde https://mta-sts.example.com/.well-known/mta-sts.txt adresinden HTTPS ile doğrulanarak alınır. Aşağıdaki tek MX’li testing örneğinde id değişiklik işareti, mx izin verilen hedef, max_age ise alınan politikanın önbellek ömrüdür; değerler zorunlu bir kurulum takvimi belirtmez.
_mta-sts.example.com. IN TXT "v=STSv1; id=policy01"version: STSv1
mode: testing
mx: mx1.example.com
max_age: 86400
HTTPS ucu doğru politika hostname’ine ait geçerli güven zinciri sunmalı ve doğrudan HTTP 200 dönmelidir; gönderenler 3xx yönlendirmelerini takip etmez. Giriş ekranı, bot doğrulaması veya HTML sayfası yerine geçerli politika gövdesi sunun. HTTP önbellek kurallarıyla MTA-STS’nin max_age politika önbelleğini karıştırmayın.
Testing, Enforce ve None Modları
Testing modunda MTA-STS doğrulama hatası nedeniyle teslimat zorunlu olarak kesilmez; TLS-RPT’yi de destekleyen gönderenler hataları raporlayabilir. Enforce modunda uygun olmayan MX, sertifika veya STARTTLS durumu o sunucuya teslimi engeller; alternatif uygun MX ve geçici hata/yeniden deneme davranışı değerlendirilir. None aktif politikadan kontrollü çıkış içindir. Mevcut önbellekleri anında silmez.
Korumanın Koşulları ve Sınırları
Geçerli bir enforce politikası edinmiş ve uygulayan gönderen için MTA-STS, STARTTLS’in düşürülmesine ve politikaya uymayan hedefe teslimata karşı koruma sağlar. İlk politika keşfi engellenirse ve geçerli önbellek yoksa aynı koruma kurulamayabilir. MTA-STS posta kutusuna düşmeyi, spam filtresini geçmeyi veya bütün gönderenlerde TLS kullanımını garanti etmez. Yanlış enforce politikası meşru postayı da geciktirebilir.
RFC 8461 MTA-STS standardı politika keşfini, MX ve sertifika doğrulamasını, SNI’ı ve önbellekli değişiklikleri tanımlar. Politika uç noktasının sertifikası ile SMTP MX sertifikası iki ayrı TLS bağlantısına aittir; aynı dosyayı veya hostname’i otomatik olarak kullanmaları gerekmez.
TLS-RPT: Güven Kararı Değil, Gözlem Kaynağı
TLS-RPT, raporlamayı destekleyen gönderen sistemlerin alan adınıza teslim sırasında gözlediği bağlantı başarılarını ve hatalarını toplulaştırır. Rapor I-JSON biçimindedir; dağıtım yöntemi sıkıştırılmış ek veya HTTPS yüklemesi olabilir. Standardın önerdiği pencere tam UTC günüdür, ancak raporlar gecikmeyle ulaşabilir. Her gönderenin rapor yollayacağını veya sessizliğin sorunsuz trafik anlamına geldiğini varsaymayın.
Politika Uygulayan ile Rapor Toplayanın Görevleri
_smtp._tls.example.com altında v=TLSRPTv1; rua=mailto:tlsrpt@example.com TXT kaydı rapor adresini belirtir. Standart mailto ve HTTPS POST uçlarını destekler; birden fazla URI virgülle ayrılabilir. Alıcı posta kutusunu veya rapor hizmetini önceden hazırlayın ve erişimini sınırlandırın. SMTP ile gelen raporlar raporlayan alanın geçerli DKIM imzasıyla doğrulanmalıdır; rapor tesliminin her durumda şifreli olduğunu varsaymayın.
Bir Raporun Kanıtlayabildiği ve Kanıtlayamadığı
Raporu politika türü, tarih aralığı, gönderen sistem, hedef MX ve hata türüne göre inceleyin. MTA-STS’de doğrulanan ad, seçilen MX hostname’idir; SMTP banner’ı veya sunucunun söylediği başka bir ad değildir. Örneğin MX mx1.example.com ise sertifikanın SAN DNS-ID’si bu adla eşleşmelidir. Bu kontrolü teslim yapan gönderen MTA yapar. certificate-host-mismatch, STARTTLS eksikliği ve zincir hatası gibi sonuçları gerçek SMTP günlükleriyle ilişkilendirin; tek rapor etiketi SNI sorununu kesin teşhis etmez.
RFC 8460 TLS-RPT standardı rapor şemasını ve hata sınıflarını açıklar. Başarı/başarısızlık toplamları TLS oturumlarına ilişkindir; doğrudan mesajın gelen kutusuna teslim edildiğini göstermez. Tek denemede birden çok hata türü oluşabildiği için failure-details satırlarını körlemesine toplayıp benzersiz kayıp mesaj sayısı olarak sunmayın.
DANE/TLSA ile DNSSEC’e Dayalı Doğrulama
DANE, DNSSEC ile doğrulanmış TLSA verisini SMTP sunucu kimliğine bağlar. Doğrudan mx1.example.com hedefine TCP 25 üzerinden gidiliyorsa tipik TLSA sahibi _25._tcp.mx1.example.com olur; yalnız alıcı alan adına rastgele TLSA eklemek yeterli değildir. Kayıt önce kullanım, seçici ve eşleştirme türünü, sonra ilişkilendirme verisini taşır. Yaygın 3 1 1, DANE-EE yaprak kimliği, SubjectPublicKeyInfo seçimi ve SHA-256 özeti demektir. DNSSEC imzası bulunması kadar gönderenin zinciri gerçekten doğrulaması da gerekir. Alıcı alanın MX keşfi ile hedef MX hostname’inin TLSA kayıtları ayrı DNS kapsamlarıdır. MX dış sağlayıcının adındaysa TLSA ve sunucu anahtarı için o sağlayıcının katılımı veya ilgili DNS bölgesinin kontrolü gerekir; yalnız alıcı alanı imzalamak yeterli değildir.
MTA-STS ve DANE’in Öncelik İlişkisi
MTA-STS HTTPS/PKIX güveni kullanır ve DNSSEC gerektirmez; DANE ise doğrulanmış DNSSEC verisine dayanır. İkisini destekleyen gönderen, başarısız DANE doğrulamasını başarılı MTA-STS sonucu ile geçersiz kılamaz. DANE-EE(3) doğrulamasında bağ TLSA üzerinden kurulur; PKIX’teki sertifika ad ve süre kontrolü aynı biçimde uygulanmaz. DANE-TA(2) ise güven çıpası, zincir ve ad kuralları içerir. Her TLSA türünü “kök sertifikayı eşleştirme” olarak anlatmak yanlıştır.
RFC 7672 SMTP için DANE standardı kullanım türlerini ve DNSSEC durumlarına göre davranışı tanımlar. Güvenli ve kullanılabilir TLSA bulunduğunda başarısız doğrulama o hedefe teslimi engeller. DNSSEC bogus veya çözümlenemeyen yanıtı “DANE yokmuş” gibi değerlendirip güveni düşürmeyin. DANE desteği olmayan gönderenlerin bu kaydı uygulamayacağını da kapasite ve risk değerlendirmesine katın.
Alıcı Alanı ve MX Sağlayıcısı Hangi Yetkileri Yönetir?
Alıcı alanının yöneticisi MX seçimini, MTA-STS keşif duyurusunu ve politika yayımlama yetkisini yönetir. Posta sağlayıcısı ise MX sunucularındaki STARTTLS hizmetini ve sunulan sertifika/anahtarı yönetebilir. Bu iki rol aynı kişide değilse bir TXT kaydının yayımlanması sunucu yapılandırmasının da doğrulandığı anlamına gelmez. Birincil ve yedek MX’lerin bütün IPv4/IPv6 uçları bu sorumluluk sınırına dahildir.
MTA-STS’de güven bağı iki ayrı denetimle kurulur: Seçilen MX politikadaki izin verilen adlardan birine uymalı, sunucu sertifikasının SAN DNS-ID’si de MX adını doğrulamalıdır. CN tek başına yeterli değildir. Politikadaki *.example.com yalnız tek sol etiketi kapsar; mx1.example.com eşleşir, example.com ve a.b.example.com eşleşmez. Politika dosyası DNS’te MX kaydı oluşturmaz ve yetkisi olmayan bir sunucuyu çalışır hale getirmez.
Dış sağlayıcının MX adı değiştiğinde alıcı alanının politikasıyla sağlayıcının hizmeti birlikte değerlendirilmelidir. Eski ve yeni MX adları için HTTPS politika gövdesinin önce yayımlanması, sonra TXT id’nin değişmesi gerekir. TXT/MX TTL’leri ve eski max_age değerleri yüzünden gönderenlerin gördüğü durumlar bir süre farklı kalabilir. Eski politikaların kabul ettiği çalışan yolu erken kapatmak, doğru yeni ayarlara rağmen teslimatı geciktirebilir.
DANE için alıcı alanının MX keşfi ile her hedef MX’in TLSA bölgesinin yetkisini ayrı kaydedin. Güvensiz MX keşfiyle seçilen bir sağlayıcının geçerli TLSA kaydı bazı gönderenlerce kullanılabilir; bu, seçilen bağlantıyı koruyabilse de alıcı alanın doğru hedefe yönlendirildiğini kanıtlamaz. İstenen alıcı alana güvenli teslim iddiası için MX keşfinin de doğrulanması gerekir. TLSA taban adını, delegasyonu, imzaları ve fiilen sunulan kimlikle eşleşmeyi birlikte değerlendirin.
Sertifika ve Önbellek Değişiklikleri Güven Bağını Nasıl Etkiler?
MTA-STS’de iki adı ayırın: politika indirilirken SNI ve sertifika adı mta-sts.example.com, SMTP tesliminde ise seçilen MX adıdır. Standart bunu uygulayan gönderenin uygun SNI göndermesini ister. SMTP sunucusu sertifika seçmek için SNI kullanabilir; ancak başka fırsatçı SMTP istemcileri için SNI’ı evrensel bir bağlantı ön koşulu yapmamalıdır. Banner adını değiştirerek MX SAN uyuşmazlığının çözüldüğünü varsaymayın.
DNS TXT/MX TTL’leri ve MTA-STS max_age farklı önbellekleri yönetir. Max_age’i bugün küçültmek, dün daha büyük süreyle alınmış politikayı anında geçersiz kılmaz. Düşük başlangıç süreleri değişikliği kolaylaştırabilir; daha uzun geçerli politika önbelleği keşif saldırılarına karşı koruma penceresini artırabilir. Politika kaldırılacaksa önce none gövdesi ve yeni id yayımlayın; daha eski uzun ömürlü politikalar da sona ermeden uçları silmeyin.
Anahtar değişikliği DANE ilişkilendirmesini etkileyebilir. Özellikle 3 1 1 kaydı sertifikanın tamamını değil SPKI’yi eşleştirir: aynı anahtarla yenileme özeti koruyabilir, yeni anahtar korumaz. Planlı geçişte yeni ilişkilendirmeyi eskisiyle birlikte önceden yayımlayın; eski TLSA ve ilgili imza önbellekleri için gereken süre geçmeden sunucu anahtarını değiştirmeyin. Yeni kimlik doğrulandıktan ve eski kimliği kullanan meşru yollar sona erdikten sonra eski bağı kaldırın. Ele geçirilmiş anahtarı rutin geçiş kolaylığı için yetkili tutmayın.
Bu değişikliklerde sorulacak temel soru, her gönderenin hangi politika ve kimliğe hâlâ güvenebileceğidir. DNS’te kaydın görünmesi doğrulanmış DNSSEC sonucu demek değildir; sertifikanın yenilenmesi de bütün MX uçlarına dağıtıldığı anlamına gelmez. Yedek MX’leri ayrı değerlendirin. Rapor kimliklerini ve zaman aralıklarını saklamak değişiklik öncesi/sonrası gözlemleri ayırmaya yardımcı olur; yinelenen raporlar yeni olay gibi sayılmamalıdır.
SPF, DKIM ve DMARC ile Görev Ayrımı
Gelişmiş DMARC ve BIMI rehberi alan adı hizalaması ve ilgili raporları ele alır. DMARC, From alanıyla hizalanmış SPF veya DKIM sonucuna dayalı politika sağlar; her insanın veya bütün mesaj içeriğinin güvenilir olduğunu kanıtlamaz. TLS taşıma politikasını açmak SPF, DKIM ve DMARC yapılandırmasını kendiliğinden tamamlamaz.
MTA-STS ve DANE, posta sunucuları arasındaki taşıma bağlantısını korur. TLS-RPT bu bağlantılarda gözlenen sonucu bildirir. SPF/DKIM/DMARC ise farklı kimlik ve politika kontrolleridir. Doğru birlikte işletilmeleri yararlıdır, fakat hiçbiri tek başına IP itibarı, içerik değerlendirmesi veya gelen kutusu yerleşimi garantisi vermez.
Gönderen, Alan Yöneticisi ve Sağlayıcı İçin Sorumluluk Sınırı
Postfix, Dovecot ve Rspamd ile e-posta altyapısı rehberi sunucu kurulumu için tamamlayıcıdır. MX tarafında doğru STARTTLS ve sertifika sunulması gerekir; MTA-STS/DANE’i gönderen tarafta uygulamak ayrıca desteklenen MTA özelliği veya uygun entegrasyon ister. TXT yayımlamanın Postfix’te bütün çıkış teslimatlarını otomatik politika denetimine aldığı varsayılmamalıdır.
Terraform ile VPS ve DNS otomasyonu rehberi kayıt yönetimi için tamamlayıcıdır. MTA-STS politika yetkisini, DNSSEC imzalama yetkisini ve SMTP anahtar dağıtımını ayrı işler olarak tanımlayın. Otomasyon HTTPS gövdesi doğrulanmadan yeni id yayımlamamalı; TLSA da gerçekten dağıtılacak anahtarları temsil etmelidir. Farklı düğümlerde farklı anahtarlar varsa geçerli ilişkilendirmelerin bunları kapsaması gerekir.
DV, OV, EV ve wildcard sertifika rehberi sertifika türlerini açıklar. MTA-STS’de gerekli olan doğru MX adını içeren SAN, geçerli süre ve gönderenin güvendiği zincirdir; OV/EV sınıfı ekstra SMTP teslim yetkisi sağlamaz. DANE-EE ile farklı bir doğrulama modeli mümkün olsa da MTA-STS’yi de kullanıyorsanız onun PKIX ve ad koşullarını ayrıca koruyun.
Gönderen MTA’nın sorumluluğu desteklediği politikayı doğru uygulamak, alıcı tarafın sorumluluğu ise o politikanın tarif ettiği hizmeti sunmaktır. Rapor toplayıcı bu iki işin yerine geçmez. Raporlayan alanın kimliğini doğrulayın, ekleri güvenilmeyen veri olarak işleyin ve alımın sürdüğünü izleyin. SMTP günlükleriyle karşılaştırma yapılmadan greylisting, oran sınırı veya spam reddi TLS doğrulama hatası olarak yorumlanmamalıdır.
Üç Durumda Doğru Güven Kararını Vermek
DNSSEC yönetemeyen alan: MX hizmeti ve politika HTTPS ucu uygun olduğunda MTA-STS değerlendirilebilir; DNSSEC protokol önkoşulu değildir. Ancak ilk keşfin engellenmesi ve gönderen desteği sınırları kalır. Haricî MX kullanan imzalı alan: yalnız alıcı alanını imzalamak yeterli değildir; sağlayıcının TLSA bölgesi, sunucu anahtarı ve doğrulanan MX keşfi de güven zincirine dahildir.
İki mekanizmayı da kullanan alan: uygulanabilir DANE doğrulaması başarısızsa başarılı MTA-STS sonucu teslimata izin veren bir istisna olamaz. Örneğin geçerli bir kamu CA sertifikası sunulsa bile kullanılabilir güvenli TLSA ile anahtar uyuşmuyorsa DANE hatası çözülmelidir. Buna karşılık doğrulanmış TLSA yokluğu, DNSSEC hatası ve gerçek TLSA uyuşmazlığı aynı durum değildir. Bu örnekler protokol kararını açıklar; belirli bir müşteri olayı veya üretim testi değildir.
Hangi Güven Modeli İçin Hazırsınız?
MTA-STS seçimi için politika HTTPS ucunu, doğru MX/SAN kimliklerini, PKIX zincirini ve önbellekli politika yönetimini üstlenebilmelisiniz. DANE seçimi için bunlardan farklı olarak doğrulanmış MX keşfi, ilgili TLSA bölgesinin yetkisi, DNSSEC sürekliliği ve gerçek anahtarla ilişkilendirme gerekir. Birlikte kullanımda her modelin koşullarını kendi kurallarına göre koruyun; TLS-RPT’yi bu koşulların gözlem kaynağı olarak kullanın.
Kararı bir sorumluluk kaydına dönüştürün: MX seçimi, politika yayını, DNSSEC/TLSA, sertifika ve anahtar dağıtımı ile rapor alımını kimin yönettiği belli olsun. Uygulamaya geçerken bütün MX yollarını doğrulayın; testing ve raporları yalnız geçen gün sayısıyla değerlendirmeyin. Güven modeli seçimi, mesajın uçtan uca şifrelenmesi veya gelen kutusuna ulaşma garantisi değildir.
DNS kayıtları, iki MX’li politika ve örnek rapor üzerinden uygulama için MTA-STS ve TLS-RPT kurulum ve hata giderme rehberine geçebilirsiniz.
