SPF a încetat să funcționeze după schimbarea furnizorului de e-mail — Remedierea pentru migrare (2026)

Publicat 2026-07-08

Date din 2026-06-29 · metodologie v7. Date agregate din recensământul a 261 milioane de domenii clasificate. Consultați cum clasificăm.

SPF se strică de obicei după o schimbare de furnizor de e-mail deoarece înregistrarea noului furnizor a fost adăugată lângă cea veche. Două înregistrări v=spf1 sunt o eroare permanentă — SPF se anulează complet. 1,013,416 domenii — aproximativ una din 138 dintre cele care încearcă SPF — se află în această stare, conform recensământului Defaults.Exposed pe 261 milioane de domenii. Îmbinați-le într-una singură.

Remedierea durează aproximativ zece minute: scanați domeniul pentru a vedea exact ce a lăsat migrarea în urmă, listați toate înregistrările SPF la serverele DNS autoritare, îmbinați-le într-o singură înregistrare care include doar noul furnizor și re-verificați cu dig. Acest ghid parcurge fiecare pas, plus verificările DKIM și ale serverelor DNS pe care le uită cele mai multe migrări.

De ce s-a stricat SPF imediat după migrare?

Deoarece ghidul de configurare al noului furnizor spunea „adăugați această înregistrare TXT” — și ați făcut-o, lângă cea veche. Aceasta este singurul lucru pe care standardul SPF nu îl permite. RFC 7208 (§3.2, eroarea prescrisă în §4.5) permite exact o înregistrare v=spf1 per domeniu; un receptor care găsește două sau mai multe trebuie să returneze PermError în loc să ghicească care este autoritară. PermError înseamnă că SPF este nul: nu înregistrarea veche, nu cea nouă, niciun SPF deloc.

Și nu se oprește aici. DMARC tratează un PermError ca un eșec pe piciorul SPF, deci e-mailul dvs. depinde acum în totalitate de DKIM. Dacă DKIM al noului furnizor nu este configurat nici el — obișnuit în mijlocul migrării — trimiteți neautentificat exact în momentul în care ați schimbat infrastructura, când receptorii vă scrutinizează cel mai intens.

Acesta este copy-paste-ul care anulează protecția la schimbarea furnizorilor, și nu este rar: 1,013,416 domenii publică două sau mai multe înregistrări SPF chiar acum — aproximativ una din 138 din populația de 139 milioane care încearcă SPF, conform recensământului Defaults.Exposed pe 261 milioane de domenii (date din 2026-06-29). Numerele complete despre capcana celor două înregistrări au propriul raport; această pagină este remedierea procedurală.

Ce a lăsat migrarea în urmă?

Cinci rămășițe cauzează aproape fiecare eșec SPF post-migrare. Verificați-le în această ordine:

Ce a rămas	Ce vedeți	Remedierea
Vechea înregistrare SPF, încă în DNS lângă cea nouă (două înregistrări `v=spf1`)	Verificatoarele raportează „multiple SPF records” sau PermError; SPF nu mai funcționează deloc	Îmbinați într-o singură înregistrare, ștergeți restul — pașii de mai jos
Include-ul vechiului furnizor în interiorul singurei înregistrări	SPF funcționează, dar irosesc interogări DNS și serverele vechiului furnizor pot încă trimite ca dvs.	Eliminați-l odată ce e-mailul a trecut complet la noul sistem
Include-ul noului furnizor niciodată adăugat	E-mailul de la noul furnizor eșuează SPF la receptori	Adăugați-l la singura înregistrare existentă — niciodată ca înregistrare nouă
Selectorii DKIM necreați pentru noul furnizor	`dkim=fail` sau semnături de la domeniul implicit al furnizorului; DMARC nu are un al doilea picior	Publicați noii selectori — pasul 6 de mai jos
Înregistrare actualizată doar la serverele DNS vechi	Răspunsuri diferite în funcție de cine întrebați; eșecuri intermitente	Corectați zona la serverele DNS autoritare; verificați ambele seturi în timpul tranziției

Cum îl remediez? Lista de verificare pentru migrare

Rulați mai întâi scanarea gratuită la defaults.exposed. Citește DNS-ul dvs. activ și vă spune dacă aveți multiple înregistrări SPF, un include lipsă sau un decalaj DKIM — diagnosticați înainte de a atinge orice.
Listați toate înregistrările SPF la serverele DNS autoritare. dig +short NS yourdomain.com, apoi dig +short TXT yourdomain.com @<nameserver> față de unul dintre ele. Numărați șirurile care încep cu v=spf1. Singura numărătoare sigură este 1.
Îmbinați într-o singură înregistrare. O singură înregistrare, începând cu v=spf1, conținând include-ul noului furnizor și orice alt expeditor pe care îl mai folosiți (instrument de facturare, CRM, platformă de newsletter), un singur -all sau ~all terminal. Exemplu — Google Workspace vechi, Microsoft 365 nou, în mijlocul drenajului:
```
Înainte:  "v=spf1 include:_spf.google.com ~all"
          "v=spf1 include:spf.protection.outlook.com -all"

După:     "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Mai târziu: "v=spf1 include:spf.protection.outlook.com -all"
```
Valorile furnizorilor și particularitățile panoului DNS sunt în ghidurile de configurare pentru Google Workspace și Microsoft 365.
Ștergeți înregistrările suplimentare. Îmbinarea fără ștergere nu rezolvă nimic — PermError vine din număr.
Păstrați include-ul vechiului furnizor doar cât timp sistemul vechi mai trimite — rapoarte programate, un conector CRM vechi, o căsuță poștală uitată. Odată ce drenajul este finalizat, eliminați-l: un include perimat lasă infrastructura veche autorizată să trimită ca dvs., și fiecare include costă interogări DNS față de limita strictă de 10 a SPF — cel puțin 797,263 domenii au anulat SPF depășind această limită (recensământ, 2026-06-29).
Configurați DKIM al noului furnizor — și nu ștergeți încă selectorii vechi. Noii selectori semnează noile e-mailuri; selectorii vechi trebuie să rămână publicați până când fiecare mesaj semnat cu ei a fost livrat și orice redirecționări s-au stabilit. Prezentare completă în DKIM eșuează după schimbarea instrumentelor de e-mail.
Dacă ați schimbat și serverele DNS, verificați ambele. Migrările DNS merg deseori în paralel cu migrările de e-mail. Interogați setul vechi și cel nou de NS direct (dig TXT yourdomain.com @old-ns și @new-ns) — până când delegarea registrarului se propagă complet, unii receptori întreabă în continuare serverele vechi, deci înregistrarea corectată trebuie să existe la oricare set răspunde.
Re-rulați scanarea și confirmați că SPF arată o singură înregistrare validă cu un pass.

Față de ce domeniu verifică SPF de fapt?

Receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom) — adresa de bounce — nu antetul From pe care îl văd destinatarii. După o migrare, aceasta contează de două ori: noul furnizor poate folosi propriul domeniu de bounce până când configurați unul personalizat, și SPF „trecând” pe un domeniu care nu este al dvs. nu se va alinia pentru DMARC. Remedierea pentru asta este DKIM al noului furnizor, semnat cu domeniul dvs.

Migrați și rebranding-uiți în același timp?

Ați schimbat și domeniul, nu doar furnizorul? Tratați-le ca două lucrări. Noul domeniu are nevoie de stiva completă — SPF, DKIM, DMARC — din prima zi; folosiți lista de verificare pentru e-mail pe un domeniu nou. Domeniul vechi rămâne autentificat atât timp cât traficul de redirecționare sau răspuns curge prin el, și este explicit blocat (nu doar abandonat) odată ce este parcat. Un domeniu vechi cu SPF pe jumătate stricat este o țintă de spoofing purtând fostul dvs. nume.

Întrebări frecvente

Pot păstra două înregistrări SPF în timp ce migrez? Nu. Nu există nicio perioadă de grație în standard — două înregistrări v=spf1 sunt un PermError din momentul în care există a doua, și 1,013,416 domenii stau în această stare din 2026-06-29. Tiparul sigur pentru migrare este o singură înregistrare purtând include-urile ambilor furnizori în timpul suprapunerii.

Cât timp ar trebui să păstrez include-ul vechiului furnizor? Până când nimic nu mai trimite prin vechiul furnizor — de obicei durata ferestrei dvs. de suprapunere, zile până la câteva săptămâni. Urmăriți Return-Path-ul a orice mai ajunge prin sistemul vechi; când acel trafic se oprește, eliminați include-ul și re-verificați numărul de interogări.

De ce un verificator mai arată încă înregistrarea veche după ce am remediat? Cache-ul DNS onorează TTL-ul înregistrării, iar dacă serverele DNS s-au schimbat, unele resolvere interogează în continuare setul vechi. Verificați direct la serverele DNS autoritare cu dig TXT yourdomain.com @<ns> — dacă răspunsul este corect acolo, remedierea este finalizată și cache-urile vor urmări. Dacă este greșit la un set NS, consultați „Înregistrare SPF negăsită” — cauzele reale.

Trebuie să schimb DMARC când schimb furnizorul? De obicei nu înregistrarea în sine — aceasta numește adresa de raportare și politica, nu furnizorul. Dar rezultatele dvs. DMARC depind de SPF și DKIM pe care tocmai le-ați migrat: așteptați-vă la o scădere în rapoarte în timpul tranziției și confirmați că ambele picioare trec înainte de a înăspri politica. Începeți la corectați SPF dacă scanarea arată că piciorul SPF încă eșuează.

Trimiteți proprietarului raportul

Dacă faceți această migrare pentru un client, terminați cu dovezi. Re-rulați scanarea gratuită odată ce îmbinarea este activă și trimiteți raportul clasificat proprietarului afacerii: SPF, DKIM și DMARC trecând la noul furnizor, în limbaj simplu, datat. Acesta este artefactul pe care îl depun pentru reînnoirea asigurării cibernetice și pentru următorul chestionar de securitate al furnizorilor — dovadă că migrarea a lăsat domeniul mai bine autentificat decât a început.

Verificați domeniul → · DKIM eșuează după schimbarea instrumentelor de e-mail → · „Înregistrare SPF negăsită” — cauzele reale → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.