Defaults.Exposed › Fikser › Guides

Videresendt e-post feiler SPF — hvorfor du ikke kan fikse det, og hva som faktisk virker (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

Du kan ikke få SPF til å bestås for videresendt e-post — videresending bryter SPF ved design, og den ærlige fiksen er justert DKIM, som overlever videresending. Skalaen er sensusomfattende: 7,355,985 av 138,927,207 SPF-publiserende domener autoriserer Namecheaps videresendingsinclude alene, med en streng-SPF-andel på <0.1%, ifølge Defaults.Exposed-sensus over 261 millioner domener.

Nedenfor: hvorfor ingen SPF-post du kan skrive overlever videresending, hvorfor SRS og ARC ikke er verktøy du kontrollerer, og fiksen som holder — DKIM-signering med ditt eget domene som DMARC-passet ditt — pluss det ene tilfellet som bryter DKIM også (e-postlister som omskriver meldinger) og hva du gjør med den resten.

Hvorfor bryter videresending SPF?

Mottakere evaluerer SPF mot Return-Path (RFC5321.MailFrom)-domenet, ikke Fra-overskriften. Når du sender direkte, er serverens IP i SPF-posten din og sjekken bestås. Når mottakeren din automatisk videresender meldingen — til en personlig Gmail, gjennom et universitetsalias, via et registrars videresendingsprodukt — retransmitterer videresenderens server den, vanligvis med domenet ditt på Return-Path. Den endelige mottakeren spør nå: er denne videresendingsserveren autorisert i din SPF-post?

Det er den ikke, og det vil den aldri bli: du valgte ikke videresendere, du vet ikke at de eksisterer, og den samme meldingen videresendt gjennom en annen tjeneste i morgen ville feile fra en annen IP. SPF svarer på ett spørsmål — «kom denne IP-en fra en server Return-Path-domenet autoriserte?» — og for videresendt e-post er det sanne svaret nei. Feilen er SPF som fungerer som spesifisert, ikke posten din som er feil.

Sensus viser hvor vanlig denne stien er: 7,355,985 domener autoriserer Namecheaps e-postvideresendingsinclude (spf.efwd.registrar-servers.com) — én enkelt leverandørs videresendingsprodukt, hentet fra 139 millioner SPF-publisister — med en streng-SPF-andel på <0.1% og bare 0.2% som håndhever DMARC. Den myke malen er ikke uaktsomhet: videresending er nøyaktig der en streng -all misfires, og leverandøren hvis produkt er videresending leverer deretter. Den fulle kvalifikator-historien er i vår ~all vs -all-rapport, og leverandør-for-leverandør-bildet i hvilken e-postleverandør gir den sterkeste SPF.

Kan jeg ikke bare legge til videresenderens server i SPF-posten min?

Nei — og grunnen er hele artikkelen:

1. Du kan ikke telle opp videresendere. En mottaker, hvor som helst, kan videresende e-posten din gjennom enhver tjeneste. SPF-posten din måtte liste servere du ikke kan vite om på forhånd.
2. Å liste dem ville motvirke hensikten. Store videresendingstjenester videreformidler e-post for millioner av kunder. Legg rekkeviddeadressene deres i posten din og alle meldinger brukerne deres videreformidler — inkludert en forfalskers — består SPF som deg.

Den samme logikken utelukker å løsne kvalifikatoren for å «få videresending til å fungere»: kvalifikatoren er ikke grunnen til at videresendt e-post feiler, og når DMARC er i spill endrer det mindre enn de fleste veiledninger hevder — se kvalifikator-dataene. Posten er ikke spaken her. Slutt å trekke i den.

Hva med SRS og ARC — fikser de ikke videresending?

De adresserer det — men ingen av dem er din å distribuere:

Data og mekanismestatus per 2026-06-29.

SRS gjør videresenderens SPF-problem å forsvinne, ikke ditt: å skrive om Return-Path endrer hvems SPF som sjekkes, mens Fra-overskriften din — domenet DMARC forsvarer — er urørt. ARC er en tillitsbeslutning mellom infrastrukturoperatører. Hvis en veiledning forteller deg å «implementere SRS» som domeneeier, har den forvekslet deg med videresendingsleverandøren.

Hvordan får jeg e-posten til å overleve videresending?

Gjør DKIM, justert til domenet ditt, til DMARC-passet ditt. En DKIM-signatur er kryptografi bært i meldingsoverskriftene: den bekrefter der meldingen enn ender opp, uansett hvor mange servere som videreformidlet den, så lenge det signerte innholdet ikke ble endret. DMARC trenger bare ett justert pass — SPF eller DKIM — slik at når videresending dreper SPF-beinet, holder justert DKIM meldingen autentisert.

1. Kjør den gratis skanningen på defaults.exposed før du rører DNS. Den viser om du har DKIM overhodet, om den signerer med ditt domene, og hvor DMARC-en din befinner seg — slik at du fikser det reelle gapet i stedet for å kjempe mot SPF-posten.
2. Bekreft at videresending faktisk er problemet ditt. I Authentication-Results-overskriften til en berørt melding, består direkte e-post SPF mens den videresendte kopien feiler fra videresendingstjenestens IP. Hvis SPF og DKIM bestås men DMARC feiler fortsatt, har du et justeringsproblem i stedet — se DMARC feiler men SPF og DKIM er OK.
3. Slå på DKIM-signering med ditt eget domene hos alle sendetjenester — postkasseleverandøren først, deretter ESP-er og transaksjonsavsendere. Leverandørstandarder signerer ofte med leverandørens domene, som ikke justerer; du vil ha d=dittdomene. Start på hvordan fikse DKIM, med klikk-stier for Google Workspace og Microsoft 365.
4. Bekreft justering, ikke bare bestått. d=-domenet i signaturen må samsvare med Fra-domenet ditt; dkim=pass på noens annens domene gjør ingenting for din DMARC.
5. La SPF-posten din være. Hold den nøyaktig for din direkte e-post — den autentiserer fortsatt mesteparten av trafikken din og er det andre DMARC-beinet ditt. Slutt bare å prøve å la den dekke videresendere.
6. Skann på nytt, og trinnvis DMARC-håndhevelse med omhu — neste avsnitt, og p=none til p=reject utrullingsveiledningen.

Denne kombinasjonen — SPF pluss håndhevende DMARC som hviler på justert DKIM — er det videresendingssikre mønsteret, og det er sjeldent: av de 77.5 millioner domenene som publiserer ~all, bare 9.2% (7,116,774) støtter det med en håndhevende DMARC-policy, og bare 3.87% av de 261 millioner graderte domenene (10,092,481) fullfører den fulle SPF + DKIM + håndhevet-DMARC-triaden, per sensus (2026-06-29).

Hva med e-postlister som omskriver meldinger?

Den ene videresendingsstien justert DKIM ikke overlever: e-postlister som modifiserer meldingen — et [listenavn]-emnemerke, en avmeldingsbunntekst, et fjernet vedlegg. Endre det signerte innholdet og body-hashen samsvarer ikke lenger, slik at DKIM feiler også (dkim=fail: body hash did not verify er den feilens egen veiledning). Nå er begge DMARC-ben døde, og bare listen kan begrense det (Fra-omskriving, ARC-forsegling).

Denne resten er nøyaktig hva trinnvis DMARC-håndhevelse er for. Å bevege seg gjennom p=quarantine med en pct-rampe mens du ser på samlede rapporter viser hvor mye av den reelle e-posten din flyter gjennom omskrivende lister før en p=reject-policy begynner å avvise den. Ikke hopp til reject på et domene hvis brukere lever på e-postlister; ikke stall på p=none for alltid heller. Den trinnvise utrullingsveiledningen gjennomgår rampen.

Ofte stilte spørsmål

Bryter videresending DKIM også? Vanlig videresending, nei: signaturen reiser med meldingen og bekrefter hos den endelige mottakeren. DKIM bryter bare når det signerte innholdet endres under transport — e-postlisteemnemerker og -bunntekster er det klassiske tilfellet — noe som er grunnen til at resten håndteres av DMARC-policy-trinnvis, ikke av noe i DNS.

Bør jeg bytte fra -all til ~all slik at videresending slutter å feile? Å endre kvalifikatoren vil ikke få videresendere til å bestå — det er ikke grunnen til at de feiler. Det er talende at Namecheaps videresendingsinclude, 7,355,985 domener og sensus’ største dedikerte videresendingspopulasjon (2026-06-29), leveres med en streng-SPF-andel på <0.1%: myk SPF er sannsynligvis den korrekte malen for et videresendingsprodukt. Se ~all vs -all-rapporten for hva kvalifikatoren faktisk endrer.

Hvorfor består e-posten min SPF når den sendes direkte men feiler når noen videresender den? Mottakeren sjekker om den sist transmitterende serverens IP er autorisert av Return-Path-domenets SPF-post. Direkte: serveren din, i posten din, bestått. Videresendt: videresenderens server, ikke i posten din, feil. Posten din endret seg ikke — den transmitterende IP-en gjorde det.

Kan jeg sette opp SRS for å fikse dette? Bare hvis du er videresendere. SRS kjører på serveren som videresender, og selv der den kjører, tilhører det resulterende SPF-passet videresenderens domene og justerer ikke med Fra-en din — DMARC-en din trenger fortsatt DKIM-beinet.

Er SPF meningsløst hvis videresending bryter det uansett? Nei. De fleste e-poster leveres direkte, der SPF fungerer nøyaktig som tiltenkt, og det er fortsatt ett av to DMARC-ben. Av de 261,086,232 domenene i sensus (2026-06-29), publiserer 138,927,207 SPF — hold din nøyaktig via SPF-fiks-siden, og la DKIM bære den videresendte resten.

Send eieren rapporten

Hvis du fikser dette for en klient eller arbeidsgiveren din, lukk løkken med bevis. Når egendefinert-domene-DKIM er live og DMARC er trinnvis, kjør den gratis skanningen på nytt og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, som viser at domenet forblir autentisert selv når e-posten videresendes. Det er artefakten for fornyelse av cyberforsikring og neste leverandørspørreskjema — en dokumentert før-og-etter, ikke «Jeg skrudde på noe».

Sjekk domenet ditt → · DMARC feiler men SPF og DKIM er OK → · Fiks DKIM → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.