MTA‑STS, TLS‑RPT ve BIMI Nedir? E‑Posta Güvenliği ve Marka Görünürlüğü İçin Gelişmiş DNS Ayarları

E‑posta güvenliğinde yeni katman: MTA‑STS, TLS‑RPT ve BIMI neden önemli?

Alan adınızla gönderdiğiniz e‑postaların gerçekten alıcıya güvenli şekilde ulaşıp ulaşmadığını, yol üzerinde şifrelemenin zorlanıp zorlanmadığını veya markanızın gelen kutusunda nasıl göründüğünü çoğu zaman web projesinin planlama toplantısında fazla konuşmayız. SPF, DKIM ve DMARC kayıtlarını kurar, bir kere test eder ve konu kapandı zannederiz. Oysa bugün büyük e‑posta sağlayıcıları, MTA‑STS, TLS‑RPT ve BIMI gibi gelişmiş DNS temelli mekanizmaları aktif olarak okuyup güven puanınıza ve marka görünürlüğünüze göre karar veriyor.

Biz DCHost tarafında, özellikle transactional (şifre sıfırlama, sipariş bildirimleri) ve pazarlama e‑postalarını aynı altyapıda çalıştıran müşterilerde, SPF/DKIM/DMARC’tan sonra ikinci adım olarak MTA‑STS, TLS‑RPT ve BIMI kurulumunun bariz fark yarattığını sahada görüyoruz. Bu makalede, bu üç bileşenin ne yaptığını, nasıl çalıştığını ve alan adınızda hangi DNS kayıtlarını eklemeniz gerektiğini sade ama teknik açıdan eksiksiz biçimde anlatacağız. Ayrıca farklı ölçeklerde işletmeler için pratik kurulum stratejileri ve DCHost altyapısında nelere dikkat etmeniz gerektiğini de adım adım üzerinden geçeceğiz.

Temel zemin: SPF, DKIM, DMARC ve TLS’i doğru kurmadan ilerlemeyin

MTA‑STS, TLS‑RPT ve BIMI, e‑posta güvenliğinin ikinci katmanı gibi düşünebileceğiniz, temel ayarların üzerine gelen özelliklerdir. Bu yüzden, önce şu dört taşı sağlam oturtmanız gerekir:

• SPF: Hangi IP’lerin/servislerin alan adınız adına e‑posta göndermeye yetkili olduğunu tanımlar.
• DKIM: E‑postaların içerik bütünlüğünü ve gönderici alan adını kriptografik imzalarla doğrular.
• DMARC: SPF/DKIM sonuçlarını politika haline getirir ve başarısız doğrulanan iletilere nasıl davranılacağını söyler.
• TLS: SMTP üzerinden e‑posta aktarılırken sunucular arası trafiğin şifrelenmesini sağlar.

Bu temele aşina değilseniz, önce SPF, DKIM ve DMARC doğrulamasını sıfırdan kurmayı anlattığımız rehbere göz atmanızı öneririz. Ayrıca PTR (reverse DNS), IP itibarı ve spam klasörüne düşmeme tarafını da PTR (Reverse DNS) kaydı ve e‑postalar neden spam klasörüne düşüyor makalelerimizle birlikte okursanız, bu yazıdaki ileri seviye konular çok daha anlamlı hale gelir.

MTA‑STS nedir? SMTP için zorunlu TLS politikası

MTA‑STS (Mail Transfer Agent Strict Transport Security), alan adınız için “Bana e‑posta gönderirken mutlaka geçerli bir TLS sertifikası ile şifreleme kullan ve sadece şu MX sunucularına bağlan” diyebildiğiniz bir politika mekanizmasıdır. Amaç, iki önemli riski azaltmaktır:

• TLS downgrade saldırıları: Saldırgan, iki sunucu arasındaki STARTTLS müzakeresini bozup iletişimi şifresiz hale getirmeye çalışabilir.
• MX spoofing / ortadaki adam: DNS’te MX cevabını manipüle edip e‑postaları sahte bir sunucuya akıtmaya çalışabilir.

MTA‑STS, iki parçadan oluşur:

1. DNS tarafında bir _mta-sts.example.com TXT kaydı,
2. HTTPS üzerinden yayınlanan bir politika dosyası (https://mta-sts.example.com/.well-known/mta-sts.txt).

MTA‑STS neyi çözer, SPF/DMARC’tan farkı nedir?

SPF, DKIM ve DMARC daha çok gönderici kimliğini ve mesaj bütünlüğünü doğrular. MTA‑STS ise taşıma katmanını güvene alır. Yani MTA‑STS, “Bu alan adına giden e‑postalar şu MX sunucularına gider ve bu sunucular TLS’i zorunlu tutar” mesajını yayınlar.

Bu sayede, SPF ve DKIM ile imzalanmış meşru bir e‑postanın bile yol üzerinde şifresiz gitmesi veya yanlış bir MX’e yönelmesi engellenmeye çalışılır.

MTA‑STS politika dosyasının yapısı

Politika dosyası düz metin bir dosyadır ve şu formatta olur:

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

• version: Şu an için her zaman STSv1.
• mode: none, testing veya enforce olabilir.
• mx: Kabul edilebilir MX host isimleri veya joker desenleri (örn. *.example.com).
• max_age: Saniye cinsinden, gönderen sunucunun bu politikayı ne kadar süre hatırlayacağı (örn. 604800 ≈ 7 gün).

MTA‑STS DNS kaydı nasıl görünür?

DNS tarafında genellikle şu şekilde bir TXT kaydı oluşturursunuz:

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

• v=STSv1: Protokol sürümü.
• id=…: Politikayı versiyonlamak için serbest bir alan. Politikayı değiştirdiğinizde id değerini de değiştirerek gönderici sunucuların politikayı yeniden almasını zorlarsınız.

MTA‑STS modları: none, testing, enforce

Canlı sistemde adım adım ilerlemeniz için üç mod düşünülmüştür:

• none: Politika yayınlanır ama gönderen sunucular bu politikayı uygulamak zorunda değildir. Keşif aşaması için uygundur.
• testing: Gönderen sunucular politikayı dener, başarısız olursa düşürmeden önce genelde rapor üretir. Hataları görmek için idealdir.
• enforce: En önemli mod. Politika şartları sağlanamazsa gönderici sunucular e‑postayı teslim etmemeyi tercih edebilir.

Bizim önerimiz, üretim ortamında genellikle şu sırayla ilerlemeniz:

1. mode: none ile 1‑2 hafta yayında tutun, DNS ve HTTPS erişiminin stabil olduğundan emin olun.
2. mode: testing’e geçin ve TLS‑RPT raporlarıyla hata olup olmadığını analiz edin.
3. Hataları çözdükten sonra mode: enforce ile sıkı şifrelemeyi zorunlu kılın.

DCHost altyapısında MTA‑STS politikası nerede barınmalı?

Politika dosyasının HTTPS üzerinden erişilebilir olması şart. Bunun için iki tip kurulum görürsünüz:

• Paylaşımlı hosting: Alan adınız zaten DCHost üzerindeyse, mta-sts.example.com için bir alt alan oluşturup, /.well-known/mta-sts.txt dosyasını web dizinine koyabilirsiniz.
• VPS/dedicated: Kendi Nginx/Apache yapılandırmanız varsa, basit bir sanal host ile sadece bu dosyayı servis eden hafif bir site kurabilirsiniz. SSL/TLS sertifikanızı Let’s Encrypt otomasyonu ile otomatik yenileyecek şekilde tasarlamanızı tavsiye ederiz.

TLS‑RPT nedir? TLS sorunları için geri bildirim kanalı

TLS‑RPT (SMTP TLS Reporting), diğer e‑posta sağlayıcılarının, alan adınıza e‑posta göndermeye çalışırken yaşadıkları TLS kaynaklı hataları size toplu raporlar halinde bildirmesini sağlar. Bu raporlar genellikle günlük veya birkaç saatte bir gelir ve JSON formatında özet bilgiler içerir.

MTA‑STS ile birlikte kullanıldığında, “TLS zorunlu” politikanızın sahada gerçekten düzgün çalışıp çalışmadığını görmeniz için çok değerli bir araçtır.

TLS‑RPT DNS kaydı nasıl tanımlanır?

Alan adınız için şu şekilde bir TXT kaydı oluşturursunuz:

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

• v=TLSRPTv1: Protokol sürümü.
• rua=mailto:: Raporların gönderileceği e‑posta adres(ler)i. Birden fazla adresi virgülle ayırabilirsiniz.

Bu adresi, mümkünse sadece rapor toplamak için ayrılmış ve gelen kutusu düzenli olarak izlenen bir posta kutusuna yönlendirin. Bazı büyük göndericiler günde yüzlerce rapor yollayabilir.

TLS‑RPT raporlarında hangi bilgileri görürsünüz?

Raporların içinde kabaca şu bilgiler yer alır:

• Hangi gönderen sunucunun sizin alan adınıza e‑posta göndermeye çalıştığı,
• Hangi MX hedefi ile konuşmaya çalıştığı,
• TLS versiyonu ve kullanılan şifre paketleri,
• Doğrulama sorunları (geçersiz sertifika, hostname uyuşmazlığı vb.),
• Kaç teslimat denemesinde sorun olduğu.

Bu veriler sayesinde şunları yakalayabilirsiniz:

• Yanlış yapılandırılmış veya süresi dolmuş TLS sertifikası olan MX sunucuları,
• Yanlış IP’ye çözülen DNS kayıtları,
• Belirli bir lokasyondan gelen hatalı trafik (örneğin bozuk bir kurumsal gateway).

Daha derin teknik analiz ve örnek rapor çıktıları için, blogumuzdaki postmaster araçları ve itibar yönetimi ile birlikte, MTA‑STS ve TLS‑RPT ile teslim edilebilirliği artırmayı anlattığımız yazıyı okumanızı tavsiye ederiz.

BIMI nedir? Marka logonuzu gelen kutusuna taşıyan DNS standardı

BIMI (Brand Indicators for Message Identification), alan adınızdan gönderilen ve belirli güvenlik kriterlerini sağlayan e‑postalar için, alıcı taraf posta kutularında marka logonuzun gösterilmesini sağlayan bir mekanizmadır. Teknik olarak BIMI de bir DNS TXT kaydı ile başlar; ancak sadece DNS kaydı yeterli değildir.

BIMI’nin ön koşulları: Neden DMARC’sız BIMI olmaz?

BIMI’yi, “e‑posta güvenliğini ciddiye alan markalara verilen görünürlük ödülü” gibi düşünebilirsiniz. Çoğu büyük sağlayıcı BIMI göstermek için şu şartları arar:

• DMARC etkin olmalı ve politikası p=quarantine veya p=reject seviyesinde olmalı.
• SPF ve/veya DKIM doğrulaması tutarlı şekilde başarılı olmalı.
• Alan adınız spam/kimlik avı açısından kötü itibara sahip olmamalı.
• Logo dosyanız SVG Tiny PS formatında, güvenli bir HTTPS kaynağında barınmalı.
• Bazı sağlayıcılar için ayrıca VMC (Verified Mark Certificate) gerekir.

DMARC’ı hâlâ p=none modunda çalıştırıyorsanız, BIMI ile ilerlemeden önce Gelişmiş DMARC ve BIMI rehberimizde anlattığımız gibi raporlara bakarak DMARC politikanızı sıkılaştırmanız çok kritik.

BIMI DNS kaydı nasıl yazılır?

Örnek bir BIMI kaydı şu şekilde görünür:

default._bimi.example.com. 3600 IN TXT 
  "v=BIMI1; l=https://static.example.com/brand/logo-bimi.svg; 
   a=https://static.example.com/brand/example-vmc.pem"

• v=BIMI1: Protokol sürümü.
• l=: Logo URL’si (HTTPS, SVG Tiny PS formatında).
• a=: VMC sertifika URL’si. Eğer henüz VMC yoksa bazı sağlayıcılarda a= boş bırakılabilir; ancak uzun vadede kurumsal markalar için VMC önerilir.

Logo URL’sini barındırdığınız altyapı güvenli ve hızlı olmalıdır. Logonun yavaş yüklenmesi, her sorguda sorun çıkarmaz ama marka deneyimini etkileyebilir. Bu dosyayı DCHost üzerindeki statik bir alan adı veya CDN destekli bir alt alan üzerinden sunmak iyi bir pratik olur.

BIMI’nin iş faydaları: Neden uğraşmaya değer?

Teknik açıdan bakarsak BIMI, e‑posta teslim edilebilirliğini doğrudan artıran bir mekanizma olmaktan ziyade, güven algısını ve tıklama oranlarını iyileştiren bir katmandır. Ancak şunu unutmamak gerekir:

• BIMI entegrasyonu için gereken DMARC seviyesi ve düşük spam oranı, dolaylı olarak teslim edilebilirliğinizi zaten yukarı çeker.
• Gelen kutusunda kurumsal logonuzun görünmesi, özellikle finansal işlem, e‑ticaret veya üyelik tabanlı hizmetlerde kullanıcıların “Bu gerçekten bizim marka mı?” sorusunu daha az sormasına yardımcı olur.
• Spam ve oltalama kampanyalarıyla kirlenmiş dikeylerde (örneğin kargo/loji̇sti̇k, finans, kripto) gerçek markaların kendini görsel olarak ayırt etmesi kritik hale gelir.

MTA‑STS, TLS‑RPT ve BIMI’yi birlikte düşünmek: Katmanlı güvenlik ve görünürlük

Şimdi bu üç mekanizmayı birlikte ele alalım. Alan adınız için ideal tabloyu şöyle özetleyebiliriz:

• SPF, DKIM, DMARC ve PTR düzgün yapılandırılmış, DMARC politikası en az p=quarantine.
• MTA‑STS mode=enforce ile aktif, HTTPS politikası oturmuş, DNS kayıtları stabil.
• TLS‑RPT raporları düzenli olarak toplanıyor, otomatik analiz veya en azından periyodik manuel kontrol yapılıyor.
• BIMI kaydı eklenmiş, logo URL’si ve (varsa) VMC sertifikası sağlıklı.

Böyle bir kurulumun pratikte size sağladığı avantajlar:

• Taşıma katmanı şifrelemesi garanti: E‑postalarınız, şifrelemesi kırılmış veya sahte MX sunucularına kolayca düşmez.
• Gözlemlenebilirlik: TLS‑RPT sayesinde, e‑posta trafiğinizdeki teknik sorunları kağıt üzerinde görebilirsiniz.
• Güçlü kimlik ve görünür marka: DMARC + BIMI kombinasyonu ile hem sahtecilik zorlaşır hem de gerçek markanız kullanıcının gözünde güçlenir.

Örnek senaryo 1: KOBİ kurumsal alan adı + paylaşımlı e‑posta altyapısı

Birçok müşterimizde gördüğümüz basit ama etkili strateji şöyle:

1. SPF/DKIM/DMARC: DCHost üzerindeki e‑posta hizmeti için SPF kaydını tanımlayıp, DKIM’i panelden aktif ediyoruz. DMARC’ı önce p=none ile başlatıp raporlara bakıyoruz.
2. MTA‑STS: Kurumsal web sitesinin barındığı hosting hesabında mta-sts.example.com alt alanını açıp, basit bir mta-sts.txt dosyası servis ediyoruz. DNS’te _mta-sts TXT kaydını ekliyoruz.
3. TLS‑RPT: _smtp._tls kaydını ekleyip raporları postmaster@ veya özel bir tls-report@ adresine topluyoruz.
4. DMARC sıkılaştırma: 1‑2 ay raporlardan yanlış kaynakları temizledikten sonra DMARC’ı p=quarantine ve daha sonra p=reject seviyesine çekiyoruz.
5. BIMI: Logo dosyasını statik bir alt alanda barındırıyor, BIMI TXT kaydını ekliyoruz.

Bu aşamalar genellikle DNS ve panel erişimi olan teknik bir kişiyle, birkaç toplantı ve kısa testlerle tamamlanabiliyor.

Örnek senaryo 2: SaaS ürünü + ayrı gönderim alan adı

Eğer SaaS veya yüksek hacimli transactional e‑posta gönderen bir yapınız varsa, ayrı gönderim alan adı kullanma stratejisini incelemenizi öneririz. Bu durumda:

• example.com kurumsal alan adı olarak kalır; BIMI, DMARC, MTA‑STS burada maksimum seviyede sıkılaştırılır.
• mail.example.com veya notify.example.com gibi bir alt alan sadece transactional/pazarlama için ayrılır.
• Bu alt alan için de SPF/DKIM/DMARC, MTA‑STS, TLS‑RPT ayrı ayrı tanımlanır.

Böylece ana alan adınızın itibarı ve BIMI görünürlüğü, yoğun pazarlama trafiğinin olası dalgalanmalarından daha az etkilenir.

Adım adım uygulama rehberi: DNS ve sunucu tarafında neler yapmalısınız?

1. DNS sağlayıcınızı ve otoriteyi netleştirin

Önce hangi platformun alan adınız için yetkili DNS sağladığını netleştirin. NS kayıtları DCHost’a mı, farklı bir DNS servisine mi işaret ediyor? DNS kayıt türlerine dair rehberimiz bu noktada referans olabilir.

2. MTA‑STS için alt alan ve politika dosyasını hazırlayın

1. Alt alanı oluşturun: mta-sts.example.com için bir sanal host veya hosting hesabı açın.
2. HTTPS sertifikası alın: Let’s Encrypt veya kurumsal bir SSL ile bu alt alanı güvenceye alın.
3. Politika dosyasını ekleyin: Web kök dizini altında /.well-known/mta-sts.txt dosyasını yaratın. İçine minik bir test politikası koyun (mode: none ile başlayın).
4. DNS TXT kaydı ekleyin: _mta-sts.example.com için v=STSv1; id=2025010101 gibi bir kayıt ekleyin.

3. TLS‑RPT raporlama adresini planlayın

1. Raporları okuyacağınız veya sisteme entegre edeceğiniz bir e‑posta adresi belirleyin (örn. [email protected]).
2. DNS’e şu kaydı ekleyin:

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

3. İlk raporlar gelmeye başladığında sertifika ve bağlantı hatalarını tespit edin, gerekiyorsa MX tarafında TLS yapılandırmanızı güncelleyin.

4. BIMI için logo ve DMARC politikasını hazır hale getirin

1. DMARC’ı sıkılaştırın: Raporları inceledikten sonra p=quarantine veya mümkünse p=reject seviyesine geçin.
2. Logo dosyasını oluşturun: Kurumsal logonuzu BIMI uyumlu SVG Tiny PS formatına dönüştürün.
3. Statik bir alt alan ayarlayın: Örneğin brand.example.com altında logoyu yayınlayın.
4. VMC durumu: VMC almayı düşünüyorsanız, marka tescil ve sertifika sürecini başlatın.
5. BIMI TXT kaydını ekleyin:

default._bimi.example.com. 3600 IN TXT 
  "v=BIMI1; l=https://brand.example.com/logo-bimi.svg; a="

Daha sonra VMC edindiğinizde a= alanına sertifika URL’sini ekleyebilirsiniz.

DCHost altyapısında dikkat etmeniz gereken pratik noktalar

DCHost olarak hem paylaşımlı hosting hem de VPS/dedicated ve colocation altyapılarında çalışan çok farklı e‑posta mimarileri görüyoruz. MTA‑STS, TLS‑RPT ve BIMI kurarken şu pratik öneriler işinizi kolaylaştırır:

• Tek MX, çoklu IP kullanıyorsanız: MTA‑STS politikasında mx: mail.example.com şeklinde hostname belirlemeniz yeterli; IP’leri tek tek yazmanız gerekmez.
• Failover MX’ler: Yedek MX kayıtlarınız (örn. mx2.example.com) varsa, bunları da MTA‑STS politikasına eklemeyi unutmayın.
• TTL değerleri: İlk kurulumda DNS TTL değerlerini görece düşük (300–900 sn) tutup, her şey oturduktan sonra 3600 sn ve üzerine çıkabilirsiniz.
• DNSSEC: Eğer alan adınızda DNSSEC aktifse, MTA‑STS ve BIMI gibi güvenlik kritik TXT kayıtlarının manipüle edilme riskini daha da düşürmüş olursunuz. DNSSEC kurmak isterseniz DNSSEC kurulum rehberimize göz atabilirsiniz.
• Log ve metrik takibi: Yüksek hacimli gönderim yapıyorsanız, MX tarafında TLS handshake ve bağlantı hatalarını takip eden bir monitoring sistemi (Grafana, Prometheus vb.) kurmak faydalıdır.

Sonuç: E‑posta güvenliğini ve markanızı aynı anda güçlendirmek mümkün

Bugün rekabetçi dijital ortamda e‑posta, hâlâ hem satış hem destek hem de güvenlik bildirimleri için en kritik kanal. Yalnızca SPF, DKIM ve DMARC ile yetinmek, güvenlik denetimlerinde ve kurumsal marka algısında artık yetersiz kalıyor. MTA‑STS ile TLS’i zorunlu kılmak, TLS‑RPT ile hataları görünür hale getirmek ve BIMI ile markanızı gelen kutusunda öne çıkarmak, alan adınızı bir üst lige taşıyan adımlar.

İster DCHost üzerindeki paylaşımlı hosting paketlerimizle kurumsal sitenizi barındırıyor olun, ister kendi VPS/dedicated veya colocation sunucularınızda gelişmiş bir e‑posta altyapısı çalıştırıyor olun; bu üç mekanizmayı doğru planladığınızda:

• Taşıma katmanında şifreleme açıklarınızı kapatır,
• Olası yapılandırma hatalarını TLS‑RPT raporlarıyla erken yakalar,
• DMARC ve BIMI sayesinde hem phishing saldırılarına karşı markanızı güçlendirir hem de kullanıcılarınızın gözünde güvenilirliğinizi artırırsınız.

E‑posta altyapınızı taşımayı, yeni bir gönderim alanı kurgulamayı veya bu DNS ayarlarını DCHost üzerindeki mevcut hesabınızla entegre etmeyi düşünüyorsanız, ekibimiz mimari tasarım ve geçiş planı konusunda size destek olmaya hazır. Mevcut SPF/DKIM/DMARC durumunuzu, IP itibarınızı ve olası MTA‑STS/BIMI fırsatlarını birlikte değerlendirelim; böylece hem güvenlik ekibiniz hem de pazarlama tarafı aynı anda kazanmış olsun.