E-postanın neden reddedildiğini ya da spama düştüğünü anlamak için kimlik doğrulamayı, sağlayıcı yanıtlarını, liste kalitesini ve abonelikten çıkmayı inceleyin.
Teslim ile gelen kutusu yerleşimi aynı şey değildir. Alıcı sunucu bir mesajı kabul edip spam klasörüne koyabilir. Kampanya kontrol panelinde “teslim edildi” yazması, okurun e-postayı gördüğünü kanıtlamaz.
Bir sorun ortaya çıktığında metni ya da sağlayıcınızı değiştirmeden önce kanıt toplayın. Sorun kimlik doğrulamada, itibarda, hedef kitlede ya da mesajın kendisinde olabilir.
Reddedilen ya da ertelenen mesajlarda gerçek SMTP yanıtını ve gelişmiş durum kodunu (enhanced status code) inceleyin. Geçici hatalar ve kalıcı retler farklı şekilde ele alınmalıdır. Google’ın gönderici SSS sayfası ikisini de anlatıyor; kurallara uymayan her durumun artık kalıcı hata ürettiğini söylemiyor.
Mesajlar kabul edilip spam klasöründe görünüyorsa alınan e-postanın başlıklarındaki kimlik doğrulama sonuçlarını, varsa sağlayıcının itibar verilerini ve hedef kitlede ya da hacimde yakın zamanda yapılan değişiklikleri inceleyin. Birkaç test gelen kutusu sorunu teşhis etmeye yardımcı olur, ancak listenin tamamındaki yerleşimi ölçmez.
Gelişmiş durum kodu, RFC 3463 ile tanımlanan ve noktalarla ayrılmış üç sayıdan oluşur. İlk sayı sınıfı belirtir. 4 ile başlayan bir kod geçici bir hatadır ve gönderen sunucu daha sonra yeniden denemelidir. 5 ile başlayan bir kod kalıcı bir hatadır; aynı mesajı değiştirmeden yeniden denemek işe yaramaz.
İkinci sayı konuyu daraltır. X.1.X aralığındaki kodlar adreslemeyle ilgilidir; 5.1.1 genellikle posta kutusunun var olmadığı anlamına gelir. Bu adrese gönderimi engelleyin. X.7.X aralığındaki kodlar güvenlik ya da politikayla ilgilidir; kimlik doğrulama ve itibar sorunları genellikle burada görünür.
Google, Gmail’in döndürdüğü yanıtları SMTP hata kodları sayfasında listeliyor. Yalnızca kodu değil, yanıt metninin tamamını da okuyun; çünkü tek bir kod birbirinden farklı birkaç nedeni kapsayabilir.
Google Postmaster Tools, Gmail’in gönderim alan adınızı nasıl gördüğünü gösterir; Google’ın gereksinimlerinde geçen, kullanıcıların bildirdiği spam oranı da buna dâhildir. Alan adını bir DNS kaydıyla doğrularsınız. Gmail verileri ancak bir alan adı kullanıcılarına günlük olarak yeterli sayıda e-posta gönderdiğinde gösterir; bu yüzden küçük bir gönderici boş kontrol panelleriyle karşılaşabilir.
Microsoft’un SNDS olarak bilinen Smart Network Data Services hizmeti, belirli IP adreslerinden Outlook.com bireysel posta kutularına gelen e-postaları, şikâyet oranları ve spam tuzaklarına takılan e-postalar dâhil raporlar. Kontrolünüzdeki IP adreslerini kaydettiğiniz için en çok ayrılmış gönderim IP’leriyle işe yarar. Paylaşılan IP’ler kullanıyorsanız gönderim sağlayıcınıza neleri izlediğini sorun.
İki araç da tek bir kampanyanın nereye düştüğünü söylemez. Günlük eğilimleri gösterirler; bir sorun birkaç gönderim boyunca biriktiğinde ihtiyacınız olan da budur.
SPF, bir zarf alan adı adına e-posta göndermeye yetkili altyapıyı belirler. DKIM, mesajı bir alan adı kimliğiyle imzalar. DMARC, görünen From alan adıyla hizalamayı kontrol eder; bir politika ve raporlama mekanizması yayımlar. Hiçbiri gelen kutusu yerleşimini garanti etmez.
Gönderim sağlayıcınızın verdiği kayıtları kullanın ve sonucu gerçekten alınmış bir mesaj üzerinde doğrulayın. Çakışan SPF kayıtları eklemeyin ve bir DNS kaydının, her gönderim yolunun onu doğru kullandığını kanıtladığını varsaymayın. Altyapınızın uygun bir ters DNS (reverse DNS) kaydına ve güvenli aktarıma da ihtiyacı vardır.
Brew içinde alan adı doğrulama adımlarını izleyin ve istenen kayıtları yayımlayın. Özellikle bir ajan birden fazla markayı yönetiyorsa gerçek kampanyanın ya da otomasyonun kullandığı From adresini gözden geçirin.
DMARC politikası, From adresindeki alan adının _dmarc host adında yer alan bir TXT kaydıdır. p=none ile başlayın. Bu politika, alıcı sunuculardan kontrolden geçemeyen e-postalar için özel bir işlem yapmamalarını ister; alıcı sunucular yine de rua adresine toplu raporlar gönderir.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Raporlar, alan adınız adına e-posta gönderen tüm kaynakları ve her birinin hizalanmış SPF ya da DKIM kontrolünden geçip geçmediğini listeler. Unuttuğunuz araçlarla, örneğin bir faturalandırma sistemiyle ya da yardım masasıyla karşılaşmayı bekleyin. Kontrolden geçemeyen her kaynağı düzeltin ya da kaldırın.
Tüm meşru e-postalar kontrolden geçtiğinde p=quarantine politikasına geçin. Bu politika, alıcı sunuculardan kontrolden geçemeyen e-postaları şüpheli saymalarını ister; bu da genellikle spam klasörüne taşımak demektir.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"En katı politika olan p=reject, alıcı sunuculardan kontrolden geçemeyen e-postaları reddetmelerini ister. Bu politikaya ancak karantina bir süre boyunca hiçbir meşru e-posta kontrolden kalmadan çalıştıktan sonra geçin. Raporları her aşamada okumaya devam edin. Alan adınız adına gönderim yapmaya başlayan yeni bir araç ilk olarak orada görünür.
mail.example.com gibi yalnızca gönderime ayrılmış bir alt alan adı bunun istisnasıdır. Başka hiçbir şey o alan adından gönderim yapmıyorsa ve sağlayıcınız SPF ile DKIM kayıtlarını doğrulamışsa doğrudan p=reject ile başlayabilir. Brew, kendi kurduğu ayrılmış bir alt alan adı için p=reject, başka hizmetlerin de gönderim yapabileceği bir ana alan adı için ise p=none önerir.
Google’ın yönergeleri, tüm göndericiler için geçerli gereksinimleri, kişisel Gmail hesaplarına günde yaklaşık 5.000 mesaj gönderenler için geçerli daha katı kurallardan ayırır. Google spam oranının %0,1’in altında olmasını istiyor ve %0,3’e ulaşılmaması konusunda uyarıyor. Toplu gönderici gereksinimleri arasında SPF ve DKIM, DMARC, hizalama ve abone olunan ilgili mesajlarda tek tıkla abonelikten çıkma yer alıyor.
Google’ın, hacmi ne olursa olsun her gönderici için listelediği gereksinimler şunları içerir:
Toplu göndericiler ayrıca şunları yapmalıdır:
p=none politikasını kabul ediyor.Google eşiği uygularken aynı birincil alan adından gelen e-postaları birlikte sayar; eşiği bir kez aşan alan adı toplu gönderici etiketini korur. Sayımın nasıl işlediğini gönderici SSS sayfası anlatıyor.
Yahoo’nun yönergeleri de kimlik doğrulamayı, şikâyetleri ve abonelikten çıkmayı ele alıyor. Yahoo aynı sayısal toplu gönderici eşiğini yayımlamıyor; Gmail’in rakamını her sağlayıcıya uygulamak yerine Yahoo’nun SSS sayfasına başvurun.
Microsoft, bireysel posta kutularına, yani outlook.com, hotmail.com ve live.com adreslerine günde 5.000’den fazla e-posta gönderen alan adlarının SPF ve DKIM kontrollerinden geçmesi ve DMARC yayımlaması gerektiğini 2025’te duyurdu. DMARC politikası p=none olabilir, ancak From alan adı SPF ya da DKIM ile hizalanmalıdır.
Sağlayıcı yönergeleri 28 Eylül 2026’da incelendi. Yeni bir sorunu teşhis ederken bağlantısı verilen sayfaları kontrol edin.
RFC 8058 kapsamındaki tek tıkla abonelikten çıkma, başlıklara ve HTTPS POST isteğine dayanan bir mekanizmadır. Alt bilgide görünen bir bağlantı da faydalıdır ve ilgili kurallar bunu zorunlu tutar; ancak tek başına bir tercih sayfası bu protokolü uygulamış olmaz.
Tek tıkla abonelikten çıkmayı destekleyen bir mesaj iki başlık taşır:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickOkur gelen kutusunda abonelikten çıkma seçeneğine tıkladığında posta kutusu sağlayıcısı HTTPS URL’sine gövdesi List-Unsubscribe=One-Click olan bir POST isteği gönderir. mailto: adresi, tek tıkla çıkmayı desteklemeyen e-posta yazılımları için bir alternatiftir. RFC 8058, iki başlığı da kapsayan geçerli bir DKIM imzasını da zorunlu tutar. URL’yi alıcıya özel ve tahmin edilmesi zor hâle getirin. Güvenlik tarayıcıları gelen e-postalardaki bağlantıları sık sık açar; bu yüzden o URL’ye yapılan sıradan bir GET isteği kimseyi abonelikten çıkarmamalıdır.
Brew, pazarlama gönderimlerine List-Unsubscribe ve List-Unsubscribe-Post başlıklarını ekler; bu başlıklar, tek tıkla gönderilen POST isteğini kabul eden, imzalı ve alıcıya özel bir HTTPS URL’sini gösterir.
Pazarlama e-postalarından çıkan birine, kullandığınız hiçbir yoldan sonraki pazarlama gönderimlerinin ulaşmadığını doğrulayın. Kişileri içe aktarırken ya da platform değiştirirken gönderim engellerini koruyun. Zorunlu işlemsel mesajları amaç ve gönderim yapılandırması açısından ayrı tutun.
Adreslerin nereden geldiğini ve insanların kaydolurken ne beklediğini gözden geçirin. Geçersiz adresleri sağlayıcının gönderim engeli süreciyle çıkarın, şikâyetlerdeki ani artışları araştırın ve izleme verileri açmadıklarını gösteriyor diye insanlara aynı e-postayı yeniden göndermekten kaçının.
Teslimi garanti eden evrensel bir liste yaşı, görsel-metin oranı ya da yasaklı kelime yoktur. İyi tanımadığınız bir listeye gönderim hacmini aniden artırmak, “ücretsiz” kelimesini kullanmaktan çok daha ciddi bir sorundur.
Kampanyayı bir ajan gönderiyorsa da aynı kontroller geçerlidir. Doğrulanmış bilgiler, ilgili bir hedef kitle ve takip edilen bir yanıt adresi kullanın. Tespit ettiğiniz nedeni düzeltin, kontrollü bir test gönderin ve hacmi yeniden artırmadan önce sağlayıcı yanıtlarını inceleyin.
