Defaults.Exposed › Opravy › Guides
Přesměrovaná pošta selhává SPF — proč to nelze opravit a co skutečně funguje (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.
Nemůžete zajistit, aby SPF procházelo pro přesměrovaný e-mail — přesměrování záměrně rozbíjí SPF a skutečná oprava je zarovnané DKIM, které přesměrování přežije. Rozsah je na úrovni sčítání: 7,355,985 z 138,927,207 domén publikujících SPF autorizuje samotný include přesměrování Namecheap, s podílem přísného SPF <0.1%, podle sčítání Defaults.Exposed zahrnujícího 261 milionů domén.
Níže: proč žádný SPF záznam, který byste mohli napsat, nepřežije přesměrování, proč SRS a ARC nejsou nástroje, které ovládáte, a oprava, která vydrží — podepisování DKIM vaší vlastní doménou jako váš DMARC průchod — plus jeden případ, který rozbíjí také DKIM (poštovní seznamy, které přepisují zprávy) a co s tímto zbytkem dělat.
Proč přesměrování rozbíjí SPF?
Příjemci vyhodnocují SPF vůči doméně Return-Path (RFC5321.MailFrom), nikoli záhlaví From. Při přímém odesílání je IP vašeho serveru ve vašem SPF záznamu a kontrola prochází. Když příjemce automaticky přesměruje zprávu dál — na osobní Gmail, přes universitní alias, přes přesměrovací produkt registrátora — server přesměrovatele ji znovu odešle, obvykle ponechávajíc vaši doménu na Return-Path. Konečný příjemce se nyní ptá: je tento přesměrovací server autorizován ve vašem SPF záznamu?
Není a nikdy nebude: nevybrali jste přesměrovatele, nevíte, že existuje, a stejná zpráva přesměrovaná přes jinou službu zítra by selhala z jiné IP adresy. SPF odpovídá na jednu otázku — „přišla tato IP adresa ze serveru, který autorizovala doména Return-Path?” — a pro přesměrovanou poštu je pravdivá odpověď ne. Selhání je SPF fungující dle specifikace, nikoli váš špatný záznam.
Sčítání ukazuje, jak hlavní tato cesta je: 7,355,985 domén autorizuje include přesměrování e-mailů Namecheap (spf.efwd.registrar-servers.com) — přesměrovací produkt jediného poskytovatele, ze 139 milionů vydavatelů SPF — s podílem přísného SPF <0.1% a pouze 0.2% vynucujícím DMARC. Tato měkká šablona není nedbalost: přesměrování je přesně tam, kde přísné -all selže, a poskytovatel, jehož produkt je přesměrování, podle toho dodává. Celý příběh o kvalifikátorech je v naší zprávě ~all vs -all a obrázek dle poskytovatele v který poskytovatel e-mailu poskytuje nejsilnější SPF.
Nemohu prostě přidat server přesměrovatele do svého SPF záznamu?
Ne — a proto je celý tento článek:
- Nemůžete vyjmenovat přesměrovatele. Jakýkoliv příjemce kdekoliv může přesměrovat vaši poštu přes jakoukoli službu. Váš SPF záznam by musel uvádět servery, o kterých nemůžete předem vědět.
- Jejich uvedení by zmarnilo účel. Velké přesměrovací služby přesměrovávají poštu pro miliony zákazníků. Dejte jejich rozsahy do svého záznamu a každá zpráva, kterou přeposílá jakýkoliv jejich uživatel — včetně útočníka — prochází SPF jako vy.
Stejná logika vylučuje uvolňování kvalifikátoru, aby „přesměrování fungovalo”: kvalifikátor není důvodem, proč přesměrovaná pošta selhává, a jakmile je DMARC v hře, mění méně, než většina průvodců tvrdí — viz data o kvalifikátorech. Záznam zde není páka. Přestaňte ji tahat.
Co SRS a ARC — neřeší přesměrování?
Řeší to — ale ani jedno není vaše k nasazení:
| Mechanismus | Co dělá při přesměrování pošty | Kdo ho ovládá | Opravuje vaše DMARC? |
|---|---|---|---|
| SPF | Selhává: IP přesměrovatele není ve vašem záznamu | Vy ho publikujete; přesměrování ho porážeje | Ne |
| SRS (Sender Rewriting Scheme) | Přesměrovatel přepíše Return-Path na svou vlastní doménu, takže jeho opětovné odeslání prochází SPF | Přesměrovatel | Ne — SPF průchod nyní patří doméně přesměrovatele, která se nezarovná s vaším From |
| ARC (RFC 8617) | Přesměrovatel zapečetí původní výsledky autentizace; konečný příjemce může důvěřovat zapečetěnému řetězci | Přesměrovatel a příjemce | Někdy — dle uvážení příjemce, nikoli vašeho |
| Zarovnané DKIM | Podpis cestuje uvnitř zprávy a stále ověřuje po přesměrování, s vaší doménou | Vy | Ano |
Data a stav mechanismů k 2026-06-29.
SRS způsobí, že problém přesměrovatele se SPF zmizí, nikoli váš: přepsání Return-Path mění, čí SPF se kontroluje, zatímco vaše záhlaví From — doména, kterou DMARC chrání — je nedotčeno. ARC je rozhodnutí o důvěře mezi operátory infrastruktury. Pokud průvodce říká, abyste „implementovali SRS” jako vlastník domény, zaměnil vás za poskytovatele přesměrování.
Jak zajistím, aby moje e-maily přežily přesměrování?
Udělejte DKIM, zarovnané s vaší doménou, vaším DMARC průchodem. Podpis DKIM je kryptografie přenášená v záhlavích zprávy: ověřuje kdekoliv zpráva skončí, přes libovolný počet serverů, které ji přenesly, pokud podepsaný obsah nebyl změněn. DMARC potřebuje pouze jeden zarovnaný průchod — SPF nebo DKIM — takže když přesměrování zabije SPF větev, zarovnané DKIM udržuje zprávu autentizovanou.
- Spusťte bezplatnou kontrolu na defaults.exposed před dotykem DNS. Ukáže, zda máte DKIM vůbec, zda podepisuje vaší doménou a kde stojí vaše DMARC — takže opravíte skutečnou mezeru spíše než bojujete se svým SPF záznamem.
- Potvrďte, že přesměrování je skutečně váš problém. V záhlaví Authentication-Results postižené zprávy prochází přímá pošta SPF, zatímco přesměrovaná kopie selhává z IP přesměrovací služby. Pokud SPF i DKIM procházejí, ale DMARC stále selhává, máte místo toho problém se zarovnáním — viz DMARC selhává, ale SPF a DKIM procházejí.
- Zapněte podepisování DKIM s vlastní doménou u každé odesílací služby — nejprve poskytovatel poštovní schránky, poté ESP a transakční odesílatelé. Výchozí nastavení poskytovatele často podepisuje doménou poskytovatele, která se nezarovnává; chcete
d=vasedomena. Začněte na jak opravit DKIM s průchody kliknutí pro Google Workspace a Microsoft 365. - Ověřte zarovnání, ne jen průchod. Doména
d=v podpisu musí odpovídat vaší doméně From;dkim=passna cizí doméně nedělá nic pro vaše DMARC. - Nechte svůj SPF záznam na pokoji. Ponechte ho přesný pro přímou poštu — stále autentizuje většinu vašeho provozu a zůstává vaší druhou větví DMARC. Jen přestaňte se pokoušet, aby pokrýval přesměrovatele.
- Znovu zkontrolujte, poté záměrně postupně zavádějte vynucení DMARC — další sekce a průvodce přechodem z p=none na p=reject.
Tato kombinace — SPF plus vynucující DMARC opírající se o zarovnané DKIM — je vzor odolný vůči přesměrování a je vzácný: z 77.5 milionů domén publikujících ~all, pouze 9.2% (7,116,774) to podpírá vynucující politikou DMARC a pouhých 3.87% z 261 milionů ohodnocených domén (10,092,481) dokončuje celou triádu SPF + DKIM + vynucené DMARC, dle sčítání (2026-06-29).
Co poštovní seznamy, které přepisují zprávy?
Jediná cesta přesměrování, kterou zarovnané DKIM nepřežije: poštovní seznamy, které mění zprávu — předmětový tag [listname], zápatí pro odhlášení, odebraná příloha. Změňte podepsaný obsah a hash těla již neodpovídá, takže DKIM také selže (dkim=fail: hash těla nebyl ověřen je vlastním průvodcem pro toto selhání). Nyní jsou mrtvé obě větve DMARC a pouze seznam může to zmírnit (přepsání From, zapečetění ARC).
Tento zbytek je přesně to, k čemu slouží postupné vynucení DMARC. Přecházení přes p=quarantine s rampou pct při sledování souhrnných zpráv ukazuje, kolik vaší skutečné pošty protéká přepisujícími seznamy před tím, než politika p=reject začne ji odmítat. Neskákejte na reject pro doménu, jejíž uživatelé žijí na poštovních seznamech; ale ani nezdržujte se navždy na p=none. Průvodce postupným zaváděním prochází rampou.
Nejčastější dotazy
Přeruší přesměrování také DKIM? Prosté přesměrování, ne: podpis cestuje se zprávou a ověřuje se u konečného příjemce. DKIM se rozbíjí pouze tehdy, když je podepsaný obsah změněn v průvozu — předmětové tagy a zápatí poštovních seznamů jsou klasickým případem — proto je zbytek seznamu zpracováván postupným zaváděním politiky DMARC, nikoli čímkoliv v DNS.
Mám přepnout z -all na ~all, aby přesměrování přestalo selhávat? Změna kvalifikátoru nezpůsobí, že přesměrovatele projdou — není to důvod, proč selhávají. Je příznačné, že include přesměrování Namecheap, 7,355,985 domén a největší populace vyhrazená přesměrování sčítání (2026-06-29), se dodává s podílem přísného SPF <0.1%: měkké SPF je pravděpodobně správná šablona pro produkt přesměrování. Viz zpráva ~all vs -all pro to, co kvalifikátor skutečně mění.
Proč moje pošta prochází SPF při přímém odeslání, ale selhává při přesměrování? Příjemce kontroluje, zda je IP posledního přenášejícího serveru autorizována SPF záznamem domény Return-Path. Přímé: váš server, ve vašem záznamu, průchod. Přesměrované: server přesměrovatele, není ve vašem záznamu, selhání. Váš záznam se nezměnil — přenášející IP se změnila.
Mohu nastavit SRS, abych to opravil? Pouze pokud jste přesměrovatelem. SRS běží na serveru provádějícím přesměrování a i tam, kde běží, výsledný SPF průchod patří doméně přesměrovatele a nezarovná se s vaším From — vaše DMARC stále potřebuje DKIM větev.
Je SPF zbytečné, když přesměrování ho každopádně rozbíjí? Ne. Většina pošty je doručována přímo, kde SPF funguje přesně dle záměru, a zůstává jednou z vašich dvou větví DMARC. Z 261,086,232 domén ve sčítání (2026-06-29) 138,927,207 publikuje SPF — ponechte váš přesný přes stránku opravy SPF a nechte DKIM nést přesměrovaný zbytek.
Pošlete vlastníkovi zprávu
Pokud toto opravujete pro klienta nebo zaměstnavatele, uzavřete práci s důkazem. Jakmile je DKIM vlastní domény aktivní a DMARC je postupně zaváděno, znovu spusťte bezplatnou kontrolu a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: s datem, srozumitelně, ukazující, že doména zůstává autentizovaná i při přesměrování pošty. To je artefakt pro obnovení kybernetického pojištění a příští dotazník dodavatele — zdokumentovaný stav před a po, nikoli „zapnul jsem něco”.
Zkontrolujte svou doménu → · DMARC selhává, ale SPF a DKIM procházejí → · Opravit DKIM → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.