E-posta Güvenliğinde Eksiksiz DNS Kayıtları: SPF'ten BIMI'ye

“E-posta güvenliği” deyince akla ilk SPF, DKIM, DMARC geliyor. Oysa alan adınızı sahte mailden, gelen kutunuzu şifrelenmemiş trafikten ve markanızı taklitten tam anlamıyla korumak sekiz ayrı DNS kaydını gerektiriyor: SPF, DKIM, DMARC, MTA-STS, TLS-RPT, DNSSEC, DANE (TLSA) ve BIMI. Bir KOBİ’nin hepsini aynı anda kurması şart değil — ama hangisinin ne işe yaradığını, hangisinin gerçekten gerekli olduğunu bilmeden “üç kayıt yeter” demek eksik bir savunma bırakıyor.

Kayıt	Örnek değer	Ne işe yarar
SPF (TXT)	v=spf1 include:_spf.google.com -all	Alan adınız adına hangi sunucuların mail gönderebileceğini listeler
DKIM (TXT)	secici._domainkey.alanadiniz.com	Giden maile dijital imza ekler, yolda değişmediğini kanıtlar
DMARC (TXT)	_dmarc.alanadiniz.com → v=DMARC1; p=quarantine; rua=...	SPF/DKIM başarısız olursa alıcıya ne yapacağını söyler, rapor toplar
MTA-STS (TXT+HTTPS)	_mta-sts.alanadiniz.com	Gelen mail trafiğinin şifresiz bağlantıya düşmesini engeller
TLS-RPT (TXT)	_smtp._tls.alanadiniz.com	TLS bağlantı hatalarını raporlar
DNSSEC	üst seviyede DS kaydı	DNS yanıtlarının sahte olmadığını imzayla garanti eder
DANE / TLSA	_25._tcp.mx.alanadiniz.com	SMTP sunucusunun TLS sertifikasını DNS üzerinden sabitler
BIMI (TXT)	default._bimi.alanadiniz.com	Gelen kutusunda marka logonuzu gösterir

SPF: söz dizimi basit, sınırı öyle değil

Bir SPF kaydı tek satırlık bir TXT kaydı: v=spf1 include:_spf.google.com include:sunucu.saglayici.com -all. Sondaki -all ile ~all arasındaki fark küçük görünüyor ama pratikte büyük fark yaratıyor. -all “listede olmayan sunucu mail gönderemez, reddet” der (hard fail); ~all “gönderebilir ama şüpheli işaretle” der (soft fail). Yeni kurulan bir SPF kaydında önce ~all ile başlayıp trafiği izlemek, sonra -all’a geçmek daha güvenli. Aksi halde unutulmuş bir gönderici — ERP, kargo takip maili, form bildirim servisi — birden reddedilmeye başlıyor.

SPF’in asıl tuzağı söz diziminde değil, sınırında. RFC 7208’in 4.6.4. bölümü, bir SPF kaydının çözümlenmesi sırasında toplam 10 DNS sorgusuyla sınırlı olduğunu söylüyor; include, a, mx, ptr, exists ve redirect mekanizmalarının her biri iç içe geçse bile bu sayıya dahil ediliyor (ip4/ip6 dahil değil, çünkü onlar DNS sorgusu gerektirmiyor). Bu sınırı aşan kayıt permerror döndürüyor ve alıcı sunucu SPF’i hiç değerlendirmeden geçebiliyor — yani kaydınız fiilen devre dışı kalıyor. Google Workspace + bir pazarlama aracı + bir kargo/fatura sistemi + bir form servisi eklediğinizde bu sınıra üç-dört include ile ulaşmak işten bile değil. Çözüm, “flatten” denilen yöntemle iç içe include zincirlerini gerçek IP aralıklarına indirmek ya da artık kullanılmayan eski include’ları düzenli temizlemek.

DKIM: seçici, anahtar uzunluğu, üçüncü taraf gönderenler

DKIM her giden maile bir dijital imza ekliyor; alıcı bu imzayı DNS’teki secici._domainkey.alanadiniz.com kaydından aldığı açık anahtarla doğruluyor. Seçici (selector), aynı alan adında birden fazla DKIM anahtarına izin veren etiket — bu yüzden pazarlama e-postanız, ERP’niz ve fatura sisteminiz aynı seçiciyi paylaşmamalı. Her biri kendi seçicisiyle imzalarsa, birini iptal etmeniz gerektiğinde (örneğin ayrılan bir tedarikçi) diğerlerini etkilemiyor.

Anahtar uzunluğu için RFC 8301 artık 2048 bit öneriyor; 1024 bit teknik olarak hâlâ çalışıyor ama kırılmaya açık kabul ediliyor ve Google/Yahoo’nun toplu gönderici kurallarını karşılamıyor. Saha notu: 2048 bit’lik açık anahtar, DNS TXT kaydının 255 baytlık tek string sınırını aşıyor; kayıt otomatik parçalara bölünmeli, elle tek satır girilirse doğrulama sessizce başarısız oluyor. Anahtar döndürme (rotation) için sabit bir kural yok ama yılda bir kez, eski anahtarı hemen silmeden iki-üç hafta paralel tutarak geçiş yapmak makul bir pratik.

DMARC: rapor okumadan reject’e geçmeyin

DMARC, SPF ve DKIM’in üstüne “ikisi de başarısız olursa ne yap” kuralını koyuyor: p=none sadece izler, p=quarantine spam’e düşürür, p=reject tamamen engeller. Mayıs 2026’da DMARC’ın teknik tanımı RFC 7489’dan RFC 9989/9990/9991’e (topluca “DMARCbis”) geçti; kurallar aynı kaldı, protokol artık IETF’in resmi standart yolunda ilerliyor.

pct etiketi politikanın postaların yüzde kaçına uygulanacağını belirliyor (varsayılan 100) — kademeli geçişte pct=10 ile başlayıp haftalar içinde artırmak yaygın bir yöntem. Hizalama (aspf/adkim) r (relaxed) ya da s (strict) olabiliyor: relaxed, alt alan adı ile ana alan adının eşleşmesine izin veriyor (mail.alanadiniz.com ile alanadiniz.com uyumlu sayılıyor); strict, tam eşleşme istiyor. Çoğu kurulum relaxed ile başlıyor, çünkü strict bazı meşru gönderim yollarını (üçüncü taraf pazarlama araçları gibi) kırabiliyor.

Kendi deneyimimden söyleyeyim: Xen’in kendi alan adında DMARC’ı kademeli sıkılaştırıyoruz. rua raporları birikip hangi sunucunun, hangi amaçla mail attığı netleşmeden p=reject’e geçmiyoruz. Rapor okumadan doğrudan reject’e atlayan bir kurulumda genelde unutulan bir sistem — form bildirimi, yazıcı tarama maili, eski bir entegrasyon — sessizce mail atmayı bırakıyor. Kimse fark etmiyor, ta ki bir fatura ya da teklif karşı tarafa ulaşmayana kadar.

MTA-STS ve TLS-RPT: giden değil, gelen trafiği koru

SPF/DKIM/DMARC kimin mail gönderdiğini doğruluyor; MTA-STS (RFC 8461) mailin yolda şifrelenip şifrelenmediğini garantiliyor. _mta-sts.alanadiniz.com TXT kaydı bir politika dosyasının varlığını duyuruyor, asıl politika https://mta-sts.alanadiniz.com/.well-known/mta-sts.txt adresinde HTTPS üzerinden yayınlanıyor. Üç modu var: testing (sorunları sadece raporla, teslimatı engelleme), enforce (TLS veya sertifika doğrulaması başarısızsa maili reddet), none (politikadan çık). TLS-RPT (RFC 8460) ise _smtp._tls.alanadiniz.com kaydıyla TLS bağlantı hatalarının raporlanacağı adresi belirtiyor. Doğru sıra: önce testing ile birkaç hafta rapor topla, sorun yoksa enforce’a geç. MTA-STS’i doğrudan enforce ile açmak, geçici bir sertifika hatasında gelen maillerin sessizce reddedilmesine yol açabiliyor.

DNSSEC, DANE ve BIMI: her zaman gerekli değil

DNSSEC, DNS yanıtlarının değiştirilmediğini imzayla garanti ediyor — DANE’nin ön koşulu da bu. Türkiye’de .tr alan adları için TRABİS üzerinden DNSSEC destekleniyor ama zorunlu değil; kayıt operatörünüzün DS kaydını API üzerinden yönetebiliyor olması gerekiyor, her sağlayıcı bunu sunmuyor. DANE (TLSA kaydı, _25._tcp.mx.alanadiniz.com), SMTP sunucunuzun TLS sertifikasını DNS üzerinden sabitliyor; sertifika otoritesine güvenmek yerine DNS’e güveniyorsunuz. Pratikte DANE, DNSSEC olmadan çalışmıyor ve çoğu KOBİ için gerçek risk azaltımı MTA-STS’in sağladığından fazlasını vermiyor. Kamu kurumu, finans ya da çok hedefli bir sektördeyseniz anlamlı; sıradan bir ticari alan adı için öncelik listesinin sonunda olabilir.

BIMI, gelen kutusunda alan adınızın yanına marka logonuzu koyuyor ama ön koşulu ağır: DMARC en az p=quarantine, tercihen p=reject olmalı. Tescilli markanız varsa VMC (Verified Mark Certificate) gerekiyor; 2026 fiyatları sağlayıcıya göre değişmekle birlikte yıllık yaklaşık 1.000-1.750 dolar bandında seyrediyor. Gmail ve bazı büyük sağlayıcılar logoyu VMC olmadan da gösterebiliyor ama garantisi yok. Bu maliyeti, marka bilinirliğinin gelen kutusunda fark edilir bir avantaj sağlayacağı yüksek hacimli gönderim yapan işletmeler için mantıklı buluyorum; küçük bir KOBİ için DMARC’ı reject’e taşımak zaten BIMI’den önce gelen, daha değerli bir adım.

Hiç mail göndermeyen alan adları da savunmasız kalmasın

Şirketinizin sadece marka koruması için aldığı, hiç mail göndermediği bir alan adı (parked domain) ya da pazarlama amaçlı ayrı bir alt alan adı varsa, boş bırakmak güvenlik açığı demek. “Hiç göndermiyorum” diyen bir alan adına v=spf1 -all (null SPF) ve v=DMARC1; p=reject; (null DMARC) eklemek, o alan adı üzerinden sahte mail atılmasını baştan kapatıyor.

Sık yapılan hatalar

• İki ayrı SPF TXT kaydı eklemek: SPF standardı tek kayıt bekliyor, ikinci kayıt varlığı permerror’a yol açıyor — tüm include’ları tek kayıtta birleştirin.
• DMARC kaydını yanlış alt alan adına koymak: _dmarc.alanadiniz.com yerine dmarc.alanadiniz.com yazmak (baştaki alt çizgi eksik) kaydı görünmez kılıyor.
• ERP, yazıcı, fatura sisteminin SPF dışında kalması: Muhasebe yazılımının veya çok fonksiyonlu yazıcının gönderdiği tarama/bildirim maillerini SPF’e eklemeyi unutmak, sonradan “faturalar müşteriye ulaşmıyor” şikayetiyle ortaya çıkıyor.

Sık sorulanlar

Kaç DNS kaydı olmadan “e-posta güvenliği var” diyemem? Asgari üçü — SPF, DKIM, DMARC — olmadan hiçbir doğrulama yok demektir. MTA-STS ve TLS-RPT bunun üzerine “iyi olur” katmanı; DNSSEC, DANE ve BIMI ise ölçeğe ve sektöre bağlı.

DMARC’ı doğrudan p=reject ile mi kurmalıyım? Hayır. Önce p=none ile rapor toplayın, gönderen listenizi netleştirin, sonra pct ile kademeli artırarak quarantine ve reject’e geçin.

MTA-STS kurmazsam ne kaybederim? Gelen maillerinizin bir kısmı şifrelenmemiş bir bağlantı üzerinden taşınabilir; aynı ağda ya da güvensiz bir Wi-Fi’de araya giren biri trafiği okuyabilir. Çoğu büyük sağlayıcı zaten fırsatçı TLS deniyor ama garantisi yok — MTA-STS bunu zorunlu hale getiriyor.