Defaults.Exposed › Fikser › Guides

DKIM består men DMARC feiler: Fellen med gappssmtp.com / onmicrosoft.com-standardsignatur (2026)

Publisert 2026-07-08

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

E-posten din består DKIM med leverandørens standardsignatur — d= slutter på gappssmtp.com (Google Workspace) eller onmicrosoft.com (Microsoft 365) — men det domenet samsvarer ikke med Fra-domenet ditt, så DMARC får ikke noe justert pass. Aktiver egendefinert-domene-signering for å fikse det. Av 12,145,313 domener som autoriserer Googles e-postservere, håndhever bare 18.5% DMARC, ifølge Defaults.Exposed-sensus over 261,086,232 graderte domener.

Fiksen er en av de reneste innen e-postautentisering: slå på egendefinert-domene-DKIM-signering. På Google Workspace er det Admin-konsollets «Autentiser e-post»-skjerm — generer nøkkelen, publiser én TXT-post, slå den på. På Microsoft 365 er det Defender-portalens DKIM-side — publiser to velger-CNAME-er, aktiver. Tjue minutters arbeid, og DMARC får endelig det justerte passet det har ventet på.

Hvorfor består DKIM men DMARC feiler fortsatt?

Fordi DMARC ikke spør «er det en gyldig DKIM-signatur?» — det spør «er det en gyldig DKIM-signatur for domenet i Fra-overskriften?» Den andre betingelsen kalles justering, og det er hele poenget med DMARC: å bevise at domenet mottakeren ser er domenet som signerte.

Ut av boksen signerer Google Workspace e-posten din med et domene som dittdomene-com.20230601.gappssmtp.com (datostempelet varierer per domene), og Microsoft 365 signerer med dittleietaker.onmicrosoft.com. Begge signaturer er kryptografisk gyldige — DKIM-kontrollører sier pass — men d=-domenet tilhører Google eller Microsoft, ikke deg. Selv under DMARCs avslappede justering, som bare krever at organisasjonsdomenet samsvarer, er ikke gappssmtp.com = dittdomene.com. Ingen match, inget justert pass, og hvis SPF heller ikke justerer (det kan den ofte ikke — mottakere evaluerer SPF mot Return-Path-domenet, ikke Fra-overskriften, og videresending bryter den helt), feiler DMARC.

Dette er den definerende fellen med leverandørstandarder: standarden gir deg leveringsevne, ikke beskyttelse — justering er det manglende nøkkeldraget. Sensus viser hvor mange avsendere som stopper ved standarden: av de 12,145,313 domenene som autoriserer Googles e-postservere via _spf.google.com (av 138,927,207 SPF-publisister globalt), håndhever bare 18.5% DMARC. Microsofts bilde er av samme form: 10,205,070 domener autoriserer spf.protection.outlook.com, 85.0% bærer den strenge SPF-posten M365-oppsettet gir dem — og bare 21.7% håndhever DMARC. Full sammenligning i vår e-postleverandør SPF-ligatabell.

Fellen er usynlig i daglig bruk: e-post leveres, innbokstester ser fine ut, ingenting feiler — til du publiserer en DMARC-policy og din egen e-post begynner å feile den. Den gratis skanningen avdekker nøyaktig dette gapet.

Hvordan oppdager jeg standard-signatur-fellen i Authentication-Results?

Åpne en melding du sendte (til en Gmail- eller Outlook-postkasse), vis originalen/råkilden, og finn Authentication-Results-overskriften. Kjennetegnet er DKIM pass med feil d= — et Gmail-mottatt eksempel ser slik ut:

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=dittdomene.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=dittdomene.com

Les det som tre spørsmål:

På Microsoft-mottatt e-post, dukker den samme historien opp som dkim=pass (signature was verified) header.d=dittleietaker.onmicrosoft.com ved siden av compauth=fail — mønsteret dekket i Outlook-avvisningsveiledningen.

Hvis overskriften din i stedet viser begge dkim=pass og spf=pass med en DMARC-feil, er du i det bredere justeringstilfellet — DMARC feiler men SPF og DKIM er OK-veiledningen gjennomgår avslappet vs. streng justering fullstendig.

Hvordan aktiverer jeg egendefinert-domene-DKIM-signering?

1. Kjør den gratis skanningen på defaults.exposed før du rører noe. Den viser om domenet ditt har justert DKIM, hva DMARC-policyen faktisk er, og om noe annet (SPF, DMARC-postsyntaks) fortsatt vil blokkere deg etter denne fiksen — slik at du gjør hele jobben én gang.
2. Identifiser hvilken standard du signerer med. Sjekk header.d= i Authentication-Results som over: gappssmtp.com betyr Google Workspace-standard, onmicrosoft.com betyr Microsoft 365-standard.
3. Google Workspace: generer og publiser din egen nøkkel. I Admin-konsollen gå til Apper → Google Workspace → Gmail → Autentiser e-post, velg domenet ditt og klikk Generer ny post (2048-bit med mindre DNS-verten din ikke kan lagre det). Publiser TXT-posten den gir deg på google._domainkey.dittdomene.com, vent på DNS (opptil 48 timer), og deretter — trinnet folk glemmer — klikk Start autentisering. Å generere posten gjør ingenting til du slår signering på. Fullstendig gjennomgang: sett opp DKIM på Google Workspace.
4. Microsoft 365: publiser de to velger-CNAME-ene og aktiver. I Defender-portalen gå til E-post og samarbeid → Retningslinjer og regler → Trusselretningslinjer → E-postautentiseringsinnstillinger → DKIM, velg ditt egendefinerte domene og opprett nøklene. Publiser begge CNAME-ene — selector1._domainkey og selector2._domainkey, pekende på målene Microsoft viser deg (kopier de eksakte målene fra portalen — domener aktivert før mai 2025 slutter på leietakerens .onmicrosoft.com; nyere slutter på .dkim.mail.microsoft) — og slå deretter signering på. To velgere er ikke valgfritt: Microsoft roterer nøkler mellom dem. Fullstendig gjennomgang: sett opp DKIM på Microsoft 365.
5. Bekreft den nye signaturen. Send en fersk melding til en ekstern postkasse og sjekk Authentication-Results på nytt: dkim=pass bør nå vise header.d=dittdomene.com. Hvis DNS-panelet auto-la til sonen din til CNAME-målet eller klusset med den lange TXT-verdien, vil signaturen ikke bytte over — panelens quirks, ikke leverandøren, forårsaker de fleste feil her.
6. Skann på nytt og ta det justerte passet et sted. Bekreft at skanningen viser justert DKIM, og bruk det deretter: en DMARC-policy på p=none beskytter ingenting. Av alle 261,086,232 graderte domener håndhever bare 10.59% DMARC (data per 2026-06-29) — justert DKIM er det som gjør håndhevelse trygt å skru opp. Start på hvordan fikse DMARC.

Vil aktivering av egendefinert DKIM ødelegge noe?

Nei — dette er den sjeldne e-postautentiseringsfiksen med i utgangspunktet ingen sprengradius: e-post som gikk ut med standardsignaturen går bare ut med en bedre, og leverandøren fortsetter å administrere nøklene (Microsoft roterer automatisk mellom de to velgerne). Den virkelige feilmodusen er å gjøre det halvveis — publisere Googles TXT men aldri klikke Start autentisering, eller publisere én M365-velger i stedet for begge. Og ikke slett DNS-postene senere «for å rydde opp»; signering stopper i det øyeblikket nøkkelen forsvinner.

Et omfangsmerke: dette fikser e-post sendt gjennom Google eller Microsoft. Nyhetsbrevverktøy og CRM-er signerer med sine egne standarder også, og hvert trenger sin egen egendefinerte-domene-DKIM slått på — det mønsteret, og Gmail-reglene for bulkavsendere som nå krever det, er dekket i 550-5.7.26-veiledningen.

Ofte stilte spørsmål

DKIM viser «pass» på alle testverktøy — hvorfor trenger noe å fikses? Fordi verktøyene svarer på et smalere spørsmål enn DMARC gjør. Signaturen er gyldig — men det er gappssmtp.coms eller onmicrosoft.coms, ikke din, så den teller ingenting for DMARC-justering. Dette er grunnen til at så mange avsendere stopper ved standarden: av 12,145,313 Google-autoriserende domener håndhever bare 18.5% DMARC (data per 2026-06-29).

Lar avslappet DMARC-justering standardsignaturen passere? Nei. Avslappet justering løsner bare matchet til organisasjonsdomener — post.dittdomene.com justerer med dittdomene.com. Standardsignaturens organisasjonsdomene er gappssmtp.com eller onmicrosoft.com, som ikke deler noe med ditt. Ingen justeringsmodus redder en tredjeparts d=.

Er gappssmtp.com / onmicrosoft.com-signaturen dårlig? Bør jeg fjerne den? Den er ikke dårlig — den sørger for at e-posten din bærer en gyldig signatur, noe som hjelper med spam-filtrering. Den er bare ikke din. Du fjerner den ikke; du erstatter den ved å aktivere egendefinert-domene-signering.

Domenet mitt er på Microsoft 365 med streng SPF — er jeg allerede dekket? Sannsynligvis ikke: den strenge posten er M365-standarden som gjør jobben sin. Av 10,205,070 domener som autoriserer spf.protection.outlook.com, har 85.0% streng SPF men bare 21.7% håndhever DMARC (data per 2026-06-29). SPF bryter også under videresending, fordi den evalueres mot Return-Path i stedet for Fra-overskriften — justert DKIM er benet som overlever, noe som er nøyaktig grunnen til at denne fiksen betyr noe.

Hvor lang tid tar fiksen? Konsolarbeidet er minutter per leverandør. DNS er ventetiden: Google sier tillat opptil 48 timer før du starter autentisering; Microsofts CNAME-er er vanligvis live innen timer. Budsjetter én arbeidsdag fra start til slutt, mesteparten av den med venting.

Send eieren rapporten

Hvis du fikser dette for en klient eller arbeidsgiveren din, lukk løkken med bevis. Kjør den gratis skanningen på nytt når den nye signaturen er live og videresend den graderte rapporten til bedriftseieren: datert, på enkelt norsk, som viser DKIM justert med domenet deres. Det er artefakten for fornyelse av cyberforsikring og neste leverandørsikkerhets-spørreskjema — bevis for at domenet autentiserer som seg selv, ikke som et underleietaker av gappssmtp.com.

Sjekk DKIM-justeringen din gratis

Se om e-posten din signerer som ditt eget domene — og nøyaktig hva du skal fikse — privat og kun for eieren.

Sjekk domenet ditt → · DMARC feiler men SPF og DKIM er OK → · Fiks DKIM → · Sett opp DKIM på Google Workspace → · Kun aggregerte data. Data lagret og behandlet i EU.