E-posta Spam Klasörüne Düşüyor: DNS Kaynaklı Deliverability Sorunları

Bir e-posta kampanyası gönderilir, açılma oranları normalin çok altında kalır; müşteri destek ekibi "mailinizi bulamıyoruz, spam'e düşmüş" şikayetleri almaya başlar. İçerik gözden geçirilir, konu satırı değiştirilir, gönderim sıklığı azaltılır; sorun genelde çözülmez. Çünkü çoğu zaman mesele metnin kendisinde değil, mesajın arkasındaki DNS altyapısındadır. Alıcı sunucu bir e-postayı gelen kutusuna mı, spam klasörüne mi, yoksa hiç mi teslim etmeyeceğine karar verirken içerikten önce domain'in ve gönderen IP'nin DNS üzerinden doğrulanabilir olup olmadığına bakar.

Spam klasörüne düşmenin en sık dört DNS kaynaklı nedeni eksik veya hatalı SPF, kırık ya da hiç olmayan DKIM, DMARC politikasının yokluğu ve reverse DNS/PTR eksikliğidir. Her biri ayrı belirti üretir; SPF, DKIM ve DMARC'ın kendi başına nasıl kurulacağı ayrı yazılarda işlendi. Teslimat sorunuyla karşılaştığınızda bu üç mekanizmadan hangisinin arızalı olduğunu ayırt etmek, kurulumu baştan yazmaktan daha hızlıdır.

İçerik mi DNS mi? İlk Ayrım Nasıl Yapılır

Spam filtreleri iki farklı katmanda çalışır: içerik analizi (konu satırı, gövde metni, ekler, link yoğunluğu) ve gönderen kimliği doğrulaması (SPF, DKIM, DMARC, PTR, IP itibarı). Bu ikisini karıştırmak, yanlış tarafta zaman harcamaya yol açar. Pratik bir ayrım testi: aynı içeriği iki farklı gönderen adresinden (biri kurumsal domain'iniz, biri örneğin kişisel bir Gmail hesabı) gönderin. İçerik her ikisinde de spam'e düşüyorsa sorun metindedir. Yalnızca kurumsal domain'den gönderilen düşüyorsa, sorun neredeyse kesin olarak o domain'in DNS yapılandırmasında ya da gönderen sunucunun itibarındadır.

Bir başka hızlı sinyal, mesajın "spam" değil "promotions" veya "updates" gibi bir sekmeye düşmesi; bu içerik sınıflandırmasıdır ve DNS ile ilgisi yoktur. Ama mesaj doğrudan spam/junk klasörüne gidiyorsa veya hiç teslim edilmeden reddediliyorsa (bounce), kimlik doğrulama katmanına bakmak gerekir.

# Gmail'de: mesajı açıp sağ üstten "Orijinali göster" seçin
# Aranacak üç satır:
Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of ...) smtp.mailfrom=example.com;
  dkim=pass [email protected];
  dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=example.com

Bu üç satırdan herhangi biri fail, softfail, none veya permerror dönüyorsa, spam klasörüne düşmenin nedeni içerik değil DNS'tir. Bu başlık çıktısı, hangi mekanizmanın arızalı olduğunu doğrudan gösterdiği için sorun giderme sürecinin ilk adımı olmalıdır.

SPF Kaydı Eksik veya Hatalı Olduğunda Ortaya Çıkan Belirtiler

SPF ile ilgili sorunlar genellikle iki biçimde görünür: kayıt hiç yok, ya da kayıt var ama gönderen sunucuyu kapsamıyor. İkinci durum daha sinsidir çünkü bazı gönderim kanalları (örneğin dahili sunucudan giden e-posta) çalışırken, sonradan eklenen bir servis (yeni bir CRM, bir fatura sistemi) SPF kaydına dahil edilmeyi unutulmuş olabilir.

dig example.com TXT +short | grep spf1

# Gönderen sunucunun IP'sinin kayıtta yer alıp almadığını
# manuel değerlendirmek için SPF mekanizmalarını tek tek açın:
dig _spf.saglayici.com TXT +short

Kayıt mevcut ama gönderen IP kapsanmıyorsa sonuç fail veya softfail olur; ~all kullanan kayıtlarda softfail teknik olarak reddedilmez ama çoğu spam filtresi bunu güven puanını düşüren bir sinyal olarak işler. Kayıt hiç yoksa sonuç none olur; bu, sunucunun domain adına e-posta göndermeye yetkili olup olmadığını hiçbir şekilde doğrulayamadığı anlamına gelir ve modern spam filtreleri için tek başına ciddi bir olumsuz sinyaldir.

Birden fazla SPF kaydı tanımlamak da aynı belirtiyi üretir: alıcı sunucu hangi kaydı esas alacağını bilemez ve genellikle permerror döner, bu da fail ile aynı sonucu doğurur. SPF kaydı oluştururken tek bir kayıt altında tüm kaynakları birleştirmek bu hatayı baştan önler.

SPF ile ilgili daha az bilinen bir belirti, 10 DNS lookup limitinin aşılmasıdır. Kayıt görünürde doğru yazılmış olsa bile, çok sayıda include mekanizması iç içe geçtiğinde limit aşılır ve sonuç sessizce permerror'a döner. Bu durumda SPF kaydını gözle incelemek yeterli olmaz; gerçek lookup sayısını hesaplamak gerekir; bu eşik SPF 10 lookup limiti yazısında ele alınır.

DKIM İmzası Kırıldığında veya Hiç Yoksa Ne Olur?

DKIM sorunlarının en yaygın belirtisi, imzanın var olması ama doğrulanamamasıdır. Bu genellikle iki nedene dayanır: DNS'teki public key ile gönderim sunucusundaki private key eşleşmiyor (genellikle bir anahtar rotasyonu sırasında yanlış selector'ın bırakılması), ya da mesaj gönderim sırasında bir ara sunucu (mailing list, forwarder, güvenlik ağ geçidi) tarafından değiştiriliyor ve imza geçersiz kalıyor.

dig default._domainkey.example.com TXT +short

# Mesaj başlığındaki gerçek selector'ı bulun:
# DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=default; ...
#                                                      ^^^^^^^ bu değer

Mesaj başlığındaki s= etiketindeki selector adıyla DNS'te sorguladığınız selector adı eşleşmiyorsa, sorgu boş döner ve doğrulama none sonucu verir; bu, DKIM kaydının hiç var olmamasıyla aynı sonuca yol açar. Selector yönetimi yazısında ele alındığı gibi, birden fazla gönderim kanalı kullanan domain'lerde her kanalın kendi selector'ını kullanması ve eski selector'ların prematüre silinmemesi bu tür kopuklukları önler.

DKIM imzasının tamamen yokluğu ayrı bir belirti üretir: mesaj SPF üzerinden geçse bile, DKIM olmadan forwarding (yönlendirme) senaryolarında teslimat neredeyse her zaman bozulur, çünkü forwarding sırasında gönderen IP değişir ve SPF alignment kaybolur. Bu ilişki SPF, DKIM ve DMARC'ın birlikte çalışması yazısında ayrıntılı işlendi; burada önemli olan nokta, DKIM eksikliğinin özellikle yönlendirilmiş mesajlarda spam'e düşme oranını belirgin biçimde artırmasıdır.

DMARC Politikası Olmadan Domain İtibarı Nasıl Zedelenir?

DMARC kaydı olmayan bir domain, SPF ve DKIM doğru yapılandırılmış olsa bile bir zafiyet taşır: alıcı sunucu, SPF veya DKIM başarısız olan bir mesajla karşılaştığında ne yapacağına dair hiçbir yönerge alamaz ve kendi varsayılan politikasını uygular. Bu politika sağlayıcıdan sağlayıcıya değişir; bazıları temkinli davranıp spam'e atarken bazıları teslim eder, bu da tutarsız ve öngörülemez bir deliverability davranışına yol açar.

dig _dmarc.example.com TXT +short

# Kayıt yoksa çıktı boş döner; bu durumda alıcı sunucular
# kendi varsayılan politikalarına göre karar verir.

Daha ciddi bir risk, domain adına başkalarının phishing veya spam amacıyla e-posta göndermesidir. DMARC yoksa alıcı sunucunun bu sahte mesajları ayırt etme ve engelleme yetkisi de yoktur; domain'iniz adına gönderilen kötü niyetli e-postalar sizin gerçek e-postalarınızla aynı itibar havuzuna karışır ve zamanla domain'in genel gönderim itibarını düşürür. Bu düşüş, DMARC'ı sonradan doğru kursanız bile hemen düzelmez; itibar kaybı haftalar içinde birikir, düzelmesi de benzer bir süre alır.

DMARC kaydını en az p=none ile yayında tutmak, politika henüz zorlayıcı olmasa bile alıcı sunucuların domain'inizin yapılandırılmış olduğunu görmesini sağlar; bazı büyük sağlayıcılar hiç DMARC kaydı olmayan domain'leri, gözlem modunda bile olsa DMARC kaydı bulunan domain'lere göre daha şüpheli değerlendirir.

Reverse DNS (PTR) Kaydı Eksikliği ve Sunucu İtibarı

SPF, DKIM ve DMARC domain düzeyinde çalışırken, PTR kaydı gönderen sunucunun IP'sinin itibarıyla ilgilidir ve genellikle atlanan bir kontrol noktasıdır. Alıcı sunucuların çoğu, gelen bağlantının IP adresi için bir reverse DNS sorgusu yapar; bu sorgu bir hostname döndürmüyorsa ya da dönen hostname'in kendi forward DNS'i (A kaydı) o IP'ye geri işaret etmiyorsa, bu ciddi bir güvensizlik sinyali sayılır.

dig -x 203.0.113.50 +short
# Örnek çıktı: mail.example.com.

dig mail.example.com A +short
# Bu IP'nin gerçekten 203.0.113.50 olması gerekir

Bu çift yönlü doğrulamaya forward-confirmed reverse DNS (FCrDNS) denir ve birçok büyük e-posta sağlayıcısı bunu neredeyse zorunlu bir ön koşul olarak değerlendirir. Kendi mail sunucunuzu (kendi IP'niz üzerinden, üçüncü taraf bir gönderim servisi olmadan) çalıştırıyorsanız ve PTR kaydı sunucu sağlayıcınız tarafından ayarlanmamışsa, SPF ve DKIM mükemmel yapılandırılmış olsa bile mesajlarınız spam'e düşer ya da tamamen reddedilir. PTR kaydının kurulumu ve mail sunucusuna özgü gereksinimleri reverse DNS PTR kaydı yazısında ayrıntılı ele alındı.

Bulut sunucu sağlayıcılarının çoğu (paylaşımlı IP havuzları özellikle) varsayılan olarak generic bir PTR kaydı (örneğin 123-45-67-89.provider.com) atar ve bunu kendi domain'inize özel bir hostname'e çevirmek genellikle destek talebi gerektirir. Bu adım, kendi mail sunucusunu kuran birçok kişi tarafından atlanır ve teslimat sorunlarının nedeni haftalarca fark edilmez.

Mail-Tester ve Benzeri Araçlarla Teşhis Sırası

Dört mekanizmayı (SPF, DKIM, DMARC, PTR) tek tek elle sorgulamak yerine, üçüncü taraf test araçları bu kontrollerin tamamını tek bir raporda birleştirir. Bu araçlara benzersiz bir test adresine örnek bir e-posta gönderirsiniz, araç mesajı alır ve her katmanın sonucunu ayrı ayrı raporlar.

dig example.com TXT +short | grep spf1
dig default._domainkey.example.com TXT +short
dig _dmarc.example.com TXT +short
dig -x GONDEREN_IP +short

Bu dört sorgunun sonucu, spam'e düşmenin DNS kaynaklı olup olmadığını büyük ölçüde netleştirir. Hepsi doğru görünüyorsa ve mesaj hâlâ spam'e düşüyorsa, sorun muhtemelen içerik tarafında (aşırı büyük ekler, kısaltılmış link servisleri, spam tetikleyici kelimeler) ya da gönderen IP'nin daha önce bir kara listeye (blacklist) girmiş olmasındadır. IP kara liste durumu DNS ile dolaylı ilişkilidir; birçok kara liste servisi kendi DNSBL (DNS-based Blackhole List) sorgu formatını kullanır.

# IP'yi ters çevirip DNSBL zone'una ekleyerek sorgulayın
dig 50.113.0.203.zen.spamhaus.org A +short
# Bir sonuç dönerse IP o listede kayıtlıdır

Yeni Domain veya IP için Warm-up ve DNS Hazırlığı

Yepyeni bir domain'den veya yeni bir sunucu IP'sinden e-posta göndermeye başlarken, SPF/DKIM/DMARC/PTR mükemmel yapılandırılmış olsa bile ilk günlerde teslimat sorunları yaşanabilir; çünkü domain ve IP'nin henüz hiçbir gönderim geçmişi (itibarı) yoktur. Büyük sağlayıcılar itibarsız kaynaklardan gelen ani yüksek hacimli gönderimi şüpheyle karşılar.

DNS tarafında yapılacak hazırlık nettir: SPF, DKIM ve DMARC'ı (gözlem modunda, p=none ile) gönderime başlamadan en az birkaç gün önce yayına almak, PTR kaydının doğru ve forward-confirmed olduğunu göndermeden önce doğrulamak. Ardından gönderim hacmini kademeli artırmak (warm-up), DNS'in doğruluğundan bağımsız ama onunla birlikte yürütülmesi gereken bir itibar inşası sürecidir. DNS doğru olmadan warm-up yapmak zaman kaybıdır; DNS doğruyken warm-up yapmadan büyük hacimde göndermek ise itibar sıfırdan yıkılmış bir domain ile başlamak anlamına gelir.

Spam klasörüne düşme şikayetiyle karşılaşıldığında ilk refleks genellikle içeriği değiştirmek olur; oysa vakaların büyük kısmında sorun mesajın kendisinde değil, alıcı sunucunun domain'i ve gönderen sunucuyu doğrulayamamasındadır. SPF, DKIM, DMARC ve PTR'yi ayrı ayrı sorgulayıp her birinin gerçek sonucunu görmek, içerik değişikliklerinde saatler harcamadan asıl nedeni dakikalar içinde ortaya çıkarır.

Bu dört kontrolün hepsi doğru olduğunda bile deliverability garantili değildir; itibar, gönderim geçmişi ve alıcı davranışı (açma, işaretleme, silme oranları) zamanla devreye giren ayrı katmanlardır. Ama DNS katmanı doğru kurulmadan bu üst katmanların hiçbiri sağlıklı çalışamaz; bu yüzden her teşhis sürecinin başlangıç noktası her zaman aynıdır: SPF, DKIM, DMARC ve PTR kayıtlarının gerçekte ne döndürdüğünü görmek.