Defaults.Exposed › Åtgärder › Guides

DKIM godkänns men DMARC misslyckas: gappssmtp.com / onmicrosoft.com standardsignatursfällan (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.

Din e-post godkänns med DKIM med leverantörens standardsignatur — d= som slutar med gappssmtp.com (Google Workspace) eller onmicrosoft.com (Microsoft 365) — men den domänen matchar inte din From-domän, så DMARC får inget anpassat godkännande. Aktivera anpassad domänsignering för att åtgärda det. Av 12,145,313 domäner som auktoriserar Googles e-postservrar tillämpar bara 18.5% DMARC, enligt Defaults.Exposed-censuset med 261,086,232 graderade domäner.

Fixen är en av de renaste inom e-postautentisering: slå på anpassad domän-DKIM-signering. På Google Workspace är det administratörskonsolen skärm “Authenticate email” — generera nyckeln, publicera en TXT-post, slå på det. På Microsoft 365 är det Defender-portalens DKIM-sida — publicera två selektor-CNAMEs, aktivera. Tjugo minuters arbete, och DMARC får äntligen det anpassade godkännande det väntat på.

Varför godkänns DKIM men misslyckas DMARC fortfarande?

Eftersom DMARC inte frågar “finns det en giltig DKIM-signatur?” — den frågar “finns det en giltig DKIM-signatur för domänen i From-rubriken?” Det andra villkoret kallas anpassning, och det är hela poängen med DMARC: att bevisa att domänen din mottagare ser är den domän som signerade.

Direkt ur lådan signerar Google Workspace din e-post med en domän som yourdomain-com.20230601.gappssmtp.com (datumstämpeln varierar per domän) och Microsoft 365 signerar med yourtenant.onmicrosoft.com. Båda signaturerna är kryptografiskt giltiga — DKIM-kontrollanter säger pass — men d=-domänen tillhör Google eller Microsoft, inte dig. Även under DMARC:s avslappnade anpassning, som bara kräver att organisationsdomänerna matchar, är gappssmtp.com inte yourdomain.com. Ingen matchning, inget anpassat godkännande, och om SPF inte heller anpassas (det kan det ofta inte — mottagare utvärderar SPF mot Return-Path-domänen, inte From-rubriken, och vidarebefordring bryter det helt), misslyckas DMARC.

Det här är den definerande fällan med leverantörsstandarder: standarden ger dig leveransbarhet, inte skydd — anpassning är det saknade vridandet av nyckeln. Censuset visar hur många avsändare som stannar vid standarden: av de 12,145,313 domänerna som auktoriserar Googles e-postservrar via _spf.google.com (av 138,927,207 SPF-publicerare världen över) tillämpar bara 18.5% DMARC. Microsofts bild har samma form: 10,205,070 domäner auktoriserar spf.protection.outlook.com, 85.0% bär den strikta SPF-posten M365-konfiguration ger dem — och bara 21.7% tillämpar DMARC. Fullständig jämförelse i vår e-postleverantörs SPF-liga-tabell.

Fällan är osynlig i daglig användning: e-post levereras, inkorgstest ser bra ut, ingenting felar — tills du publicerar en DMARC-policy och din egen e-post börjar misslyckas med den. Vår kostnadsfria sökning visar exakt detta gap.

Hur spottar jag standardsignatursfällan i Authentication-Results?

Öppna ett meddelande du skickade (till en Gmail- eller Outlook-postlåda), visa originalet/råkällan och hitta Authentication-Results-rubriken. Kännetecknet är ett DKIM pass med fel d= — ett Gmail-mottaget exempel ser ut som:

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

Läs det som tre frågor:

På Microsoft-mottagen e-post visas samma berättelse som dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com bredvid compauth=fail — mönstret täckt i Outlook-avvisningsguiden.

Om din rubrik istället visar både dkim=pass och spf=pass med ett DMARC-misslyckande befinner du dig i det bredare anpassningsfallet — DMARC misslyckas men SPF och DKIM godkänns-guiden går igenom avslappnad kontra strikt anpassning fullständigt.

Hur aktiverar jag anpassad domän-DKIM-signering?

1. Kör den kostnadsfria sökningen på defaults.exposed innan du rör något. Den visar om din domän har anpassad DKIM, vad din DMARC-policy faktiskt är, och om något annat (SPF, DMARC-postsyntax) fortfarande kommer att blockera dig efter den här fixen — så du gör hela jobbet en gång.
2. Identifiera vilken standard du signerar med. Kontrollera header.d= i Authentication-Results som ovan: gappssmtp.com betyder Google Workspace-standard, onmicrosoft.com betyder Microsoft 365-standard.
3. Google Workspace: generera och publicera din egen nyckel. I administratörskonsolen gå till Apps → Google Workspace → Gmail → Authenticate email, välj din domän och klicka Generate New Record (2048-bit om inte din DNS-värd kan lagra den). Publicera TXT-posten den ger dig på google._domainkey.yourdomain.com, vänta på DNS (upp till 48 timmar), klicka sedan — steget folk missar — Start authentication. Att generera posten gör ingenting tills du slår på signering. Fullständig genomgång: konfigurera DKIM på Google Workspace.
4. Microsoft 365: publicera de två selektor-CNAMEerna och aktivera. I Defender-portalen gå till Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, välj din anpassade domän och skapa nycklarna. Publicera båda CNAMEerna — selector1._domainkey och selector2._domainkey, som pekar på målen Microsoft visar dig (kopiera de exakta målen från portalen — domäner aktiverade före maj 2025 slutar med din klientorganisations .onmicrosoft.com; nyare slutar med .dkim.mail.microsoft) — aktivera sedan signering. Två selektorer är inte valfritt: Microsoft roterar nycklar mellan dem. Fullständig genomgång: konfigurera DKIM på Microsoft 365.
5. Verifiera den nya signaturen. Skicka ett nytt meddelande till en extern postlåda och kontrollera om Authentication-Results igen: dkim=pass bör nu visa header.d=yourdomain.com. Om din DNS-panel automatiskt lade till din zon till CNAME-målet eller förvanskat det långa TXT-värdet kommer signaturen inte att byta över — panel-egenheter, inte leverantören, orsakar de flesta fel här.
6. Scanna igen och ta det anpassade godkännandet någonstans. Bekräfta att sökningen visar anpassad DKIM, använd den sedan: en DMARC-policy vid p=none skyddar ingenting. Bland alla 261,086,232 graderade domäner tillämpar bara 10.59% DMARC (data per 2026-06-29) — anpassad DKIM är det som gör tillämpning säker att dra åt. Börja på hur man åtgärdar DMARC.

Kommer aktivering av anpassad DKIM att bryta något?

Nej — det här är den sällsynta e-postautentiseringsfixen med i princip ingen skaderadie: e-post som gick ut med standardsignaturen går helt enkelt ut med en bättre, och leverantören fortsätter hantera nycklarna (Microsoft roterar automatiskt mellan de två selektorerna). Det verkliga felläget är att halvgöra det — publicera Googles TXT men aldrig klicka Start authentication, eller publicera en M365-selektor istället för båda. Och radera inte DNS-posterna senare “för att städa upp”; signering stannar det ögonblick nyckeln försvinner.

En scopeanteckning: det här åtgärdar e-post skickad via Google eller Microsoft. Nyhetsbrevverktyg och CRM:er signerar med sina egna standarder också, och var och en behöver sin egna anpassade domän-DKIM påslagen — det mönstret, och Gmail:s bulk-avsändarregler som nu kräver det, täcks i 550-5.7.26-guiden.

Vanliga frågor

DKIM visar “pass” på varje testverktyg — varför behöver något åtgärdas? Eftersom verktygen besvarar en smalare fråga än DMARC gör. Signaturen är giltig — men den är gappssmtp.com:s eller onmicrosoft.com:s, inte din, så den räknas för ingenting i DMARC-anpassning. Det är därför så många avsändare stannar vid standarden: av 12,145,313 Google-auktoriserande domäner tillämpar bara 18.5% DMARC (data per 2026-06-29).

Låter avslappnad DMARC-anpassning standardsignaturen godkännas? Nej. Avslappnad anpassning löser bara upp matchningen till organisationsdomäner — mail.yourdomain.com anpassas till yourdomain.com. Standardsignaturens organisationsdomän är gappssmtp.com eller onmicrosoft.com, som inte delar något med din. Inget anpassningsläge räddar ett d= från tredje part.

Är gappssmtp.com / onmicrosoft.com-signaturen dålig? Ska jag ta bort den? Den är inte dålig — den säkerställer att din e-post bär någon giltig signatur, vilket hjälper spamfiltrering. Det är bara inte din. Du tar inte bort den; du ersätter den genom att aktivera anpassad domänsignering.

Min domän är på Microsoft 365 med strikt SPF — är jag redan täckt? Troligtvis inte: den strikta posten är M365-standarden som gör sitt enda jobb. Av 10,205,070 domäner som auktoriserar spf.protection.outlook.com har 85.0% strikt SPF men bara 21.7% tillämpar DMARC (data per 2026-06-29). SPF bryter också under vidarebefordring, eftersom det utvärderas mot Return-Path snarare än From-rubriken — anpassad DKIM är det ben som överlever, vilket är exakt varför den här fixen spelar roll.

Hur lång tid tar fixen? Konsol-arbetet är minuter per leverantör. DNS är väntan: Google säger tillåt upp till 48 timmar innan du startar autentisering; Microsofts CNAMEs är vanligtvis live inom timmar. Budget en arbetsdag från start till slut, det mesta väntan.

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 när den nya signaturen är live och vidarebefordra den graderade rapporten till företagsägaren: daterad, klarspråk, visar DKIM anpassad till deras domän. Det är artefakten för förnyelse av cyberförsäkring och nästa leverantörs säkerhetsenkät — bevis på att domänen autentiserar sig som sig själv, inte som en undertenant till gappssmtp.com.

Kontrollera din DKIM-anpassning kostnadsfritt

Se om din e-post signerar som din egen domän — och exakt vad som ska åtgärdas — privat och enbart för ägaren.

Kontrollera din domän → · DMARC misslyckas men SPF och DKIM godkänns → · Åtgärda DKIM → · Konfigurera DKIM på Google Workspace → · Enbart aggregerade data. Data lagras och behandlas inom EU.