E-posta Teslim Edilebilirlik Denetimi: E-postalar Neden Spam'e Düşer?

İşlemsel e-postayı müşteriye gönderdiniz, SMTP günlüğü 250 OK diyor, ama müşteri hiçbir şey görmediğini söylüyor. Ya da daha kötüsü: şifre sıfırlama formu çalışmıyor ve kullanıcı sitenin bozuk olduğunu düşünüyor. Burada sorun gönderim değil; sorun e-posta teslim edilebilirliği. Sunucunuz mesajı teslim etti, ancak alıcı sunucu onu spam klasörüne attı ya da tamamen reddetti. Bu farkı kabul etmediğiniz sürece koddaki her değişiklik boşa gider.

Önce e-postanın nerede öldüğünü anlayın

Herhangi bir şey yapmadan önce, mesajın zincirin hangi aşamasında kaybolduğunu anlamalısınız. Üç durum var ve her birinin tedavisi tamamen farklıdır:

• Reddedildi (Bounce): Alıcı sunucu 5xx koduyla yanıt verdi. Bunu kendi MTA günlüğünüzde görürsünüz.
• Kabul edildi ama spam'e düştü: 250 kodu aldınız ama mesaj Junk'ta. Burada sorun gönderim değil, itibardır.
• Kabul edildi ve kayboldu: Nadirdir ama alıcının kurumsal iç filtresi olduğunda ortaya çıkar.

İkinci durum için tek güvenilir yol, Gmail ve Outlook üzerinde gerçek bir posta kutusu oluşturup ona test göndermektir. Sadece puan veren "spam testi" araçları yanıltıcıdır; onlar alıcının gerçek davranışını simüle etmezler.

DNS kayıtları: Çoğu sitenin kaybettiği yer

Üç kayıt doğru olmalı ve üçü de aynı alan adıyla hizalı olmalı. Biri yoksa diğerleri de etkisiz kalır.

SPF

Gönderen alan adı üzerinde bir TXT kaydı. En basit doğru biçimi şudur:

v=spf1 include:_spf.google.com include:spf.servername.ir -all

Önemli nokta: -all, listede olmayan her sunucunun açıkça reddedilmesi anlamına gelir. Çoğu kişi sadece "yumuşak" reddeden ~all koyar ve spam göndericileri tam da bunu kullanır. Gönderim kaynaklarının tümünü bildiğinizden eminseniz, -all koyun.

Yaygın hata: Bir alan adı üzerinde iki ayrı SPF kaydı. Standart, bu durumda sonucun permerror olduğunu söyler ve katı alıcılar tamamen reddeder. dig TXT example.com +short ile yalnızca bir v=spf1 kaydı gördüğünüzü kontrol edin.

DKIM

Mesaj başlığı üzerinde kriptografik imza. Ortak anahtarı DNS'e koyarsınız ve gönderim sunucusu özel anahtarla imzalar. DKIM yoksa, mesaj yolundaki her değişiklik (örneğin forward edilmesi) itibarını yok eder. Anahtar uzunluğunu 2048 yapın; 1024 hâlâ çalışır ama bazı alıcılar negatif puan verir.

DMARC

Alıcıya, SPF ve DKIM'de başarısız olan mesajlarla ne yapacağını söyleyen kayıt:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; pct=100

Her zaman p=none ile başlayın ve raporları birkaç hafta okuyun. Doğrudan p=reject koyarsanız ve eski bir gönderim kaynağı geride kalmışsa, aynı gün işlemsel e-postanız ölür. Raporlar tüm kaynakların kontrol altında olduğunu gösterdikten sonra quarantine'e ve ardından reject'e geçin.

Yeni alan adı ısındırma: Herkesin hafife aldığı şey

Yeni alan adı veya yeni IP'nin itibarı yoktur. İlk gün 5000 e-posta gönderirseniz, SPF ve DKIM tam olsa bile spam'e düşme olasılığı yüksektir. Alıcılar yalnızca kayıtlara değil, gönderim desenine de bakar.

Pratik bir plan: İlk gün 50 e-posta, ikinci gün 100 ve her gün yaklaşık 1,5 katına çıkararak gerçek hacme ulaşın. Bu işlem iki ila üç hafta sürer. Aceleniz varsa, iyi itibara sahip paylaşımlı IP'si olan güvenilir bir işlemsel gönderim hizmeti kullanın; maliyeti daha yüksektir ama kurulum süresini üç haftadan birkaç saate indirir.

Burada hata yapıyorlar: Teknik ekip alan adını ısındırıyor ama aynı zamanda aynı IP üzerinden toplu pazarlama e-postası gönderiyor. Sonuç, IP itibarının ilk hafta içinde yanması ve sonrasında işlemsel dahil hiçbir e-postanın teslim edilmemesidir. İşlemsel ve tanıtım gönderimini ayrı alan adı ve IP üzerinde tutun. Bu ayrım diğer tüm ayarlardan daha önemlidir.

Geri bildirim döngüsü ve şikayet raporu

Bir kullanıcı "spam olarak bildir"e bastığında, büyük alıcılar bunu FBL (Feedback Loop) aracılığıyla göndericiye bildirir. Kayıt olmadıysanız bu sinyali görmezsiniz ve yalnızca teslim oranının düştüğünü görürsünüz.

Gmail için Postmaster Tools'u, Outlook için SNDS'yi kullanın. Şikayet eşiği %0,1'in altındadır; %0,3'ün üzeri genellikle ciddi sorunla karşılaşırsınız. Şikayet oranı yükselirse ilk yapılacak iş e-posta metnini değiştirmek değil, listeyi temizlemektir.

DMARC'deki rua kaydı da toplu raporlar gönderir. Bu raporlar XML'dir ve ham halleri okunmaz; bir ayrıştırıcı araçla onları tabloya dönüştürün ve her hafta hangi IP'nin sizin alan adınız adına e-posta gönderdiğine bakın. Birçok kez, unutulmuş eski bir sunucunun hâlâ alan adı adına e-posta gönderdiğini ve tüm alan adının itibarını düşürdüğünü gördüm.

Reddedilen bir e-postanın başlığını okuma

E-posta spam'e düştüğünde, mesajın tam başlığı her şeyi söyler. Gmail'de mesaj üzerinde üç nokta menüsüne ve ardından "Show original"a basın. Şu satırları arayın:

• Authentication-Results: SPF, DKIM ve DMARC sonucunu gösterir. spf=fail görürseniz sorun DNS'tir.
• Received: Mesajın yolu. Hop sayısı anormal fazlaysa, yolda bilinmeyen bir röle vardır.
• X-Spam-Score veya X-Spam-Status: Alıcıda SpamAssassin varsa puanı ve nedenini yazar.

Sorunlu bir başlıktan gerçek örnek:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=example.com;
       dkim=fail header.d=example.com;
       dmarc=fail (p=NONE sp=NONE) header.from=example.com

Burada SPF geçti ama DKIM başarısız oldu. Yani DNS kaydı doğru ama sunucudaki özel anahtar DNS'teki ortak anahtarla eşleşmiyor. Genellikle sunucu taşındıktan veya anahtar yeniden oluşturulduktan sonra olur ve kimse kaydı güncellemeyi hatırlamaz. opendkim-testkey -d example.com -s selector -vvv ile bunu doğrudan test edebilirsiniz.

Araçlar ve periyodik kontroller

Nereye bakacağınızı biliyorsanız tam bir denetimi yarım saatte yapabilirsiniz. DNS kayıtlarını ve çözümlemeyi kontrol etmek için DNS ve ağ kontrol araçlarını kullanın ve sonucu kendi DMARC raporunuzla karşılaştırın. Gönderim sunucunuz kendi altyapınızdaysa, IP'nin herhangi bir genel kara listede olmadığından emin olun; blacklist check araçları bunu birkaç saniyede söyler.

Daha az dikkat edilen bir nokta: Siteniz DDoS saldırısına hedef olursa ve e-posta gönderim sunucusu da aynı altyapıdaysa, performans düşüşü teslimatta timeout'a ve mesajların kuyruğa girmesine neden olabilir. Böyle bir durumda DDoS koruması, güvenlik tartışmasından ayrı olarak e-posta teslim istikrarına da yardımcı olur.

Denetim sonuçlarını belgelemek ve kayıt değişikliklerinin geçmişini tutmak için basit bir defter yeterlidir, ama ekip büyükse bu işin denetim günlüğü çerçevesinde yapılması, DKIM kaydını kimin ve ne zaman değiştirdiğinin bilinmesi için daha iyidir.

Sık sorulan sorular

SPF ve DKIM doğruyken sitemin işlemsel e-postaları neden spam'e düşüyor?

Kayıtların doğru olması gerekli koşuldur, yeterli değil. Yaygın üç neden daha vardır: Düşük IP veya yeni alan adı itibarı, yüksek kullanıcı şikayet oranı ve spam desenleri içeren e-posta içeriği (kısaltılmış bağlantı, metinsiz büyük görsel, tamamı büyük harf subject). Önce Gmail'de gerçek bir e-postanın başlığını açın ve Authentication-Results'ı okuyun; üçü de geçtiyse sorun ayarlar değil itibardır.

E-posta alan adı ısındırma ne kadar sürer?

Tamamen yeni bir alan adı ve ortalama gönderim hacmi için nihai hacme ulaşmak iki ila üç hafta sürer. Gönderim hacminiz yüksekse veya aciliyetiniz varsa, paylaşımlı IP ve yerleşik itibara sahip bir gönderim hizmeti kullanmak daha hızlıdır, ancak IP itibarı üzerinde daha az kontrolünüz olur.

SPF, DKIM ve DMARC arasındaki fark tek cümlede nedir?

SPF, alan adınız adına hangi sunucuların gönderim yapmaya yetkili olduğunu söyler; DKIM, mesajın yolda değiştirilmediğini kanıtlar; DMARC ise alıcının bu ikisini geçemeyen mesajla ne yapacağını belirler. Etkili olmaları için üçünün de aynı alan adı üzerinde ayarlanması gerekir.

İşlemsel gönderim ve bülteni aynı alan adı üzerinden mi göndermeliyim?

Hayır. Bu, e-posta teslim edilebilirlik denetiminde gördüğüm en yaygın hatadır. Bir bülten kampanyası yüksek şikayet oranı alırsa, aynı alan adının itibarı zarar görür ve şifre sıfırlama e-postası da spam'e düşer. Ana alan adını işlemsel için saklayın ve bülteni ayrı IP'li bir alt alan adı üzerinden gönderin.

Sonraki adım belli: Bir test e-postasını bir Gmail posta kutusuna gönderin, tam başlığını açın ve Authentication-Results satırını okuyun. Üçü de geçtiyse DMARC raporuna ve şikayet oranına geçin; biri başarısız olduysa önce onu düzeltin. Diğer işler bu aşamadan sonra anlam kazanır.