E-mailul redirecționat eșuează SPF — De ce nu îl puteți repara și ce funcționează cu adevărat (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.

Nu puteți face SPF să treacă pentru e-mailul redirecționat — redirecționarea strică SPF prin design, iar remedierea onestă este DKIM aliniat, care supraviețuiește redirecționării. Amploarea este la nivel de recensământ: 7,355,985 din 138,927,207 domenii care publică SPF autorizează include-ul de redirecționare Namecheap singur, cu o cotă SPF-strict de <0.1%, conform recensământului Defaults.Exposed pe 261 milioane de domenii.

Mai jos: de ce nicio înregistrare SPF pe care ați putea-o scrie nu supraviețuiește redirecționării, de ce SRS și ARC nu sunt instrumente pe care le controlați și remedierea care rezistă — semnarea DKIM cu domeniul dvs. ca pass DMARC — plus singurul caz care strică și DKIM (listele de corespondență care rescriu mesajele) și ce să faceți cu acel reziduu.

De ce strică redirecționarea SPF?

Receptorii evaluează SPF față de domeniul Return-Path (RFC5321.MailFrom), nu antetul From. Când trimiteți direct, IP-ul serverului dvs. este în înregistrarea SPF și verificarea trece. Când destinatarul dvs. redirecționează automat mesajul mai departe — la un Gmail personal, prin un alias universitar, prin produsul de redirecționare al registrarului — serverul redirecționatorului îl retransmite, de obicei menținând domeniul dvs. pe Return-Path. Receptorul final întreabă acum: este acest server de redirecționare autorizat în înregistrarea dvs. SPF?

Nu este, și niciodată nu va fi: nu ați ales redirecționatorul, nu știți că există, și același mesaj redirecționat prin un serviciu diferit mâine ar eșua de la un alt IP. SPF răspunde la o singură întrebare — „a venit acest IP de la un server autorizat de domeniul Return-Path?” — și pentru e-mailul redirecționat răspunsul adevărat este nu. Eșecul înseamnă că SPF funcționează conform specificațiilor, nu că înregistrarea dvs. este greșită.

Recensământul arată cât de mainstream este această cale: 7,355,985 domenii autorizează include-ul de redirecționare Namecheap (spf.efwd.registrar-servers.com) — produsul de redirecționare al unui singur furnizor, extras din cei 139 milioane de publicatori SPF — cu o cotă SPF-strict de <0.1% și doar 0.2% aplicând DMARC. Acel șablon soft nu este neglijență: redirecționarea este exact locul unde un -all strict se întoarce greșit, iar furnizorul al cărui produs este redirecționarea livrează în consecință. Întreaga poveste despre calificatori este în raportul nostru ~all vs -all, și imaginea furnizor cu furnizor în care furnizor de e-mail oferă cel mai puternic SPF.

Nu pot adăuga pur și simplu serverul redirecționatorului la înregistrarea SPF?

Nu — și motivul pentru care nu este tot articolul:

Nu puteți enumera redirecționatorii. Orice destinatar, oriunde, poate redirecționa e-mailul dvs. prin orice serviciu. Înregistrarea SPF ar trebui să listeze servere pe care nu le puteți cunoaște în avans.
Listarea lor ar anula scopul. Serviciile mari de redirecționare redirecționează e-mailuri pentru milioane de clienți. Puneți intervalele lor în înregistrarea dvs. și fiecare mesaj pe care îl redirecționează oricare dintre utilizatorii lor — inclusiv cel al unui falsificator — trece SPF ca dvs.

Aceeași logică exclude relaxarea calificatorului pentru a „face redirecționarea să funcționeze”: calificatorul nu este motivul pentru care e-mailul redirecționat eșuează, și odată ce DMARC este în joc, schimbă mai puțin decât pretind cele mai multe ghiduri — consultați datele despre calificatori. Înregistrarea nu este pârghia aici. Opriți-vă să o trageți.

Ce este cu SRS și ARC — nu rezolvă redirecționarea?

Îi abordează — dar niciuna nu este a dvs. să o implementați:

Mecanism	Ce face când e-mailul este redirecționat	Cine îl controlează	Rezolvă DMARC-ul dvs.?
SPF	Eșuează: IP-ul redirecționatorului nu este în înregistrarea dvs.	Dvs. îl publicați; redirecționarea îl înfrânge	Nu
SRS (Sender Rewriting Scheme)	Redirecționatorul rescrie Return-Path-ul la propriul domeniu, astfel încât retransmiterea sa trece SPF	Redirecționatorul	Nu — pass-ul SPF aparține acum domeniului redirecționatorului, care nu se aliniază cu From-ul dvs.
ARC (RFC 8617)	Redirecționatorul sigilează rezultatele originale de autentificare; receptorul final poate să aibă încredere în lanțul sigilat	Redirecționatorul și receptorul	Uneori — la discreția receptorului, nu a dvs.
DKIM aliniat	Semnătura călătorește în interiorul mesajului și se verifică în continuare după redirecționare, cu domeniul dvs. pe ea	Dvs.	Da

Date și starea mecanismului din 2026-06-29.

SRS face ca problema SPF a redirecționatorului să dispară, nu a dvs.: rescrierea Return-Path-ului schimbă al cui SPF este verificat, în timp ce antetul From — domeniul pe care îl apără DMARC — rămâne neatins. ARC este o decizie de încredere între operatorii de infrastructură. Dacă un ghid vă spune să „implementați SRS” ca proprietar de domeniu, v-a confundat cu furnizorul de redirecționare.

Cum fac e-mailul să supraviețuiască redirecționării?

Faceți DKIM, aliniat la domeniul dvs., să fie pass-ul DMARC. O semnătură DKIM este criptografie purtată în antetele mesajului: se verifică oriunde ajunge mesajul, prin câte servere l-au relayat, atât timp cât conținutul semnat nu a fost modificat. DMARC are nevoie doar de un pass aliniat — SPF sau DKIM — deci când redirecționarea distruge piciorul SPF, DKIM aliniat păstrează mesajul autentificat.

Rulați scanarea gratuită la defaults.exposed înainte de a atinge DNS-ul. Arată dacă aveți DKIM deloc, dacă semnează cu domeniul dvs. și unde se situează DMARC — astfel reparați golul real în loc să luptați cu înregistrarea SPF.
Confirmați că redirecționarea este cu adevărat problema. În antetul Authentication-Results al unui mesaj afectat, e-mailul direct trece SPF în timp ce copia redirecționată eșuează de la IP-ul serviciului de redirecționare. Dacă SPF și DKIM trec, dar DMARC eșuează totuși, aveți în schimb o problemă de aliniere — consultați DMARC eșuează dar SPF și DKIM trec.
Activați semnarea DKIM cu propriul domeniu la fiecare serviciu de trimitere — mai întâi furnizorul de căsuțe poștale, apoi ESP-urile și expeditorii tranzacționali. Valorile implicite ale furnizorilor semnează deseori cu domeniul furnizorului, care nu se aliniază; doriți d=yourdomain. Începeți la cum să corectați DKIM, cu căi de click pentru Google Workspace și Microsoft 365.
Verificați alinierea, nu doar un pass. Domeniul d= din semnătură trebuie să se potrivească cu domeniul From; dkim=pass pe domeniul altcuiva nu face nimic pentru DMARC-ul dvs.
Lăsați înregistrarea SPF în pace. Păstrați-o exactă pentru e-mailul direct — autentifică în continuare cel mai mult din traficul dvs. și rămâne al doilea picior DMARC. Doar opriți-vă să încercați să o faceți să acopere redirecționătorii.
Re-scanați, apoi etapizați aplicarea DMARC deliberat — secțiunea următoare și ghidul de implementare de la p=none la p=reject.

Această combinație — SPF plus DMARC aplicat bazat pe DKIM aliniat — este tiparul rezistent la redirecționare, și este rar: dintre cele 77.5 milioane de domenii care publică ~all, doar 9.2% (7,116,774) îl susțin cu o politică DMARC aplicată, și doar 3.87% din cele 261 milioane de domenii clasificate (10,092,481) completează triada completă SPF + DKIM + DMARC aplicat, conform recensământului (2026-06-29).

Ce este cu listele de corespondență care rescriu mesajele?

Singura cale de redirecționare pe care DKIM aliniat nu o supraviețuiește: listele de corespondență care modifică mesajul — un tag de subiect [list-name], un subsol de dezabonare, un atașament eliminat. Schimbați conținutul semnat și hash-ul corpului nu mai corespunde, deci DKIM eșuează și el (dkim=fail: body hash did not verify este ghidul propriu al acelui eșec). Acum ambele picioare DMARC sunt moarte, și numai lista poate atenua (rescrierea From, sigilarea ARC).

Acest reziduu este exact pentru ce există aplicarea DMARC etapizată. Trecerea prin p=quarantine cu o rampă pct în timp ce urmăriți rapoartele agregate arată cât din e-mailul dvs. real curge prin liste de rescrierea înainte ca o politică p=reject să înceapă să îl respingă. Nu săriți la reject pe un domeniu ai cărui utilizatori trăiesc pe liste de corespondență; nu stagnați la p=none pentru totdeauna. Ghidul de implementare etapizată parcurge rampa.

Întrebări frecvente

Strică redirecționarea și DKIM? Redirecționarea simplă, nu: semnătura călătorește cu mesajul și se verifică la receptorul final. DKIM se strică numai când conținutul semnat este modificat în tranzit — taguri de subiect ale listelor de corespondență și subsoluri fiind cazul clasic — ceea ce este motivul pentru care reziduul listei este gestionat prin etapizarea politicii DMARC, nu prin nimic din DNS.

Ar trebui să trec de la -all la ~all pentru ca redirecționarea să nu mai eșueze? Schimbarea calificatorului nu va face redirecționatorii să treacă — nu este motivul pentru care eșuează. Este relevant că include-ul de redirecționare Namecheap, 7,355,985 domenii și cea mai mare populație dedicată redirecționării din recensământ (2026-06-29), vine cu o cotă SPF-strict de <0.1%: SPF soft este posibil șablonul corect pentru un produs de redirecționare. Consultați raportul ~all vs -all pentru ceea ce schimbă de fapt calificatorul.

De ce trece e-mailul meu SPF când este trimis direct, dar eșuează când cineva îl redirecționează? Receptorul verifică dacă IP-ul ultimului server de transmitere este autorizat de înregistrarea SPF a domeniului Return-Path. Direct: serverul dvs., în înregistrarea dvs., pass. Redirecționat: serverul redirecționatorului, nu în înregistrarea dvs., fail. Înregistrarea dvs. nu s-a schimbat — IP-ul de transmitere s-a schimbat.

Pot configura SRS pentru a remedia asta? Numai dacă sunteți redirecționatorul. SRS rulează pe serverul care face redirecționarea, și chiar și acolo unde rulează, pass-ul SPF rezultat aparține domeniului redirecționatorului și nu se aliniază cu From-ul dvs. — DMARC-ul dvs. are în continuare nevoie de piciorul DKIM.

Este SPF fără rost dacă redirecționarea îl strică oricum? Nu. Cel mai mult e-mail este livrat direct, unde SPF funcționează exact conform intențiilor, și rămâne unul din cele două picioare DMARC. Dintre cele 261,086,232 domenii din recensământ (2026-06-29), 138,927,207 publică SPF — păstrați-l exact prin pagina de corecții SPF și lăsați DKIM să gestioneze reziduul redirecționat.

Trimiteți proprietarului raportul

Dacă reparați asta pentru un client sau angajatorul dvs., încheiați cu dovezi. Odată ce DKIM cu domeniu personalizat este activ și DMARC este etapizat, re-rulați scanarea gratuită și trimiteți raportul clasificat proprietarului afacerii: datat, limbaj simplu, arătând că domeniul rămâne autentificat chiar și când e-mailul este redirecționat. Acesta este artefactul pentru reînnoirea asigurării cibernetice și pentru următorul chestionar al furnizorilor — un înainte-și-după documentat, nu „am activat ceva”.

Verificați domeniul → · DMARC eșuează dar SPF și DKIM trec → · Corectați DKIM → · Cum clasificăm → · Doar date agregate. Date stocate și procesate în UE.