Defaults.Exposed › Opravy › Guides

SPF přestalo fungovat po přechodu k poskytovateli e-mailu — oprava po migraci (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.

SPF se obvykle rozbíjí po přechodu k poskytovateli e-mailu, protože záznam nového poskytovatele byl přidán vedle starého. Dva záznamy v=spf1 jsou trvalá chyba — SPF se zcela zruší. 1,013,416 domén — přibližně jedna z 138 těch, které se pokoušejí o SPF — je v tomto stavu, podle sčítání Defaults.Exposed zahrnujícího 261 milionů domén. Sloučte je do jednoho.

Oprava trvá asi deset minut: zkontrolujte doménu, abyste viděli přesně, co migrace zanechala, vypište každý SPF záznam na autoritativních nameserverech, sloučte je do jednoho záznamu, který zahrnuje pouze vašeho nového poskytovatele, a znovu ověřte pomocí dig. Tento průvodce prochází každý krok a také kontroly DKIM a nameserveru, na které většina migrací zapomíná.

Proč se SPF rozbilo hned po migraci?

Protože průvodce nastavením nového poskytovatele říkal „přidejte tento TXT záznam” — a vy jste to udělali, vedle starého. To je jediná věc, kterou standard SPF nepovoluje. RFC 7208 (§3.2, výsledek chyby předepsaný v §4.5) povoluje přesně jeden záznam v=spf1 na doménu; příjemce, který nalezne dva nebo více, musí vrátit PermError spíše než hádat, který je autoritativní. PermError znamená, že SPF je neplatné: ne starý záznam, ne nový, žádné SPF vůbec.

A to nekončí zde. DMARC považuje PermError za selhání na SPF větvi, takže vaše pošta nyní závisí výhradně na DKIM. Pokud DKIM nového poskytovatele ještě není nastaveno — běžné uprostřed migrace — odesíláte neautentizovaně přesně v okamžiku, kdy jste změnili infrastrukturu, což je chvíle, kdy vás příjemci nejvíce prověřují.

Toto je kopírování-vkládání, které zruší ochranu při přechodu k poskytovateli, a není to vzácné: 1,013,416 domén publikuje dva nebo více SPF záznamů právě teď — přibližně jedna z 138 z populace 139 milionů, která se pokouší o SPF, podle sčítání Defaults.Exposed zahrnujícího 261 milionů domén (data k 2026-06-29). Úplná čísla o pasti dvou záznamů mají vlastní zprávu; tato stránka je procedurální oprava.

Co migrace zanechala?

Pět pozůstatků způsobuje téměř každé selhání SPF po migraci. Zkontrolujte je v tomto pořadí:

Jak to opravím? Kontrolní seznam migrace

1. Nejprve spusťte bezplatnou kontrolu na defaults.exposed. Načte vaše živé DNS záznamy a řekne vám, zda máte více SPF záznamů, chybějící include nebo mezeru v DKIM — diagnostikujte před dotykem čehokoliv.

2. Vypište každý SPF záznam na autoritativních nameserverech. dig +short NS vasedomena.cz, poté dig +short TXT vasedomena.cz @<nameserver> vůči jednomu z nich. Spočítejte řetězce začínající v=spf1. Jediný bezpečný počet je 1.

3. Sloučit do jednoho záznamu. Jeden záznam, začínající v=spf1, obsahující include vašeho nového poskytovatele a jakéhokoliv dalšího odesílatele, kterého stále používáte (fakturační nástroj, CRM, newsletterová platforma), jeden terminální -all nebo ~all. Příklad — starý Google Workspace, nový Microsoft 365, uprostřed vypouštění:

   Před:  "v=spf1 include:_spf.google.com ~all"
          "v=spf1 include:spf.protection.outlook.com -all"
   
   Po:    "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
   Poté:  "v=spf1 include:spf.protection.outlook.com -all"
   

   Hodnoty poskytovatele a zvláštnosti DNS panelů jsou v průvodcích nastavení pro Google Workspace a Microsoft 365.

4. Smazat nadbytečné záznamy. Slučování bez mazání nic neopraví — PermError pochází z počtu.

5. Ponechte include starého poskytovatele pouze po dobu, kdy starý systém stále odesílá — plánované zprávy, starý konektor CRM, zapomenutá poštovní schránka. Jakmile je vypouštění hotové, odstraňte ho: zastaralý include nechává starou infrastrukturu s oprávněním odesílat jako vy a každý include stojí DNS vyhledávání vůči pevnému limitu 10 SPF — nejméně 797,263 domén zrušilo SPF překročením tohoto limitu (sčítání, 2026-06-29).

6. Nastavte DKIM nového poskytovatele — a zatím neodstraňujte staré selektory. Nové selektory podepisují novou poštu; staré selektory musí zůstat publikované, dokud nebude každá zpráva podepsaná jimi doručena a veškeré přesměrování se usadí. Úplný průvodce v DKIM selhávající po přechodu k nástrojům e-mailu.

7. Pokud jste také změnili nameservery, zkontrolujte oba. DNS migrace se často uskutečňují společně s migracemi e-mailu. Dotaz na starý i nový NS set přímo (dig TXT vasedomena.cz @stary-ns a @novy-ns) — dokud delegace registrátora plně nepropaguje, někteří příjemci stále ptají starých serverů, takže opravený záznam musí existovat na jakémkoliv setu, který odpovídá.

8. Znovu spusťte skenování a potvrďte, že SPF zobrazuje jeden platný záznam s procházením.

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

Příjemci vyhodnocují SPF vůči Return-Path (RFC5321.MailFrom) doméně — bounce adrese — nikoli záhlaví From, které příjemci vidí. Po migraci je to důležité dvakrát: váš nový poskytovatel může používat svou vlastní bounce doménu, dokud nenakonfigurujete vlastní, a SPF „procházení” na doméně, která není vaše, se nezarovná pro DMARC. Opravou je DKIM nového poskytovatele, podepsaný vaší doménou.

Migrujete a zároveň rebrandujete?

Změnili jste také doménu i poskytovatele? Zacházejte s nimi jako se dvěma úkoly. Nová doména potřebuje celý zásobník — SPF, DKIM, DMARC — od prvního dne; použijte kontrolní seznam e-mailu pro novou doménu. Stará doména zůstává autentizovaná, dokud přes ni probíhá přesměrování nebo odpovědi, a je explicitně uzamčena (ne jen opuštěna), jakmile je zaparkována. Stará doména se zbylým, napůl rozbitým SPF je cíl spoofingu nesoucí vaše bývalé jméno.

Nejčastější dotazy

Mohu mít dva SPF záznamy při migraci? Ne. Ve standardu neexistuje žádná lhůta tolerance — dva záznamy v=spf1 jsou PermError od okamžiku, kdy druhý existuje, a 1,013,416 domén v tomto stavu sedí k datu sčítání (2026-06-29). Bezpečný vzor pro migraci je jeden záznam nesoucí include obou poskytovatelů po dobu překrytí.

Jak dlouho mám ponechat include starého poskytovatele? Dokud nic neodesílá přes starého poskytovatele — typicky délka vašeho okna překrytí, dny až pár týdnů. Sledujte Return-Path všeho, co stále přichází přes starý systém; když tento provoz přestane, odstraňte include a znovu zkontrolujte počet vyhledávání.

Proč nástroj stále zobrazuje můj starý záznam poté, co jsem ho opravil? DNS cacheování respektuje TTL záznamu a pokud se vaše nameservery změnily, někteří resolvery stále dotazují starý set. Ověřte přímo na autoritativních nameserverech pomocí dig TXT vasedomena.cz @<ns> — pokud je odpověď tam správná, oprava je hotová a cache se dohoní. Pokud je špatná na jednom NS setu, viz „SPF záznam nenalezen” — skutečné příčiny.

Potřebuji při přechodu k poskytovateli změnit DMARC? Obvykle ne samotný záznam — pojmenovává vaši schránku zpráv a politiku, nikoli vašeho poskytovatele. Ale vaše výsledky DMARC závisí na SPF a DKIM, které jste právě migrovali: očekávejte pokles ve zprávách během přechodu a potvrďte, že obě větve procházejí, než zpřísníte politiku. Začněte na opravit SPF, pokud skenování ukazuje, že SPF větev stále selhává.

Pošlete vlastníkovi zprávu

Pokud tuto migraci provádíte pro klienta, dokončete ji s důkazem. Znovu spusťte bezplatnou kontrolu jakmile je sloučení aktivní a přepošlete ohodnocenou zprávu obchodnímu vlastníkovi: SPF, DKIM a DMARC procházejí u nového poskytovatele, srozumitelně, s datem. To je artefakt, který archivuje pro obnovení kybernetického pojištění a příští dotazník bezpečnosti dodavatele — důkaz, že migrace zanechala doménu lépe autentizovanou, než začala.

Zkontrolujte svou doménu → · DKIM selhávající po přechodu k nástrojům e-mailu → · „SPF záznam nenalezen” — skutečné příčiny → · Jak hodnotíme → · Pouze souhrnná data. Data uložena a zpracována v EU.