DMARC feiler men SPF og DKIM er OK? Justeringsfiksen (2026)

Publisert 2026-07-08

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

DMARC trenger mer enn en bestått sjekk — domenet som besto SPF eller DKIM må samsvare med Fra-domenet ditt. Det meste av «SPF bestått, DMARC feiler»-e-post besto SPF på leverandørens sprett-domene, ikke ditt. Bare 7.4% av 261,086,232 graderte domener består SPF med justering under en håndhevende DMARC-policy, ifølge Defaults.Exposed-sensus (2026-06-29).

Fiksen er raskere enn forvirringen tilsier. Les Authentication-Results-overskriften for å se hvilket ben — SPF eller DKIM — som består på feil domene; aktiver deretter avsendertjenestens egendefinerte-domene-DKIM-signering (vanligvis noen CNAME-er, og fiksen som overlever videresending), eller sett dens egendefinerte Return-Path slik at SPF bestås på domenet ditt. Ett justert ben er alt DMARC trenger.

Hvordan kan DMARC feile når SPF og DKIM begge er OK?

Fordi DMARC aldri spør «besto SPF?» Det spør: besto SPF eller DKIM for et domene som samsvarer med Fra-adressen mottakeren ser? Den ekstra betingelsen kalles justering, og det er hele poenget med DMARC — uten det kunne hvem som helst bestå SPF på et domene de eier mens de viser ditt i Fra-overskriften.

Hver sjekk autentiserer et annet domene:

Sjekk	Domenet det faktisk evaluerer	Hvor du ser det
SPF	Return-Path (RFC5321.MailFrom, sprett/konvolutt-fra-adressen) — ikke Fra-overskriften	`smtp.mailfrom=` i Authentication-Results
DKIM	Domenet i signaturens `d=`-tagg — hva enn signereren valgte	`header.d=` i Authentication-Results
DMARC	*Fra-overskriftens domene — og det krever at SPFs domene eller* DKIMs `d=` samsvarer med det**	`header.from=` i Authentication-Results

Slik går bitene vanligvis galt: nyhetsbrevplattformen din eller CRM-et sender med en Return-Path som [email protected], SPF sjekkes mot leverandor.com og bestås, DKIM bestås med d=leverandor.com — og DMARC feiler, fordi ingen bestående domene samsvarer med dittselskap.com. Alle sjekker fortalte sannheten; ingen av dem autentiserte deg. Å redigere din egen SPF-post kan ikke fikse dette — den ble aldri konsultert. Det er den samme fellen som dekkes av SPF feiler for SaaS-verktøy.

Sensus viser hvor få avsendere fullfører dette siste steget: 27,640,987 av 261,086,232 graderte domener (10.59%) har en håndhevende DMARC-policy overhodet, og bare 7.4% består SPF med justering under én. Blant de 77.5 millioner domenene hvis SPF ender i softfail (~all), befinner bare 9.2% seg under en håndhevende DMARC-policy; blant hardfail (-all)-publisister er 12,142,351 håndhevet mens 42,514,532 ikke er det. De fleste domener stopper på «SPF består» — som, uten DMARC som handler på det, beskytter nesten ingenting.

Hvordan leser jeg Authentication-Results for å se hvilket ben som er unjustert?

Send deg selv en melding gjennom den sviktende tjenesten, åpne kilden, og finn Authentication-Results-overskriften. Et typisk unjustert resultat ser slik ut:

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

Les det i tre sammenligninger:

SPF-beinet: ender smtp.mailfrom= med domenet ditt? Her er det bounces.espmail.net — unjustert.
DKIM-beinet: ender header.d= med domenet ditt? Her er det espmail.net — unjustert.
DMARC-dommen: header.from= er domenet DMARC forsvarer. Inget ben samsvarte med det, så dmarc=fail — selv om begge individuelle sjekker sier pass.

Hvilket ben som allerede involverer ditt eget domene (eller kan gjøres til det) er det som skal fikses. Du trenger bare ett.

Hva er forskjellen mellom avslappet og streng justering?

DMARC tilbyr to matchende moduser, satt med aspf (SPF) og adkim (DKIM)-taggene i DMARC-posten din:

Avslappet (r, standard): de to domenene må dele det samme organisasjonsdomenet — det registrerbare domenet per Public Suffix List. bounce.dittselskap.com justerer med dittselskap.com; det gjør også et DKIM d=mail.dittselskap.com. Det er grunnen til at leverandørens egendefinerte Return-Path-er og egendefinerte DKIM, som bor på subdomener, fungerer.
Streng (s): domenene må samsvare nøyaktig, tegn for tegn. bounce.dittselskap.com justerer ikke lenger med dittselskap.com.

Hvis posten din ikke nevner aspf eller adkim, er du i avslappet modus — og du vil nesten sikkert bli der. Streng modus legger til ingen meningsfull sikkerhet for de fleste avsendere og bryter stille alle legitime subdomene-avsendere du setter opp. Hvis DMARC feiler og posten din inneholder aspf=s eller adkim=s, kan det alene være feilen.

Hvordan fikser jeg DMARC-justering?

Kjør den gratis skanningen på defaults.exposed før du rører DNS. Den viser DMARC-posten og -policyen din, om SPF og DKIM er satt opp for å justere, og hva annet som er ødelagt — slik at du fikser det riktige beinet først.
Test hver avsendertjeneste og les Authentication-Results (som over). List opp alle kilder — postkasseleverandør, nyhetsbrevverktøy, CRM, faktureringsapp — og noter per kilde om smtp.mailfrom og header.d er domenet ditt eller leverandørens.
Aktiver egendefinert-domene-DKIM-signering for hver leverandør — fiksen som varer. Alle seriøse avsendertjenester tilbyr «domeneautentisering»: noen CNAME-poster som lar den signere som d=dittselskap.com (eller et subdomene, som justerer i avslappet modus). Justert DKIM er vanligvis den enklere fiksen og den eneste som overlever videresending, fordi videresending bryter SPF av design.
For SPF-justering, aktiver leverandørens egendefinerte Return-Path (ofte kalt et egendefinert sprett-domene) — vanligvis én CNAME som bounce.dittselskap.com peker mot leverandøren. SPF bestås da på ditt organisasjonsdomene og justerer. Gjør dette der det tilbys, men behandle det som det andre beinet, ikke en erstatning for justert DKIM.
La justering stå i avslappet modus med mindre du har en spesifikk, forstått grunn for aspf=s/adkim=s.
Skann på nytt og bekreft begge ben, og gå deretter mot håndhevelse. En DMARC-policy på p=none rapporterer men blokkerer ingenting; når de reelle avsenderne justerer, er hele veien til en policy som beskytter deg på siden fiks DMARC, og leverandørgjennomganger som DMARC på IONOS dekker DNS-panel-klikkene.

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

Du trenger ett justert ben per avsenderkilde. Hvis du bare kan gjøre ett, er valget ikke nært:

Fiks	Hva det innebærer	Overlever videresending?
Justert DKIM (egendefinert-domene-signering)	Noen CNAME-er i leverandørens «domeneautentisering»-panel	Ja — signaturen reiser med meldingen
Justert SPF (egendefinert Return-Path/sprett-domene)	Én CNAME, der leverandøren tilbyr det	Nei — enhver forwarders IP erstatter leverandørens

Det spesielle tilfellet som er verdt å kjenne til: Google Workspace og Microsoft 365 vil DKIM-signere e-posten din som standard med sine egne reserve-domener (gappssmtp.com, onmicrosoft.com) — så DKIM viser pass mens DMARC fortsatt feiler. Det er det ene mest vanlige spesifikke tilfellet av hele dette problemet, og det har sin egen veiledning: DKIM består men DMARC feiler fortsatt: standard-signatur-fellen.

Ofte stilte spørsmål

Må begge SPF og DKIM justere for at DMARC skal bestås? Nei — ett justert pass er tilstrekkelig. Best praksis er å justere begge uansett, slik at når videresending bryter SPF-beinet, bærer DKIM-beinet fortsatt DMARC-beståelsen. Av 261,086,232 domener gradert i 2026-06-29-sensus, er det bare 3.87% som fullfører den fulle SPF + DMARC + DKIM-triaden.

ESP-dashbordet sier at SPF og DKIM er «verifisert» — hvorfor feiler DMARC fortsatt? «Verifisert» betyr vanligvis at leverandørens egen sending bestås på leverandørens domener. Med mindre du fullførte trinnene for egendefinert domene (DKIM CNAME-er, egendefinert Return-Path), autentiserer e-post som leverandøren, ikke som deg — og DMARC sammenligner med Fra-domenet ditt.

Er en streng -all SPF-post nok uten justering? Nei. En streng kvalifikator styrker SPFs dom over Return-Path-domenet, men DMARC trenger fortsatt at domenet er ditt. Per 2026-06-29-sensus befinner bare 12,142,351 av domenene som publiserer -all seg under en håndhevende DMARC-policy — de andre 42,514,532 har en streng post som ingen policy handler på.

Bør jeg bytte til streng justering (aspf=s/adkim=s) for mer sikkerhet? Nesten aldri. Avslappet justering krever allerede det samme registrerbare domenet, som en svindler ikke kontrollerer. Streng modus bryter for det meste dine egne subdomene-avsendere — sjekk for det når justering feiler uventet.

DMARC feiler bare på e-post som mottakere videresender — samme fiks? Det er SPF-beinet som dør under transport: forwarderens server er ikke i noen SPF-post for din Return-Path. Du kan ikke fikse SPF for videresendt e-post; justert DKIM er svaret, siden signaturen overlever videresending intakt. Detaljer i videresendt e-post feiler SPF.

Send eieren rapporten

Hvis du fikser dette for en klient eller arbeidsgiveren din, lukk løkken med bevis. Kjør den gratis skanningen etter at CNAME-ene er på plass og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, som viser SPF, DKIM og DMARC justert og bestått. Det er artefakten de vil trenge til fornyelse av cyberforsikring og neste leverandørsikkerhetsspørreskjema — bevis for en fungerende konfigurasjon, ikke bare «jeg la til noen DNS-poster».

Sjekk domenet ditt → · DKIM består men DMARC feiler fortsatt → · Fiks DMARC → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.