DKIM Signature Failed: What It Means and How to Fix It

The short answer: dkim=fail means the receiving server found a DKIM signature but couldn't verify it — the public key in DNS doesn't match, or the message was altered in transit. dkim=none means no signature was present at all. The six most common causes are: DKIM not configured, wrong DNS selector, key mismatch, message modification in transit (mailing lists, forwarding), DNS propagation delay, and an RSA key exceeding the 255-character DNS TXT record limit.

When a receiving mail server reports dkim=fail in your email headers, it means the DKIM signature on your email couldn't be verified. The server found a signature, looked up your public key in DNS, attempted to verify — and the verification failed.

This is different from dkim=none, which means no signature was found at all. A failed signature is actively suspicious: the email claimed to be signed but the signature doesn't check out.

The result depends on your DMARC policy. With p=none, it's logged but delivered. With p=quarantine or p=reject, failing emails go to spam or get blocked entirely.

Here are the six most common causes of DKIM signature failures and how to fix each one.

How to Confirm DKIM Is Failing

Before debugging, confirm what's actually happening. Two ways:

1. Check the email headers. Open a received copy of your email in Gmail or Outlook and view the raw headers. Look for Authentication-Results. It will show something like:

Authentication-Results: mx.google.com;
  dkim=fail header.i=@yourdomain.com header.s=google header.b=abc123

The header.s= field shows which selector is being used. The header.i= shows which domain is being signed.

2. Use a DKIM validator. Enter your domain and the selector shown in the headers.

Check your DKIM record now — free DKIM Validator at EmailAudit.io

Cause 1: DKIM Is Not Set Up

The most common cause of dkim=fail or dkim=none is that DKIM simply hasn't been configured on your email platform. Signing doesn't happen by default on all providers.

Google Workspace: Go to Admin Console → Apps → Google Workspace → Gmail → Authenticate email. Generate a new DKIM key and publish it in DNS.

Microsoft 365: Go to Security → Email & collaboration → Policies & rules → Threat policies → DKIM. Enable DKIM signing for your domain — it is not active by default.

Other platforms: Check your provider's documentation for "DKIM setup" or "email authentication". They will provide the selector name and the DNS record value to publish.

Once published, allow up to 48 hours for DNS propagation before testing again.

Cause 2: The DNS Record Doesn't Exist or Has the Wrong Selector

DKIM signatures include a selector in the email header (header.s=). The receiving server uses that selector to look up [selector]._domainkey.[yourdomain.com] in DNS.

If the DNS record doesn't exist at that selector, verification fails immediately.

How to check: Look at your email headers for the header.s= value, then check whether a TXT record exists at [selector]._domainkey.[yourdomain.com]. The DKIM Validator tool does this automatically — enter your domain and it probes 22+ common selectors to find which ones have records published.

Fix: Publish the correct DKIM TXT record for the selector your email platform is using. If you've changed providers or rotated keys, ensure the old selector is still published until all in-flight mail has been delivered.

Cause 3: The Public Key Doesn't Match the Private Key

DKIM uses a key pair: the private key signs outgoing email (held by your mail server), and the public key verifies the signature (published in DNS).

If these keys are mismatched — for example, because a new key was generated but only one side was updated — verification will fail every time.

How this happens:

You generated a new DKIM key in your email platform but published the old public key in DNS (or vice versa)
You migrated to a new server or service and the private key wasn't carried over correctly
A platform auto-rotated its signing key without you updating DNS

Fix: Regenerate the DKIM key pair in your email platform. The platform will give you a new public key to publish in DNS. Replace the existing TXT record with the new value and allow up to 48 hours for propagation.

If you need to format the DNS record manually, use a DKIM record generator.

Build your DKIM DNS record — free DKIM Record Generator at EmailAudit.io

Cause 4: The Email Was Modified in Transit

DKIM signs specific headers and the email body at the moment of sending. If anything in the signed content is modified after the signature is applied, verification fails.

Common culprits:

Mailing list software that adds a footer to the message body
Email forwarding services that modify headers
Antivirus or content filtering gateways that rewrite content
Email aliasing services that alter the message path

This is a structural problem, not a configuration error. The signature was valid when applied but the email was changed before the receiving server could verify it.

Fix options:

Use l= tag in DKIM to sign only part of the body (allows footers to be added without breaking the signature — though this reduces security slightly)
Work with the mailing list or forwarding service to avoid body modification
Use ARC (Authenticated Received Chain) — a newer standard that preserves authentication results through forwarding chains. Gmail and Microsoft 365 support ARC.

Cause 5: DNS Propagation Hasn't Completed

If you recently published or updated a DKIM record, it may not yet be visible to all receiving servers. DNS changes propagate across the internet gradually, typically within a few hours but sometimes up to 48 hours.

How to check: Use a DNS lookup tool to query [selector]._domainkey.[yourdomain.com] from multiple locations. If the record isn't returning consistently, propagation is still in progress.

Fix: Wait. Test again after 48 hours. If the record still isn't visible, check that you published it at the correct subdomain and with the correct record type (TXT, not CNAME).

Cause 6: Key Too Long for DNS

RSA-2048 DKIM keys produce a public key string longer than 255 characters. DNS TXT records have a maximum of 255 characters per string, so long keys must be split across multiple quoted strings.

Some DNS providers do this automatically. Others require you to manually split the key.

A correctly formatted multi-string DKIM record looks like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA" "4f8nKf3Lk..."

Note the two separate quoted strings — DNS treats them as one continuous value.

Fix: Check how your DNS provider handles long TXT records. If the record appears to exist but verification keeps failing, the key may be truncated. Re-publish with correct string splitting, or switch to an RSA-1024 key (less secure but within the single-string limit).

Checking All Three Together

DKIM failures rarely exist in isolation. If DKIM is failing, check SPF and DMARC at the same time — a misconfiguration in one often signals issues in the others.

Run a full authentication check — free Email Security Score at EmailAudit.io

The security score runs SPF, DKIM, DMARC, blacklist, and MTA-STS checks simultaneously and shows exactly which components are failing and why.

Related Guides

Still getting DKIM failures after checking the above? Get a free Full Audit PDF at EmailAudit.io — a branded report showing your exact DKIM status, selector results, and recommended next steps. No account required.