E‑Posta Taşırken ve Gönderirken Zorunlu Şifreleme: STARTTLS, DANE, MTA‑STS ve TLS Politikaları Nasıl Birlikte Kurulur?

E‑posta şifrelemesini gerçekten zorunlu hale getirmek

Artık kurumsal e‑postayı “mümkünse şifreli, olmazsa düz metin” mantığıyla taşımak veya göndermek lüks değil, ciddi bir risk. KVKK/GDPR kapsamında kişisel veri içeren her e‑posta, taşıma sırasında üçüncü tarafların göremeyeceği şekilde korunmak zorunda. Buna rağmen pek çok kurumda hâlâ sadece varsayılan opportunistic STARTTLS (yani “olursa güzel olur” TLS) açık, ancak zorunlu değil. E‑posta altyapısını yeni bir sağlayıcıya taşırken, yeni bir alan adı devreye alırken ya da kendi SMTP sunucunuzu kurarken, en çok atlanan konu bu “zorunluluk” katmanı.

Bu yazıda DCHost ekibi olarak, e‑postayı taşırken ve günlük gönderimde STARTTLS, DANE, MTA‑STS ve TLS policy (harita) mekanizmalarını birlikte nasıl kurgulayabileceğinizi adım adım ele alacağız. Hedefimiz: Alıcı ve gönderici MTA’lar arasında her zaman TLS, doğru sertifika ve doğru hedef sunucu kombinasyonunu garanti altına almak. Bunun için DNS, web sunucusu ve MTA yapılandırmasının nasıl uyumlu çalışması gerektiğini; Postfix gibi yaygın MTA’larda pratik ayar örneklerini ve kesintisiz geçiş senaryolarını detaylıca konuşacağız.

SMTP üzerinden TLS nasıl çalışır? Temeli netleştirelim

Önce temeli sağlam kuralım; çünkü DANE veya MTA‑STS’ye geçtiğinizde aslında bu altyapının üstüne politika katmanı ekliyorsunuz.

STARTTLS nedir?

SMTP, tarihsel olarak düz metin çalışan bir protokol. STARTTLS, SMTP oturumu başladıktan sonra tarafların karşılıklı anlaşarak bağlantıyı TLS’e yükseltmesini sağlayan komut seti. Özetle:

• İlk bağlantı düz metin başlar.
• Sunucu EHLO yanıtında STARTTLS desteğini ilan eder.
• İstemci (gönderici MTA) STARTTLS komutunu gönderir.
• TLS el sıkışması tamamlandıktan sonra SMTP komutları şifreli tünelden devam eder.

Buradaki kritik ayrım: Çoğu MTA, STARTTLS’i “opportunistic” modda kullanır. Yani alıcı tarafta STARTTLS yoksa veya TLS el sıkışması başarısız olursa bağlantıyı yine de şifresiz devam ettirir. İşte bu noktada DANE, MTA‑STS ve TLS politikaları devreye girerek “Şifresiz devam etmeyeceksin” diyebilir.

Opportunistic TLS vs zorunlu TLS

Opportunistic TLS yaklaşımında gönderici MTA, TLS dener; olmazsa şifresiz gönderir. Bu, e‑postanın ulaşma ihtimalini maksimize eder ama gizlilik ve bütünlük garantisi vermez. Araya giren bir saldırgan STARTTLS ilanını silebilir (STRIP), sahte bir MX’e yönlendirme yapabilir veya geçersiz sertifikayla MITM kurabilir.

Zorunlu TLS yaklaşımında ise:

• Alıcı alan adı için TLS gerekliliği bir politika ile ilan edilir (DANE veya MTA‑STS).
• Gönderici MTA, bu alan adının TLS ve sertifika kurallarına uymazsa mesajı kesinlikle göndermemelidir.
• Sonuç: E‑posta ya şifreli ve doğru hedefe gider ya da hiç gitmez. “Arası” yoktur.

Bu yazı tam olarak bu zorunlu TLS dünyasını nasıl kuracağınızı anlatıyor.

DANE ile DNS tabanlı TLS politikası

DANE (DNS‑Based Authentication of Named Entities), SMTP için en güçlü ve en teknik TLS zorunluluk mekanizması. Çalışabilmesi için alan adınızda DNSSEC etkin olmalı; çünkü DANE, güvenilir bir DNS zinciri üzerinden TLSA kayıtlarını doğrular.

DANE/TLSA nedir, nasıl çalışır?

DANE, SMTP için şu soruları DNS üzerinden yanıtlar:

• Bu alan adının MX’i hangi host ve portta?
• Bu host için kabul edilebilir TLS sertifikası hangisi?
• Gönderici MTA, hangi sertifika türünü beklemeli ve ona göre doğrulama yapmalı?

Bunun için TLSA adlı özel DNS kayıtları kullanılır. Örnek bir kayıt:

_25._tcp.mail.ornekdomain.com. IN TLSA 3 1 1 <sha256‑sertifika‑özeti>

Burada:

• _25._tcp.mail.ornekdomain.com: 25 numaralı port üzerinden TCP ile ulaşılan mail sunucusu.
• 3 1 1: TLSA parametreleri (usage, selector, matching type). Örneğin 3 1 1, DANE‑EE, SubjectPublicKeyInfo, SHA‑256 hash anlamına gelir.
• Son kısım: Sertifikanızın ya da public key’inizin SHA‑256 özeti.

Gönderici MTA, DNSSEC ile doğruladığı bu kaydı kullanarak şunu der: “Bu alan adına ait SMTP bağlantısında yalnızca bu sertifikaya (veya bu CA zincirine) güveneceğim. Sertifika farklıysa ya MITM vardır ya da yanlış yapılandırma. Bu durumda mesajı asla şifresiz ya da yanlış hedefe göndermem.”

DANE’in güçlü ve zayıf yanları

Artıları:

• Politikayı DNSSEC ile kökten güvenli ilan edersiniz; üçüncü taraf bir CA’ya veya ayrı bir HTTPS endpoint’ine ihtiyacınız yoktur.
• MX kayıtlarıyla birebir entegre çalışır; yanlış MX’e gitme riskini ciddi biçimde azaltır.
• “Taraflar arası gizlice anlaşma” ihtimalini (MITM’in sahte sertifika sunması) büyük ölçüde engeller.

Eksi yanları:

• DNSSEC şart. Her DNS sağlayıcısı DNSSEC’i doğru ve kararlı sunmuyor; operasyonel karmaşıklık artabiliyor.
• Gönderici MTA’ların DANE desteği hâlâ tüm ekosistemde yaygın değil. Büyük sağlayıcılar ve modern MTA’lar destekliyor, ama evrenin tamamı değil.
• TLSA kayıt yönetimi dikkat gerektirir; sertifika yenilerken hash güncellemeyi unutmamak gerekiyor.

Alan adınız için zaten DNSSEC’i etkinleştirdiyseniz, DANE eklemek SMTP tarafında makul bir sonraki adım olur.

MTA‑STS ile HTTPS tabanlı TLS politikası

MTA‑STS (SMTP MTA Strict Transport Security), DNSSEC gerektirmeyen ama HTTPS’e dayanan bir TLS zorunluluk mekanizmasıdır. Temel fikir, alan adınız için “TLS kullanacaksınız ve yalnızca şu host’lara bağlanacaksınız” diyen bir politika dosyasını HTTPS üzerinden imzalatmak.

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

Bir alan adını örnek alalım: ornekdomain.com. MTA‑STS devreye alınırken üç bileşen kullanılır:

1. DNS’te TXT kayıt: _mta-sts.ornekdomain.com
2. HTTPS endpoint: https://mta-sts.ornekdomain.com/.well-known/mta-sts.txt
3. Policy dosyası: Sunucular, mod, sürüm ve MX desenlerini içeren metin dosyası.

Örnek bir politika dosyası şöyle olabilir:

version: STSv1
mode: enforce
mx: mail1.ornekdomain.com
mx: mail2.ornekdomain.com
max_age: 604800

DNS tarafında ise:

_mta-sts.ornekdomain.com. IN TXT "v=STSv1; id=20250208"

Gönderici MTA, alıcı alan adının MTA‑STS desteği olup olmadığını önce bu TXT kaydıyla anlar, sonra HTTPS üzerinden politika dosyasını indirir ve önbelleğe alır. mode: enforce ise şunları söyler:

• Bu alan adına e‑posta gönderirken her zaman TLS kullanılacak.
• MX host’u yalnızca tanımlı desenlerle eşleşiyorsa geçerli sayılacak.
• Sunulan sertifika, standart CA doğrulamasından geçmeli (tarayıcı TLS’ine benzer).

MTA‑STS’nin güçlü ve zayıf yanları

Artıları:

• DNSSEC’e ihtiyaç duymadan çok geniş bir ekosisteme uyum sağlar.
• CA tabanlı, tarayıcı benzeri bir TLS güven modeli kullanır; yöneticilerin kafası daha az karışır.
• Politikayı değiştirmek görece kolaydır; id parametresi ile sürüm yönetimi yapılabilir.

Eksi yanları:

• İlk politika alma aşamasında “TOFU” (Trust On First Use) benzeri zayıflıklar vardır; ilk indirme sırasında MITM teorik risk taşır.
• HTTPS endpoint’in kendisi için de doğru SSL/TLS konfigürasyonu ve uptime gerekir.
• DNS + HTTPS entegrasyonu, küçük ekipler için karmaşık gelebilir.

MTA‑STS, özellikle DNSSEC kullan(a)mayan ama TLS’i zorunlu kılmak isteyen alan adları için oldukça pratik. Biz DCHost tarafında müşterilerimizin alan adları için MTA‑STS ve TLS‑RPT yapılandırmasını sıkça öneriyoruz.

Gönderici tarafta TLS policy haritaları (örnek: Postfix)

DANE ve MTA‑STS, alıcı alan adının dış dünyaya “Ben TLS istiyorum” demesini sağlar. Ancak gönderici MTA’nın bu isteğe nasıl tepki vereceği de ayrı bir ayardır. Çoğu modern MTA, alan adı bazlı TLS policy map veya smtp_tls_policy_maps gibi mekanizmalar sunar.

Postfix’te basit bir TLS policy örneği

Postfix kullanan bir VPS veya dedicated sunucuda şöyle bir yapılandırma düşünebiliriz:

# main.cf
smtp_tls_security_level = may
smtp_tls_policy_maps = texthash:/etc/postfix/tls_policy

/etc/postfix/tls_policy dosyasında ise:

ornekdomain.com      encrypt
kritikfirma.com      secure
*.bankadomain.com    secure match=mx

Burada:

• encrypt: Bu alan adına her zaman TLS kullan (ama sertifika doğrulamasında esnek ol).
• secure: Hem TLS zorunlu olsun hem de sertifika doğrulaması sıkı olsun.
• match=mx: MX kayıtlarına göre host eşleştirmesi yap.

DANE ve MTA‑STS devreye girdikçe Postfix gibi MTA’lar bunları otomatik olarak da değerlendirebiliyor. Ancak kritik alanlar için manuel policy map tanımları hâlâ oldukça değerli.

STARTTLS, DANE, MTA‑STS ve TLS politikaları birlikte nasıl kurgulanır?

Şimdi asıl soruya gelelim: Bu mekanizmaları birlikte kullanınca ideal mimari nasıl görünür? DCHost tarafında önerdiğimiz katmanlı model şu:

1. Katman: Temel TLS hijyeni

• Mail sunucunuzda TLS 1.2 ve TLS 1.3 etkin, zayıf şifre paketleri kapalı olmalı.
• Güncel bir sertifika zinciri (Let’s Encrypt veya kurumsal SSL) kullanmalısınız.
• İsim eşleşmesi doğru olmalı: Sertifikadaki CN/SAN ile SMTP host adınız (örn. mail.ornekdomain.com) tutarlı olsun.

Bu adımları detaylı anlattığımız SSL/TLS protokol güncellemeleri rehberi, web tarafına odaklansa da aynı prensipler SMTP için de geçerli.

2. Katman: Opportunistic STARTTLS + SPF/DKIM/DMARC

Henüz DANE/MTA‑STS seviyesine geçemeyenler için bile en azından:

• STARTTLS zorunlu olmasa bile aktif olmalı,
• SPF, DKIM, DMARC düzgün ayarlanmalı,
• PTR (rDNS) doğru tanımlanmalı.

Bu aşama için SPF, DKIM ve DMARC’i sıfırdan kurma rehberimizi ve PTR kaydı yapılandırmasını detaylandırdığımız yazıyı mutlaka okumanızı öneririm. Şifreleme tek başına yetmez; kimlik doğrulama ve itibar yönetimi de kritik.

3. Katman: Alıcı tarafında TLS politikası ilanı (DANE ve/veya MTA‑STS)

Alıcı alan adı sahibi olarak iki opsiyonunuz var; ikisini de paralel kullanmak ideal:

• DANE + DNSSEC: DNS tarafında TLSA kayıtlarıyla sertifika politikanızı ilan edin.
• MTA‑STS: DNS TXT + HTTPS politika dosyası ile TLS ve MX desenlerini tanımlayın.

Bu iki mekanizma birbirini tamamlar. DNSSEC kullanan, teknik ekibi güçlü organizasyonlarda DANE çok iyi çalışıyor. DNSSEC’in olmadığı veya karmaşık geldiği senaryolarda MTA‑STS, TLS’i zorunlu kılmak için pratik bir araç. Biz DCHost üzerinde yönettiğimiz alan adlarında her iki seçeneği de müşterinin operasyon seviyesine göre birlikte veya ayrı ayrı konumlandırıyoruz.

4. Katman: Gönderici tarafta zorunlu TLS policy haritaları

Gönderici MTA’nız (örneğin DCHost üzerinde çalışan Postfix’li bir VPS) için şu yaklaşımı uygulayabilirsiniz:

• Tüm dış alanlar için en az “may” seviyesinde STARTTLS aktif olsun.
• Regülasyon kritik alanlar (banka, kamu, sağlık, finans) için encrypt/secure gibi sıkı TLS policy tanımları ekleyin.
• DANE veya MTA‑STS politikası gördüğünüz alanlar için, MTA’nızın bu politikaları hard‑fail modunda uyguladığından emin olun.

Sonuç: Bazı alanlara e‑posta hiç gönderilmeyebilir (alıcı taraf yanlış konfigüre olduğunda). Fakat bu tercih, şifresiz veya MITM riskli bir bağlantıya göre çok daha güvenli ve regülasyon dostudur.

5. Katman: İzleme ve raporlama (TLS‑RPT / log analizi)

MTA‑STS ile birlikte TLS‑RPT (SMTP TLS Reporting) de devreye alınabilir. Bu mekanizma, diğer MTA’ların sizin alan adınıza TLS ile bağlanırken yaşadıkları sorunları raporlamasını sağlar. Böylece:

• Yanlış sertifika zinciri,
• Hatalı MX tanımı,
• Uyumsuz protokol/şifre setleri

gibi hataları sahada gözlemleyebilirsiniz. Bu başlığı daha derin işlediğimiz MTA‑STS, TLS‑RPT ve DANE/TLSA ile SMTP güvenliğini güçlendirme rehberimiz bu yazının doğal tamamlayıcısıdır.

E‑posta altyapısını taşırken şifrelemeyi bozmadan ilerlemek

Teori güzel ama en çok hata taşıma sırasında yapılıyor. Alan adınızı veya mail sunucunuzu yeni bir altyapıya geçirirken, TLS tarafını bozmadan (hatta güçlendirerek) nasıl ilerlemelisiniz?

1. Adım: Mevcut durumu envanterleyin

Önce şunları not edin:

• Mevcut MX kayıtları ve TTL değerleri
• Kullanılan SMTP host adları (örn. mail.eski-domain.com)
• Mevcut sertifika türü ve kapsamı (SAN alanları, wildcard vs.)
• DANE (TLSA), MTA‑STS ve TLS‑RPT kullanıp kullanmadığınız

Bu aşamada e‑posta teslim edilebilirliği denetim listemizde anlattığımız DNS ve IP itibarı kontrollerini de paralel yürütmek iyi fikirdir.

2. Adım: Yeni altyapıda TLS’i önce ayağa kaldırın

DCHost üzerinde yeni bir paylaşımlı hosting, VPS veya dedicated sunucuya geçiyorsanız:

• Yeni SMTP host adını netleştirin (örn. mail.yeni-domain.com).
• Bu host için geçerli, güncel TLS sertifikası kurun.
• SMTP sunucusunda TLS 1.2/1.3 ve modern şifre paketlerini etkinleştirin.
• Test için openssl s_client -starttls smtp -crlf -connect mail.yeni-domain.com:587 gibi komutlarla bağlantıyı sınayın.

3. Adım: MX cutover’dan önce DANE/MTA‑STS geçiş planı

Mevcutta DANE veya MTA‑STS kullanıyorsanız, MX geçişi yaparken aşağıdaki sıraya dikkat edin:

1. Yeni MX host’unuzu paralel ekleyin (eskiyi hemen silmeyin).
2. Yeni host için gerekli TLSA kayıtlarını ekleyin (DNSSEC varsa).
3. MTA‑STS politika dosyanıza yeni MX’i ekleyip id değerini güncelleyin.
4. Tüm bu değişiklikler DNS’te yayıldıktan ve testler geçtikten sonra MX ağırlıklarını yavaş yavaş yeni host lehine çevirin.
5. Eski host’a gelen son trafiği izleyip drenaj tamamlanınca son MX ve TLSA referanslarını temizleyin.

Böylece hiçbir noktada “MX yeni host’u gösteriyor ama TLS politikası eski host’u zorunlu kılıyor” gibi bir tutarsızlığa düşmezsiniz.

4. Adım: Zorunlu TLS’te hataya yer bırakmadan test

Zorunlu TLS kullanan bir alan adı için taşımadan sonra mutlaka:

• Farklı dış sağlayıcılardan test e‑postaları gönderip TLS oturumlarını loglardan inceleyin.
• Online TLS checker araçlarıyla SMTP sertifika zincirinizi ve protokol desteğinizi doğrulayın.
• Hata durumlarında 550, 554, 421 gibi hata kodlarını doğru yorumlayın.

DCHost ekibi olarak e‑posta altyapısını bize taşıyan müşterilerde, bu testleri beraber yürütüp hem TLS şifrelemesini hem de teslim edilebilirliği birlikte doğruluyoruz.

KVKK/GDPR, loglar ve izleme tarafı

Zorunlu TLS yalnızca teknik bir “güzel olsun” özelliği değil, aynı zamanda regülasyon uyumu açısından da kritik. Özellikle KVKK, e‑postayla aktarılan kişisel veriler için aktarılırken şifrelemeyi makul ve beklenen bir önlem olarak görüyor.

Bu bağlamda:

• SMTP loglarınızda TLS kullanılan ve kullanılmayan bağlantıları ayırt edebilmeli,
• Mümkünse TLS‑RPT raporlarını toplayıp düzenli analiz edebilmeli,
• Şüpheli sertifika hatalarını veya TLS fallback denemelerini alarmlarla gözlemleyebilmelisiniz.

Genel log saklama ve anonimleştirme gereksinimlerini de hosting ve e‑posta altyapısında log saklama süreleri rehberimizde ayrıntılı olarak anlattık; TLS’e özel log analizi de bu politikanın doğal bir parçası olmalı.

DCHost altyapısında pratik bir senaryo

Örnek bir kurumsal senaryo düşünelim: Kendi on‑premise mail sunucusundan DCHost üzerindeki yönetilen bir VPS’e geçiyorsunuz ve şu hedefleriniz var:

• Tüm dış e‑postalar TLS ile şifreli gitsin.
• Kurumsal alan adınıza gelen e‑postalar yalnızca sizin MX’lerinize ve doğru sertifika ile kabul edilsin.
• Taşıma sırasında e‑posta kesintisi minimum olsun.

Biz bu tip projelerde tipik olarak şu adımları izliyoruz:

1. DCHost VPS üzerinde Postfix + Dovecot altyapısını TLS 1.2/1.3 ve modern şifre setleriyle kurmak.
2. Alan adı için SPF, DKIM, DMARC ve PTR yapılandırmasını taşıma öncesi hazır hale getirmek.
3. DANE isteniyorsa DNSSEC’i etkinleştirip TLSA kayıtlarını planlamak.
4. MTA‑STS ve TLS‑RPT’yi devreye alıp, mode: testing ile birkaç gün gözlem yapmak, ardından mode: enforce’a almak.
5. MX cutover’ı TTL’leri düşürerek ve kademeli ağırlık değişimi ile gerçekleştirmek.
6. Son olarak, DCHost üzerindeki outbound Postfix’te kritik alanlar için TLS policy haritalarını tanımlamak.

Bu sayede taşıma tamamlandığında yalnızca daha hızlı veya daha stabil bir altyapıya geçmiş olmuyor; aynı zamanda e‑posta şifreleme ve kimlik doğrulama seviyeniz de ciddi şekilde yükselmiş oluyor.

Sonuç: E‑postada “olursa iyi olur” döneminden “ya TLS ya hiç” dönemine geçmek

E‑posta altyapısında şifrelemeyi gerçekten ciddiye almak istiyorsanız, sadece STARTTLS’i açmak yeterli değil. DANE, MTA‑STS, TLS policy map’leri, SPF/DKIM/DMARC ve PTR gibi bileşenleri birlikte kurguladığınızda, ortaya hem teknik olarak güçlü hem de regülasyonlara uyumlu bir mimari çıkıyor. Özellikle altyapı taşıma dönemleri, bu dönüşümü yapmak için en uygun zamanlar; zaten MX, DNS ve sertifika tarafına dokunuyorsunuz.

DCHost olarak ister paylaşımlı hosting, ister VPS, dedicated veya colocation altyapısı kullanın; e‑posta tarafında zorunlu TLS, DANE ve MTA‑STS kurgusunu sizinle birlikte planlayıp uygulayabiliyoruz. Mevcut e‑posta trafiğinizi ve DNS kayıtlarınızı analiz ederek, adım adım bir geçiş planı çıkaralım; hem kesintiyi minimumda tutalım hem de e‑postalarınızın artık ya şifreli ya da hiç gönderileceği, güvenli bir dünyaya birlikte geçelim.