DMARC misslyckas men SPF och DKIM godkänns? Anpassningsfixen (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.

DMARC behöver mer än ett godkännande — domänen som godkändes med SPF eller DKIM måste matcha din From-domän. De flesta “SPF godkänt, DMARC misslyckas”-e-poster godkändes med SPF på leverantörens studsdomän, inte din. Bara 7.4% av 261,086,232 graderade domäner godkänns med SPF med anpassning under en tillämpad DMARC-policy, enligt Defaults.Exposed-censuset (2026-06-29).

Fixen är snabbare än förvirringen antyder. Läs Authentication-Results-rubriken för att se vilket ben — SPF eller DKIM — som godkänns på fel domän; aktivera sedan din sändande tjänsts anpassade domän-DKIM-signering (vanligtvis några CNAMEs, och fixen som överlever vidarebefordring), eller sätt dess anpassade return-path så att SPF godkänns på din domän. Ett anpassat ben är allt DMARC behöver.

Hur kan DMARC misslyckas när SPF och DKIM båda godkänns?

Eftersom DMARC aldrig frågar “godkändes SPF?” Det frågar: godkändes SPF eller DKIM för en domän som matchar From-adressen din mottagare ser? Det extra villkoret kallas anpassning, och det är hela poängen med DMARC — utan det kunde vem som helst godkännas med SPF på en domän de äger medan de visar din i From-rubriken.

Varje kontroll autentiserar en annan domän:

Kontroll	Domän den faktiskt utvärderar	Var man ser den
SPF	Return-Path (RFC5321.MailFrom, studs-/kuvertsändaradressen) — inte From-rubriken	`smtp.mailfrom=` i Authentication-Results
DKIM	Domänen i signaturens `d=`-tag — vad undertecknaren än valde	`header.d=` i Authentication-Results
DMARC	*Din From-rubrik-domän — och den kräver att SPF:s domän eller* DKIM:s `d=` matchar den**	`header.from=` i Authentication-Results

Så här brukar delarna gå fel: din nyhetsbrevplattform eller CRM skickar med en Return-Path som [email protected], SPF kontrolleras mot vendor.com och godkänns, DKIM godkänns med d=vendor.com — och DMARC misslyckas, eftersom ingen godkänd domän matchar yourcompany.com. Varje kontroll talade sanning; ingen av dem autentiserade dig. Att redigera din egen SPF-post kan inte åtgärda detta — den rådfrågades aldrig. Det är samma fälla som täcks i SPF misslyckas för dina SaaS-verktyg.

Censuset visar hur få avsändare slutför detta sista steg: 27,640,987 av 261,086,232 graderade domäner (10.59%) har en tillämpad DMARC-policy överhuvudtaget, och bara 7.4% godkänns med SPF med anpassning under en sådan. Bland de 77.5 miljoner domäner vars SPF slutar med softfail (~all) sitter bara 9.2% under en tillämpad DMARC-policy; bland hardfail (-all)-publicerare är 12,142,351 tillämpade medan 42,514,532 inte är det. De flesta domäner stannar vid “SPF godkänns” — vilket, utan DMARC som agerar på det, skyddar nästan ingenting.

Hur läser jag Authentication-Results för att se vilket ben som inte är anpassat?

Skicka dig själv ett meddelande via den misslyckade tjänsten, öppna råkällan och hitta Authentication-Results-rubriken. Ett typiskt oanpassat resultat ser ut så här:

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

Läs det i tre jämförelser:

SPF-ben: slutar smtp.mailfrom= med din domän? Här är det bounces.espmail.net — oanpassat.
DKIM-ben: slutar header.d= med din domän? Här är det espmail.net — oanpassat.
DMARC-dom: header.from= är den domän DMARC försvarar. Inget ben matchade den, så dmarc=fail — även om båda individuella kontrollerna säger pass.

Det ben som redan involverar din domän (eller kan göras att involvera) är det att åtgärda. Du behöver bara ett.

Vad är skillnaden mellan avslappnad och strikt anpassning?

DMARC erbjuder två matchningslägen, inställda med aspf (SPF) och adkim (DKIM)-taggarna i din DMARC-post:

Avslappnad (r, standardläget): de två domänerna måste dela samma organisationsdomän — den registrerbara domänen per Public Suffix List. bounce.yourcompany.com anpassas till yourcompany.com; det gör även ett DKIM d=mail.yourcompany.com. Det är därför anpassade return-paths och anpassad DKIM för leverantörer, som lever på underdomäner, fungerar.
Strikt (s): domänerna måste matcha exakt, tecken för tecken. bounce.yourcompany.com anpassas inte längre till yourcompany.com.

Om din post inte nämner aspf eller adkim är du i avslappnat läge — och du vill nästan säkert stanna där. Strikt läge lägger till ingen meningsfull säkerhet för de flesta avsändare och bryter tyst varje legitim underdomänavsändare du har konfigurerat. Om DMARC misslyckas och din post innehåller aspf=s eller adkim=s kan det ensamt vara felet.

Hur åtgärdar jag DMARC-anpassning?

Kör den kostnadsfria sökningen på defaults.exposed innan du rör DNS. Den visar din DMARC-post och policy, om dina SPF och DKIM är konfigurerade att anpassa sig, och vad annat som är trasigt — så du åtgärdar rätt ben först.
Testa varje sändande tjänst och läs dess Authentication-Results (som ovan). Lista varje källa — postlådeleverantör, nyhetsbrevverktyg, CRM, faktureringsapp — och notera per källa om smtp.mailfrom och header.d är din domän eller leverantörens.
Aktivera anpassad domän-DKIM-signering för varje leverantör — fixen som håller. Varje seriös sändande tjänst erbjuder “domänautentisering”: några CNAME-poster som låter den signera som d=yourcompany.com (eller en underdomän, som anpassas i avslappnat läge). Anpassad DKIM är vanligtvis den enklare fixen och den enda som överlever vidarebefordring, eftersom vidarebefordring bryter SPF med avsikt.
För SPF-anpassning, aktivera leverantörens anpassade return-path (kallas ofta anpassad studsdomän) — vanligtvis en CNAME som bounce.yourcompany.com som pekar på leverantören. SPF godkänns sedan på din organisationsdomän och anpassas. Gör detta där det erbjuds, men behandla det som det andra benet, inte ett substitut för anpassad DKIM.
Lämna anpassning i avslappnat läge om du inte har en specifik, förstådd anledning till aspf=s/adkim=s.
Scanna igen och bekräfta båda benen, gå sedan mot tillämpning. En DMARC-policy på p=none rapporterar men blockerar ingenting; när dina riktiga avsändare anpassas finns hela vägen till en policy som skyddar dig på sidan åtgärda DMARC, och leverantörsgenomgångar som DMARC på IONOS täcker DNS-panelens klick.

Ska jag åtgärda SPF-anpassning eller DKIM-anpassning?

Du behöver ett anpassat ben per sändande källa. Om du bara kan göra ett är valet inte svårt:

Fix	Vad det innebär	Överlever vidarebefordring?
Anpassad DKIM (anpassad domänsignering)	Några CNAMEs i leverantörens “domänautentisering”-panel	Ja — signaturen reser med meddelandet
Anpassad SPF (anpassad return-path/studsdomän)	En CNAME, där leverantören erbjuder det	Nej — vilken vidarebefordrares IP som helst ersätter leverantörens

Det speciella fallet värt att känna till: Google Workspace och Microsoft 365 DKIM-signerar din e-post som standard med deras egna reservdomäner (gappssmtp.com, onmicrosoft.com) — så DKIM visar pass medan DMARC fortfarande misslyckas. Det är den enskilt vanligaste specifika förekomsten av hela det här problemet, och den har sin egen guide: DKIM godkänns men DMARC misslyckas fortfarande: standardsignatursfällan.

Vanliga frågor

Behöver båda SPF och DKIM anpassa sig för att DMARC ska godkännas? Nej — ett anpassat godkännande är tillräckligt. Bästa praxis är att anpassa båda ändå, så att när vidarebefordring bryter SPF-benet bär DKIM-benet fortfarande DMARC-godkännandet. Av 261,086,232 domäner graderade i 2026-06-29-censuset slutför bara 3.87% den fullständiga SPF + DMARC + DKIM-triaden.

Min ESP-instrumentpanel säger att SPF och DKIM är “verifierade” — varför misslyckas DMARC fortfarande? “Verifierade” betyder vanligtvis att leverantörens egna utskick godkänns på leverantörens domäner. Om du inte slutförde deras anpassade domän-steg (DKIM-CNAMEs, anpassad return-path) autentiseras e-post som leverantören, inte som du — och DMARC jämför mot din From-domän.

Räcker en strikt -all SPF-post utan anpassning? Nej. En strikt kvalificerare stärker SPF:s dom på Return-Path-domänen, men DMARC behöver fortfarande att domänen är din. Per 2026-06-29-censuset sitter bara 12,142,351 av de domäner som publicerar -all under en tillämpad DMARC-policy — de andra 42,514,532 har en strikt post som ingen policy agerar på.

Ska jag byta till strikt anpassning (aspf=s/adkim=s) för mer säkerhet? Nästan aldrig. Avslappnad anpassning kräver redan samma registrerbara domän, vilket en bedragare inte kontrollerar. Strikt läge bryter mestadels dina egna underdomänavsändare — kontrollera det när anpassning misslyckas oväntat.

DMARC misslyckas bara på e-post som mottagare vidarebefordrar — samma fix? Det är SPF-benet som dör under transit: vidarebefordrarens server finns inte i någons SPF-post för din return-path. Du kan inte åtgärda SPF för vidarebefordrad e-post; anpassad DKIM är svaret, eftersom signaturen överlever vidarebefordring intakt. Detaljer i vidarebefordrad e-post misslyckas med SPF.

Skicka ägaren rapporten

Om du åtgärdar detta för en kund eller din arbetsgivare, avsluta loopen med bevis. Kör om den kostnadsfria sökningen efter att CNAMEerna har aktiverats och vidarebefordra den graderade rapporten till företagsägaren: daterad, klarspråk, visar SPF, DKIM och DMARC anpassade och godkända. Det är artefakten de behöver för förnyelse av cyberförsäkring och nästa leverantörs säkerhetsenkät — bevis på en fungerande konfiguration, inte bara “jag lade till några DNS-poster”.

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