Defaults.Exposed › Åtgärder › Guides

Vidarebefordrad e-post misslyckas med SPF — varför du inte kan fixa det, och vad som faktiskt fungerar (2026)

Publicerad 2026-07-08

Siffror från 2026-06-29 · metodik v7. Aggregerade censusdata över 261 miljoner graderade domäner. Se hur vi graderar.

Du kan inte få SPF att godkännas för vidarebefordrad e-post — vidarebefordring bryter SPF med avsikt, och den ärliga lösningen är anpassad DKIM, som överlever vidarebefordring. Skalan är census-bred: 7,355,985 av 138,927,207 SPF-publicerandade domäner auktoriserar Namecheaps vidarebefordrings-include ensamt, med en strikt-SPF-andel på <0.1%, enligt Defaults.Exposed censusdata för 261 miljoner domäner.

Nedan: varför ingen SPF-post du kan skriva överlever vidarebefordring, varför SRS och ARC inte är verktyg du kontrollerar, och lösningen som håller — DKIM-signering med din egen domän som din DMARC-godkännare — plus det enda fallet som bryter DKIM också (e-postlistor som skriver om meddelanden) och vad du gör med den återstoden.

Varför bryter vidarebefordring SPF?

Mottagare utvärderar SPF mot Return-Path (RFC5321.MailFrom)-domänen, inte From-rubriken. När du skickar direkt finns din servers IP i din SPF-post och kontrollen godkänns. När din mottagare vidarebefordrar meddelandet automatiskt — till en personlig Gmail, via ett universitets alias, via en registrars vidarebefordringsprodukt — retransmitterar vidarebefordrarens server det, vanligtvis med din domän kvar på Return-Path. Den slutliga mottagaren frågar nu: är den här vidarebefordringsservern auktoriserad i din SPF-post?

Det är den inte, och det kommer den aldrig att vara: du valde inte vidarebefordraren, du vet inte att den existerar, och samma meddelande vidarebefordrat via en annan tjänst imorgon skulle misslyckas från en annan IP. SPF besvarar en fråga — “kom den här IP:n från en server som Return-Path-domänen auktoriserade?” — och för vidarebefordrad e-post är det sanna svaret nej. Felet är SPF som fungerar enligt specifikation, inte att din post är fel.

Censuset visar hur vanlig den här vägen är: 7,355,985 domäner auktoriserar Namecheaps e-postvidarebefordrings-include (spf.efwd.registrar-servers.com) — en enda leverantörs vidarebefordringsprodukt, hämtad från de 139 miljoner SPF-publicerarna — med en strikt-SPF-andel på <0.1% och bara 0.2% som tillämpar DMARC. Den mjuka mallen är inte slarv: vidarebefordring är exakt där en strikt -all gör fel, och leverantören vars produkt är vidarebefordring levererar i enlighet med det. Hela kvalificeringshistorien finns i vår ~all vs -all-rapport, och bilden per leverantör i vilken e-postleverantör ger starkast SPF.

Kan jag inte bara lägga till vidarebefordrarens server i min SPF-post?

Nej — och varför det är hela den här artikeln:

1. Du kan inte räkna upp vidarebefordrare. Varje mottagare, varsomhelst, kan vidarebefordra din e-post via vilken tjänst som helst. Din SPF-post skulle behöva lista servrar du inte kan känna till i förväg.
2. Att lista dem skulle besegra syftet. Stora vidarebefordringstjänster vidarebefordrar e-post för miljoner kunder. Lägg deras intervall i din post och varje meddelande som någon av deras användare vidarebefordrar — inklusive en spoofares — godkänns med SPF som du.

Samma logik utesluter att mjuka din kvalificerare för att “få vidarebefordring att fungera”: kvalificeraren är inte varför vidarebefordrad e-post misslyckas, och när DMARC är aktivt ändrar det mindre än de flesta guider påstår — se kvalificeringsdata. Posten är inte hävstången här. Sluta dra i den.

Vad sägs om SRS och ARC — löser de inte vidarebefordring?

De hanterar det — men ingen av dem är din att driftsätta:

Data och mekanismstatus per 2026-06-29.

SRS får vidarebefordrarens SPF-problem att försvinna, inte ditt: att skriva om Return-Path ändrar vars SPF som kontrolleras, medan din From-rubrik — domänen som DMARC försvarar — är orörd. ARC är ett förtroendebeslut mellan infrastrukturoperatörer. Om en guide ber dig att “implementera SRS” som domänägare, har den förväxlat dig med vidarebefordringsleverantören.

Hur gör jag så att min e-post överlever vidarebefordring?

Gör DKIM, anpassat till din domän, till din DMARC-godkännare. En DKIM-signatur är kryptografi som bärs i meddelanderubrikerna: den verifieras varhelst meddelandet hamnar, oavsett hur många servrar som har vidarebefordrat det, så länge det signerade innehållet inte ändrades. DMARC behöver bara ett anpassat godkännande — SPF eller DKIM — så när vidarebefordring dödar SPF-benet håller anpassad DKIM meddelandet autentiserat.

1. Kör den kostnadsfria sökningen på defaults.exposed innan du rör DNS. Den visar om du har DKIM alls, om det signerar med din domän och var din DMARC står — så du åtgärdar det verkliga gapet snarare än att kämpa mot din SPF-post.
2. Bekräfta att vidarebefordring faktiskt är ditt problem. I Authentication-Results-rubriken för ett drabbat meddelande godkänns direktutskickad e-post med SPF medan den vidarebefordrade kopian misslyckas från vidarebefordrandets tjänsts IP. Om SPF och DKIM godkänns men DMARC fortfarande misslyckas, har du ett anpassningsproblem istället — se DMARC misslyckas men SPF och DKIM godkänns.
3. Aktivera DKIM-signering med din egen domän på varje sändande tjänst — postlådeleverantören först, sedan ESPer och transaktions­avsändare. Leverantörsstandarder signerar ofta med leverantörens domän, vilket inte anpassas; du vill ha d=yourdomain. Börja på hur man åtgärdar DKIM, med klickvägar för Google Workspace och Microsoft 365.
4. Verifiera anpassning, inte bara ett godkännande. Domänen d= i signaturen måste matcha din From-domän; dkim=pass på någon annans domän gör ingenting för din DMARC.
5. Lämna din SPF-post ifred. Håll den korrekt för din direkta e-post — den autentiserar fortfarande det mesta av din trafik och förblir ditt andra DMARC-ben. Sluta bara försöka få den att täcka vidarebefordrare.
6. Scanna igen, inled sedan DMARC-tillämpning med avsikt — nästa avsnitt, och guiden för p=none till p=reject-utfasning.

Den här kombinationen — SPF plus tillämpande DMARC baserat på anpassad DKIM — är det vidarebefordringssäkra mönstret, och det är sällsynt: av de 77.5 miljoner domäner som publicerar ~all, backar bara 9.2% (7,116,774) upp det med en tillämpande DMARC-policy, och bara 3.87% av de 261 miljoner graderade domänerna (10,092,481) slutför hela triaden SPF + DKIM + tillämpat-DMARC, per censuset (2026-06-29).

Vad sägs om e-postlistor som skriver om meddelanden?

Den enda vidarebefordringsvägen som anpassad DKIM inte överlever: e-postlistor som modifierar meddelandet — en [listnamn]-ämnestagg, en avregistreringsfot, en bortlagrad bilaga. Ändra det signerade innehållet och body-hashen matchar inte längre, så DKIM misslyckas också (dkim=fail: body hash did not verify är det felets egen guide). Nu är båda DMARC-benen döda, och bara listan kan mildra det (From-omskrivning, ARC-försegling).

Det här restutfallet är exakt vad gradvis DMARC-tillämpning finns för. Att röra sig från p=quarantine med en pct-ökning medan du tittar på aggregerade rapporter visar hur mycket av din verkliga e-post som flödar genom omskrivande listor innan en p=reject-policy börjar studsa dem. Hoppa inte till reject på en domän vars användare lever på e-postlistor; stanna inte vid p=none för evigt heller. Guiden för gradvis utfasning går igenom ökningen.

Vanliga frågor

Bryter vidarebefordring DKIM också? Enkel vidarebefordring, nej: signaturen reser med meddelandet och verifierar hos den slutliga mottagaren. DKIM bryter bara när det signerade innehållet modifieras under transit — e-postlistors ämnestaggar och sidfötter är det klassiska fallet — vilket är varför list-restutfallet hanteras av DMARC-policy-staging, inte av något i DNS.

Ska jag byta från -all till ~all så att vidarebefordring slutar misslyckas? Att ändra kvalificeraren får inte vidarebefordrare att godkännas — det är inte varför de misslyckas. Det är talande att Namecheaps vidarebefordrings-include, 7,355,985 domäner och censusens största dedikerade vidarebefordringspopulation (2026-06-29), levereras med en strikt-SPF-andel på <0.1%: mjuk SPF är förmodligen den korrekta mallen för en vidarebefordringsprodukt. Se ~all vs -all-rapporten för vad kvalificeraren faktiskt ändrar.

Varför godkänns min e-post med SPF när den skickas direkt men misslyckas när någon vidarebefordrar den? Mottagaren kontrollerar om den senast sändande serverns IP är auktoriserad av Return-Path-domänens SPF-post. Direkt: din server, i din post, godkänt. Vidarebefordrad: vidarebefordrarens server, inte i din post, misslyckat. Din post ändrades inte — den sändande IP:n ändrades.

Kan jag konfigurera SRS för att åtgärda detta? Bara om du är vidarebefordraren. SRS körs på den server som gör vidarebefordringen, och även där det körs tillhör det resulterande SPF-godkännandet vidarebefordrarens domän och anpassas inte till din From — din DMARC behöver fortfarande DKIM-benet.

Är SPF meningslöst om vidarebefordring bryter det ändå? Nej. Det mesta av e-post levereras direkt, där SPF fungerar exakt som avsett, och det förblir ett av dina två DMARC-ben. Av de 261,086,232 domänerna i censuset (2026-06-29) publicerar 138,927,207 SPF — håll din korrekt via SPF-fixsidan och låt DKIM bära den vidarebefordrade återstoden.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller din arbetsgivare, avsluta loopen med bevis. När anpassad domän-DKIM är aktiv och DMARC är gradvis inledd, kör den kostnadsfria sökningen och vidarebefordra den graderade rapporten till ägaren: daterad, klarspråk, visar att domänen förblir autentiserad även när dess e-post vidarebefordras. Det är artefakten för förnyelse av cyberförsäkring och nästa leverantörsenkät — en dokumenterad före-och-efter, inte “jag slog på något”.

Kontrollera din domän → · DMARC misslyckas men SPF och DKIM godkänns → · Åtgärda DKIM → · Hur vi graderar → · Enbart aggregerade data. Data lagras och behandlas inom EU.