Defaults.Exposed › Rettelser › Guides

DKIM godkendes, men DMARC fejler: gappssmtp.com / onmicrosoft.com-standardsignatur-fælden (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.

Din mail godkendes med DKIM via udbyderens standardsignatur — d= der slutter på gappssmtp.com (Google Workspace) eller onmicrosoft.com (Microsoft 365) — men det domæne matcher ikke dit Fra-domæne, så DMARC får ingen justeret godkendelse. Aktiver signering med dit eget domæne for at løse det. Af 12,145,313 domæner, der godkender Googles mailservere, er det kun 18.5%, der håndhæver DMARC, ifølge Defaults.Exposed-census over 261,086,232 graderede domæner.

Løsningen er en af de reneste inden for e-mailgodkendelse: aktiver DKIM-signering med dit eget domæne. I Google Workspace er det skærmbilledet “Authenticate email” i Administratorkonsollen — generer nøglen, udgiv én TXT-post, slå det til. I Microsoft 365 er det DKIM-siden i Defender-portalen — udgiv to selektor-CNAMEs, aktivér. Tyve minutters arbejde, og DMARC får endelig det justerede pass, det har ventet på.

Hvorfor godkendes DKIM, men DMARC fejler stadig?

Fordi DMARC ikke spørger “er der en gyldig DKIM-signatur?” — det spørger “er der en gyldig DKIM-signatur for domænet i Fra-headeren?” Den anden betingelse hedder justering, og det er hele pointen med DMARC: at bevise, at det domæne din modtager ser, er det domæne, der signerede.

Som standard signerer Google Workspace din mail med et domæne som ditdomæne-com.20230601.gappssmtp.com (datostemplet varierer per domæne), og Microsoft 365 signerer med dinlejer.onmicrosoft.com. Begge signaturer er kryptografisk gyldige — DKIM-kontrollørerne siger pass — men d=-domænet tilhører Google eller Microsoft, ikke dig. Selv under DMARCs relaxed-justering, der kun kræver, at organisationsdomænerne matcher, er gappssmtp.com ikke ditdomæne.com. Ingen match, ingen justeret godkendelse, og hvis SPF heller ikke justerer (det kan det ofte ikke — modtagere evaluerer SPF mod Return-Path-domænet, ikke Fra-headeren, og videresendelse ødelægger det fuldstændigt), fejler DMARC.

Dette er standardindstillingernes definerende fælde: standarden giver dig leveringsdygtighed, ikke beskyttelse — justering er det manglende nøgledrej. Census viser, hvor mange afsendere stopper ved standarden: af de 12,145,313 domæner, der godkender Googles mailservere via _spf.google.com (af 138,927,207 SPF-udgivere verden over), er det kun 18.5%, der håndhæver DMARC. Microsofts billede ser ens ud: 10,205,070 domæner godkender spf.protection.outlook.com, 85.0% har den strenge SPF-post, M365-opsætning giver dem — og kun 21.7% håndhæver DMARC. Fuld sammenligning i vores SPF-rangliste for e-mailudbydere.

Fælden er usynlig i daglig brug: mail leveres, indbakketests ser fine ud, intet fejler — indtil du udgiver en DMARC-politik, og din egen mail begynder at fejle den. Vores gratis scanning afslører præcis dette hul.

Hvordan spotter jeg standardsignatur-fælden i Authentication-Results?

Åbn en besked, du har sendt (til en Gmail- eller Outlook-postkasse), vis kilden/råformatet, og find Authentication-Results-headeren. Tegnet er et DKIM pass med det forkerte d= — et Gmail-modtaget eksempel ser sådan ud:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@ditdomæne-com.20230601.gappssmtp.com;
       spf=pass smtp.mailfrom=ditdomæne.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ditdomæne.com

Læs det som tre spørgsmål:

På Microsoft-modtaget mail optræder den samme situation som dkim=pass (signature was verified) header.d=dinlejer.onmicrosoft.com ved siden af compauth=fail — det mønster, der er dækket i Outlook-afvisningsguiden.

Hvis din header i stedet viser begge dkim=pass og spf=pass med et DMARC-fejl, befinder du dig i det bredere justeringstilfælde — vejledningen om DMARC fejler men SPF og DKIM godkendes gennemgår relaxed vs. strict justering fuldt ud.

Hvordan aktiverer jeg DKIM-signering med mit eget domæne?

1. Kør den gratis scanning på defaults.exposed inden du rører noget som helst. Den viser, om dit domæne har justeret DKIM, hvad din DMARC-politik faktisk er, og om noget andet (SPF, DMARC-postsyntaks) stadig vil blokere dig efter denne løsning — så du gør hele jobbet én gang.
2. Identificer, hvilken standard du signerer med. Kontrollér header.d= i Authentication-Results som ovenfor: gappssmtp.com betyder Google Workspace-standard, onmicrosoft.com betyder Microsoft 365-standard.
3. Google Workspace: generer og udgiv din egen nøgle. Gå i Administratorkonsollen til Apps → Google Workspace → Gmail → Authenticate email, vælg dit domæne, og klik Generate New Record (2048-bit, medmindre din DNS-udbyder ikke kan lagre det). Udgiv den TXT-post, det giver dig, på google._domainkey.ditdomæne.com, vent på DNS (op til 48 timer), og derefter — det trin folk glemmer — klik Start authentication. At generere posten gør ingenting, inden du slår signering til. Fuld gennemgang: opsæt DKIM på Google Workspace.
4. Microsoft 365: udgiv de to selektor-CNAMEs og aktivér. Gå i Defender-portalen til E-mail & samarbejde → Politikker & regler → Trusselsregler → E-mail-godkendelsesindstillinger → DKIM, vælg dit eget domæne, og opret nøglerne. Udgiv begge CNAMEs — selector1._domainkey og selector2._domainkey, der peger på de mål, Microsoft viser dig (kopiér de præcise mål fra portalen — domæner aktiveret før maj 2025 slutter på din lejers .onmicrosoft.com; nyere slutter på .dkim.mail.microsoft) — og aktivér derefter signering. To selektorer er ikke valgfrit: Microsoft roterer nøgler mellem dem. Fuld gennemgang: opsæt DKIM på Microsoft 365.
5. Verificer den nye signatur. Send en ny besked til en ekstern postkasse og kontrollér Authentication-Results igen: dkim=pass bør nu vise header.d=ditdomæne.com. Hvis dit DNS-panel automatisk tilføjede din zone til CNAME-målet eller forvrængte den lange TXT-værdi, vil signaturen ikke skifte over — panelets særheder, ikke udbyderen, forårsager de fleste fejl her.
6. Scan igen og brug det justerede pass til noget. Bekræft, at scanningen viser justeret DKIM, og brug det derefter: en DMARC-politik på p=none beskytter ingenting. På tværs af alle 261,086,232 graderede domæner er det kun 10.59%, der håndhæver DMARC (data pr. 2026-06-29) — justeret DKIM er det, der gør håndhævelse sikker at stramme. Start på hvordan man retter DMARC.

Vil aktivering af tilpasset DKIM ødelægge noget?

Nej — dette er den sjældne e-mailgodkendelsesrettelse med i det væsentlige ingen risiko: mail, der gik ud med standardsignaturen, går simpelthen ud med en bedre, og udbyderen fortsætter med at administrere nøglerne (Microsoft roterer automatisk mellem de to selektorer). Den reelle fejlmodus er at halvgøre det — at udgive Googles TXT men aldrig klikke Start authentication, eller udgive én M365-selektor i stedet for begge. Og slet ikke DNS-posterne senere “for at rydde op”; signering stopper i det øjeblik, nøglen forsvinder.

En note om rækkevidde: dette løser mail sendt via Google eller Microsoft. Nyhedsbrevværktøjer og CRM’er signerer også med deres egne standarder, og hvert skal have sin egen tilpassede DKIM slået til — det mønster, og de Gmail-masseafsendefregler, der nu kræver det, er dækket i 550-5.7.26-guiden.

Ofte stillede spørgsmål

DKIM viser “pass” på alle testværktøjer — hvorfor skal noget rettes? Fordi værktøjerne besvarer et smallere spørgsmål end DMARC. Signaturen er gyldig — men det er gappssmtp.coms eller onmicrosoft.coms, ikke din, så den tæller ingenting i DMARC-justering. Det er grunden til, at så mange afsendere stopper ved standarden: af 12,145,313 Google-godkendende domæner er det kun 18.5%, der håndhæver DMARC (data pr. 2026-06-29).

Lader DMARC relaxed-justering standardsignaturen godkendes? Nej. Relaxed-justering løsner kun matchen til organisationsdomæner — mail.ditdomæne.com justerer med ditdomæne.com. Standardsignaturens organisationsdomæne er gappssmtp.com eller onmicrosoft.com, som ikke har noget til fælles med dit. Ingen justeringstilstand redder et tredjeparts d=.

Er gappssmtp.com / onmicrosoft.com-signaturen dårlig? Bør jeg fjerne den? Den er ikke dårlig — den sikrer, at din mail bærer en gyldig signatur, hvilket hjælper spamfiltrering. Den er bare ikke din. Du fjerner den ikke; du erstatter den ved at aktivere signering med dit eget domæne.

Mit domæne er på Microsoft 365 med streng SPF — er jeg allerede dækket? Sandsynligvis ikke: den strenge post er M365-standarden, der gør sit ene job. Af 10,205,070 domæner, der godkender spf.protection.outlook.com, har 85.0% streng SPF, men kun 21.7% håndhæver DMARC (data pr. 2026-06-29). SPF bryder desuden ved videresendelse, fordi det evalueres mod Return-Path frem for Fra-headeren — justeret DKIM er det ben, der overlever, hvilket er præcis, hvorfor denne løsning er vigtig.

Hvor lang tid tager løsningen? Konsolarbejdet tager minutter per udbyder. DNS er ventetiden: Google siger tillad op til 48 timer inden start af godkendelse; Microsofts CNAMEs er typisk live inden for timer. Budgettér én arbejdsdag i alt, det meste af det som ventetid.

Send ejeren rapporten

Løser du dette for en klient eller din arbejdsgiver, skal du afslutte med dokumentation. Kør den gratis scanning igen, når den nye signatur er live, og videresend den graderede rapport til virksomhedsejeren: dateret, klart sprog, der viser DKIM justeret med deres domæne. Det er artefaktet til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — bevis for, at domænet godkender som sig selv, ikke som en underlejer af gappssmtp.com.

Kontrollér din DKIM-justering gratis

Se om din mail signerer som dit eget domæne — og præcis hvad der skal rettes — privat og kun for ejeren.

Kontrollér dit domæne → · DMARC fejler men SPF og DKIM godkendes → · Ret DKIM → · Opsæt DKIM på Google Workspace → · Kun aggregerede data. Data opbevares og behandles i EU.