DKIM record published but messages arrive unsigned: why DKIM isn't signing and the fix

Your DKIM public key is published correctly in DNS, but messages still arrive with dkim=none because nothing is putting a signature on them. DKIM only verifies a signature that is present on the message in a DKIM-Signature: header (RFC 6376 §3.5); when a verifier finds no such header it has nothing to check (RFC 6376 §6.1), so the result is dkim=none, not a pass or a fail. The fix is to switch on signing at the sending platform, not to touch DNS again.

Quick answer

Your DKIM public key is published correctly in DNS, but messages still arrive with dkim=none because nothing is putting a signature on them. DKIM only verifies a signature that is present on the message in a DKIM-Signature: header (RFC 6376 §3.5). When a verifier finds no such header, it has no signature to check (RFC 6376 §6.1), so the Authentication-Results show dkim=none rather than a pass or a fail. The fix is to switch on signing at the sending platform, not to touch DNS again. This is the opposite problem to a missing key: the record is present, the signature is absent.

dkim=none is not the same as dkim=fail

These three results mean different things, and the fix differs for each:

dkim=none. The message carried no DKIM-Signature: header, or none that named your domain, so there was nothing to verify. The signing step never ran. Publishing a key in DNS does not create this header; only the sending platform does, and only once you enable signing.
dkim=fail. A DKIM-Signature: header was present and named your domain, the verifier fetched your published key, and the cryptographic check failed. That is a different page: a key or body-hash mismatch, not a missing signature.
dkim=permerror or a key-fetch error. A signature was present but the key record itself was unusable (revoked with an empty p=, malformed, or absent at the queried selector).

This page is about none. If you are seeing none, no amount of editing the DNS record will help, because the record is not the thing that is missing.

The three common reasons a published key still yields dkim=none:

Signing was never enabled at the platform. Most platforms generate the key pair and tell you the DNS records to publish, but signing does not start until you flip a switch in the admin console. Until then, every outgoing message leaves unsigned. In the Google Workspace admin console this is the Start authentication action; until you take it, mail is not signed even with the TXT record live (Google Workspace: Set up DKIM). In Microsoft 365 you set the Sign messages for this domain with DKIM signatures toggle to Enabled, or run Set-DkimSigningConfig -Identity <domain> -Enabled $true; publishing the CNAMEs alone does not sign (Microsoft 365: Configure DKIM).
The platform signs with its own domain, not yours. Some platforms sign every message with a d= value they own (a shared signing domain) rather than your From domain. The message is signed and dkim=pass is reported, but for the platform's domain. Against your domain the result is effectively none, and DMARC will not align. The d= tag in the DKIM-Signature: header (RFC 6376 §3.5) tells you which domain actually signed.
Selector mismatch. The platform signs with a selector (the s= tag) that is different from the one whose key you published. The verifier reads the s= from the signature, queries that selector's key, and finds nothing. A key exists in your zone, but not at the name the signature points to. Either the platform changed selectors, or you published the key under the wrong selector name.

How to diagnose dkim=none on a published key

Read a real delivered message, not the DNS record in isolation.

Open the original source of a message you sent through the real path to a mailbox you control (in Gmail: the three-dot menu, then Show original).
Find the Authentication-Results: header and read the dkim= token. If it says dkim=none, the message arrived without a signature that named your domain, which confirms this scenario rather than a verify failure.
Look for a DKIM-Signature: header in the same message. If there is none at all, the platform is not signing (cause 1). If one is present, read its d= and s= tags (RFC 6376 §3.5). A d= that is the platform's domain rather than yours is cause 2. A d= that is your domain but an s= you do not recognise is cause 3.
Confirm what is actually published. Query the key record at the selector the signature uses (or the one your platform documents):
```
dig TXT selector1._domainkey.example.com
```
The record lives at <selector>._domainkey.<domain> and should return v=DKIM1 and a non-empty p= value holding the base64 public key (RFC 6376 §3.6). If the record is healthy there but the message still shows dkim=none, the gap is on the signing side, not the DNS side. If the message's s= and the selector you published do not match, that mismatch is the defect.

How to fix unsigned mail when the key is published

Enable DKIM signing in the sending platform's admin console. In Google Workspace, complete the Start authentication step so the status reads that email is being authenticated with DKIM (Google Workspace: Set up DKIM). In Microsoft 365, set the Sign messages for this domain with DKIM signatures toggle to Enabled, or run Set-DkimSigningConfig -Identity <domain> -Enabled $true (Microsoft 365: Configure DKIM).
Match the published selector to the one the platform signs with. Read the s= tag the platform actually emits on a test message, then confirm the key at that selector name exists in DNS. If they differ, either publish the key at the selector the platform uses, or reconfigure the platform to sign with the selector you published.
Confirm the signing domain is yours. The d= tag must be your From domain (or its organizational domain) for DKIM to align under DMARC. If the platform signs with its own domain, find the option to sign with a custom domain and complete it; signing with the platform's domain leaves your domain unauthenticated.
Re-test with a fresh message. Send through the real path again and re-read the Authentication-Results: header. You are looking for dkim=pass with your domain in the d=. A move from none to pass confirms signing is now active; a move from none to fail means signing started but the published key or selector still does not match, which is a separate fix.

What this does not prove

A public DNS check reads the key record at a selector you name and reports whether v=DKIM1 and a non-empty p= are present. It cannot see your message stream, so it cannot tell you whether the platform is actually signing, which selector a given message used, or what d= your live mail carries. Those answers live in message headers from a real delivery, not in the zone.

A healthy key record is necessary but not sufficient. The record being correct does not mean mail is signed; it means the key is available if and when the platform signs with it. The only proof that signing works end to end is dkim=pass for your domain in the Authentication-Results: header of a message that travelled your real sending path. If the key record itself is missing rather than the signature, that is a different diagnosis (see the missing-key case below).

Frequently asked questions

My DKIM record is published and correct, so why do messages still show dkim=none?

Because publishing the public key in DNS does not put a signature on your mail. DKIM only verifies a `DKIM-Signature:` header that is actually present on the message, and a verifier extracts that header from the message rather than from your zone. If the sending platform was never enabled to sign, no header is added, so the verifier has nothing to check and the Authentication-Results show `dkim=none`. The fix is at the platform, not in DNS.

What is the difference between dkim=none and dkim=fail?

`dkim=none` means no `DKIM-Signature:` header naming your domain was present, so there was nothing to verify. `dkim=fail` means a signature was present and named your domain, your published key was fetched, and the cryptographic check did not pass. None is a signing problem you fix at the platform; fail is a key, selector, or body-hash problem. They have different causes and different fixes, so read the `dkim=` token before changing anything.

The platform says my mail is DKIM-signed, but DMARC still does not align. Why?

Some platforms sign every message with a `d=` domain they own rather than your From domain. The message is signed and reports `dkim=pass`, but for the platform's domain, not yours. Against your domain the result is effectively none, and DMARC alignment fails. Read the `d=` tag in the `DKIM-Signature:` header: if it is the platform's domain, switch the platform to sign with your custom domain.

I see a DKIM-Signature header but the verifier still reports no key. What now?

Check the `s=` selector in the signature against the selector whose key you published. The verifier queries `<s=>._domainkey.<d=>`, so if the platform signs with a selector different from the one you published, the lookup lands on a name with no key even though a key exists elsewhere in your zone. Either publish the key at the selector the platform uses, or reconfigure the platform to sign with the selector you published.

Should I edit or re-add the DNS record to fix dkim=none?

No, not if the record is already correct at the right selector. A `none` result means the signature is missing, not that the key is wrong. Editing or re-adding a healthy key record changes nothing about whether mail is signed. Enable signing in the platform admin console first, then re-test and confirm `dkim=pass` for your domain in a real message header.

References

Browse all guides →