Teslim edilebilirlik testi, e-postanın yalnızca gönderilip gönderilmediğini değil; alıcı tarafın onu nereye yerleştirdiğini (gelen kutusu/spam/karantina), geciktirip geciktirmediğini, hatta sessizce reddedip reddetmediğini de anlamaya çalışır. Sorunlar çoğu zaman tek bir yerde değil, üst üste binen küçük kırılmalarda saklıdır. Aşağıdaki bölümde “en sık görülen başarısızlık desenleri”ni, tipik belirtileri ve pratik düzeltme adımlarını bulacaksınız.
Teslim edilebilirlik testinde temel yaklaşım
Bir e-postanın kaderi genelde üç katmanda belirlenir: kimlik doğrulama (SPF/DKIM/DMARC), itibar (alan adı ve IP reputasyonu) ve içerik/etkileşim sinyalleri (spam şikâyeti, açılma/okunma, link davranışları, içerik tetikleyicileri). Test sırasında hatayı yakalamak için “tek metrik” yerine hata desenlerini okumak daha hızlı sonuç verir.
- Semptom: Mesaj bazı alıcılarda gelir, bazılarında gelmez.
- İpucu: Bu genelde politika farkı (DMARC enforcement), reputasyon segmentasyonu veya rate-limit kaynaklı gecikmedir.
- Hedef: Hatanın “gönderici taraf mı, alıcı taraf mı, içerik mi” olduğunu net ayırmak.
1) SPF başarısızlığı: “Yetkili gönderen” tanımı kopuk
SPF, alan adınız adına e-posta göndermeye yetkili IP/servisleri DNS üzerinden ilan eder. Testlerde en sık görülen hata, gönderim yapan servis IP’sinin SPF kaydına dahil edilmemesi veya SPF zincirinin gereksiz uzamasıyla “lookup limit”e takılmasıdır.
Tipik belirtiler
- Alıcı taraf loglarında SPF=fail / softfail / permerror
- Bazı sağlayıcılarda spam’a düşme, bazılarında direkt reddedilme
- Forward (yönlendirme) senaryolarında başarısızlıkların artması
En sık kök nedenler
- Yanlış
include:kullanımı veya eksik include - Çok fazla DNS lookup (10 limitine takılma)
- Birden fazla SPF TXT kaydı yayınlama (bir tane olmalı)
- Gönderim servisinin yeni IP havuzu kullanması ve SPF’nin güncellenmemesi
Düzeltme yaklaşımı
SPF kaydını sadeleştirin, tek TXT kaydında toplayın ve kullandığınız tüm gönderim kaynaklarını (SMTP, ESP, transactional servis) doğru şekilde ekleyin. Forward trafiği yoğun ise DMARC tarafını da buna göre tasarlayın (aşağıda).
2) DKIM başarısızlığı: İmza var ama doğrulanamıyor
DKIM, e-postaya kriptografik imza ekleyerek içeriğin yolda bozulmadığını ve alan adıyla ilişkili olduğunu kanıtlar. Testlerde DKIM fail çoğu zaman “DNS’te key yok”tan ziyade, yanlış selector, yanlış record biçimi veya içerik üzerinde oynayan ara sistemlerden çıkar.
Tipik belirtiler
- DKIM=fail / neutral
- Aynı mesaj bazı alıcıda geçer, bazı alıcıda kalır (farklı canonicalization davranışı)
- Liste servisi/CRM üzerinden giden maillerde daha sık görülür
En sık kök nedenler
- Yanlış selector veya yanlış alan adı (d=) kullanımı
- DNS record parçalanması/bozulması (uzun key kayıtlarında sık olur)
- Araya giren gateway’in header/body’yi değiştirmesi
- Birden fazla DKIM imzası ve birinin bozuk olması (bazı alıcılar bunu negatif sinyal sayar)
Düzeltme yaklaşımı
Selector’ü ve DNS DKIM kaydını doğrulayın, mümkünse 2048-bit key kullanın. Gönderim zincirinde “mesajı sonradan değiştiren” sistem var mı kontrol edin (footer ekleyen güvenlik gateway’leri gibi). DKIM, DMARC ile birlikte çalıştığında daha anlamlı hâle gelir.
3) DMARC uyumsuzluğu: Politika var, hizalama yok
DMARC, SPF veya DKIM’den en az birinin “geçmesini” ve ayrıca From alanıyla hizalanmasını ister. En yaygın başarısızlık deseni, SPF/DKIM geçse bile “alignment” tutmadığı için DMARC fail olmasıdır. Bu özellikle üçüncü taraf servislerle (CRM, support araçları, form bildirimleri) çalışırken çıkar.
Tipik belirtiler
- DMARC=fail; policy=quarantine/reject
- Kurumsal alıcılarda direkt reddedilme artışı
- Forward senaryolarında kayıp oranının yükselmesi
En sık kök nedenler
- From: sizin alan adınız, ama DKIM imzası üçüncü taraf alan adından geliyor
- Return-Path/Envelope-From hizası bozuk (SPF alignment yok)
- DMARC policy çok sert (p=reject) ama altyapı hazırlığı tamamlanmamış
Düzeltme yaklaşımı
Üçüncü taraf servislerde “custom domain DKIM” veya “domain alignment” özelliklerini açın. DMARC’ı aşamalı ilerletin: önce p=none ile rapor toplayın, sonra kontrollü biçimde quarantine ve rejecte geçin. Böylece test sonuçları “sürpriz” olmaz.
4) Alan adı / IP itibarı düşüşü: “Tek seferlik” bir hata gibi görünür
Teslim edilebilirlikte reputasyon, çoğu sorunun görünmez çarpanıdır. Bazen her şey teknik olarak doğru görünür ama mailler spam’a kayar veya gecikir. Bunun nedeni şikâyet oranı, bounce oranı, ani hacim artışı veya geçmişteki kötü trafiğin “iz” bırakması olabilir.
Tipik belirtiler
- Inbox yerine spam/Promotions’a kayma
- Gecikmeler (deferred) ve dalgalı teslimat
- Yeni domain/IP’de özellikle düşük inbox oranı
En sık kök nedenler
- Isınma yapılmadan yüksek hacimle gönderim (warm-up eksik)
- Eski listeler, doğrulanmamış adresler, yüksek hard bounce
- Opt-in kalitesizliği ve spam şikâyetleri
- Paylaşımlı IP havuzunda “komşu” trafiği
Düzeltme yaklaşımı
Hacmi kademeli artırın, önce en yüksek etkileşimli segmentlere gönderin, bounce/complaint oranını kontrol altında tutun. Liste hijyeni (temizlik) reputasyonun sigortasıdır. Paylaşımlı IP’de sorun yaşıyorsanız dedicated IP veya daha iyi reputasyon havuzuna geçiş değerlendirilir.
5) Blok liste (blocklist) deseni: “Bazı yerlere hiç gitmiyor”
Birçok alıcı sistemi, bilinen blok listeleri veya kendi iç listelerini sinyal olarak kullanır. Eğer IP veya domain blok listede görünüyorsa, teslimat ya tamamen kesilir ya da spam’a gömülür. Bu durum genelde “bir anda” olmuş gibi görünür ama çoğunlukla bir süre birikmiş sinyallerin sonucudur.
Tipik belirtiler
- 5xx red cevapları, “blocked” ibareleri
- Belirli sağlayıcılarda sıfıra yakın teslimat
- Test maili bile düşmüyor; rate-limit değil, net engel
Düzeltme yaklaşımı
Önce hangi katmanda bloklandığınızı saptayın: IP mi, domain mi, içerik mi? Sonra listeden çıkma (delist) süreçlerini yönetin. Ancak delist tek başına yetmez; aynı davranış devam ederse tekrar girersiniz. Kök neden: liste hijyeni, şikâyet oranı, kötü içerik/URL’ler olabilir.
6) İçerik tetikleyicileri: Teknik her şey doğru, ama spam’a kayıyor
Modern filtreler yalnızca “kelime avcılığı” yapmaz; link reputasyonu, HTML yapısı, görsel-ağırlık oranı, takip pikselleri, şüpheli yönlendirmeler, hatta e-postanın “şablon benzerliği” gibi sinyalleri birlikte değerlendirir. Bu yüzden teslim edilebilirlik testlerinde içerik kaynaklı hatalar çok yaygındır.
Tipik belirtiler
- Inbox oranı düşer ama 5xx red yoktur
- Aynı altyapıyla farklı şablon gönderince düzelir
- Bazı kurumsal filtreler karantinaya alır
En sık kök nedenler
- Kısa metin + çok link + agresif CTA kombinasyonu
- Güvensiz/şüpheli domainlere link verme (kısaltıcılar dahil)
- Bozuk HTML: eksik kapanan tag’ler, aşırı inline stil, gizli metin
- Görsel ağırlıklı “poster” mail (metin çok az)
- Takip parametreleriyle şüpheli URL zincirleri
Düzeltme yaklaşımı
Şablonu sadeleştirin, link sayısını makul tutun, metin-görsel dengesini kurun. Şüpheli URL kısaltıcıları kullanmayın. HTML’i doğrulayın, “tek mail her şeye” yaklaşımı yerine farklı içerikleri farklı segmentlerde test edin.
7) DNS ve altyapı hataları: Küçük yanlış, büyük kayıp
Bazen sorun reputasyon ya da içerik değildir; tamamen altyapı kaynaklıdır. Yanlış PTR/rDNS, eksik HELO/EHLO, hatalı TLS konfigürasyonu, yanlış MX yönlendirmesi… Bu tür hatalar test ortamında “arada bir” görünür; üretimde hacim artınca patlar.
Tipik belirtiler
- Geçici 4xx hataları, ardından tekrar denemeler
- Belirli kurumsal alıcılarda tutarsız teslimat
- SMTP el sıkışma sorunları (TLS/HELO)
Düzeltme yaklaşımı
DNS kayıtlarını (A, MX, SPF, DKIM, DMARC) tutarlı tutun, rDNS/PTR ile gönderim IP’sini alan adınıza bağlayın. TLS yapılandırmasını güncel ve uyumlu tutun. Özellikle kendi SMTP altyapınızı yönetiyorsanız bu katman kritik hâle gelir.
8) Throttling ve rate-limit: “Mail gidiyor ama geç gidiyor”
Büyük sağlayıcılar (ve birçok kurumsal gateway), belirli bir hızın üzerindeki gönderimleri geciktirebilir (defer) veya kademeli kabul edebilir. Teslim edilebilirlik testinde bu, “bazı adreslere geç ulaşıyor” şeklinde görünür. Bu durum çoğu zaman reputasyon veya hacim değişimiyle tetiklenir.
Tipik belirtiler
- 4xx deferred cevapları, “try again later” benzeri mesajlar
- İlk birkaç mail geçer, sonra gecikme başlar
- Gönderim hacmi yükseldikçe inbox oranı dalgalanır
Düzeltme yaklaşımı
Gönderim hızını segmentlere bölün, sağlayıcı bazlı throttling politikalarına uyum sağlayın. Warm-up stratejisi uygulayın. Çok agresif tekrar denemeler (retry) de reputasyonu olumsuz etkileyebileceği için denge kurun.
9) Bounce desenleri: Hard bounce, soft bounce ve “sessiz kayıp”
Bir e-posta testinde yalnızca “bounce var mı” değil, bounce türü önemlidir. Hard bounce genelde adresin yokluğunu gösterir; liste hijyenine doğrudan zarar verir. Soft bounce geçici nedenler (quota dolu, geçici blok, rate-limit) olabilir. Bir de “sessiz kayıp” vardır: e-posta kabul edilir gibi görünür ama kullanıcı hiç görmez (filtre/karantina/sekmeleme).
Tipik belirtiler
- Hard bounce oranı yükselir, reputasyon düşer
- Soft bounce dalgalıdır; belirli saatlerde artar
- SMTP kabul var ama kullanıcı “gelmedi” der
Düzeltme yaklaşımı
Hard bounce adresleri listeden hızla çıkarın. Soft bounce’larda neden dağılımını analiz edin (quota mı, rate-limit mi, policy mi). Kabul var ama görünürlük yoksa içerik ve DMARC/reputasyon katmanına geri dönün.
10) Test metodolojisi hataları: Sonuçlar doğru ama yorum yanlış
Teslim edilebilirlik testleri bazen “yanlış kurgulanmış test” yüzünden yanıltır. Çok küçük örneklem, yalnızca tek sağlayıcıya bakmak, aynı şablonu aşırı tekrar etmek veya seed list kalitesinin düşük olması gerçek dağılımı maskeleyebilir.
Tipik belirtiler
- Bir testte mükemmel, diğerinde felaket sonuç
- Gerçek kullanıcılar spam derken seed list inbox gösterir
- Segment bazında farklı davranışlar yakalanamaz
Düzeltme yaklaşımı
Testi çoklu sağlayıcıyla yapın, gerçek kullanıcı segmentlerini temsil eden örneklem kullanın. İçerik varyasyonları deneyin. Sadece “teslim” değil “yerleşim” (inbox/spam) ve gecikme metriklerini birlikte okuyun.
Hızlı teşhis akışı: Nereden başlayayım?
- Önce kimlik doğrulama: SPF, DKIM, DMARC geçiyor mu ve hizalı mı?
- Sonra SMTP geri dönüşleri: 4xx mi 5xx mi? Mesaj metni ne söylüyor?
- Reputasyon sinyalleri: Bounce/şikâyet artışı, hacim sıçraması var mı?
- İçerik analizi: Link reputasyonu, HTML yapısı, şablon tetikleyicileri.
- Sağlayıcı bazlı farklılık: Sorun tek bir yerde mi yoksa genelde mi?
Bu akış, “rastgele deneme” yerine sorunu daraltır. Çoğu ekip, içerik değiştirerek başlar; oysa kimlik doğrulama hizası bozuksa içerik ne kadar iyi olursa olsun sonuç sınırlı kalır.
Sonuç: Başarısızlık desenini yakala, çözüm hızlanır
Teslim edilebilirlik, tek bir ayar veya tek bir “spam kelimesi” meselesi değildir. SPF/DKIM/DMARC hizası, alan adı/IP reputasyonu, liste kalitesi, içerik sinyalleri ve alıcı politikaları birlikte çalışır. Bu yüzden en hızlı yol, problemi bir “desen” olarak okumaktır: reddedilme mi var, gecikme mi var, spam yerleşimi mi var, yoksa kurumsal karantina mı?
Deseni doğru yakaladığınızda, düzeltme adımları da kendiliğinden netleşir: DNS ve imzalar, reputasyon ısınması, liste hijyeni, içerik sadeleştirme ve hız kontrolü… Hepsi bir araya geldiğinde test sonuçları sadece iyileşmez; uzun vadede daha stabil hâle gelir.