MTA-STS Nedir? E-posta Trafiğinde TLS Zorunluluğu

MTA-STS (SMTP MTA Strict Transport Security), bir alan adının kendisine gelen e-postaların yalnızca şifreli ve sertifikası doğrulanmış bağlantılarla teslim edilmesini talep etmesini sağlayan standarttır. Alan adı sahibi, HTTPS üzerinden yayımladığı bir politika dosyası ve _mta-sts TXT kaydıyla hangi MX sunucularının geçerli olduğunu ve TLS'in zorunlu olup olmadığını duyurur. RFC 8461 ile tanımlanan MTA-STS, özellikle STARTTLS düşürme saldırılarına karşı koruma sağlar.

STARTTLS neden tek başına yetmez?

SMTP başlangıçta şifresiz tasarlanmıştır. Sunucular arası şifreleme, RFC 3207 ile tanımlanan STARTTLS komutuyla isteğe bağlı olarak eklenir: Alıcı sunucu EHLO yanıtında STARTTLS desteğini ilan eder, gönderen de bağlantıyı TLS'e yükseltir. Bu fırsatçı yaklaşımın üç zayıf noktası vardır:

• Düşürme (downgrade) saldırısı: Araya giren bir saldırgan EHLO yanıtındaki STARTTLS satırını silerse gönderen sunucu iletiyi şifresiz gönderir.
• Doğrulanmayan sertifika: Fırsatçı TLS'te gönderenler çoğu zaman alıcının sertifikasını doğrulamaz ve sahte sertifikalı bir sunucuya da bağlanabilir.
• MX yanıltması: DNS yanıtları sahteleştirilirse posta, saldırganın kontrol ettiği bir sunucuya yönlenebilir.

MTA-STS, gönderen sunucuya "bu alan adına yalnızca şu MX sunucularına, geçerli sertifikayla ve TLS üzerinden teslim et" talimatını güvenli bir kanaldan iletir. Konunun genel çerçevesi için e-posta şifreleme ve TLS yazımıza bakabilirsiniz.

MTA-STS nasıl çalışır?

1. Gönderen sunucu, alıcı alan adının _mta-sts TXT kaydını sorgular.
2. Kayıt varsa politika dosyasını https://mta-sts.example.com.tr/.well-known/mta-sts.txt adresinden HTTPS ile indirir; bu web sunucusunun sertifikası geçerli olmalıdır.
3. Politikayı max_age süresince önbelleğe alır.
4. Teslimat sırasında MX sunucusunun adının politikadaki mx satırlarından biriyle eşleştiğini ve sunucunun geçerli, adla uyumlu bir sertifika sunduğunu doğrular.
5. Politika enforce modundaysa ve doğrulama başarısız olursa iletiyi o sunucuya teslim etmez; iletiyi kuyrukta tutar ve sorun sürerse sonunda geri döndürür.

Önbellekleme kritik bir ayrıntıdır: Saldırgan sonradan DNS yanıtlarını engellese bile gönderen sunucu, süresi dolmamış politikayı uygulamaya devam eder.

MTA-STS kurulumu adım adım

Kurulum dört bölümden oluşur ve her biri ayrı bir kontrol gerektirir.

MX sunucularını hazırlayın

Tüm MX sunucularınız STARTTLS desteklemeli ve MX kaydındaki adla eşleşen, güvenilir bir sertifika otoritesinden alınmış geçerli bir sertifika sunmalıdır. Kendinden imzalı sertifikalar MTA-STS ile çalışmaz. MX kayıtlarınızın doğru olduğundan emin olmak için MX kaydı rehberimize göz atabilirsiniz.

Politika dosyasını yayımlayın

mta-sts.example.com.tr adında, geçerli HTTPS sertifikasına sahip bir web adresi oluşturun ve aşağıdaki içeriği /.well-known/mta-sts.txt yolunda düz metin olarak yayımlayın:

version: STSv1
mode: testing
mx: mx1.example.com.tr
mx: mx2.example.com.tr
max_age: 86400

mx satırları *.example.com.tr gibi en soldaki etikette joker karakter içerebilir. max_age saniye cinsindendir ve en fazla 31557600 (yaklaşık bir yıl) olabilir. Gönderenler HTTP yönlendirmelerini izlemediği için dosya doğrudan bu adreste sunulmalıdır.

Politika dosyası için ayrı bir uygulama sunucusu gerekmez; statik dosya sunabilen herhangi bir web sunucusu yeterlidir. Önemli olan, mta-sts.example.com.tr adının bu ada uygun, geçerli bir sertifikayla yanıt vermesi ve dosyanın düz metin olarak sunulmasıdır. İsterseniz bu adı, politika barındırma hizmeti sunan bir sağlayıcıya CNAME kaydıyla da yönlendirebilirsiniz.

MTA-STS TXT kaydını ekleyin

_mta-sts.example.com.tr.  3600  IN  TXT  "v=STSv1; id=2026101101"

id değeri 1 ile 32 karakter arasında harf ve rakamlardan oluşur. Politika dosyasını her değiştirdiğinizde bu değeri de değiştirmelisiniz; gönderenler yeni politikayı indirmeleri gerektiğini buradan anlar.

TLS-RPT raporlamasını açın

_smtp._tls.example.com.tr.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:[email protected]"

Bu kayıt, gönderen sunucuların TLS bağlantı sonuçlarını günlük raporlar halinde size iletmesini sağlar.

Testing ve enforce modları arasındaki fark nedir?

Güvenli bir geçiş için şu sırayı izleyebilirsiniz:

1. TLS-RPT kaydını ilk iş olarak yayımlayın; böylece politika devreye girmeden önce bile bazı gönderenlerden TLS bağlantı sonuçları almaya başlayabilirsiniz.
2. Politikayı testing modunda ve bir gün gibi kısa bir max_age değeriyle yayımlayın.
3. İki ila dört hafta boyunca raporları izleyin; görülen hataları sertifika veya MX düzeltmeleriyle giderin.
4. Politikayı enforce moduna alın ve TXT kaydındaki id değerini değiştirin.
5. Birkaç hafta sorunsuz geçtikten sonra max_age değerini artırın; RFC 8461 de bu değerin tipik olarak haftalar veya daha uzun süreler mertebesinde olmasını bekler.

Bu kademeli yaklaşım, DMARC politikasını none değerinden reject değerine taşırken izlenen mantığa benzer.

TLS-RPT raporları ne anlatır?

RFC 8460 ile tanımlanan TLS-RPT raporları JSON biçimindedir ve her politika için başarılı ve başarısız oturum sayılarını içerir. Kısaltılmış bir örnek:

{
  "organization-name": "Örnek Posta Sağlayıcı",
  "date-range": {
    "start-datetime": "2026-10-10T00:00:00Z",
    "end-datetime": "2026-10-10T23:59:59Z"
  },
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "example.com.tr" },
    "summary": {
      "total-successful-session-count": 512,
      "total-failure-session-count": 3
    },
    "failure-details": [{
      "result-type": "certificate-expired",
      "receiving-mx-hostname": "mx2.example.com.tr",
      "failed-session-count": 3
    }]
  }]
}

Raporlarda sık karşılaşılan hata türleri şunlardır:

• certificate-expired: MX sunucusunun sertifikasının süresi dolmuş.
• certificate-host-mismatch: Sertifikadaki ad, MX sunucusunun adıyla eşleşmiyor.
• starttls-not-supported: MX sunucusu STARTTLS sunmuyor.
• sts-policy-fetch-error: Politika dosyası indirilemedi.
• validation-failure: Genel bir doğrulama hatası oluştu.

MTA-STS ile DANE arasındaki fark nedir?

İki yöntem birbirini dışlamaz ve birlikte kullanılabilir. DNS sağlayıcısı DNSSEC desteklemeyen kuruluşlar için MTA-STS daha kolay uygulanabilir bir başlangıçtır.

MTA-STS neyi korumaz?

MTA-STS yalnızca sunucular arasındaki aktarımı korur; iletinin posta kutusunda nasıl saklandığına veya uçtan uca şifrelenip şifrelenmediğine karışmaz. Ayrıca politika ilk kez indirilene kadar koruma sınırlıdır: Gönderen sunucu alan adınızla ilk kez karşılaşıyorsa ve o anda bir saldırgan DNS yanıtlarını engelliyorsa politika hiç öğrenilmeyebilir. Bu nedenle MTA-STS'yi, iletinin içeriğini koruyan uçtan uca şifrelemenin yerine değil, aktarım güvenliğinin bir parçası olarak düşünün.

Sık yapılan hatalar

• Politika dosyasını değiştirip TXT kaydındaki id değerini güncellememek.
• mx satırlarına MX kayıtlarında kullanılmayan adlar yazmak ya da bir sunucuyu listeye eklemeyi unutmak.
• mta-sts alt alan adındaki HTTPS sertifikasının yenilenme tarihini takip etmemek.
• Doğrudan enforce modu ve uzun bir max_age ile başlamak.
• MX sunucularında süresi dolmuş ya da adla eşleşmeyen sertifika kullanmak.

MX kayıtlarınız MXZilla gibi bir filtreleme ağ geçidini gösteriyorsa, politika dosyasındaki mx satırlarının ağ geçidinin sunucu adlarını içermesi gerekir. Ağ geçidine geçerken MX kayıtlarıyla birlikte politika dosyasını ve id değerini de aynı planın parçası olarak güncelleyin.

MTA-STS'yi kurmadan önce MX, SPF, DKIM ve DMARC kayıtlarınızın sağlam olduğundan emin olun; ücretsiz güvenlik kontrolü bu kayıtları hızlıca denetler. Gelen posta trafiğinizi filtreleyen bir ağ geçidi arıyorsanız paketlerimizi inceleyebilirsiniz.

Sık sorulan sorular

MTA-STS gelen e-postayı mı giden e-postayı mı korur?

MTA-STS, politikayı yayımlayan alan adına gelen e-postaları korur. Politika, size posta gönderen sunuculara nasıl bağlanmaları gerektiğini söyler. Kendi giden postanızın korunması ise sizin gönderen sunucunuzun karşı tarafın MTA-STS politikasını desteklemesine bağlıdır.

MTA-STS için DNSSEC gerekir mi?

Gerekmez. MTA-STS güvenini HTTPS sertifikalarından alır ve politika dosyası geçerli bir sertifikayla sunulan bir web adresinden indirilir. DNSSEC gerektiren yöntem DANE'dir ve iki yöntem birlikte de kullanılabilir.

MTA-STS politikası değişince ne yapmalıyım?

Politika dosyasını güncelledikten sonra _mta-sts TXT kaydındaki id değerini mutlaka değiştirin, çünkü gönderen sunucular yeni politikayı ancak bu değişikliği fark ettiklerinde indirir. Politikayı tamamen kaldırmak istiyorsanız önce mode: none içeren bir politika yayımlayıp eski önbelleklerin süresinin dolmasını bekleyin.

TLS-RPT olmadan MTA-STS kullanılabilir mi?

Kullanılabilir, ancak önerilmez. TLS-RPT olmadan testing modundaki sorunları göremez ve enforce moduna geçtiğinizde teslim edilemeyen iletilerden habersiz kalabilirsiniz. Raporlama tek bir TXT kaydıyla açıldığı için eklemesi zahmetsizdir.

Hangi sağlayıcılar MTA-STS'yi destekler?

Gmail ve Microsoft 365 gibi büyük posta sağlayıcıları, e-posta gönderirken alıcı alan adının MTA-STS politikasını dikkate alır; Microsoft, Exchange Online'da bu doğrulamanın varsayılan olarak açık olduğunu belgelerinde belirtir. Postfix gibi açık kaynak sunucularda ise destek ek bileşenlerle sağlanabilir. Destek kapsamı zamanla değiştiği için kullandığınız sağlayıcının güncel belgelerini kontrol etmek en doğrusudur.