E-posta Teslim Edilebilirlik Denetimi: 20 Maddelik Kontrol

"Mailler spam'e düşüyor" cümlesi, bir sistem yöneticisinin duyabileceği en belirsiz şikâyettir. Sebep DNS'te bir eksik kayıt da olabilir, iki yıldır temizlenmemiş bir liste de, mesajın içindeki tek bir kısaltılmış bağlantı da. Rastgele denemelerle ilerlemek haftalar alır. E-posta teslim edilebilirlik denetimi bu yüzden sistematik yapılır: her katmanı sırayla, ölçülebilir bir kontrol listesiyle geçersiniz ve hangi maddenin başarısız olduğunu tahmin etmek yerine görürsünüz.

Bu yazıda beş katmana bölünmüş 20 maddelik bir denetim listesi bulacaksınız: DNS ve altyapı, kimlik doğrulama, liste hijyeni ve izin, içerik ve biçim, izleme ve geri bildirim. Her madde için ne kontrol edeceğinizi, nasıl kontrol edeceğinizi ve başarısızsa ne yapacağınızı yazdım. Sonunda hangi maddeye önce el atmanız gerektiğini gösteren bir öncelik tablosu var.

Denetimi Nasıl Yürütmelisiniz#

Denetime başlamadan önce bir temel ölçüm alın; aksi halde yaptığınız düzeltmelerin işe yarayıp yaramadığını asla bilemezsiniz. En az şu üç sayıyı kaydedin: son 30 günün teslim oranı, bounce oranı ve şikâyet oranı. Bu sayıları gönderim panelinizden veya sunucu log'larınızdan çıkarabilirsiniz.

# Postfix log'undan 30 günlük özet (sent / bounced / deferred)
grep -hoE "status=(sent|bounced|deferred)" /var/log/mail.log* | \
  sort | uniq -c | sort -rn

# Bounce oranını hesapla
S=$(grep -ho "status=sent" /var/log/mail.log* | wc -l)
B=$(grep -ho "status=bounced" /var/log/mail.log* | wc -l)
echo "Bounce orani: $(awk -v s=$S -v b=$B 'BEGIN{printf "%.2f%%", (b/(s+b))*100}')"

İkinci kural: aynı anda birden fazla değişiklik yapmayın. Bir maddeyi düzeltin, birkaç gün ölçün, sonra sıradakine geçin. Beş şeyi birden değiştirip iyileşme gördüğünüzde hangisinin işe yaradığını bilemezsiniz — ve daha kötüsü, bir sonraki sorunda aynı beş şeyi yine deneyeceksiniz. Denetimi bir tabloya yazın ve her maddeyi geçti/kaldı olarak işaretleyin.

Bölüm 1 — DNS ve Altyapı (Madde 1-5)#

Bu katman en sık atlanan ve en hızlı düzelen katmandır. Buradaki bir eksiklik, diğer her şeyi mükemmel yapsanız bile teslimi baştan sakatlar.

1. PTR (ters DNS) kaydı var mı ve doğru mu? Gönderim yaptığınız IP'nin bir PTR kaydı olmalı ve o isim ileri yönde aynı IP'ye çözümlenmelidir. dig +short -x 185.12.34.56 çıktısı boşsa büyük sağlayıcılar sizi bağlantı aşamasında reddeder. Kayıt IP bloğunun sahibinde ayarlanır; kendi panelinizden yapamıyorsanız sağlayıcınızdan isteyin.
2. HELO/EHLO adı PTR ile tutarlı mı? Sunucunuz kendini mail.firmaniz.com olarak tanıtıyorsa PTR kaydı da bu olmalı. Uyumsuzluk, filtrelerin puan düşürdüğü klasik bir sinyaldir. Postfix'te postconf myhostname ile kontrol edin.
3. MX kayıtları geçerli ve erişilebilir mi? Yalnızca gönderiyor olsanız bile alan adınızın çalışan bir MX kaydı olmalı; bounce mesajlarını alamayan gönderici şüpheli görünür. dig +short firmaniz.com MX ile doğrulayın; sorun görürseniz maillerim gelmiyor MX sorunu yazısındaki akışı izleyin.
4. Gönderim IP'niz kara listede mi? Başlıca DNSBL'lerde IP'nizi sorgulayın. Listelenmişse önce sebebi giderin, sonra listeden çıkarma talebi açın; sebep giderilmeden yapılan talep genellikle reddedilir.
5. TLS sertifikanız geçerli ve isme uygun mu? Süresi geçmiş veya sunucu adıyla uyuşmayan bir sertifika, TLS zorunlu tutan alıcılarda teslimatı doğrudan durdurur. Şifreleme modu ve port eşleşmesi için STARTTLS mi implicit SSL mi yazısına bakın.

# 1-2: PTR ve ileri yön tutarlılığı
dig +short -x 185.12.34.56
dig +short mail.firmaniz.com A

# 3: MX kayıtları
dig +short firmaniz.com MX

# 4: DNSBL sorgusu (IP ters çevrilerek)
dig +short 56.34.12.185.zen.spamhaus.org

# 5: Sertifika geçerlilik tarihleri
openssl s_client -connect mail.firmaniz.com:25 -starttls smtp 2>/dev/null | \
  openssl x509 -noout -dates -subject

Bölüm 2 — Kimlik Doğrulama (Madde 6-10)#

Gmail ve Yahoo'nun yürürlüğe koyduğu gönderici kuralları bu katmanı isteğe bağlı olmaktan çıkardı. Toplu gönderim yapıyorsanız üç kaydın da eksiksiz olması artık bir asgari şarttır; ayrıntılar için Gmail ve Yahoo yeni gönderici kuralları yazısına bakın.

6. SPF kaydı var, tek ve sözdizimi doğru mu? Alan adınızda yalnızca bir tane v=spf1 kaydı olmalı; iki kayıt varsa değerlendirme permerror verir ve SPF hiç çalışmaz.
7. SPF, 10 DNS sorgu limitini aşıyor mu? Arka arkaya eklenen include mekanizmaları bu sınırı sessizce aşar ve kayıt geçersiz hale gelir. Kullanmadığınız servisleri kayıttan çıkarın.
8. SPF sonu ~all mı -all mı ve bu bilinçli bir seçim mi? İkisi arasındaki fark ve hangisinin ne zaman doğru olduğu için SPF SoftFail ve HardFail farkı yazısına bakın.
9. DKIM imzası var ve doğrulanıyor mu? Yalnızca kaydın varlığı yetmez; gerçek bir mesajın Authentication-Results satırında dkim=pass görmelisiniz. dkim=fail alıyorsanız DKIM doğrulaması başarısız yazısı sebepleri sıralıyor.
10. DMARC kaydı yayında ve hizalama sağlanıyor mu? SPF ve DKIM ayrı ayrı geçse bile hizalama sağlanmazsa DMARC başarısız olur. Bu mekanizmayı DMARC alignment nedir yazısında ayrıntısıyla anlattım.

# 6-7: SPF kaydı tek mi, kaç include var
dig +short firmaniz.com TXT | grep -c "v=spf1"
dig +short firmaniz.com TXT | grep "v=spf1" | grep -o "include:" | wc -l

# 9: DKIM seçicisinin yayında olduğu
dig +short s1._domainkey.firmaniz.com TXT

# 10: DMARC politikası
dig +short _dmarc.firmaniz.com TXT

Bölüm 3 — Liste Hijyeni ve İzin (Madde 11-14)#

Teslim sorunlarının en pahalı yarısı buradadır ve DNS düzeltmeleriyle çözülmez. Filtreler sizin listenizi görmez ama listenizin davranışını görür.

11. Adresler izinli mi toplandı? Satın alınmış, kazınmış veya bir etkinlikten toplanıp izin alınmamış listeler kaçınılmaz olarak yüksek şikâyet oranı üretir. Bu maddede "kaldı" alıyorsanız diğer 19 maddeyi düzeltmenin faydası sınırlıdır.
12. Hard bounce alan adresler otomatik çıkarılıyor mu? Kalıcı hata (5.1.1) alan bir adrese ikinci kez göndermek, filtreler için gönderenin listesini yönetmediğinin en net kanıtıdır.
13. Şikâyet edenler derhal çıkarılıyor mu? Geri bildirim döngüsünden (FBL) veya webhook'tan gelen şikâyet olayı, o adrese bir daha gönderilmemesi anlamına gelir. Bu isteğe bağlı değildir.
14. Uzun süredir etkileşmeyenler ayıklanıyor mu? Bir yıldır hiç açmayan adresler teslim oranınızı aşağı çeker. Önce yeniden etkileşim kampanyası, sonra pasif listeye alma yapın.

Bu dört maddeyi ölçmek için gönderim platformunuzun raporlarına ya da webhook kayıtlarınıza bakın. Kabaca hedeflenecek eşikler şöyledir:

Bölüm 4 — İçerik ve Biçim (Madde 15-17)#

İçerik, filtrelerin karar verirken baktığı son katmandır ve tek başına nadiren spam'e düşürür — ama zaten zayıf olan bir itibarı kesin sonuca çevirir.

15. Düz metin alternatifi var mı? Yalnızca HTML gövdeli mesajlar birçok filtrede puan kaybeder. Her mesajın multipart/alternative yapısında bir düz metin sürümü bulunmalıdır ve bu sürüm HTML'in gerçek karşılığı olmalıdır, "Bu maili görüntüleyemiyorsanız tıklayın" cümlesi değil.
16. Bağlantılar kendi alan adınıza mı gidiyor? Kısaltma servisleri (bit.ly benzeri) spam kampanyalarında yoğun kullanıldığı için doğrudan risk sinyalidir. Takip bağlantılarınız da kendi alt alan adınız üzerinden geçmelidir.
17. Görsel/metin dengesi makul mü ve tüm görseller barındırılıyor mu? Tek bir büyük görselden ibaret mesajlar tipik spam desenidir. Görselleri kendi sunucunuzdan sunun ve her birine anlamlı alt metni verin.

Buna ek olarak, mesajın abonelikten çıkma bağlantısını hem gövdede hem de List-Unsubscribe başlığında sunmalısınız. Tek tıkla çıkışı destekleyen başlık çifti şudur:

List-Unsubscribe: https://firmaniz.com/abonelik/cik?t=TOKEN
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Bu iki başlık, kullanıcının "spam" tuşuna basmak yerine temiz bir çıkış yapmasını sağlar — yani doğrudan şikâyet oranınızı düşürür.

Bölüm 5 — İzleme ve Geri Bildirim (Madde 18-20)#

Bu son üç madde, denetimi tek seferlik bir iş olmaktan çıkarıp sürekli bir sisteme dönüştürür.

18. DMARC raporlarını topluyor ve okuyor musunuz? DMARC kaydınızdaki rua adresine gelen XML raporlar, alan adınız adına kimin mail gönderdiğini gösteren tek kaynaktır. Raporları okumaya DMARC raporu nasıl okunur yazısıyla başlayabilirsiniz.
19. Gönderici panellerine kayıtlı mısınız? Büyük sağlayıcıların gönderici araçları size şikâyet oranınızı ve itibar durumunuzu doğrudan gösterir; başka hiçbir yerden bu veriye ulaşamazsınız.
20. Bounce ve şikâyet olayları otomatik işleniyor mu? Webhook uç noktanız çalışıyor olmalı, olayları veritabanınıza yazmalı ve ilgili adresleri listeden çıkarmalıdır. Elle yapılan temizlik ölçeklenmez.

Bu üçünün ortak noktası, hepsinin veri toplamasıdır. Denetimi altı ayda bir tekrarlamak yerine bu üç kanalı sürekli açık tutarsanız, bir sorun büyümeden fark edilir.

Denetim Sonrası: Öncelik Sırası ve Sık Yapılan Hatalar#

Yirmi maddenin hepsinde "kaldı" alan bir kurulumda nereden başlayacağınıza karar vermek zor olabilir. Etkiye göre sıralama şöyledir:

Denetim sırasında en sık yapılan hatalara gelince. Birincisi kayıtları eklemek ile çalıştığını doğrulamayı karıştırmaktır: SPF ve DKIM kayıtlarını eklemiş olmanız yetmez, gerçek bir mesajın başlığında pass sonucunu görmelisiniz. Bunu nasıl okuyacağınızı mail başlıklarını okuma ve analiz etme yazısında anlattım.

İkinci hata, DMARC politikasını doğrudan p=reject ile yayınlamaktır. Hizalamayan meşru bir gönderim yolunuz varsa (fatura yazılımı, CRM, destek sistemi) o yoldan çıkan tüm mailler bir anda reddedilir. Daima p=none ile başlayıp raporları okuyun.

Üçüncü hata, tek bir maddeyi düzeltip anında sonuç beklemektir. İtibar kayan bir pencere üzerinden hesaplanır; bugünkü düzeltmenin etkisini görmek genellikle bir ile iki hafta alır. Bu süre boyunca hacmi artırmayın, aksine sabit tutun.

Dördüncüsü ise pazarlama ve işlemsel maili aynı akıştan göndermektir. Bültenin şikâyet oranı, aynı yoldan giden şifre sıfırlama mailinin de teslimini düşürür. İki akışı ayırmanın en temiz yolu ayrı alt alan adları ve mümkünse ayrı IP'lerdir; hangi durumda ayrılmış IP'nin mantıklı olduğunu paylaşımlı mı ayrılmış IP mi yazısında ele aldım.

Sıkça Sorulan Sorular#

Teslim edilebilirlik denetimi ne kadar sürer#

Kontrollerin kendisi birkaç saat sürer; DNS ve kimlik doğrulama maddelerini bir öğleden sonrada geçebilirsiniz. Asıl süre düzeltmelerin etkisinin görülmesinde geçer. İtibar kayan bir pencere üzerinden hesaplandığı için tipik olarak bir ile dört hafta arasında iyileşme görürsünüz. Bu süre boyunca gönderim hacmini sabit tutmak, ölçümü temiz kılar.

SPF, DKIM ve DMARC'ı kurdum ama hâlâ spam'e düşüyorum, neden#

Kimlik doğrulama teslimatın gerekli şartıdır ama yeterli şartı değildir. Üç kayıt da geçtiği hâlde spam'e düşüyorsanız sorun neredeyse kesinlikle itibar veya liste tarafındadır: yüksek bounce oranı, şikâyetler, uzun süredir etkileşmeyen adresler ya da IP'nizin kara listede olması. Denetim listesinin 3. ve 5. bölümlerine dönün.

Bounce oranım ne kadar olmalı#

Hard bounce oranını binde 5'in altında tutmayı hedefleyin; toplam bounce (soft dahil) %2'yi aşmamalıdır. %5 üzerindeki bir oran, büyük sağlayıcılarda gönderim yetkinizin kısıtlanmasına yol açar. Oran yüksekse tek çözüm listeyi temizlemektir: hard bounce alan adresleri kalıcı olarak çıkarın, uzun süredir etkileşmeyenleri pasife alın.

Kara listeden çıkmak ücretli mi#

Başlıca kara listelerin çıkarma işlemi ücretsizdir ve kendi sitelerinden talep açılır. Ücret talep eden aracılara ihtiyacınız yoktur. Kritik nokta şudur: listelenme sebebini gidermeden yapılan talep genellikle reddedilir ya da kısa süre sonra yeniden listelenirsiniz. Önce açık relay, ele geçirilmiş hesap veya kirli liste gibi kök sebebi bulup kapatın.

Denetimi ne sıklıkla tekrarlamalıyım#

Tam denetimi altı ayda bir, ayrıca her büyük değişiklikten sonra (sunucu taşıma, gönderim servisi değiştirme, yeni alt alan adı ekleme) tekrarlayın. Bunun dışında 18-20. maddelerdeki izleme kanallarını sürekli açık tutun; DMARC raporları ve webhook olayları bir sorun büyümeden sizi uyarır, böylece denetimler arasında kör kalmazsınız.

List-Unsubscribe başlığı zorunlu mu#

Toplu gönderim yapıyorsanız pratikte evet. Büyük sağlayıcılar tek tıkla abonelikten çıkışı gönderici şartları arasına aldı ve bu başlığı sunmayan gönderimleri kısıtlıyor. Bunun ötesinde kendi çıkarınıza da çalışır: kullanıcı "spam" tuşuna basmak yerine temiz bir çıkış yaptığında şikâyet oranınız düşer ve itibarınız korunur.

Kendi sunucumdan mı yoksa bir servisten mi göndermeliyim#

Bu, denetim listesinin kaç maddesini kendiniz üstlenmek istediğinizle ilgilidir. Kendi sunucunuzda 1-5. maddelerin tamamı (PTR, HELO, sertifika, kara liste izleme) sizin sorumluluğunuzdadır; bir servis bunları üstlenir ama karşılığında gönderim davranışınız üzerinde daha az kontrolünüz olur. Yüksek ve düzenli hacimde kendi sunucunuz maliyet avantajı sağlar, düşük hacimde servis çok daha az iş çıkarır.

Kapanış#

Teslim edilebilirlik, tek bir ayarla çözülen bir problem değil, beş katmanın hepsinde sürekli tutulan bir disiplindir. Aklınızda kalması gereken dört alışkanlık: denetime başlamadan önce temel ölçümü alın ve aynı anda tek değişiklik yapın; kayıtları eklemekle çalıştığını doğrulamayı karıştırmayın, gerçek bir başlıkta pass görün; bounce ve şikâyet olaylarını otomatik işleyin, çünkü elle temizlik ölçeklenmez; ve pazarlama ile işlemsel maili asla aynı akıştan göndermeyin.

Altyapı tarafını kendiniz kurmak isterseniz Postfix, Dovecot, Rspamd ve DKIM'i yapılandırılmış olarak gelen SMTP sunucu paketleri PTR kaydı dahil teslim edilir; daha genel bir altyapı için tam root erişimli VDS sunucularına bakabilirsiniz. Kampanya ve segmentasyon tarafında e-posta pazarlama çözümlerimiz liste hijyenini kolaylaştırır, sunucu tarafındaki bakımı devretmek isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.