Dr.Who
← blog

dkim=none (message not signed): what it means and how to fix it

· dkim · email · dmarc · authentication · deliverability

dkimemaildmarcauthenticationdeliverability

dkim=none means the receiving server found no DKIM-Signature header on the message at all — nothing was signed, so there was nothing to verify. This is different from dkim=fail, where a signature was present but did not verify (wrong key, mangled body, expired record), and from dkim=pass, where a signature verified cleanly. A none result is not an error in the cryptography; it means the sending source never applied DKIM in the first place.

How to read the result

DKIM results show up in the Authentication-Results header that the receiving server stamps on inbound mail. Open a delivered message, view the original/source, and look for a line like:

Authentication-Results: mx.google.com;
  dkim=none (message not signed) [email protected];
  spf=pass ...

The parenthetical (message not signed) is the tell. There is no header.d= or header.s= selector to inspect because no signature exists — unlike a healthy stream, which reads dkim=pass header.s=selector1.

Why a stream ends up unsigned

Three common causes, roughly in order of how often we see them:

  • DKIM signing was never enabled at the source. The most common case. The mailbox provider or app can sign, but no one turned it on or published the key.
  • The mail went out through a path that does not sign. A second ESP, a CRM, a help-desk/ticketing system, a multifunction printer's "scan to email," a monitoring tool, or a forgotten relay. These often send as your domain but were never wired into your DKIM setup.
  • An intermediary stripped the header. A forwarder or a poorly behaved mail gateway rewrote or removed the DKIM-Signature in transit. Rarer, but it happens.

Why dkim=none is a DMARC problem

On its own, an unsigned message is not automatically rejected — DMARC passes if either SPF or DKIM passes with alignment. The danger is when dkim=none combines with broken SPF alignment. If a stream is unsigned and its SPF passes only on the ESP's bounce domain rather than your From: domain, DMARC has nothing left to pass on, and the message fails. Under p=quarantine or p=reject that means your own legitimate mail lands in spam or bounces.

That is the rule worth internalising: every legitimate sender must sign. DKIM is the alignment mechanism that survives forwarding, where SPF often does not — so an unsigned stream is one SPF misconfiguration away from a deliverability incident.

How to fix it

  1. Enable DKIM on every sending source. Walk your DMARC aggregate reports, list every service sending as your domain, and turn on signing for each.
  2. Confirm outbound mail carries the header. Send a test to a mailbox you control, view the source, and verify a DKIM-Signature: header is present with d=yourdomain.com.
  3. Publish the matching selector record. The signature names a selector; publish its key at selector._domainkey.yourdomain.com as a TXT record. Check it with:
dig +short TXT selector1._domainkey.yourdomain.com

If that lookup is empty, the receiver cannot fetch the public key even when the source signs — so resolve the DNS side and the signing side together.

Check whether your domain is signed and the selector resolves →

Further reading