BIMI ve MTA-STS: E-posta Güvenliğinde İleri DNS

BIMI ve MTA-STS: E-posta Güvenliğinde İleri DNS

E-posta hâlâ kurumsal iletişimin omurgası ama aynı zamanda saldırganların en sevdiği giriş kapılarından biri. SPF, DKIM ve DMARC artık çoğu sistem yöneticisinin bildiği temel üçlü haline geldi; sahte gönderen adreslerini engellemek, mesaj bütünlüğünü doğrulamak ve politika uygulamak için bu üç kayıt neredeyse standart oldu. Ancak e-posta güvenliğinin sınırları burada bitmiyor. MTA-STS ile posta sunucuları arasındaki bağlantının şifrelenmesini zorunlu kılabilir, BIMI ile de doğrulanmış markanızın logosunu alıcının gelen kutusunda görünür kılabilirsiniz. İkisi de temelde birer DNS kaydı ama arkalarında farklı problemler ve farklı mühendislik gereksinimleri var.

Bu yazıda SPF/DKIM/DMARC üçlüsünün üzerine ne eklendiğini, MTA-STS'in aktarım katmanındaki hangi zafiyeti kapattığını, BIMI'nin nasıl marka görünürlüğü sağladığını ve bu kayıtları kendi alan adınızda nasıl güvenli şekilde devreye alacağınızı adım adım anlatıyoruz.

Büyükweb notu: DNS yönetim panelimizden TXT kayıtlarını dakikalar içinde ekleyip güncelleyebilirsiniz; propagasyon süresi dışında ek bir bekleme veya onay süreci yok. Aşağıdaki tüm örnekler doğrudan panelde oluşturabileceğiniz kayıt formatlarıdır.

Temel Katmanı Hızlıca Hatırlayalım: SPF, DKIM, DMARC

MTA-STS ve BIMI'ye geçmeden önce üzerine inşa edildikleri temeli netleştirmek gerekiyor, çünkü her ikisi de bu üç kaydın doğru yapılandırılmış olmasını ön koşul sayıyor.

• SPF (Sender Policy Framework): Hangi sunucuların alan adınız adına e-posta gönderebileceğini TXT kaydıyla ilan eder.
• DKIM (DomainKeys Identified Mail): Gönderilen her mesajı özel anahtarla imzalar, alıcı bu imzayı yayınladığınız açık anahtarla doğrular.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): SPF ve DKIM sonuçlarını birleştirip başarısız durumlarda ne yapılacağına (izin ver, karantinaya al, reddet) karar veren politika katmanıdır.

Bu üçlüyü ilk kez kuruyorsanız veya kayıtlarınızı gözden geçirmek istiyorsanız SPF, DKIM ve DMARC e-posta kimlik doğrulama rehberimize göz atmanızı öneririz — MTA-STS ve BIMI'nin ikisi de DMARC'ın belirli bir olgunluk seviyesinde olmasını bekliyor.

Peki bu üçlü zaten varken neden daha fazlasına ihtiyaç var? Çünkü SPF/DKIM/DMARC "bu e-posta gerçekten kimden geldi" sorusuna cevap veriyor, ama "bu e-posta bana ulaşırken araya biri girdi mi" ve "bu markanın gerçekten kendisi mi konuşuyor" sorularını cevaplamıyor. İşte MTA-STS birinci soruyu, BIMI ikinci soruyu çözmek için var.

MTA-STS Nedir? Aktarım Katmanını Zorunlu Şifrelemeye Zorlamak

Klasik SMTP protokolünün en büyük zayıflıklarından biri, sunucular arası bağlantının şifreli olup olmayacağının karşılıklı "el sıkışma" ile belirlenmesi ve bu el sıkışmanın kolayca düşürülebilmesidir. STARTTLS mekanizması bağlantıyı şifrelemeyi dener ama bir saldırgan ortadaki trafiği manipüle ederek STARTTLS teklifini gizleyip iletişimi düz metne (plaintext) düşürebilir — buna STARTTLS downgrade saldırısı denir. Alıcı sunucu bunun farkına bile varmadan mesajı şifresiz kabul edebilir.

MTA-STS (SMTP MTA Strict Transport Security), bu riski ortadan kaldırmak için tasarlandı: alan adınıza gelen postanın mutlaka TLS ile, mutlaka doğrulanmış bir sertifikayla iletilmesini zorunlu kılan bir politika yayınlamanızı sağlar. Web tarafındaki HSTS'in (HTTP Strict Transport Security) e-posta karşılığı gibi düşünebilirsiniz.

MTA-STS Nasıl Çalışır?

MTA-STS iki bileşenden oluşur: bir DNS TXT kaydı ve HTTPS üzerinden servis edilen bir politika dosyası.

1. DNS TXT kaydı — gönderen sunuculara "bende MTA-STS politikası var, kontrol et" der:

_mta-sts.buyukweb-ornek.com.  TXT  "v=STSv1; id=2026080200Z;"

id alanı, politika her güncellendiğinde değiştirilmesi gereken bir sürüm etiketidir (genelde tarih-saat damgası kullanılır). Alıcı sunucular bu id'nin değiştiğini gördüğünde politikayı yeniden çeker.

2. Politika dosyası — mta-sts.<alanadi> alt alanında, HTTPS üzerinden /.well-known/mta-sts.txt yolunda barındırılır:

version: STSv1
mode: enforce
mx: mail.buyukweb-ornek.com
max_age: 604800

• mode: enforce → politika ihlali (TLS kurulamıyor veya sertifika geçersiz) durumunda mesaj reddedilir.
• mode: testing → aynı kontroller yapılır ama mesaj yine de teslim edilir, sadece raporlanır. İlk kurulumda mutlaka testing ile başlayın.
• mx → hangi posta sunucularının geçerli kabul edileceğini listeler; MX kaydınızla tutarlı olmalı.
• max_age → politikanın saniye cinsinden geçerlilik süresi (604800 saniye = 7 gün).

Bu politika dosyasının HTTPS üzerinden servis edilmesi gerektiği için, mta-sts alt alan adınıza geçerli bir SSL sertifikası tanımlı olmalı. Alt alan adları ve SSL yönetimi konusunda alt alan adı yönetimi ve subdomain stratejileri yazımız ek bir referans olabilir.

TLS-RPT: Sorun Yaşandığında Haberdar Olmak

MTA-STS tek başına "reddet" der ama size ne olduğunu söylemez. TLS-RPT (SMTP TLS Reporting) bu boşluğu doldurur: TLS el sıkışmalarında yaşanan hataları toplu rapor olarak e-posta veya HTTPS uç noktasına gönderir.

_smtp._tls.buyukweb-ornek.com.  TXT  "v=TLSRPTv1; rua=mailto:tls-raporlari@buyukweb-ornek.com"

Bu raporlar günlük olarak, hangi gönderen sunucunun hangi hatayla karşılaştığını (sertifika süresi dolmuş, MX uyuşmazlığı, STARTTLS reddedildi vb.) JSON formatında özetler. MTA-STS'i enforce moduna geçirmeden önce en az birkaç hafta bu raporları izlemeniz, yanlış yapılandırılmış bir ikincil MX sunucusu yüzünden meşru postaların reddedilmesini engeller.

Büyükweb perspektifi: MTA-STS'i doğrudan enforce ile başlatmak sık yapılan bir hatadır. Bizim önerimiz: önce testing modunda en az 2-3 hafta çalıştırıp TLS-RPT raporlarını inceleyin, sorun görünmüyorsa enforce'a geçin. Aksi halde ikincil bir MX sunucunuzda eksik TLS yapılandırması varsa, o sunucuya giden meşru postalar sessizce reddedilebilir.

BIMI Nedir? Gelen Kutusunda Marka Görünürlüğü

BIMI (Brand Indicators for Message Identification), doğrulanmış göndericilerin logolarının, destekleyen e-posta istemcilerinde (gönderen adının yanında) otomatik olarak gösterilmesini sağlayan bir standart. Kullanıcı gelen kutusunu açtığında, e-postanın yanında markanızın logosunu görmesi hem güven algısını artırıyor hem de phishing girişimlerini görsel olarak ayırt etmeyi kolaylaştırıyor — çünkü sahte gönderenler bu logoyu gösteremez.

BIMI'nin çalışması için sıkı ön koşullar var; bu, standardın kasıtlı bir tasarım kararı. Amaç, herkesin rastgele bir logo eklemesini değil, gerçekten güçlü kimlik doğrulaması yapan göndericilerin ödüllendirilmesini sağlamak.

BIMI Ön Koşulları

1. DMARC politikası p=quarantine veya p=reject olmalı, pct=100 ile (yani politika mesajların tamamına uygulanmalı). p=none ile BIMI çalışmaz.
2. SPF ve DKIM aktif ve doğru hizalanmış olmalı.
3. Logo SVG Tiny Portable/Secure (SVG P/S) profiline uygun olmalı — standart bir SVG dosyası değil, BIMI'ye özel kısıtlanmış bir alt küme (script, animasyon, harici referans içeremez).
4. Bazı e-posta sağlayıcıları (örneğin bazı büyük kurumsal servisler) VMC (Verified Mark Certificate) adında ayrı bir sertifika talep eder — bu, logonun tescilli markanızla eşleştiğini doğrulayan, belirli yetkili kuruluşlardan alınan ek bir belgedir. VMC olmadan da BIMI kaydı yayınlanabilir ama bazı istemcilerde logo görünmeyebilir.

BIMI DNS Kaydı Örneği

default._bimi.buyukweb-ornek.com.  TXT  "v=BIMI1; l=https://buyukweb-ornek.com/assets/logo.svg;"

VMC sertifikası varsa a= parametresiyle sertifika dosyasının konumu eklenir:

default._bimi.buyukweb-ornek.com.  TXT  "v=BIMI1; l=https://buyukweb-ornek.com/assets/logo.svg; a=https://buyukweb-ornek.com/assets/vmc.pem;"

Birden fazla gönderim seçicisi (selector) kullanmak isterseniz default yerine kendi seçici adınızı belirleyip DKIM'deki gibi çoklu kayıt yönetebilirsiniz, ama çoğu kurulum için tek default seçici yeterlidir.

Büyükweb notu: BIMI'nin en çok atlanan koşulu DMARC sıkılığıdır. Birçok ekip p=none ile aylarca DMARC raporlarını izler — bu doğru bir alışkanlıktır — ama BIMI'ye geçmeden önce mutlaka p=quarantine veya p=reject'e yükseltmeniz gerektiğini unutur. Önce DMARC'ı sıkılaştırın, raporları birkaç hafta temiz görün, sonra BIMI kaydını ekleyin.

Kurulum Sırası: Baştan Sona Pratik Yol Haritası

Bu iki mekanizmayı sıfırdan devreye almak istiyorsanız önerilen sıra şu şekilde:

1. SPF ve DKIM'i doğrulayın. Mevcut kayıtlarınızı test edin, eksik gönderen sunucu yoksa emin olun.
2. DMARC'ı p=none ile başlatın, rua raporlarını izleyin, meşru gönderim kaynaklarınızın hepsinin SPF/DKIM'den geçtiğinden emin olun.
3. DMARC'ı p=quarantine, ardından p=reject'e (pct=100 ile) yükseltin.
4. TLS-RPT kaydını ekleyin, raporlanan hataları birkaç hafta izleyin.
5. MTA-STS'i testing modunda yayınlayın, TLS-RPT raporlarında sorun kalmadığını doğrulayın.
6. MTA-STS'i enforce'a geçirin.
7. BIMI logosunu SVG P/S formatında hazırlayın, gerekiyorsa VMC sertifikası edinin, default._bimi kaydını yayınlayın.

Tüm bu kayıtlar sonuçta birer TXT kaydı; genel DNS kayıt tiplerine (A, CNAME, MX, TXT, NS) aşina değilseniz DNS kayıtları rehberimiz temel kavramları netleştirir. E-posta altyapınızı kendi sunucunuzda mı barındırdığınız yoksa üçüncü taraf bir servis mi kullandığınız da bu kayıtların nereye ekleneceğini etkiler; bu kararı verirken e-posta altyapısı karşılaştırma yazımıza bakabilirsiniz.

Büyükweb hosting paketlerinde alan adınıza bağlı e-posta hesapları standart olarak sunulur; DNS panelinden bu kayıtları eklemek için ayrıca bir e-posta sunucusu kurmanıza gerek yoktur. Paket detayları ve güncel kapsam için web hosting sayfamıza göz atabilirsiniz.

Sık Yapılan Hatalar

Politika dosyasını yanlış yolda yayınlamak. MTA-STS politikası tam olarak https://mta-sts.<alanadi>/.well-known/mta-sts.txt adresinde olmalı — başka bir dizin veya http:// (şifresiz) kabul edilmez.

MX kaydıyla politika dosyasındaki mx alanının uyuşmaması. Politikada listelenmeyen bir sunucudan gelen postalar enforce modunda reddedilir; ikincil veya yedek MX sunucularınızı unutmayın.

BIMI logosunu standart SVG olarak yüklemek. BIMI, tarayıcıda çalışan her SVG dosyasını kabul etmez; script etiketleri, harici font referansları veya animasyon içeren dosyalar reddedilir. Logo, BIMI Group'un yayınladığı SVG Tiny P/S şartnamesine uygun şekilde yeniden export edilmelidir.

id alanını güncellemeden politika içeriğini değiştirmek. MTA-STS önbelleklemesi id değerine dayanır; politika dosyasını değiştirip TXT kaydındaki id'yi güncellemezseniz bazı alıcı sunucular eski politikayı önbellekten kullanmaya devam edebilir.

DMARC'ı sıkılaştırmadan doğrudan BIMI eklemeyi denemek. p=none iken BIMI kaydı yayınlansa bile büyük posta sağlayıcılarının çoğu logoyu göstermez, çünkü kimlik doğrulama garantisi yeterli değildir.

Test ve Doğrulama

Kayıtları yayınladıktan sonra doğrulama için:

• MTA-STS politika dosyasının HTTPS üzerinden erişilebilir olduğunu tarayıcıdan veya curl ile kontrol edin:

curl -I https://mta-sts.buyukweb-ornek.com/.well-known/mta-sts.txt

• DNS kayıtlarının doğru yayıldığını dig veya nslookup ile teyit edin:

dig TXT _mta-sts.buyukweb-ornek.com
dig TXT default._bimi.buyukweb-ornek.com

• BIMI logonuzun destekleyen bir istemcide (örneğin bazı büyük webmail servislerinde) göründüğünü gerçek bir test e-postasıyla doğrulayın; bazı istemciler önbellekleme yaptığı için değişikliklerin görünmesi birkaç gün sürebilir.
• Yeni eklenen bir kayıt tüm dünyada hemen görünmeyebilir; DNS yayılımının neden zaman aldığını ve nasıl hızlandırılabileceğini DNS propagasyonu yazımızda detaylıca ele aldık.

Bu aşamada sabırlı olmak önemli — özellikle MTA-STS politikanızı enforce'a geçirmeden önce raporları temiz görmeden aceleyle ilerlemek, meşru e-postaların sessizce reddedilmesine yol açabilir.

Sıkça Sorulan Sorular

MTA-STS olmadan sadece DMARC yeterli değil mi?

Hayır, farklı katmanları korurlar. DMARC gönderen kimliğinin doğruluğunu kontrol eder; MTA-STS ise mesaj sunucular arasında taşınırken şifreli kalmasını ve bir saldırganın araya girip bağlantıyı düz metne düşürmesini engeller. İkisi birbirini tamamlar, birbirinin yerine geçmez.

BIMI logomu ekledim ama gelen kutusunda görünmüyor, neden?

En sık nedenler: DMARC politikanızın p=none olması (quarantine veya reject gerekir), SVG dosyasının BIMI Tiny P/S formatına uygun olmaması, kullandığınız e-posta istemcisinin BIMI'yi henüz desteklememesi veya istemci tarafındaki önbelleğin henüz güncellenmemiş olmasıdır. Ayrıca bazı sağlayıcılar VMC sertifikası olmadan logoyu hiç göstermez.

MTA-STS kaydını enforce moduna geçirmek postalarımı riske sokar mı?

Politika yanlış yapılandırılmışsa (örneğin mx listesinde eksik bir sunucu varsa) evet, meşru postalar reddedilebilir. Bu yüzden önce testing modunda çalıştırıp TLS-RPT raporlarını incelemek, ardından enforce'a geçmek güvenli yoldur.

TLS-RPT raporları kimin için gerekli, küçük işletmeler de kullanmalı mı?

Ölçek fark etmeksizin faydalıdır. Rapor almak ek bir maliyet getirmez, sadece bir TXT kaydı eklemektir; sorun oluştuğunda erken haberdar olmanızı sağlar. Özellikle üçüncü taraf bir e-posta pazarlama servisi veya harici bir SMTP relay kullanıyorsanız bu raporlar yapılandırma hatalarını hızlıca ortaya çıkarır.

BIMI için mutlaka VMC sertifikası almam mı gerekiyor?

Zorunlu değil; VMC olmadan da BIMI kaydı yayınlayabilir ve bazı istemcilerde logonuz görünebilir. Ancak bazı büyük kurumsal posta sağlayıcıları logoyu göstermek için VMC şartı koşuyor. Markanızın görünürlüğünü tüm platformlarda maksimize etmek istiyorsanız VMC edinmeniz önerilir.

Bu kayıtları eklemek için özel bir sunucu türüne mi ihtiyacım var?

Hayır, MTA-STS ve BIMI tamamen DNS ve HTTPS üzerinden çalışan kayıtlardır; herhangi bir hosting veya sunucu paketinde alan adınızın DNS yönetimine erişiminiz varsa ekleyebilirsiniz. Politika dosyasını barındırmak için ayrı bir alt alan adına küçük bir statik dosya sunmanız yeterli.

DKIM anahtarımı düzenli olarak değiştirmem BIMI veya MTA-STS'i etkiler mi?

DKIM anahtar rotasyonu doğrudan bu iki mekanizmayı bozmaz, ama DMARC hizalamasının bozulmamasına dikkat etmelisiniz — rotasyon sırasında eski ve yeni anahtar bir süre paralel yayınlanmalı ki geçiş sırasında imza doğrulaması başarısız olan mesajlar DMARC'ı kırıp dolaylı olarak BIMI'nin görünürlüğünü etkilemesin.

Büyükweb Hizmetleri

E-posta güvenliğinizi DNS seviyesinde güçlendirmek istiyorsanız aşağıdaki sayfalarımıza göz atabilirsiniz:

• Web Hosting — alan adınıza bağlı e-posta hesapları ve DNS yönetim paneli dahil hosting paketlerimiz

Kurulum sırasında takıldığınız bir adım olursa veya mevcut DNS kayıtlarınızın gözden geçirilmesini isterseniz 0850 302 60 70 numaralı satış öncesi destek numaramızdan bize ulaşabilir ya da iletişim sayfası üzerinden bizimle yazışabilirsiniz.