dkim=pass, dmarc=fail: when the signing domain belongs to your provider

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

Both checks passed and DMARC failed anyway, and the reason is sitting in the second line. The signature is valid, but the domain that made it is yourdomain-com.20230601.gappssmtp.com, which belongs to Google, and DMARC only counts a signature from the domain in your From header. Switching on custom-domain signing in your provider’s console fixes it. The DNS work is one TXT record on Google Workspace or two CNAMEs on Microsoft 365, and the change is safe to make today.

The fragment that decides the verdict

Open a message you sent to an outside mailbox, view the original source, and find the Authentication-Results header. Ignore the three verdict words for a moment and read the domain that follows dkim=pass. Gmail reports it as header.i=@... and most other receivers report it as header.d=, and either way it names the domain that signed the message.

Compare that domain with the one after header.from=. In the block above the From domain is yourdomain.com and the signing domain is yourdomain-com.20230601.gappssmtp.com. They don’t match, so DMARC has no aligned DKIM pass to work with, and the line ends dmarc=fail.

There are three shapes this line can take, and only one of them is the goal. If dkim=pass comes with header.d=yourdomain.com, the signature is valid and matches your From domain, which is what you’re aiming for. A header.d= ending in gappssmtp.com or onmicrosoft.com alongside dkim=pass tells you the provider signed it, and that is the case this page is about. Where the line reads dkim=fail, the signature itself is broken whatever the d= says, a different problem covered on the DKIM page.

If you’re reading a header from Microsoft-received mail, the same story appears as dkim=pass header.d=yourtenant.onmicrosoft.com alongside compauth=fail, which is the same cause in a different receiver’s vocabulary.

Why a valid signature still fails DMARC

DMARC only counts a DKIM signature when the signing domain matches the domain in the From header, and that condition is called alignment. The whole purpose of DMARC is to prove that the domain your recipient sees is the domain that vouched for the message, so a signature from anyone else’s domain earns nothing, however sound the cryptography.

Relaxed alignment doesn’t rescue you here. Relaxed mode only loosens the match to organisational domains, so mail.yourdomain.com aligns with yourdomain.com. The organisational domain of the default signature is gappssmtp.com or onmicrosoft.com, which shares nothing with yours, and a third-party d= fails to align in either mode.

SPF can’t step in either, even though your header shows spf=pass. Receivers evaluate SPF against the Return-Path domain (the smtp.mailfrom= value), and for DMARC to accept it the Return-Path must align with the From header as well. Your own outbound mail often manages that, which is why plenty of senders see intermittent results. Any forwarding rewrites the Return-Path and the SPF leg drops away, leaving DKIM as the only thing DMARC has to go on, and DKIM is signed by someone else.

The two defaults you’re almost certainly signing with

Out of the box, Google Workspace signs your mail as yourdomain-com.20230601.gappssmtp.com. The date stamp varies per domain, and the shape is always your domain with the dot swapped for a hyphen, then a date, then gappssmtp.com. Where that name comes from and why it appears in spam complaints has its own page; the mechanics of fixing the alignment live here.

Microsoft 365 signs as yourtenant.onmicrosoft.com until you enable DKIM for your custom domain. The signature is valid and the key is Microsoft’s, published under the tenant name you picked at sign-up.

Both defaults exist so that your mail carries some valid signature from day one, which helps spam filtering and does no harm, though neither domain is yours. Turning on custom-domain signing replaces the default, and from then on the provider signs with a key published under your own domain.

What a green tick from a single-record checker settles

DKIM keys live under selector names that only the sender knows, so an outside observer can’t test a domain’s DKIM without guessing selectors, and a green tick from a one-record checker settles less than it looks. In the September 2026 census the DKIM check could run on 75,823,110 domains, and on those it observed a selector for 37,999,462 (50.1%) and none for 37,823,648 (49.9%). A further 240,777,792 domains gave the check nothing to determine at all.

So a checker that reports “DKIM: pass” is telling you it found a valid key at a selector it knew to look for. It isn’t telling you the selector it found is the one your provider is using today, and it isn’t telling you the signing domain matches your From header. Only the Authentication-Results header on a real delivered message tells you that.

The other half of the picture is what your DMARC record does with the failure. Of the 78,444,857 DMARC records the September 2026 census found, 36,602,897 are enforcing, meaning a policy of quarantine or reject. Your header shows p=NONE, so for now the failure is reported and nothing is blocked. That’s the right place to be while you fix alignment, and the DMARC page covers what to do once your own mail passes.

Turning on your own signature in Google Workspace

In the Admin console go to Apps, then Google Workspace, then Gmail, then Authenticate email. Select the domain and generate the record. Take the 2048-bit key unless your DNS host can’t store a value that long.

Publish the TXT record it gives you at google._domainkey.yourdomain.com. Then wait for DNS, which Google says can take up to 48 hours.

Once the record resolves, go back to the same screen and click Start authentication, which is the step people miss. Generating the record and publishing it does nothing to your outbound mail until you press that button. Plenty of domains have a perfectly good key sitting in DNS while Google carries on signing with the gappssmtp.com default, because nobody came back after the DNS wait.

Turning on your own signature in Microsoft 365

In the Defender portal open Email authentication settings and choose DKIM. Select your custom domain and create the keys.

Publish both CNAMEs, selector1._domainkey and selector2._domainkey, pointing at the targets the portal shows you. Copy the targets exactly. Domains enabled before May 2025 point at your tenant’s .onmicrosoft.com; newer ones point at .dkim.mail.microsoft, and guessing the pattern from an old blog post is how people end up with one broken selector.

You need both selectors because Microsoft rotates keys between them, so a domain with only selector1 published will sign correctly until the next rotation and then stop. Once both CNAMEs resolve, toggle signing on for the domain.

Proving it worked

Send a fresh message to an external mailbox and open its Authentication-Results header again. You’re looking for dkim=pass with header.d= (or Gmail’s header.i=@) equal to your own domain, and dmarc=pass on the last line. If the signing domain is still the provider default, the most common causes are a DNS panel that appended your zone to the CNAME target, a TXT value that got split or truncated, or the Start authentication button on Google that never got clicked.

The blast radius of this change is close to nil. Mail that went out with the default signature goes out with a better one, and the provider keeps managing the keys, including Microsoft’s rotation across the two selectors. Where it does go wrong is when the job is half done: Google’s TXT published and never enabled, or one Microsoft selector published instead of two. Don’t delete the DNS records later to tidy up either, because signing stops the moment the key disappears.

What you’ve fixed is mail sent through Google or Microsoft. Your newsletter tool and your CRM sign with their own defaults too, and each needs custom-domain DKIM switched on separately in its own settings, with its own selector in your DNS. Run the free scan once your provider’s signature is aligned, then work through any other sender that shows up in your DMARC reports with a d= that isn’t yours.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.