5.7.20 bounce: no passing DKIM signature found

5.7.20No passing DKIM signature foundPermanent: retrying will not help

Typical wording
550 5.7.20 No passing DKIM signature found

What it means

RFC 7372 (Email Authentication Status Codes) registered X.7.20, “no passing DKIM signature found”, normally sent with reply 550. The receiver checked the message for DKIM, and either it had no signature at all or every signature it carried failed verification.

This is the broadest of the three DKIM codes. 5.7.21 means signatures passed but none was acceptable under local policy, and 5.7.22 means none passed from a signer that matches the author (From) domain. With 5.7.20 nothing verified, whatever the domain.

RFC 7372 also allows the 4-class form when the failure might be temporary, for instance when the public key lookup failed with a DNS error. A permanent 5.7.20 says the signature is broken or missing.

Likely causes

  • The sending service is not signing at all, because DKIM was never enabled for your domain there.
  • The public key record at `selector._domainkey.example.com` is missing, truncated or has the wrong value.
  • A footer, disclaimer or link rewriter modified the body or signed headers after signing, so the body hash no longer matches.
  • Key rotation removed the old key from DNS while mail signed with it was still in queues.

How to fix it

  1. Open the headers of a message you sent to an outside mailbox and look at the DKIM-Signature (d= and s= tags) and the Authentication-Results line.
  2. Look up the selector’s TXT record and compare it with the public key your sending service shows; it should start with `v=DKIM1; k=rsa; p=`.
  3. Enable DKIM signing in every service that sends as your domain, including newsletters and helpdesks.
  4. Move footers and link rewriting before the signing step, or exempt signed mail from them.
  5. When rotating keys, publish the new selector first and keep the old record for a few days.

Checks that apply

  • DKIM Check Fetches the selector’s public key and checks its syntax and key length, the first thing to rule out for 5.7.20.
  • Email Header Analyzer Reads the DKIM-Signature and Authentication-Results of a sample, showing whether the failure was a body hash or a key problem.
  • DMARC Check Shows whether your DMARC policy depends on DKIM, so you know how much a broken signature hurts delivery.

The classification runs without network lookups and we never store your paste.

FAQ

My DKIM record exists; why 5.7.20?
The record may be fine while the signature fails, because something changed the message after signing. The Authentication-Results header usually says “body hash did not verify” in that case.
Is 5.7.20 a DMARC failure?
Not exactly. It reports DKIM alone. A DMARC failure is usually reported with 5.7.26 or a provider-specific code.

All 191 bounce codes