Yahoo uyumluluğu, başka bir sağlayıcının kopyalanmış kontrol listesiyle değil, alıcı hizmetin gerçek gereksinimleriyle başlar. Çoğu kuruluş, başlamak için yeterli yapılandırma bilgisine zaten sahiptir, ancak yararlı sonuç, her gereksinimden mesaj kanıtlarına, bir sahipe ve bir düzeltme planına kadar bir haritadır.
Evrensel ve toplu gereksinimleri ayırın
Yahoo listeleri SPF veya DKIM, a spam şikayet oranı %0,3'ün altında, ileriye yönelik geçerli ve ters DNS IP göndermek için ve tüm gönderenler için RFC 5321 ve RFC 5322 ile uyumluluk. Toplu gereksinimleri, hem SPF hem de geçerli bir DKIM ekler DMARC en azından politikası p=none DMARC geçişiyle ve ilgili pazarlama ve abone olunan trafik için kolayca abonelikten çıkma. Rahat hizalama kabul edilebilir. Yahoo gönderen gereksinimleri.
Başka bir sağlayıcının cilt numarasını içe aktarmayın. Yahoo SSS bölümü toplu bir eşik belirtmediğini ve gönderenleri kimliği doğrulanmış veya Kimden alan adlarını ve diğer mevcut bilgileri kullanarak değerlendirdiğini söylüyor. Bu nedenle bir kampanyadaki küçük hacim bir muafiyet oluşturmaz. Belirsizliği kaydedin ve yayınlanmamış bir sınırın hemen altındaki bir sayıyı bulmaya çalışmak yerine sağlam kimlik doğrulaması uygulayın.
Her gerçek rotada kimlik doğrulamayı doğrulayın
Referanslar: RFC 9989 §4.4, RFC 9989 §5.3.5.
Her yetkili gönderme servisinden son bir mesaj alın. Görünür olanını tanımlayın, Zarf göndereni ve DKIM imzalama etki alanını inceleyin, ardından kimlik doğrulama ve hizalama sonuçlarını karşılaştırın. Yayınlanmış bir DMARC kaydı tek başına mesajın iletildiğini göstermez. Benzer şekilde ilgisiz bir hizmet alanı için SPF başarısı, markanın From alanıyla uyumun kanıtı değildir.
Altyapı sahiplerinden, gönderen IP'nin ters eşlemesini ve ilgili iletme adresini doğrulamalarını isteyin. Bu gözlemleri alan adının posta alan MX yapılandırmasından ayrı tutun. IP'ler yönetilen bir hizmete aitse, kuruluşun denetlemediği DNS bölgelerini düzenlemeye çalışmak yerine hizmetin gerçek rota kanıtını edinin.
Belgelenen abonelikten çıkma davranışını uygulayın
Referanslar: RFC 8058 §3.
Yahoo mevcut gereksinimleri, çalışan bir mailto yöntemini kabul ederken, RFC 8058 POST yöntemini de şiddetle tavsiye ediyor. Ayrıca görünür bir abonelikten çıkma bağlantısı ve iki gün içinde isteklerin yerine getirilmesini gerektirirler. Tek başına vücut bağlantısı yeterli değildir. SSS, işlem mesajlarını promosyonel tek tıklama gereksiniminin dışında tutar. Yahoo SSS.
Çok sağlayıcılı bir program için RFC 8058 pratik bir ortak uygulamadır, ancak bunu Yahoo mailto'yu yasakladığını iddia etmek yerine tasarım tercihiniz olarak tanımlayın. Kontrollü bir aboneliğin fiili olarak kaldırılmasını test edin. Bastırma değişikliği olmayan başarılı bir web yanıtı, operasyonel başarı değildir.
Şikayet verilerini doğru paydaya göre yorumlayın
Yahoo spam oranının gelen kutusuna gönderilen postalara bağlı olduğunu söylüyor. Alınan şikayet raporlarının tüm gönderme denemelerine bölünmesiyle hesaplanan oran farklı bir ölçümdür. Dahili olarak faydalı olabilir ancak Yahoo kendi ücreti olarak etiketlenmemelidir. Her kontrol paneli ölçümünün kaynağını, kapsamını ve paydasını koruyun.
Örneğin, kurgusal bir dahili rapor, üç şikayet bildirimi ve 10.000 başvuru girişimi içerir. Ortaya çıkan %0,03 yalnızca iç orandır. Gelen kutusuna iletilen payda ve rapor kapsamı bilinmediğinden Yahoo uyumluluğunu sağlayamaz. Bu öğretici örnek, bir sağlayıcı ölçümü veya herhangi bir kuruluşun itibarına ilişkin bir ifade değildir.
Garanti talep etmeden açıkları kapatın
Kimlik doğrulama sorunlarını gönderen sahibine, IP/ DNS sorunlarını altyapıya atayın ve abonelikten çıkma yayılımını abonelik sistemi sahibine atayın. Düzeltilen akışı yeni bir yetkili örnekle yeniden kontrol edin. Bastırma zamanlamasına ve kalan bilinmeyen şikayet kapsamına ilişkin kanıtları saklayın.
Tarihli bir gereksinim incelemesi ve gözlemlenen sonuçlarla bitirin. Bu adımlar savunulabilir bir uyumluluk kaydı oluşturabilir ancak gelecekteki gelen kutusu yerleşimini kanıtlamaz veya canlı bir Yahoo sertifikası oluşturmaz.