Defaults.Exposed › Opravy › Guides

SPF selhává pro vaše SaaS nástroje? Proč se to děje a pořadí oprav — evropské vydání (2026)

Publikováno 2026-07-08

Údaje k 2026-06-29 · metodologie v7. Souhrnná data ze sčítání napříč 261 miliony ohodnocených domén. Viz jak hodnotíme.

Když SaaS nástroj „selhává SPF”, váš záznam obvykle není problémem: pošta selhává zarovnání DMARC nebo váš řetězec include překročil limit 10 DNS vyhledávání SPF. 2,119,539 z 138,927,207 domén publikujících SPF stojí na 9–10 vyhledáváních — jeden SaaS include od propasti — podle sčítání Defaults.Exposed zahrnujícího 261,086,232 domén.

Níže: jak zjistit, který ze dvou problémů máte, a poté pořadí oprav — nejprve skenovat, zjistit doménu, ze které nástroj skutečně odesílá, přepnout dodavatele na DKIM vlastní domény a přidat SPF include pouze tam, kde skutečně pomáhá — plus specifika pro HubSpot, Salesforce, Mailchimp a SendGrid.

Proč pošta ze SaaS nástroje selhává SPF?

Tři vzory pokrývají téměř každý případ:

Data k 2026-06-29.

Zvýrazněný řádek je místo, kde většina lidí stojí. Přidávání řádků include: pro každý nástroj se ho nedotýká — a každý řádek vás přibližuje k druhému řádku: nejméně 797,263 domén již překročilo limit 10 vyhledávání a jejich SPF nyní vrací PermError, který nic nechrání. Úplná čísla jsou v zprávě o SPF PermError.

Vůči které doméně SPF skutečně kontroluje?

Ne vůči té v záhlaví From. Příjemci vyhodnocují SPF vůči doméně Return-Path (RFC5321.MailFrom, také nazývaný bounce nebo envelope-from adresa) — záhlaví From, které příjemce vidí, nehraje při kontrole SPF žádnou roli.

Tento jediný fakt vysvětluje většinu „SPF selhání SaaS”. Vaše marketingová platforma odesílá s Return-Path jako [email protected]; SPF se kontroluje vůči dodavatel.com a čistě prochází. Poté se DMARC ptá, zda tato SPF zkontrolovaná doména odpovídá vaší doméně From. Neodpovídá, takže SPF větev DMARC selhává a váš řídicí panel říká „SPF selhává”. Úprava vlastního SPF záznamu to nemůže opravit — váš záznam nebyl nikdy konzultován.

Jaké je pořadí oprav?

1. Nejprve spusťte bezplatnou kontrolu. Řekne vám v jednom průchodu, zda vaše SPF chybí, je duplicitní, překračuje limit vyhledávání nebo je v pořádku, a kde stojí DMARC — než se dotknete DNS.
2. Zjistěte Return-Path, který nástroj skutečně používá. Pošlete si test z nástroje a přečtěte záhlaví Return-Path (a Authentication-Results) v surové zprávě. To vám řekne, v jakém řádku výše uvedené tabulky se nacházíte.
3. Zapněte DKIM vlastní domény dodavatele. Každý seriózní SaaS nástroj nabízí „ověření domény”: několik CNAME záznamů, které mu umožňují podepisovat DKIM jako vaše doména. Tento podpis se zarovná s vaší doménou From, takže DMARC prochází přes DKIM — trvale a dokonce i při přesměrování pošty. Toto je oprava, která vydrží.
4. Přidejte SPF include dodavatele pouze v případě, že používá váš return-path — povolili jste jeho vlastní bounce doménu nebo skutečně odesílá s vaší doménou v obálce. Include pro dodavatele, který odskakuje přes vlastní doménu, nic nekupuje a utrácí váš rozpočet vyhledávání.
5. Spočítejte DNS vyhledávání před uložením. Limit je 10 rozluštěných vyhledávání, include se počítají rekurzivně a 2,119,539 domén již stojí na 9–10 — percentil p99 sčítání je 9. Blízko hraně? Nejprve odstraňte include pro nástroje, které již nepoužíváte. Právě jste přepnuli poskytovatele e-mailu? Zkontrolujte, zda nezůstal druhý záznam — dva SPF záznamy se rovnají PermError.
6. Znovu zkontrolujte a potvrďte. SPF prochází na správné doméně, DKIM je zarovnáno, DMARC prochází. Úplná reference je na stránce jak opravit SPF; průvodci pro poskytovatele jako SPF na GoDaddy a DMARC na IONOS pokrývají klikání v DNS panelu.

Co dělat pro HubSpot, Salesforce, Mailchimp a SendGrid?

HubSpot. Připojte svou odesílací doménu v nastavení HubSpotu a publikujte dva DKIM CNAME záznamy, které vydá (hs1-… / hs2-…). To zarovná DKIM s vaší doménou From. Nepotřebujete SPF include pro HubSpot, pokud jste nenakonfigurovali HubSpot tak, aby používal vaši vlastní bounce doménu.

Salesforce. Vytvořte klíč DKIM v Salesforce Setup a publikujte pár CNAME záznamů, které vygeneruje. Pokud Salesforce odesílá s return-path vaší organizace, přidejte include:_spf.salesforce.com a nakonfigurujte bounce doménu — toto je jeden velký CRM, kde je SPF include často skutečně potřeba.

Mailchimp. Ověřte svou doménu a publikujte DKIM CNAME záznamy k2 / k3. Zarovnání Mailchimpu je pouze přes DKIM — neexistuje žádný SPF include k přidání a přidání jednoho ze starého návodu jen plýtvá vyhledáváními.

SendGrid. Dokončete ověření domény („automatizované zabezpečení”): tři CNAME záznamy zpracovávající DKIM i return-path na vaší vlastní subdoméně. Žádný SPF include není potřeba. Z 740,321 domén, jejichž SPF autorizuje sendgrid.net, má pouze 18.0% vynucující DMARC (data k 2026-06-29) — většina odesílatelů SendGrid se zastaví jeden krok před cílem.

Zendesk a vše ostatní: stejný vzor. Najděte stránku „ověření domény” nástroje, publikujte jeho DKIM CNAME záznamy a dotýkejte se SPF pouze tehdy, pokud nástroj dokumentuje, že používá váš return-path.

Je SPF pro evropské firmy jiné?

Ne — SPF, DKIM a DMARC fungují všude identicky. Co se v Evropě liší je kontext: kdo se ptá a co vaši sousedé již udělali.

Vaše ccTLD stanovuje místní laťku. Evropské ccTLD publikují SPF výrazně nad sazbami .com, ale domény, které dokončí práci — vynucující politika DMARC na vrcholu — jsou všude menšinou:

Data k 2026-06-29. Francie: 13.65% vynucující DMARC; Itálie: 5.24%.

Výchozí nastavení vašeho evropského hostitele záleží. 4,346,526 domén autorizuje poštovní servery IONOS pro EU (_spf-eu.ionos.com) ve svém SPF — a pouze 0.3% končí přísným -all, přičemž 1.0% má vynucené DMARC. 2,132,049 domén OVH si vede lépe z hlediska přísnosti (43.7%), ale pouze 2.2% vynucuje DMARC (data k 2026-06-29). Pokud jste nikdy nezměnili svůj záznam, stojíte na těchto výchozích hodnotách.

Regulátoři toto nyní pojmenovávají. Článek 21(2)(j) NIS2 vyžaduje, aby subjekty v rozsahu zabezpečily svou komunikaci, a prováděcí nařízení Komise (EU) 2024/2690 upřesňuje opatření v oblasti zabezpečení e-mailu a DNS. E-mailová autentizace je konkrétní, ověřitelný kus — a neobvykle pro soulad s předpisy, zdarma opravitelný.

K rezidenci dat: skener a sčítání Defaults.Exposed běží na AWS eu-west-1, publikujeme pouze souhrnné číslice a skenování kontroluje pouze doménu, na kterou se ptáte.

Nejčastější dotazy

Můj SPF nástroj říká „pass”, ale řídicí panel nástroje říká, že SPF selhává — proč? Nástroj testoval váš záznam; příjemce testoval doménu Return-Path, kterou nástroj skutečně použil, poté DMARC porovnal s vaší doménou From. Jde o selhání zarovnání, nikoli selhání záznamu — opraveno DKIM vlastní domény dodavatele, nikoli úpravami SPF.

Mám prostě přidat SPF include pro každý nástroj, který používáme? Ne. Každý include utrácí část rozpočtu 10 vyhledávání SPF rekurzivně: 2,119,539 z 138,927,207 domén publikujících SPF stojí na 9–10 vyhledáváních a nejméně 797,263 je přes limit — jejich SPF vrací PermError a nic nechrání (data k 2026-06-29).

Opraví include také DMARC? Pouze pokud nástroj odesílá s vaším return-path, takže SPF prochází a zarovnává. Pro většinu SaaS nástrojů to tak není — proto zarovnané DKIM, nikoli SPF, je větev, která způsobuje procházení DMARC pro SaaS poštu.

Je to právní požadavek v EU? Pro subjekty v rozsahu NIS2 jsou článek 21(2)(j) a prováděcí nařízení (EU) 2024/2690 závazné. I mimo rozsah se pojistitelé a dotazníky zákazníků stále více ptají — a k 2026-06-29 žádná evropská ccTLD nedosáhne ani třetiny svých domén na vynucující politiku DMARC (29.43% v .nl v nejlepším případě; 5.24% v .it).

Pošlete vlastníkovi zprávu

Jakmile jsou CNAME záznamy aktivní, spusťte skenování znovu a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi nebo klientovi. Ukazuje srozumitelně, co selhávalo, co jste opravili a kde doména nyní stojí — přesně důkaz, který potřebují pro obnovení pojištění nebo dotazník bezpečnosti zákazníka, písemně spíše než na vaše slovo.

Zkontrolujte svou doménu zdarma

Zjistěte přesně, která větev SPF, DKIM a DMARC selhává — soukromě a pouze pro vlastníky.

Zkontrolujte svou doménu → · Opravit SPF → · SPF PermError: „příliš mnoho DNS vyhledávání” → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.