Gmail, Yahoo ve Outlook gönderen gereksinimleri, sade bir dille

Zaman çizelgesi

Google ve Yahoo yeni gönderen gereksinimlerini Şubat 2024'te uygulamaya başladı. Microsoft, Outlook.com, Hotmail.com ve Live.com adresleri için eşdeğer gereksinimleri duyurdu ve bunlar Mayıs 2025'te yürürlüğe girdi. Her birinde uygulama aşamalı olarak devreye alındı: önce uyarılar ve spam klasörüne yerleştirme, sonra geçici ve kalıcı reddetmeler.

Kim toplu gönderen sayılır

Google toplu göndereni, kişisel Gmail hesaplarına günde yaklaşık beş bin ya da daha fazla ileti gönderen domain olarak tanımlar. Microsoft da bireysel domainleri için aynı beş bin eşiğini kullanır. İletiler görünen From adresindeki domaine göre sayılır, dolayısıyla aynı domain adına gönderen birden fazla sistemin iletileri toplanır.

Daha küçük gönderenler kimlik doğrulamadan muaf değildir. Google'ın yönergeleri her gönderenden SPF ya da DKIM, gönderim IP'leri için geçerli ileri ve ters DNS, iletim için de TLS ister.

Toplu gönderenlerde neler bulunmalı

Ortak çekirdek üç sağlayıcıda da aynıdır.

1. Gönderen domain için hem SPF hem DKIM kurulmuş olmalı.
2. Domain için bir DMARC kaydı yayınlanmış olmalı. p=none politikası kabul edilir, quarantine ya da reject olması gerekmez.
3. Hizalama: görünen From adresindeki domain, SPF domainiyle ya da DKIM imzalama domainiyle eşleşmeli.
4. Pazarlama ve abonelik e-postalarında çalışan bir tek tıkla abonelikten çıkma bulunmalı ve istek iki gün içinde yerine getirilmeli (Google ve Yahoo).
5. Spam şikâyet oranı düşük olmalı. Google, gönderenlerden Postmaster Tools'ta bildirilen oranın yüzde 0,3'ün altında kalmasını ister.

p=none size ne kazandırır, ne kazandırmaz

p=none yayınlamak DMARC gereksinimini karşılar. Birçok domainin orada durmasının nedeni budur. Ancak domaini korumaz: alıcı sunuculardan, doğrulamadan geçemeyen e-postayı her zamanki gibi teslim etmeleri istenir.

p=none politikasının değeri raporlardadır. Bir rua adresiyle alıcı sunucular, domaininiz adına e-posta gönderen her kaynağı ve doğrulamadan geçip geçmediğini listeleyen toplu raporlar gönderir. Meşru e-postayı kaybetmeden quarantine ya da reject politikasına geçmeyi mümkün kılan şey bu raporlardır.

Bir domain nasıl denetlenir

Niyet edilen yapılandırmayı değil, yayınlanan kayıtları okuyun. Tam olarak bir SPF kaydı olduğunu ve on DNS sorgusu içinde kaldığını, gönderenlerinizin kullandığı seçicilerin geçerli DKIM anahtarları yayınladığını ve rapor adresi içeren tek bir DMARC kaydı bulunduğunu doğrulayın.

Ardından hizalamayı gerçek e-postayla doğrulayın: her sağlayıcıdaki bir posta kutusuna ileti gönderin ve Authentication-Results başlığını okuyun. Kayıtlar doğru olduğu halde hizalama yine de başarısız olabilir, çünkü üçüncü taraf bir servis kendi domainiyle imzalıyor olabilir.

Ajanslar ve MSP'ler için anlamı

Müşteriler adına domain yönetiyorsanız, yanlış yapılandırılmış tek bir müşteri domaini bir teslimat olayına yol açar ve müşteri bunu e-postasının bozulması olarak yaşar. Her domaini bir kez denetlemek yetmez, çünkü müşteri bir araç eklediğinde ya da bir sağlayıcı include girdilerini değiştirdiğinde kayıtlar değişir. Bunu bir olaydan rutin bir düzeltmeye dönüştüren şey, değişiklik uyarılarıyla sürekli izlemedir.

Asgari kayıt kümesi

Tek bir sağlayıcı üzerinden gönderen bir domain için, gereksinimlerin kimlik doğrulama kısmını üç kayıt karşılar. Burada, bir e-posta sağlayıcısı kullanan ve kendi domainiyle imzalayan bir domain için gösterilmiştir.

example.com.                TXT  "v=spf1 include:_spf.google.com ~all"
s1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."
_dmarc.example.com.         TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Tek tıkla abonelikten çıkma, somut olarak

Abonelikten çıkma gereksinimi tekniktir, alt bilgideki bir bağlantıdan ibaret değildir. Pazarlama ve abonelik iletileri RFC 8058'de tanımlanan iki başlığı taşımalıdır. İlki, POST isteği kabul eden bir HTTPS adresi verir. İkincisi tek bir isteğin yeterli olduğunu bildirir. E-posta sağlayıcıları bunları kendi abonelikten çıkma düğmelerini göstermek için kullanır. Alıcı, oturum açmak ya da başka bir sayfada onay vermek zorunda kalmadan listeden çıkarılmalıdır.

İleti gövdesinde görünür bir abonelikten çıkma bağlantısı yine de gereklidir. Makbuz ve parola sıfırlama gibi işlemsel iletiler bu kuralın kapsamında değildir. Çoğu gönderim platformu başlıkları sizin yerinize ekler. Kendi uygulamanızın ürettiği e-postalarda ise genellikle bir geliştiricinin bunları eklemesi gerekir.

List-Unsubscribe: <https://example.com/unsubscribe?id=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Ters DNS ve TLS

İki gereksinim domain için değil, gönderen sunucu için geçerlidir. Her gönderim IP adresinin bir PTR kaydı olmalı ve o kayıttaki ana makine adı yeniden aynı adrese çözümlenmelidir. Buna ileri doğrulamalı ters DNS (forward-confirmed reverse DNS) denir. E-posta ayrıca bir TLS bağlantısı üzerinden iletilmelidir.

Bir e-posta sağlayıcısı ya da e-posta servisi üzerinden gönderiyorsanız ikisini de onlar yönetir ve sizin yapılandırmanız gereken bir şey yoktur. Kendi posta sunucunuzu işletiyorsanız PTR kaydı kendi DNS bölgenizde değil, IP adresinin sahibi tarafından ayarlanır. Bu normalde barındırma şirketidir.

dig -x 203.0.113.10 +short      ; mail.example.com.
dig mail.example.com A +short    ; 203.0.113.10

Şikâyet oranı

Şikâyet oranı, teslim edilen iletiler içinde alıcıların spam olarak işaretlediklerinin payıdır. Google, gönderenlerden bu oranı yüzde 0,1'in altında tutmalarını ve hiçbir zaman yüzde 0,3'e ulaşmasına izin vermemelerini ister. Oranı e-posta sağlayıcısı hesaplar ve yalnızca kendi araçlarında gösterir. Bu araçlara domaininizi orada doğruladıktan sonra erişebilirsiniz.

Bu, DNS ile düzeltilebilecek bir şey değildir. İnsanlar yalnızca istedikleri e-postayı aldığında, abonelikten çıkmak kolay olduğunda ve hızla geçerlilik kazandığında, hiç etkileşime girmeyen adresler listeden çıkarıldığında oran düşer. Yüksek oranın olağan nedeni satın alınmış ya da çok eski bir listedir.

Bir reddetme nasıl görünür

Bir ileti bu nedenlerden biriyle ertelendiğinde ya da geri çevrildiğinde, alıcı sunucu bunu SMTP yanıtında söyler ve metin geri dönen iletide ya da gönderim platformunuzun günlüklerinde görünür. Yanıt, kimlik doğrulama, hizalama ya da ters DNS gibi eksik olan öğeyi adıyla belirtir ve genellikle sağlayıcının kılavuzuna bağlantı verir.

Tahmin yürütmek yerine yanıtı okuyun. 4 ile başlayan bir koda sahip geçici yanıt, iletinin yeniden deneneceği anlamına gelir ve bir uyarıdır. 5 ile başlayan kalıcı yanıt, iletinin reddedildiği anlamına gelir. Ardından gelen genişletilmiş durum kodu çoğu zaman 5.7 ile başlar. Bu, politika ve güvenlik kaynaklı reddetmeler için kullanılan kod ailesidir.

Her gönderen domain için uygulanacak kontrol listesi

Gereksinimler, her domain ve o domain adına gönderen her sistem için denetlenebilecek kısa bir listeye dönüşür.

1. Tam olarak bir SPF kaydı, geçerli ve on DNS sorgusu içinde.
2. Her gönderen sistemde DKIM imzalama etkin, anahtar en az 1024 bit ve tercihen 2048 bit.
3. En az p=none ve bir rua adresi içeren bir DMARC kaydı.
4. Her gönderen için From domaini, SPF domainiyle ya da DKIM imzalama domainiyle hizalı.
5. Pazarlama ve abonelik e-postalarında tek tıkla abonelikten çıkma başlıkları var ve istekler iki gün içinde yerine getiriliyor.
6. Gönderim IP adresleri için geçerli ileri ve ters DNS, iletim için TLS.
7. Şikâyet oranı e-posta sağlayıcılarının kendi araçlarında denetlenmiş.
8. From adresi kendi domaininizde, asla ücretsiz bir e-posta sağlayıcısının domaininde değil.

Ücretsiz bir posta kutusu adresiyle göndermeyin

Kendi platformunuz üzerinden, From adresi bireysel bir e-posta sağlayıcısının domaininde olan toplu e-posta göndermek uyumlu hale getirilemez. Bu sağlayıcılar kendi domainleri için quarantine ya da reject DMARC politikaları yayınlar. Denetiminizde olmayan bir domain adına imzalayamaz ve onunla hizalanamazsınız. Bu yüzden iletiler DMARC'tan geçemez, filtrelenir ya da reddedilir. Sahibi olduğunuz bir domaindeki adresi kullanın.

Daha küçük gönderenler

Beş bin eşiği, gereksinimlerin tamamını kimin karşılaması gerektiğini belirler, ama altında kalanlar için güvenli bir liman değildir. Bütün gönderenlerden SPF ya da DKIM ile kimlik doğrulaması beklenir ve kimliği doğrulanmamış e-posta, hacim ne olursa olsun giderek daha sık ertelenir ya da filtrelenir. Sayım ayrıca domain başınadır ve sistemler arasında toplanır. Bu yüzden bülten platformu, mağazası ve çalışanları aynı domain adına gönderen küçük bir işletme, yoğun bir günde eşiği aşabilir. Toplu gönderen gereksinimlerini karşılamanın maliyeti düşüktür ve bu soruyu ortadan kaldırır.

Uyumlu kalmak

Uyumluluk zamanla bozulan bir durumdur. Yeni bir araç bağlanır ve hizalı olmayan e-posta gönderir. Bir sağlayıcı bir include girdisinin arkasındaki kayıtları değiştirir ve SPF sınırı aşar. Sağlayıcıda bir DKIM anahtarı yenilenir ve DNS kaydı güncellenmez. Bunların her biri, kimse DMARC kaydını düzenlemeden bir gereksinimi bozar. Kurulumda bir kez denetlemek, domainin o gün uyumlu olduğunu gösterir. Hâlâ uyumlu olduğunu gösteren şey, kayıtları izlemek ve toplu raporları okumaktır. CloudSpex herkese açık kayıtları belirli aralıklarla denetler ve biri değiştiğinde uyarı verir. Şikâyet oranlarını ya da gelen kutusuna yerleşimi ölçmez.