"dkim=none" means the receiving mail server found no DKIM signature on your message at all. This is different from dkim=fail, where a signature was present but did not verify — dkim=none means nothing was signed in the first place. On its own it does not bounce mail, but it removes one of your two paths to passing DMARC, hurts deliverability, and leaves your domain easier to spoof. The fix is to enable DKIM signing on whatever platform sends your mail and publish the selector it gives you.
What It Looks Like
The verdict shows up in the Authentication-Results header. With dkim=none there is no selector or signing domain to report, because nothing signed the message:
# No signature was present
Authentication-Results: mx.google.com;
dkim=none (message not signed);
spf=pass smtp.mailfrom=example.com;
dmarc=fail (p=NONE) header.from=example.com
# Some receivers phrase it as "no signature"
Authentication-Results: mx.example.net;
dkim=none header.d=none;
dmarc=pass (relying on SPF alignment only)Notice the difference from a signature failure: there is no header.s= selector and no header.d= signing domain. Contrast that with dkim=fail (bad signature), which does name a selector — the two verdicts have completely different fixes.
Confirm the verdict in the Email Header Analyzer
Why It Matters
dkim=none is not itself a rejection, but it weakens your mail in three ways:
- DMARC has only one leg to stand on. DMARC passes if SPF or DKIM passes and aligns. With no DKIM, you depend entirely on SPF alignment — which breaks on forwarding and when a provider uses its own Return-Path.
- Deliverability suffers. Mailbox providers treat unsigned mail as lower-trust; it is more likely to land in spam even when it is not rejected outright.
- Your domain is easier to spoof. DKIM is the durable, forward-surviving proof that a message really came from you. Without it, you lean on the weakest link.
dkim=none means no signature exists — you fix it by enabling DKIM signing. dkim=fail means a signature exists but did not verify — you fix that by correcting the published key, selector, or downstream message handling. Read the verdict before you start; the fixes do not overlap.Why It Happens
1. DKIM was never turned on
The most common cause. The sending platform supports DKIM but you never enabled it, so mail goes out unsigned. Many providers do not sign with your domain until you complete their DKIM setup.
2. Signing is enabled but the DNS records were never published
You switched DKIM on in the platform, but the CNAME/TXT selector records it asked you to add were never created in DNS — so the platform will not sign (or signs with a key nobody can verify, which some platforms downgrade to unsigned).
3. Mail is sent from a source you forgot to configure
Your primary mailbox provider signs fine, but a secondary sender — a CRM, billing system, contact form, or transactional API — sends unsigned because DKIM was only set up for the main platform. The unsigned stream is the one showing dkim=none.
4. A custom or self-hosted server is not signing
A self-hosted MTA (Postfix, Exim) sends unsigned unless a signing milter such as OpenDKIM is installed and configured. Out of the box it does not sign at all.
dkim=none. But SPF alignment breaks the moment a message is forwarded or sent through a service with its own Return-Path. Adding aligned DKIM is what makes DMARC reliable across all those cases.How to Diagnose It
First confirm mail really is unsigned (a missing DKIM-Signature header), then check whether a selector is published at all:
# In the raw message, is there a DKIM-Signature header?
# If absent, the message was never signed (dkim=none).
# Is any selector published for your domain?
# Try the selector your platform expects you to use:
dig TXT selector1._domainkey.example.com +short
dig TXT google._domainkey.example.com +short
# NXDOMAIN / empty means nothing is published there.How to Fix It
Fix A — Enable DKIM in your sending platform
In Google Workspace, Microsoft 365, SendGrid, Mailchimp, or whatever sends your mail, open the DKIM / email authentication settings and turn on signing for your domain. The platform generates a key pair and shows you a selector name plus the DNS record to publish.
Fix B — Publish the selector record it gives you
Add the record exactly as provided. Most ESPs hand you a CNAME pointing at their managed key (so they can rotate it for you); some give a raw TXT public key. Publish it verbatim under <selector>._domainkey.<domain>:
; Common: a CNAME to the provider's managed key
selector1._domainkey.example.com. 3600 IN CNAME selector1.dkim.provider.net.
; Or a raw TXT public key you publish yourself
selector1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB...IDAQAB"After publishing, return to the platform and click its "verify" / "authenticate" button so it starts signing. Many providers will not begin signing until they detect the record live.
Fix C — Sign every sending source
Repeat the process for each service that sends as your domain — the main mailbox provider and every secondary sender (CRM, helpdesk, billing, marketing). Each typically uses its own selector, so you may publish several _domainkey records. Use the DKIM generator if you need to create a key for a source that does not provide one.
Fix D — Turn on signing for a self-hosted server
For Postfix/Exim, install and configure OpenDKIM (or your platform's signing milter): generate a key pair, publish the public key at your selector, point the milter at the private key, and hook it into the MTA so outbound mail is signed. Then confirm the selector resolves before sending.
d= domain must align with your visible From: domain. Sign with your domain (or its organizational domain), not the provider's — otherwise you get dkim=pass that still fails DMARC alignment.Verify the Fix
DNS changes only take effect once the old record's TTL expires. After publishing and enabling signing, confirm the selector resolves, send a test message to a mailbox you control, and check that its headers now carry a signature and show dkim=pass:
# Confirm the selector now returns a valid key
dig TXT selector1._domainkey.example.com +short
# Send a test, then in the raw headers look for a DKIM-Signature header and:
# dkim=pass header.i=@example.com header.s=selector1 header.d=example.comYou can also send to a Gmail address and use Show original, or paste the full source into the Email Header Analyzer to confirm the message is now signed and aligned.
Frequently Asked Questions
Is dkim=none the same as dkim=fail?
No. dkim=none means the message was never signed, so there is nothing to verify. dkim=fail means a signature was present but did not check out. The first is fixed by enabling signing; the second by correcting the key, selector, or downstream handling.
Will dkim=none cause my mail to bounce?
Not directly. Many receivers accept unsigned mail if SPF passes and DMARC is satisfied. But it lowers trust and, if SPF alignment breaks (e.g. on forwarding), it can leave DMARC with nothing to pass on — turning into a reject.
I enabled DKIM but still see dkim=none — why?
Usually the selector record is not yet live, so the platform is not signing. Confirm the record resolves with dig, wait out the TTL, click the platform's verify button, then send a fresh test. Also check you enabled signing for the specific source that is sending unsigned.
Do I need a separate DKIM key for every sender?
Typically yes — each platform signs with its own selector and key, so you publish a _domainkey record per source. That is fine; DKIM supports many selectors on one domain.
Does enabling DKIM guarantee DMARC passes?
Only if the signature aligns — the signing d= domain must match your visible From: domain (relaxed alignment matches the organizational domain). Signing with the provider's domain gives dkim=pass without alignment, which does not satisfy DMARC.