SMTP error 5.7.20 No passing DKIM signature found

What SMTP error 5.7.20 means

Not one DKIM signature on this message verified. Either it carried no DKIM-Signature header at all, or every signature present failed its cryptographic check. It comes back as 550 5.7.20. The two everyday causes are a selector that was never published in DNS, and a message that was altered somewhere between being signed and being delivered so the hashes no longer agree.

Security or policy status
Sent by The receiving mail server, after attempting to verify the DKIM signatures on the message
Common

What SMTP error 5.7.20 No passing DKIM signature found actually means

DKIM hashes a chosen set of headers together with the body, signs that hash with a private key held by the sending platform, and publishes the matching public key in DNS under selector._domainkey.yourcompany.co.uk. The receiver repeats the calculation and compares. A failure means the arithmetic did not come out, so there is no cryptographic evidence that the message is intact. Note what the code does not say: it makes no judgement about which domain did the signing, only that nothing verified. It is registered in the permanent form alone, so the result is a hard bounce rather than a queued retry.

This status code is returned when a message did not contain any passing DKIM signatures. (This violates the advice of Section 6.1 of [RFC6376].)
— RFC 7372 with RFC 6376

How 5.7.20 appears in a bounce

A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists 550 5.7.20 as the pairing for this status.

The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.

What causes SMTP error 5.7.20 on a business phone system

The selector was never publishedThe signature names a selector in its s= tag and the receiver looks that name up. Where the CNAMEs or TXT records for it were never created at the DNS host, the lookup returns nothing and there is no key to verify against.
The key was rotated at the platform but not in DNSAnywhere the public key is pasted into DNS as a literal TXT value rather than delegated by CNAME, rotation is a two-party job. The platform starts signing with the new key, DNS still serves the old one, and every message fails from that moment.
Something edited the message after it was signedA disclaimer appliance appending a footer, a transport rule prefixing the subject with EXTERNAL, a security product rewriting links, or a discussion list adding a trailer. Any of these invalidates the body hash.
The published key record is malformedA 2048-bit key exceeds the 255-character limit for a single TXT string and has to be split correctly. Control panels handle that inconsistently, and a key that looks right in the editing screen can be served with a stray quote.
Two systems both signing on the way outA tenant signs, then an outbound gateway such as Mimecast or Proofpoint signs again. If the second stage alters headers the first stage covered, the original signature breaks even though both products are working as designed.

How to fix SMTP error 5.7.20

Take the selector from a failing message and look it upRead the s= and d= tags from the DKIM-Signature header, then query the TXT record at that selector under _domainkey for that domain. An empty answer ends the investigation immediately.
Send a test to a mailbox you own at a different providerA message to a personal Gmail or Outlook.com account gives you a full Authentication-Results header to read at leisure, without asking a customer to dig headers out of their client.
Separate a body hash failure from a signature failureA body hash mismatch means something changed the content in transit, so hunt for the appliance or rule doing it. A signature failure with a key that resolves points at header changes or a key that no longer matches.
Make signing the last thing that touches the messagePut disclaimer and branding tools ahead of the signer in the outbound path, or apply signatures at the client instead. Anything that edits content after signing will keep breaking DKIM no matter how many times you republish the key.
Rotate keys with an overlap, not a switchPublish the new selector, confirm it resolves everywhere, then move signing to it and retire the old one a week later. Better still, delegate by CNAME so the provider can rotate without anybody editing DNS.

Fixing the underlying problem

This page explains the code. These guides walk through the fix in detail.

Questions about SMTP error 5.7.20

Does this mean our message was tampered with?

Very rarely. The overwhelming majority of these are benign modification by something in your own outbound path, a footer tool or a subject-tagging rule, doing exactly what it was installed to do. Treat it as a configuration finding first and a security incident only if nothing in the path explains it.

We do not sign with DKIM at all. Is that why?

Yes, and this code covers both cases equally. A receiver that requires a passing signature does not care whether none was offered or all of them failed, since either way it has nothing to verify. Enabling DKIM on your mail platform is the fix.

Mail started bouncing right after we deployed a signature manager. Coincidence?

Almost certainly not. Signature and disclaimer products insert content into the body, and if they run after the signing stage the body hash no longer matches. Move the product earlier in the path or switch it to client-side insertion.

Related SMTP status codes

Source. SMTP error 5.7.20 No passing DKIM signature found is defined in RFC 7372 with RFC 6376 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.

All Email delivery & SMTP codes