DMARC fejler, men SPF og DKIM godkendes? Justeringsrettelsen (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.

DMARC behøver mere end en godkendelse — det domæne, der godkendte SPF eller DKIM, skal matche dit Fra-domæne. Det meste “SPF pass, DMARC fail”-mail godkendte SPF på leverandørens bounce-domæne, ikke dit. Kun 7.4% af 261,086,232 graderede domæner godkendes med SPF og justering under en håndhævet DMARC-politik, ifølge Defaults.Exposed-census (2026-06-29).

Rettelsen er hurtigere end forvirringen antyder. Læs Authentication-Results-headeren for at se, hvilket ben — SPF eller DKIM — der godkendes på det forkerte domæne; aktivér derefter enten din afsendertjenestes DKIM-signering med dit eget domæne (typisk et par CNAMEs, og rettelsen der overlever videresendelse), eller konfigurér dens tilpassede return-path, så SPF godkendes på dit domæne. Ét justeret ben er alt, DMARC behøver.

Hvordan kan DMARC fejle, når SPF og DKIM begge godkendes?

Fordi DMARC aldrig spørger “godkendte SPF?” Det spørger: godkendte SPF eller DKIM for et domæne, der matcher den Fra-adresse, din modtager ser? Den ekstra betingelse hedder justering, og det er hele pointen med DMARC — uden det kunne enhver bestå SPF på et domæne, de ejer, mens de viser dit i Fra-headeren.

Hver kontrol godkender et andet domæne:

Kontrol	Domæne den faktisk evaluerer	Hvor du ser det
SPF	Return-Path (RFC5321.MailFrom, bounce/konvolut-fra-adressen) — ikke Fra-headeren	`smtp.mailfrom=` i Authentication-Results
DKIM	Domænet i signaturens `d=`-tag — hvad end signatoren valgte	`header.d=` i Authentication-Results
DMARC	*Dit Fra-header-domæne — og det kræver, at SPFs domæne eller* DKIMs `d=` matcher det**	`header.from=` i Authentication-Results

Sådan går det typisk galt: din nyhedsbrevplatform eller dit CRM sender med en Return-Path som [email protected]ør.com, SPF kontrolleres mod leverandør.com og godkendes, DKIM godkendes med d=leverandør.com — og DMARC fejler, fordi intet af de to godkendte domæner matcher ditfirma.com. Alle kontroller fortalte sandheden; ingen af dem godkendte dig. At redigere din egen SPF-post kan ikke løse dette — den blev aldrig konsulteret. Det er den samme fælde dækket i SPF fejler for dine SaaS-værktøjer.

Census viser, hvor få afsendere gennemfører dette sidste trin: 27,640,987 af 261,086,232 graderede domæner (10.59%) har en håndhævet DMARC-politik overhovedet, og kun 7.4% godkendes med SPF og justering under én. Blandt de 77.5 millioner domæner, hvis SPF slutter i softfail (~all), befinder blot 9.2% sig under en håndhævet DMARC-politik; blandt hardfail (-all)-udgivere er 12,142,351 håndhævet, mens 42,514,532 ikke er. De fleste domæner stopper ved “SPF godkendes” — hvilket, uden DMARC der handler på det, beskytter næsten ingenting.

Hvordan læser jeg Authentication-Results for at se, hvilket ben er ude af justering?

Send dig selv en besked via den fejlende tjeneste, åbn råkilden, og find Authentication-Results-headeren. Et typisk ujusteret resultat ser sådan ud:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.espmail.net;
       dkim=pass header.d=espmail.net;
       dmarc=fail (p=NONE) header.from=ditfirma.com

Læs det i tre sammenligninger:

SPF-ben: slutter smtp.mailfrom= på dit domæne? Her er det bounces.espmail.net — ude af justering.
DKIM-ben: slutter header.d= på dit domæne? Her er det espmail.net — ude af justering.
DMARC-dom: header.from= er det domæne, DMARC forsvarer. Ingen af benene matchede det, så dmarc=fail — selv om begge individuelle kontroller siger pass.

Det ben, der allerede involverer dit eget domæne (eller kan bringes til det), er det, du skal rette. Du behøver kun ét.

Hvad er forskellen mellem relaxed- og strict-justering?

DMARC tilbyder to matchetilstande, sat med aspf (SPF)- og adkim (DKIM)-tagsene i din DMARC-post:

Relaxed (r, standard): de to domæner skal dele det samme organisationsdomæne — det registrerbare domæne per Public Suffix List. bounce.ditfirma.com justerer med ditfirma.com; det gør et DKIM d=mail.ditfirma.com også. Det er grunden til, at leverandørers tilpassede return-paths og tilpassede DKIM, der bor på underdomæner, fungerer.
Strict (s): domænerne skal matche præcist, tegn for tegn. bounce.ditfirma.com justerer ikke længere med ditfirma.com.

Nævner din post ikke aspf eller adkim, er du i relaxed-tilstand — og du vil næsten helt sikkert forblive der. Strict-tilstand tilføjer ingen meningsfuld sikkerhed for de fleste afsendere og bryder lydløst alle legitime underdomæne-afsendere, du har sat op. Fejler DMARC, og din post indeholder aspf=s eller adkim=s, kan det alene være fejlen.

Hvordan løser jeg DMARC-justering?

Kør den gratis scanning på defaults.exposed inden du rører DNS. Den viser din DMARC-post og -politik, om din SPF og DKIM er sat op til at justere, og hvad der ellers er brudt — så du retter det rette ben først.
Test hver afsendertjeneste og læs dens Authentication-Results (som ovenfor). List alle kilder — postkasseudbyder, nyhedsbrevværktøj, CRM, faktureringsprogram — og notér per kilde, om smtp.mailfrom og header.d er dit domæne eller leverandørens.
Aktivér DKIM-signering med dit eget domæne for hver leverandør — rettelsen der holder. Alle seriøse afsendertjenester tilbyder “domænegodkendelse”: et par CNAME-poster, der lader dem signere som d=ditfirma.com (eller et underdomæne, der justerer i relaxed-tilstand). Justeret DKIM er typisk den nemmere rettelse og den eneste, der overlever videresendelse, fordi videresendelse ødelægger SPF med vilje.
For SPF-justering, aktivér leverandørens tilpassede return-path (ofte kaldet et tilpasset bounce-domæne) — typisk ét CNAME som bounce.ditfirma.com, der peger på leverandøren. SPF godkendes derefter på dit organisationsdomæne og justerer. Gør dette, hvor det tilbydes, men behandl det som det andet ben, ikke som en erstatning for justeret DKIM.
Lad justering forblive i relaxed-tilstand, medmindre du har en specifik, forstået grund til aspf=s/adkim=s.
Scan igen og bekræft begge ben, og bevæg dig derefter mod håndhævelse. En DMARC-politik på p=none rapporterer men blokerer ingenting; når dine rigtige afsendere justerer, er den fulde vej til en politik, der beskytter dig, på siden ret DMARC, og udbydervejledninger som DMARC på IONOS dækker DNS-panel-klikkene.

Bør jeg rette SPF-justering eller DKIM-justering?

Du behøver ét justeret ben per afsenderkilde. Kan du kun gøre ét, er valget ikke svært:

Rettelse	Hvad det kræver	Overlever videresendelse?
Justeret DKIM (signering med eget domæne)	Et par CNAMEs i leverandørens “domænegodkendelses”-panel	Ja — signaturen rejser med beskeden
Justeret SPF (tilpasset return-path/bounce-domæne)	Ét CNAME, hvor leverandøren tilbyder det	Nej — enhver videresendelses-IP erstatter leverandørens

Det særlige tilfælde, der er værd at kende: Google Workspace og Microsoft 365 vil DKIM-signere din mail som standard med deres egne fallback-domæner (gappssmtp.com, onmicrosoft.com) — så DKIM viser pass, mens DMARC stadig fejler. Det er det enkelt mest almindelige specifikke eksempel på hele dette problem, og det har sin egen vejledning: DKIM godkendes, men DMARC fejler stadig: standardsignatur-fælden.

Ofte stillede spørgsmål

Skal SPF og DKIM begge justere for at DMARC skal godkendes? Nej — ét justeret pass er tilstrækkeligt. Bedste praksis er at justere begge alligevel, så når videresendelse ødelægger SPF-benet, bærer DKIM-benet stadig DMARC-godkendelsen. Af 261,086,232 domæner graderet i 2026-06-29-census er det kun 3.87%, der fuldfører den fulde SPF + DMARC + DKIM-triade.

Min ESP-dashboard siger SPF og DKIM er “verificeret” — hvorfor fejler DMARC stadig? “Verificeret” betyder typisk, at leverandørens eget send godkendes på leverandørens domæner. Medmindre du afsluttede deres tilpassede domæne-trin (DKIM-CNAMEs, tilpasset return-path), godkender mail som leverandøren, ikke som dig — og DMARC sammenligner mod dit Fra-domæne.

Er en strict -all SPF-post nok uden justering? Nej. En strict qualifier styrker SPFs dom på Return-Path-domænet, men DMARC har stadig brug for, at det domæne er dit. Pr. 2026-06-29-census befinder kun 12,142,351 af de domæner, der udgiver -all, sig under en håndhævet DMARC-politik — de andre 42,514,532 har en strict post, som ingen politik handler på.

Bør jeg skifte til strict-justering (aspf=s/adkim=s) for mere sikkerhed? Næsten aldrig. Relaxed-justering kræver allerede det samme registrerbare domæne, som en spoofer ikke kontrollerer. Strict-tilstand ødelægger for det meste dine egne underdomæne-afsendere — kontrollér for det, når justering fejler uventet.

DMARC fejler kun på mail, som modtagere videresender — samme løsning? Det er SPF-benet, der dør under transit: videresenderens server er ikke i nogens SPF-post for dit return-path. Du kan ikke rette SPF for videresendt mail; justeret DKIM er svaret, da signaturen overlever videresendelse intakt. Detaljer i videresendt e-mail fejler SPF.

Send ejeren rapporten

Løser du dette for en klient eller din arbejdsgiver, skal du afslutte med dokumentation. Kør den gratis scanning igen, efter CNAMEsene er live, og videresend den graderede rapport til virksomhedsejeren: dateret, klart sprog, der viser SPF, DKIM og DMARC justerede og godkendt. Det er artefaktet, de har brug for til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — bevis for en fungerende konfiguration, ikke bare “jeg tilføjede nogle DNS-poster”.

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