Cause · impact · fix
dkim=none
The receiver looked for a DKIM signature and found none, so it had nothing to verify. Here is why the message went out unsigned, what it costs you, and how to get it signing.
What it means
The cause.
dkim=none is a result a receiver writes into the Authentication-Results header. Under RFC 8601 the value "none" for DKIM means one thing precisely: the message carried no DKIM-Signature header, so there was nothing to verify. It is not a failed check — it is the absence of a check.
This is different from dkim=fail. A fail means the message was signed but the signature did not verify — wrong key, altered body, expired signature. A none means no signature was ever applied. If you are seeing dkim=none, the fix is not to repair a broken key; it is to start signing in the first place.
It usually appears for one of three reasons: DKIM signing is simply not switched on at your sending platform; you send through a service (a CRM, a newsletter tool, a transactional provider) that has not been configured to sign as your domain; or a signature is being added but for a different domain than your From: address, so the receiver reports no aligned signature for you.
Why it matters
The impact.
On its own an unsigned message is not always rejected, but it strips out one of the two ways you can authenticate. DKIM is the more robust of the two: unlike SPF it survives forwarding and does not break when mail is relayed, so leaning only on SPF leaves you fragile.
The real cost is through DMARC. DMARC passes only when SPF or DKIM passes and aligns with your From: domain. With dkim=none you are relying entirely on SPF alignment — and the moment SPF also fails or breaks in transit, DMARC fails with it. Since 2024 Gmail, Yahoo and Microsoft require bulk senders to pass DMARC, so an unsigned stream that loses its SPF leg lands in spam or is rejected outright.
What to do
The fix, in order.
Work top to bottom, then re-check — DNS changes take a few minutes to take effect.
- 1 Confirm the message is genuinely unsigned. Open a delivered message and read the Authentication-Results header, or send one through the email tester. dkim=none confirms no signature was present — as opposed to dkim=fail, which means a signature was there but did not verify. The two need different fixes, so be sure which you have.
- 2 Turn on DKIM signing at every sending service. DKIM is enabled per platform, not once for the domain. Your main mailbox provider, your marketing tool, your helpdesk and your transactional sender each sign independently. Find the DKIM or domain-authentication setting in every service that sends as your domain and enable it.
- 3 Publish the DKIM public key your provider gives you. When you enable signing, the platform issues a selector and a public key to publish as a TXT (or CNAME) record — typically at selector._domainkey.yourdomain.com. Add exactly what they supply. The private key stays with them; only the public half goes in DNS.
- 4 Make sure the signing domain aligns with your From:. Some services sign with their own domain by default, which still reads as dkim=none for you because the signature is not aligned. Configure custom or branded domain authentication so the d= tag in the signature matches the domain in your From: address.
- 5 Send a test and read the result back. After DNS propagates, send a fresh message and check the Authentication-Results header shows dkim=pass with your domain in the d= tag. Test each platform separately — one may sign correctly while another is still going out as none.
- 6 Verify DMARC now passes on DKIM. Once DKIM passes and aligns, your mail no longer depends on SPF alone to satisfy DMARC. Check that DMARC reports a pass via DKIM so a forwarded or relayed message still authenticates when SPF breaks.
Confirm the error is gone.
Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.
Common questions