Defaults.Exposed › Rettelser › Guides

Videresendt e-mail fejler SPF — Hvorfor du ikke kan løse det, og hvad der faktisk virker (2026)

Udgivet 2026-07-08

Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.

Du kan ikke få SPF til at godkendes for videresendt e-mail — videresendelse ødelægger SPF med vilje, og den ærlige løsning er justeret DKIM, der overlever videresendelse. Omfanget er census-dækkende: 7,355,985 af 138,927,207 SPF-udgivende domæner godkender Namecheaps videresendel-include alene, med en strict-SPF-andel på <0.1%, ifølge Defaults.Exposed-census over 261 millioner domæner.

Nedenfor: hvorfor ingen SPF-post, du kan skrive, overlever videresendelse, hvorfor SRS og ARC ikke er redskaber, du kontrollerer, og løsningen der holder — DKIM-signering med dit eget domæne som dit DMARC-pass — samt det ene tilfælde, der også ødelægger DKIM (mailinglister, der omskriver beskeder), og hvad man gør ved den rest.

Hvorfor ødelægger videresendelse SPF?

Modtagere evaluerer SPF mod Return-Path (RFC5321.MailFrom)-domænet, ikke Fra-headeren. Sender du direkte, er din servers IP i din SPF-post, og kontrollen godkendes. Når din modtager automatisk videresender beskeden — til en personlig Gmail, via et universitetsalias, via en registrators videresendelsesprodukt — retransmitterer videresenderens server den, typisk med dit domæne på Return-Path. Den endelige modtager spørger nu: er denne videresendelsesserver godkendt i din SPF-post?

Det er den ikke, og det vil den aldrig blive: du valgte ikke videresender, du ved ikke, den eksisterer, og den samme besked videresendt via en anden tjeneste i morgen ville fejle fra en anden IP. SPF besvarer ét spørgsmål — “kom dette IP fra en server, som Return-Path-domænet godkendte?” — og for videresendt mail er det sande svar nej. Fejlen er SPF, der fungerer som specificeret, ikke din post, der er forkert.

Census viser, hvor mainstream denne vej er: 7,355,985 domæner godkender Namecheaps e-mailvideresendel-include (spf.efwd.registrar-servers.com) — ét udbyders videresendelsesprodukt, trukket fra de 139 millioner SPF-udgivere — med en strict-SPF-andel på <0.1% og kun 0.2%, der håndhæver DMARC. Den bløde skabelon er ikke skødesløshed: videresendelse er præcis, hvor en strict -all misser, og udbyderen, hvis produkt er videresendelse, leverer derefter. Den fulde qualifier-historie er i vores ~all vs -all-rapport, og udbyder-for-udbyder-billedet i hvilken e-mailudbyder giver den stærkeste SPF.

Kan jeg ikke blot tilføje videresenderens server til min SPF-post?

Nej — og det er hele artiklen:

1. Du kan ikke opremse videresendere. Enhver modtager, overalt, kan videresende din mail via enhver tjeneste. Din SPF-post ville skulle liste servere, du ikke kan kende til på forhånd.
2. At liste dem ville besejre formålet. Store videresendelsestjenester relayer mail for millioner af kunder. Sæt deres IP-intervaller i din post, og enhver besked, en af deres brugere relayer — herunder en spoofers — godkendes med SPF som dig.

Den samme logik udelukker at løsne din qualifier for “at få videresendelse til at virke”: qualifieren er ikke grunden til, at videresendt mail fejler, og når DMARC er i spil, ændrer det mindre, end de fleste vejledninger hævder — se qualifier-dataene. Posten er ikke løftestangen her. Stop med at trykke på den.

Hvad med SRS og ARC — løser de ikke videresendelse?

De adresserer det — men ingen af dem er dit at implementere:

Data og mekanismestatus pr. 2026-06-29.

SRS løser videresenderens SPF-problem, ikke dit: at omskrive Return-Path ændrer, hvis SPF kontrolleres, mens din Fra-header — det domæne DMARC forsvarer — er uberørt. ARC er en tillids beslutning mellem infrastrukturoperatører. Fortæller en vejledning dig at “implementere SRS” som domæneejeren, har den forvekslet dig med videresendelsesudbyderen.

Hvordan overlever min e-mail videresendelse?

Sæt DKIM, justeret med dit domæne, som dit DMARC-pass. En DKIM-signatur er kryptografi båret i beskedheadrerne: den verificeres, uanset hvor beskeden ender op, uanset hvor mange servere der relayede den, så længe det signerede indhold ikke blev ændret. DMARC behøver kun ét justeret pass — SPF eller DKIM — så når videresendelse dræber SPF-benet, holder justeret DKIM beskeden godkendt.

1. Kør den gratis scanning på defaults.exposed inden du rører DNS. Den viser, om du har DKIM overhovedet, om det signerer med dit domæne, og hvor din DMARC befinder sig — så du løser det reelle hul frem for at kæmpe med din SPF-post.
2. Bekræft, at videresendelse faktisk er dit problem. I Authentication-Results-headeren på en berørt besked godkendes direkte mail med SPF, mens den videresendte kopi fejler fra videresendertjenestens IP. Godkendes SPF og DKIM, men DMARC fejler stadig, har du i stedet et justeringsproblem — se DMARC fejler men SPF og DKIM godkendes.
3. Slå DKIM-signering med dit eget domæne til hos alle afsendertjenester — postkasseudbyder først, derefter ESP’er og transaktionelle afsendere. Udbyderstandarder signerer ofte med udbyderens domæne, som ikke justerer; du vil have d=ditdomæne. Start på hvordan man løser DKIM, med klikkestier til Google Workspace og Microsoft 365.
4. Verificer justering, ikke blot en godkendelse. d=-domænet i signaturen skal matche dit Fra-domæne; dkim=pass på et andet domæne gør intet for din DMARC.
5. Lad din SPF-post være. Hold den præcis for din direkte mail — den godkender stadig det meste af din trafik og forbliver dit andet DMARC-ben. Stop blot med at forsøge at lade den dække videresendere.
6. Scan igen og stag DMARC-håndhævelse bevidst — næste afsnit, og p=none til p=reject udrulningsguiden.

Denne kombination — SPF plus håndhævet DMARC, der hviler på justeret DKIM — er videresendelsessikker-mønsteret, og det er sjældent: af de 77.5 millioner domæner, der udgiver ~all, bakker kun 9.2% (7,116,774) det op med en håndhævet DMARC-politik, og blot 3.87% af de 261 millioner graderede domæner (10,092,481) fuldfører den fulde SPF + DKIM + håndhævet-DMARC-triade, per census (2026-06-29).

Hvad med mailinglister, der omskriver beskeder?

Den ene videresendelsessti, som justeret DKIM ikke overlever: mailinglister, der modificerer beskeden — et [listenavn]-emnetag, en afmeldingsfooter, en fjernet vedhæftning. Ændr det signerede indhold, og body-hashen matcher ikke længere, så DKIM fejler også (dkim=fail: body hash did not verify er den fejls egen vejledning). Nu er begge DMARC-ben døde, og kun listen kan afhjælpe det (Fra-omskrivning, ARC-forsegling).

Denne rest er præcis, hvad en trinvis DMARC-håndhævelse er til. At bevæge sig igennem p=quarantine med en pct-rampe, mens du overvåger aggregerede rapporter, viser, hvor meget af din rigtige mail der løber via omskrivende lister inden en p=reject-politik begynder at returnere den. Hop ikke til reject på et domæne, hvis brugere lever på mailinglister; stall ikke på p=none for evigt heller. Den trinvise udrulningsguide gennemgår rampen.

Ofte stillede spørgsmål

Ødelægger videresendelse også DKIM? Simpel videresendelse, nej: signaturen rejser med beskeden og verificeres hos den endelige modtager. DKIM ødelægges kun, når det signerede indhold modificeres under transit — mailinglisternes emnetags og footers er det klassiske tilfælde — hvilket er grunden til, at listeregistret håndteres af DMARC-politikstagning, ikke af noget i DNS.

Bør jeg skifte fra -all til ~all, så videresendelse holder op med at fejle? At ændre qualifieren får ikke videresendere til at godkendes — det er ikke grunden til, at de fejler. Det er sigende, at Namecheaps videresendel-include, 7,355,985 domæner og census’s største dedikerede videresendelsespopulation (2026-06-29), leveres med en strict-SPF-andel på <0.1%: blød SPF er arguabelt den korrekte skabelon for et videresendelsesprodukt. Se ~all vs -all-rapporten for, hvad qualifieren faktisk ændrer.

Hvorfor godkendes min mail med SPF, når den sendes direkte, men fejler, når nogen videresender den? Modtageren kontrollerer, om den seneste transmitterende servers IP er godkendt af Return-Path-domænets SPF-post. Direkte: din server, i din post, pass. Videresendt: videresenderens server, ikke i din post, fail. Din post ændrede sig ikke — det transmitterende IP gjorde.

Kan jeg opsætte SRS for at løse dette? Kun hvis du er videresend eren. SRS kører på den server, der foretager videresendelsen, og selv hvor det kører, tilhører det resulterende SPF-pass videresenderens domæne og justerer ikke med dit Fra — din DMARC har stadig brug for DKIM-benet.

Er SPF formålsløst, hvis videresendelse alligevel ødelægger det? Nej. Det meste mail leveres direkte, hvor SPF fungerer præcis som tiltænkt, og det forbliver et af dine to DMARC-ben. Af de 261,086,232 domæner i census (2026-06-29) udgiver 138,927,207 SPF — hold din præcis via SPF-rettelsessiden, og lad DKIM bære den videresendte rest.

Send ejeren rapporten

Løser du dette for en klient eller din arbejdsgiver, skal du afslutte med dokumentation. Når tilpasset-domæne DKIM er live og DMARC er stadet, kør den gratis scanning igen og videresend den graderede rapport til virksomhedsejeren: dateret, klart sprog, der viser, at domænet forbliver godkendt, selv når dets mail videresendes. Det er artefaktet til fornyelse af cyberforsikring og det næste leverandørspørgeskema — en dokumenteret før-og-efter, ikke “jeg slog noget til”.

Kontrollér dit domæne → · DMARC fejler men SPF og DKIM godkendes → · Ret DKIM → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.