Požadavky Googlu a Yahoo na odesílatele e-mailů

Co Google a Yahoo vyžadují od odesílatelů e-mailů

Od února 2024 platí zpřísněná pravidla pro odesílatele e-mailů směřujících na adresy Gmail a Yahoo. Požadavky se týkají autentizace (SPF, DKIM, DMARC), míry stížností na spam a způsobu odhlašování z newsletterů. Kdo je nesplňuje, riskuje nedoručení e-mailů — od dočasných odmítnutí až po trvalé blokování.

Požadavky se dělí na dvě úrovně: pro všechny odesílatele a pro hromadné odesílatele (bulk senders), kteří posílají 5 000 a více zpráv denně na Gmail adresy.

Požadavky pro všechny odesílatele

Tato pravidla platí bez ohledu na objem odesílaných e-mailů.

Autentizace pomocí SPF nebo DKIM

Každý e-mail musí projít ověřením alespoň jedním z protokolů — SPF nebo DKIM. Google i Yahoo vyžadují, aby doména odesílatele měla platný autentizační záznam v DNS.

• SPF: TXT záznam na doméně v obálkové adrese (envelope sender) musí autorizovat IP adresu odesílajícího serveru.
• DKIM: E-mail musí být podepsán platným DKIM klíčem a podpis musí odpovídat veřejnému klíči v DNS.

Pokud nemáte nastavený ani jeden z těchto protokolů, nastavte SPF záznam a DKIM podepisování jako první krok.

Platný PTR záznam odesílající IP adresy

Odesílající IP adresa musí mít platný PTR (reverzní DNS) záznam. To znamená, že zpětný DNS lookup IP adresy musí vracet hostname, a dopředný DNS lookup tohoto hostname musí vracet stejnou IP adresu.

Ověření:

dig -x 198.51.100.25 +short

Pokud příkaz vrátí hostname (např. mail.firma.cz), ověřte dopředný záznam:

dig mail.firma.cz A +short

Výsledek musí odpovídat původní IP adrese. Pokud PTR záznam chybí, kontaktujte svého poskytovatele hostingu nebo správce IP rozsahu — PTR záznamy nastavuje vlastník IP adresy, ne vlastník domény.

Šifrování přenosu pomocí TLS

E-maily musí být přenášeny přes šifrované TLS spojení. Odesílající server musí podporovat STARTTLS a navázat šifrované spojení s přijímajícím serverem.

Většina moderních mailových serverů a služeb (Google Workspace, Microsoft 365, Mailgun, SendGrid) TLS podporuje ve výchozím nastavení. Pokud provozujete vlastní server, ověřte konfiguraci — v Postfixu musí být smtp_tls_security_level = may (nebo vyšší).

Míra stížností pod 0,3 %

Google měří míru stížností na spam prostřednictvím Google Postmaster Tools. Požadavek je udržovat stížnosti pod 0,3 %. Google doporučuje cílit na hodnotu pod 0,1 %.

Překročení hranice 0,3 % znamená problémy s doručitelností. Od června 2024 jsou hromadní odesílatelé s mírou stížností nad 0,3 % vyloučeni z možnosti požádat o zmírnění blokace.

Požadavky pro hromadné odesílatele

Hromadný odesílatel je ten, kdo pošle 5 000 a více zpráv denně na osobní Gmail adresy. Jakmile doména tento práh dosáhne, Google si ji trvale označí jako hromadného odesílatele — stav se neruší.

Kromě požadavků platných pro všechny odesílatele musí hromadní odesílatelé splnit navíc:

SPF a DKIM současně

Zatímco běžný odesílatel potřebuje SPF nebo DKIM, hromadný odesílatel musí mít obojí. Nestačí jen jedno — oba protokoly musí být správně nakonfigurované a e-maily musí oběma projít.

DMARC s minimální politikou p=none

Doména v hlavičce From musí mít publikovaný DMARC záznam s politikou alespoň p=none. Zároveň musí alespoň jeden z protokolů (SPF nebo DKIM) být v alignmentu s doménou v hlavičce From.

Příklad minimálního DMARC záznamu:

v=DMARC1; p=none; rua=mailto:firma.cz@rua.spfmonitor.com

Politika p=none je minimum — Google a Yahoo ji přijmou, ale pro skutečnou ochranu před spoofingem doporučujeme postupně přejít na p=quarantine a následně p=reject. Kompletní průvodce nastavením DMARC popisuje postup krok za krokem.

Přidáním adresy rua= do záznamu získáte DMARC reporty, které ukáží, kdo z vaší domény odesílá a jak prochází autentizací. SPF Monitor tyto reporty automaticky zpracuje a vizualizuje — nemusíte ručně parsovat XML.

Jednoklikové odhlášení (one-click unsubscribe)

Marketingové a hromadné e-maily musí podporovat odhlášení jedním klikem. Technicky to znamená:

• Hlavička List-Unsubscribe s HTTPS odkazem a volitelně mailto adresou
• Hlavička List-Unsubscribe-Post: List-Unsubscribe=One-Click
• Obě hlavičky musí být pokryty platným DKIM podpisem (RFC 8058)
• Viditelný odkaz pro odhlášení v těle zprávy

Požadavek na zpracování: odhlášení musí být provedeno do 2 dnů od žádosti.

Příklad hlaviček:

List-Unsubscribe: <https://firma.cz/unsubscribe?id=abc123>, <mailto:unsubscribe@firma.cz>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Transakční e-maily (potvrzení objednávky, reset hesla) tímto požadavkem nejsou dotčeny.

Alignment domény v hlavičce From

Doména v hlavičce From musí být v alignmentu buď s doménou v SPF (envelope sender), nebo s doménou v DKIM podpisu (d=). Alignment znamená, že domény se shodují — buď přesně (strict), nebo na úrovni organizační domény (relaxed).

Pokud odesíláte e-maily přes službu třetí strany (ESP — e-mail service provider), ověřte, že služba podepisuje DKIM vaší doménou, nebo že envelope sender používá vaši doménu.

Časová osa vynucování

Yahoo vynucuje požadavky od února 2024 s postupným zpřísňováním. Microsoft (Outlook.com, Hotmail, Live.com) oznámil podobné požadavky na SPF, DKIM a DMARC s vynucováním od května 2025.

Trend je jasný: požadavky se budou pouze zpřísňovat, ne uvolňovat. Podobné požadavky na e-mailovou autentizaci přináší i evropská regulace NIS2.

Jak ověřit splnění požadavků

Kontrola autentizace

Kompletní analýza domény na SPF Monitoru zkontroluje:

• Platnost a správnost SPF záznamu
• Existenci a konfiguraci DKIM
• Přítomnost DMARC záznamu a nastavení politiky
• Alignment mezi protokoly

Alternativně zkontrolujte jednotlivé záznamy:

dig firma.cz TXT +short | grep spf
dig _dmarc.firma.cz TXT +short
dig selector._domainkey.firma.cz TXT +short

Google Postmaster Tools

Pro monitorování reputace odesílatele a míry stížností na spam používejte Google Postmaster Tools. Nástroj zobrazuje:

• Míru stížností na spam
• Reputaci IP adresy a domény
• Procento autentizovaných e-mailů
• Chyby v doručování

Průběžný monitoring

Jednorázová kontrola nestačí. DNS záznamy se mohou změnit, odesílací služby mohou upravit konfiguraci, nový marketingový nástroj může začít odesílat bez správné autentizace. DMARC reporty poskytují průběžný přehled o tom, jak vaše e-maily procházejí autentizací u příjemců.

Nejčastější problémy a jejich řešení

E-maily od třetí strany neprocházejí autentizací

Pokud odesíláte přes ESP (Mailchimp, SendGrid, Mailgun) a e-maily neprocházejí SPF nebo DKIM:

1. SPF: přidejte include: mechanismus poskytovatele do svého SPF záznamu. Příklad pro SendGrid: include:sendgrid.net.
2. DKIM: nastavte DKIM podepisování vaší doménou u poskytovatele — typicky přidáním CNAME záznamu do DNS.
3. Alignment: ověřte, že envelope sender nebo DKIM doména odpovídá doméně v hlavičce From.

Konkrétní postup pro Google Workspace najdete v článku Nastavení SPF/DKIM pro Google Workspace, pro Microsoft 365 v článku Nastavení SPF/DKIM pro Microsoft 365.

Chybějící DMARC záznam

Pokud DMARC záznam nemáte, začněte s politikou p=none a adresou pro reporty:

v=DMARC1; p=none; rua=mailto:firma.cz@rua.spfmonitor.com

Tím splníte minimální požadavek Google a Yahoo a zároveň začnete sbírat data o tom, kdo z vaší domény odesílá. Na základě reportů pak můžete bezpečně zpřísnit politiku.

Vysoká míra stížností

Pokud míra stížností překračuje 0,1 %:

• Posílejte e-maily jen příjemcům, kteří k odběru dali souhlas
• Zjednodušte odhlášení — viditelný odkaz v každém e-mailu
• Neposílejte zbytečně často a segmentujte seznamy podle aktivity příjemců
• Monitorujte spam trapy v seznamech adresátů
• Odstraňte neaktivní příjemce, kteří nereagují déle než 6 měsíců

Co hrozí při nesplnění požadavků

Důsledky jsou odstupňované, ale nevratné z hlediska reputace:

• Dočasné odmítnutí (4xx) — odesílající server zkusí doručit znovu, ale opakovaná selhání poškozují reputaci odesílatele
• Trvalé odmítnutí (5xx) — e-mail není doručen a odesílatel dostane bounce zprávu
• Zařazení do spamu — e-mail se doručí, ale skončí ve složce spamu
• Poškození reputace domény — dlouhodobé nesplňování vede ke snížení reputace, což ovlivní doručitelnost i po nápravě

Náprava reputace trvá týdny až měsíce. Prevence je výrazně jednodušší než řešení následků.

Kompletní analýza domény odhalí nesplněné požadavky dříve, než způsobí problémy s doručitelností.