Defaults.Exposed › Taisymai › Guides

DKIM Passes but DMARC Fails: The gappssmtp.com / onmicrosoft.com Default-Signature Trap (2026)

Paskelbta 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

Your mail passes DKIM with the provider’s default signature — d= ending in gappssmtp.com (Google Workspace) or onmicrosoft.com (Microsoft 365) — but that domain doesn’t match your From domain, so DMARC gets no aligned pass. Enable custom-domain signing to fix it. Of 12,145,313 domains authorising Google’s mail servers, only 18.5% enforce DMARC, according to the Defaults.Exposed census of 261,086,232 graded domains.

The fix is one of the cleanest in email authentication: switch on custom-domain DKIM signing. On Google Workspace that’s the Admin console’s “Authenticate email” screen — generate the key, publish one TXT record, turn it on. On Microsoft 365 it’s the Defender portal’s DKIM page — publish two selector CNAMEs, enable. Twenty minutes of work, and DMARC finally gets the aligned pass it’s been waiting for.

Why does DKIM pass but DMARC still fail?

Because DMARC doesn’t ask “is there a valid DKIM signature?” — it asks “is there a valid DKIM signature for the domain in the From header?” That second condition is called alignment, and it’s the entire point of DMARC: proving the domain your recipient sees is the domain that signed.

Out of the box, Google Workspace signs your mail with a domain like yourdomain-com.20230601.gappssmtp.com (the date stamp varies per domain) and Microsoft 365 signs with yourtenant.onmicrosoft.com. Both signatures are cryptographically valid — DKIM checkers say pass — but the d= domain belongs to Google or Microsoft, not to you. Even under DMARC’s relaxed alignment, which only requires the organizational domains to match, gappssmtp.com is not yourdomain.com. No match, no aligned pass, and if SPF doesn’t align either (it often can’t — receivers evaluate SPF against the Return-Path domain, not the From header, and forwarding breaks it entirely), DMARC fails.

This is the defining trap of provider defaults: the default gets you deliverability, not protection — alignment is the missing turn of the key. The census shows how many senders stop at the default: of the 12,145,313 domains that authorise Google’s mail servers via _spf.google.com (of 138,927,207 SPF publishers worldwide), only 18.5% enforce DMARC. Microsoft’s picture is the same shape: 10,205,070 domains authorise spf.protection.outlook.com, 85.0% carry the strict SPF record M365 setup hands them — and only 21.7% enforce DMARC. Full comparison in our email-provider SPF league table.

The trap is invisible in day-to-day use: mail delivers, inbox tests look fine, nothing errors — until you publish a DMARC policy and your own mail starts failing it. Our free scan surfaces exactly this gap.

How do I spot the default-signature trap in Authentication-Results?

Open a message you sent (to a Gmail or Outlook mailbox), view the original/raw source, and find the Authentication-Results header. The tell is a DKIM pass with the wrong d= — a Gmail-received example looks like:

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

Read it as three questions:

On Microsoft-received mail, the same story appears as dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com alongside compauth=fail — the pattern covered in the Outlook rejection guide.

If your header instead shows both dkim=pass and spf=pass with a DMARC fail, you’re in the broader alignment case — the DMARC fails but SPF and DKIM pass guide walks through relaxed vs strict alignment in full.

How do I enable custom-domain DKIM signing?

1. Run the free scan at defaults.exposed before touching anything. It shows whether your domain has aligned DKIM, what your DMARC policy actually is, and whether anything else (SPF, DMARC record syntax) will still block you after this fix — so you do the whole job once.
2. Identify which default you’re signing with. Check header.d= in Authentication-Results as above: gappssmtp.com means Google Workspace default, onmicrosoft.com means Microsoft 365 default.
3. Google Workspace: generate and publish your own key. In the Admin console go to Apps → Google Workspace → Gmail → Authenticate email, select your domain and click Generate New Record (2048-bit unless your DNS host can’t store it). Publish the TXT record it gives you at google._domainkey.yourdomain.com, wait for DNS (up to 48 hours), then — the step people miss — click Start authentication. Generating the record does nothing until you turn signing on. Full walk-through: set up DKIM on Google Workspace.
4. Microsoft 365: publish the two selector CNAMEs and enable. In the Defender portal go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM, select your custom domain and create the keys. Publish both CNAMEs — selector1._domainkey and selector2._domainkey, pointing at the targets Microsoft shows you (copy the exact targets from the portal — domains enabled before May 2025 end in your tenant’s .onmicrosoft.com; newer ones end in .dkim.mail.microsoft) — then toggle signing on. Two selectors is not optional: Microsoft rotates keys between them. Full walk-through: set up DKIM on Microsoft 365.
5. Verify the new signature. Send a fresh message to an external mailbox and re-check Authentication-Results: dkim=pass should now show header.d=yourdomain.com. If your DNS panel auto-appended your zone to the CNAME target or mangled the long TXT value, the signature won’t switch over — panel quirks, not the provider, cause most failures here.
6. Re-scan and take the aligned pass somewhere. Confirm the scan shows aligned DKIM, then use it: a DMARC policy at p=none protects nothing. Across all 261,086,232 graded domains, only 10.59% enforce DMARC (data as of 2026-06-29) — aligned DKIM is what makes enforcement safe to ratchet. Start at how to fix DMARC.

Will enabling custom DKIM break anything?

No — this is the rare email-authentication fix with essentially no blast radius: mail that went out with the default signature simply goes out with a better one, and the provider keeps managing the keys (Microsoft rotates across the two selectors automatically). The real failure mode is half-doing it — publishing Google’s TXT but never clicking Start authentication, or publishing one M365 selector instead of both. And don’t delete the DNS records later “to tidy up”; signing stops the moment the key disappears.

One scope note: this fixes mail sent through Google or Microsoft. Newsletter tools and CRMs sign with their own defaults too, and each needs its own custom-domain DKIM switched on — that pattern, and the Gmail bulk-sender rules now demanding it, are covered in the 550-5.7.26 guide.

Frequently asked questions

DKIM shows “pass” on every test tool — why does anything need fixing? Because the tools answer a narrower question than DMARC does. The signature is valid — but it’s gappssmtp.com’s or onmicrosoft.com’s, not yours, so it counts for nothing in DMARC alignment. This is why so many senders stop at the default: of 12,145,313 Google-authorising domains, only 18.5% enforce DMARC (data as of 2026-06-29).

Does relaxed DMARC alignment let the default signature pass? No. Relaxed alignment only loosens the match to organizational domains — mail.yourdomain.com aligns with yourdomain.com. The default signature’s organizational domain is gappssmtp.com or onmicrosoft.com, which shares nothing with yours. No alignment mode rescues a third-party d=.

Is the gappssmtp.com / onmicrosoft.com signature bad? Should I remove it? It’s not bad — it ensures your mail carries some valid signature, which helps spam filtering. It’s just not yours. You don’t remove it; you replace it by enabling custom-domain signing.

My domain is on Microsoft 365 with strict SPF — am I already covered? Probably not: that strict record is the M365 default doing its one job. Of 10,205,070 domains authorising spf.protection.outlook.com, 85.0% have strict SPF but only 21.7% enforce DMARC (data as of 2026-06-29). SPF also breaks under forwarding, because it’s evaluated against the Return-Path rather than the From header — aligned DKIM is the leg that survives, which is exactly why this fix matters.

How long does the fix take? The console work is minutes per provider. DNS is the wait: Google says allow up to 48 hours before starting authentication; Microsoft’s CNAMEs are usually live within hours. Budget one working day end to end, most of it waiting.

Send the owner the report

If you’re fixing this for a client or your employer, close the loop with evidence. Re-run the free scan once the new signature is live and forward the graded report to the business owner: dated, plain-language, showing DKIM aligned with their domain. That’s the artefact for the cyber-insurance renewal and the next supplier security questionnaire — proof the domain authenticates as itself, not as a subtenant of gappssmtp.com.

Check your DKIM alignment free

See whether your mail signs as your own domain — and exactly what to fix — privately and owner-only.

Check your domain → · DMARC fails but SPF and DKIM pass → · Fix DKIM → · Set up DKIM on Google Workspace → · Aggregate data only. Data stored and processed in the EU.