MTA-STS Kaydı Nedir, Nasıl Kurulur

SMTP, 1980'lerden kalma bir protokol olduğu için şifrelemeyi sonradan, üstüne yama gibi aldı. Bugün iki posta sunucusu birbirine bağlandığında TLS kullanıp kullanmayacağına o an karar verir ve bu karar tamamen isteğe bağlıdır — araya giren biri STARTTLS reklamını sessizce silerse iki taraf da hiçbir uyarı görmeden düz metin konuşmaya devam eder. MTA-STS kaydı tam olarak bu açığı kapatmak için var: alan adın adına "bana mail göndereceksen TLS kullanacaksın, sertifikam da şu isimlere ait olacak" diye bağlayıcı bir politika ilan etmeni sağlar.

Bu rehberde MTA-STS'in ne çözdüğünü, üç parçadan (DNS kaydı, HTTPS politika dosyası, MX listesi) nasıl oluştuğunu ve bunu kendi alan adında adım adım nasıl kuracağını anlatacağım. Mod seçiminde neden testing ile başlaman gerektiğini, politika dosyasının hangi teknik şartları sağlaması gerektiğini ve kurulumdan sonra nasıl doğrulayacağını da göreceğiz. Kurulum toplamda yarım saat sürer; asıl dikkat isteyen kısım politikayı enforce moduna alma kararıdır.

MTA-STS Neyi Çözüyor: SMTP'nin Şifreleme Açığı#

Klasik SMTP teslimatında gönderen sunucu, alıcının MX kaydını bulur, bağlanır ve karşı taraf 250-STARTTLS diye cevap verirse şifreli oturuma geçer. Sorun şu: bu reklam düz metin olarak gelir. Ağ yolunda konumlanmış bir saldırgan o satırı çıkarırsa gönderen sunucu "demek TLS desteklemiyor" diye düşünür ve maili şifresiz gönderir. Buna STARTTLS indirgeme (downgrade) saldırısı denir ve gönderen tarafta hiçbir uyarı üretmez.

İkinci sorun sertifika doğrulamasıdır. Çoğu MTA, fırsatçı TLS kullanırken sertifikayı doğrulamaz; kendinden imzalı bir sertifika bile kabul edilir. Yani bağlantı şifrelidir ama karşındakinin gerçekten alıcı sunucu olduğunun garantisi yoktur. MTA-STS her iki sorunu birden çözer: politikayı bir kez indiren gönderen sunucu, bundan sonra o alan adına yalnızca TLS ile ve geçerli, isim eşleşmesi doğrulanmış bir sertifika ile bağlanır.

DNSSEC gerektiren DANE'in aksine MTA-STS, güveni HTTPS ve mevcut sertifika altyapısına dayandırır. Bu, DNSSEC kurmadan da uygulanabilmesi anlamına gelir ve pratikte benimsenme oranının yüksek olmasının sebebi budur. Gmail, Outlook ve Yahoo gibi büyük gönderenler MTA-STS politikalarına uyar.

MTA-STS Nasıl Çalışır: Üç Parça#

Kurulum üç bileşenden oluşur ve üçü de doğru olmadan sistem çalışmaz.

1. DNS TXT kaydı — _mta-sts.firmaniz.com adresinde yayınlanır ve yalnızca "politikam var, sürümü şu" bilgisini taşır. Politikanın kendisi burada durmaz.
2. HTTPS politika dosyası — https://mta-sts.firmaniz.com/.well-known/mta-sts.txt adresinde yayınlanır ve asıl kuralları içerir.
3. Geçerli TLS sertifikası — Hem politika sunan web sunucusunun hem de MX sunucularının sertifikaları geçerli ve isimleri eşleşen sertifikalar olmalıdır.

Gönderen sunucunun akışı şöyle işler: mail göndereceği alan adı için önce _mta-sts TXT kaydını sorar. Kayıt varsa ve id değeri elindekinden farklıysa politika dosyasını HTTPS üzerinden indirir, max_age süresince önbelleğe alır ve o süre boyunca her teslimatta bu kurallara uyar. Politika önbellekte olduğu sürece DNS'e tekrar bakılmaz — bu, saldırganın DNS'i ele geçirse bile politikayı hemen kaldıramaması demektir.

Adım 1: Politika Dosyasını Yayınlamak#

Politika dosyası düz metindir ve biçimi katıdır. Önce mta-sts alt alan adı için bir A kaydı oluştur ve o isme geçerli bir TLS sertifikası al.

; DNS bölgesine ekle
mta-sts.firmaniz.com.   3600   IN   A      185.12.34.56
_mta-sts.firmaniz.com.  3600   IN   TXT    "v=STSv1; id=20260825120000;"

Ardından web sunucunda dosyayı yayınla. İçeriği şudur:

version: STSv1
mode: testing
mx: mail.firmaniz.com
mx: mail2.firmaniz.com
max_age: 604800

mx satırlarında MX kayıtlarında yazan tüm sunucu isimlerini listelemen gerekir; eksik bıraktığın bir sunucuya yapılan teslimat enforce modunda reddedilir. Joker karakter kullanabilirsin: mx: *.firmaniz.com satırı tüm alt alan adlarını kapsar ama yalnızca bir seviye derinlik için geçerlidir.

Nginx tarafında yayınlamak için ayrı bir sunucu bloğu en temiz yöntemdir:

server {
    listen 443 ssl;
    server_name mta-sts.firmaniz.com;

    ssl_certificate     /etc/letsencrypt/live/mta-sts.firmaniz.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/mta-sts.firmaniz.com/privkey.pem;

    root /var/www/mta-sts;

    location = /.well-known/mta-sts.txt {
        default_type text/plain;
        add_header Cache-Control "max-age=3600";
    }
}

Üç teknik şart var ve üçü de zorunludur: dosya HTTPS üzerinden sunulmalı, Content-Type başlığı text/plain olmalı ve istek yönlendirme olmadan doğrudan 200 dönmelidir. HTTP'den HTTPS'e yönlendirme bile kabul edilmez — gönderen sunucu doğrudan HTTPS ister ve 3xx görürse politikayı yok sayar.

Adım 2: DNS TXT Kaydını Doğru Yazmak#

TXT kaydında yalnızca iki alan bulunur ve id değeri kritik öneme sahiptir.

_mta-sts.firmaniz.com.  3600  IN  TXT  "v=STSv1; id=20260825120000;"

id değeri, politika dosyasının sürüm numarasıdır. Gönderen sunucular önbellekteki id ile DNS'teki id aynı olduğu sürece dosyayı tekrar indirmez. Yani politika dosyasını değiştirdiğinde id değerini mutlaka artırmalısın; aksi hâlde değişikliğin max_age süresi (bir haftaya kadar) boyunca hiç kimseye ulaşmaz. Tarih-saat biçiminde tutmak (YYYYMMDDHHMMSS) hem artan bir değer üretir hem de ne zaman değiştirdiğini hatırlatır.

Kayıt adının başındaki alt çizgiye dikkat et: DNS kaydı _mta-sts, politika dosyasının bulunduğu host ise mta-sts (alt çizgisiz). Bu ikisini karıştırmak en sık yapılan hatadır. MX kayıtlarının teslimatı nasıl yönlendirdiğini tazelemek istersen e-postalarım gelmiyor: MX sorunu yazısı iyi bir başlangıçtır.

Mod Seçimi: none, testing, enforce#

Politika dosyasındaki mode satırı, kuralın ne kadar bağlayıcı olduğunu belirler ve doğru sırayla ilerlemek çok önemlidir.

• testing — Gönderen sunucu politikayı okur, ihlal olursa maili yine de teslim eder ama TLS-RPT üzerinden rapor gönderir. Her kurulum burada başlamalıdır.
• enforce — Politika ihlal edilirse teslimat yapılmaz, mail gönderende kuyrukta bekler ve sonunda geri döner. Gerçek koruma budur.
• none — Politikanın kaldırıldığını ilan eder. Önbellekleri temizlemenin doğru yolu politikayı silmek değil, mode: none yayınlayıp max_age süresi kadar beklemektir.

testing modunda en az iki hafta kal ve gelen TLS-RPT raporlarını oku. Bu raporlar, hangi gönderenin hangi sunucuna bağlanırken sorun yaşadığını tam olarak söyler; nasıl okunacağını TLS-RPT kaydı ve raporları yazısında anlattım. Raporlarda başarısızlık görmediğin bir dönem geçirdikten sonra enforce moduna geç ve id değerini artırmayı unutma.

max_age değeri için ilk kurulumda kısa bir süre (örneğin 86400, yani bir gün) kullan. Bir hata yaparsan düzeltmen bir gün sürer, bir hafta değil. Politikanın oturduğundan emin olduktan sonra 604800 (bir hafta) ya da daha uzun bir değere çıkabilirsin.

Doğrulama ve Sorun Giderme#

Kurulumdan sonra üç şeyi ayrı ayrı doğrula: DNS kaydı, politika dosyası ve MX sunucularının sertifikaları.

# 1) TXT kaydı görünüyor mu
dig _mta-sts.firmaniz.com TXT +short
# "v=STSv1; id=20260825120000;"

# 2) Politika dosyası yönlendirmesiz ve doğru tiple mi dönüyor
curl -sSI https://mta-sts.firmaniz.com/.well-known/mta-sts.txt
# HTTP/2 200
# content-type: text/plain

curl -sS https://mta-sts.firmaniz.com/.well-known/mta-sts.txt

# 3) MX kayıtları politika ile birebir uyuşuyor mu
dig firmaniz.com MX +short
# 10 mail.firmaniz.com.
# 20 mail2.firmaniz.com.

# 4) Her MX sunucusunun sertifikası geçerli ve isim eşleşiyor mu
openssl s_client -connect mail.firmaniz.com:25 -starttls smtp \
  -servername mail.firmaniz.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

Dördüncü adımı atlamak, enforce moduna geçtiğinde mail almayı tamamen durdurmanın en hızlı yoludur. MX sunucunda kendinden imzalı ya da farklı bir isme ait sertifika varsa, politikaya uyan her gönderen teslimatı reddeder ve sen bunu ancak kullanıcılar şikâyet ettiğinde fark edersin.

Bir kontrol listesi olarak: sertifika süresi dolmamış olmalı, sertifikadaki isim MX kaydındaki isimle birebir eşleşmeli, ara sertifika zinciri eksiksiz sunulmalı ve tüm MX sunucuları TLS 1.2 ya da üstünü desteklemelidir. Postfix tarafında bunları nasıl yapılandıracağını Postfix main.cf yapılandırması yazısındaki TLS bölümünde bulabilirsin.

Sık Yapılan Hatalar#

1. Politika dosyasını HTTP'den HTTPS'e yönlendirmek. Gönderen sunucu 3xx yanıtını kabul etmez ve politikayı hiç okumaz. Doğrudan 200 dönmeli.
2. id değerini artırmadan politika değiştirmek. Değişiklik max_age süresi boyunca kimseye ulaşmaz; en fazla bir hafta boyunca eski kural geçerli kalır.
3. MX listesini eksik yazmak. Yedek MX sunucunu politikaya eklemezsen, birincil sunucu düştüğünde enforce modu yedek sunucuya teslimatı da engeller.
4. Doğrudan enforce ile başlamak. Testing aşamasını atlarsan, fark etmediğin bir sertifika sorunu yüzünden mail almayı tamamen durdurabilirsin.
5. mta-sts alt alan adının sertifikasını yenilemeyi unutmak. Sertifika süresi dolduğunda gönderenler politikayı indiremez; önbellek süresi bitince koruma sessizce devre dışı kalır.
6. Politikayı silerek kaldırmaya çalışmak. Doğru yol mode: none yayınlayıp max_age süresi kadar beklemektir; dosyayı silmek önbellekteki eski politikayı geçersiz kılmaz.

Sıkça Sorulan Sorular#

MTA-STS zorunlu mu, kurmazsam ne olur#

Zorunlu değildir; kurmazsan mailler yine gelir ve gider. Ancak alan adın, STARTTLS indirgeme saldırılarına ve sahte sertifikayla araya girme girişimlerine karşı savunmasız kalır. Büyük gönderenlerin bir kısmı MTA-STS politikası olan alan adlarını daha güvenilir kabul eder. Kurumsal veya finansal yazışma taşıyan bir alan adında kurulmasını güçlü biçimde öneririm; teknik maliyeti düşük, kazancı somuttur.

MTA-STS ile DANE arasındaki fark nedir#

İkisi de aynı sorunu çözer ama güven kaynakları farklıdır. DANE, sertifika parmak izini DNS'te yayınlar ve güvenliğini DNSSEC'e dayandırır; DNSSEC kurulu değilse hiç çalışmaz. MTA-STS ise politikayı HTTPS üzerinden yayınlar ve mevcut sertifika otoritesi altyapısına güvenir, yani DNSSEC gerektirmez. Pratikte DNSSEC yaygınlaşmadığı için MTA-STS'in benimsenmesi çok daha kolaydır; ikisini birlikte de kullanabilirsin.

MTA-STS kurulumu ne kadar sürer#

DNS kaydını eklemek, alt alan adı için sertifika almak ve politika dosyasını yayınlamak toplamda yarım saat civarında bir iştir. Asıl süre testing modunda geçirmen gereken gözlem dönemidir; en az iki hafta rapor toplayıp hiçbir teslimat sorunu görmediğinden emin olmadan enforce moduna geçme. DNS yayılması ve önbellek süreleri nedeniyle bir değişikliğin tüm gönderenlere ulaşması max_age değeri kadar sürer.

Politika dosyasını değiştirdim ama etkili olmuyor#

Neredeyse kesinlikle id değerini artırmayı unutmuşsundur. Gönderen sunucular DNS'teki id değişmediği sürece politikayı yeniden indirmez ve önbellekteki eski kuralı kullanmaya devam eder. TXT kaydındaki id değerini yeni bir tarih-saat damgasıyla güncelle, ardından dig _mta-sts.firmaniz.com TXT +short ile yeni değerin yayına girdiğini doğrula. Önbelleği zaten dolmuş gönderenler değişikliği hemen görür.

enforce moduna geçince mail almayı durdurur muyum#

Yalnızca MX sunucularından birinin TLS yapılandırması bozuksa. Politikaya uyan bir gönderen, sertifikası geçersiz ya da isim eşleşmesi başarısız olan bir sunucuya mail teslim etmez. Bu yüzden enforce öncesi her MX sunucusunu tek tek openssl s_client ile test etmen kritik. Sertifikaların geçerli ve isimleri MX kayıtlarıyla eşleşiyorsa geçiş görünmez olur, hiçbir kullanıcı fark etmez.

Paylaşımlı hosting kullanıyorum, MTA-STS kurabilir miyim#

Politika dosyasını yayınlamak için bir alt alan adına HTTPS ile dosya koyabiliyor olman yeterlidir; çoğu paylaşımlı hosting bunu destekler. Asıl kısıt, mail sunucusunun sertifika yapılandırmasını değiştirememendir — MX sunucuları hosting sağlayıcına aitse ve sertifikaları isim eşleşmesi sağlamıyorsa enforce moduna geçemezsin. Bu durumda sağlayıcına MX sunucularının sertifika durumunu sorman ya da kendi sunucunu kullanman gerekir.

Kapanış#

MTA-STS, posta trafiğinde şifrelemeyi "isteğe bağlı" olmaktan çıkarıp bağlayıcı bir kurala dönüştürür ve bunu DNSSEC gibi ağır bir ön koşul olmadan yapar. Aklında kalması gereken dört şey: DNS kaydı _mta-sts, politika dosyası mta-sts alt alan adında ve yönlendirmesiz HTTPS üzerinden sunulmalı; politikayı her değiştirdiğinde id değerini artır; testing modunda en az iki hafta kal; enforce öncesi tüm MX sunucularının sertifikalarını tek tek doğrula. Politikayı kaldırman gerekirse dosyayı silmek yerine mode: none yayınla.

Bu kurulum için geçerli sertifikalı bir web sunucusu ve kendi MX yapılandırmana erişim gerekir. Kendi posta altyapını kurup yönetmek istiyorsan VDS sunucularımızda tam root erişimiyle hem web hem mail tarafını yapılandırabilirsin; hazır ve doğru yapılandırılmış bir gönderim altyapısı istiyorsan SMTP sunucu paketlerimiz TLS sertifikası kurulu teslim edilir. Alt alan adı için sertifika ihtiyacın varsa SSL sertifikası sayfamıza, tüm bu işleri devretmek istersen sunucu yönetimi hizmetimize göz atabilirsin.