5.7.20

Enhanced Status Code 5.7.20: No Passing DKIM Signature Found

Permanent failure Critical severity Authentication RFC 7372
What it means

Enhanced Status Code 5.7.20 means “No Passing DKIM Signature Found.” The receiving server required a valid DKIM signature and your message did not carry one that passed. Either nothing signed the message, or a signature was present and failed verification.

At a glance
Code5.7.20
Bounce typeHard (permanent)
SeverityCritical
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7372
What it looks like in your mail logs
550 5.7.20 Message rejected: no passing DKIM signature found for the sending domain

What does 5.7.20 mean?

Enhanced status code 5.7.20 means no passing DKIM signature was found. RFC 7372 defines it for a message that did not contain any DKIM signature that verified, and it covers both halves of that: a message with no DKIM-Signature header at all, and a message that carried one which failed. The receiver has a local policy requiring DKIM and your message did not satisfy it.

A signature can be present and still fail for several distinct reasons. The public key may be missing from DNS at the selector named in the header, which is the most common single cause and usually means the DNS record was never published or was published at the wrong name. The message may have been modified in transit by a mailing list, a forwarding service, or an appliance that appends a footer, which invalidates the body hash. The key may have been rotated at the signer without the DNS record being updated. Or the signing domain may not align with the From header, which passes DKIM but fails DMARC.

Since February 2024, when Google and Yahoo began requiring authentication from bulk senders, this class of rejection stopped being an edge case. Any domain sending meaningful volume needs DKIM signing that verifies and aligns, and needs it on every path the mail can take, including the forwarding and list paths that break signatures.

How 5.7.20 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.20 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.7.20 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
5.7.20 is✓ this code

Common causes of 5.7.20

  • No DKIM-Signature header was added, because signing is not enabled at the sending platform
  • The public key is not published in DNS at the selector named in the signature
  • The message body was altered in transit, so the body hash no longer matches
  • The signing key was rotated without the DNS record being updated
  • The DNS record is malformed, split incorrectly across strings, or has trailing whitespace
  • A mailing list or forwarder re-wrote the message and broke the original signature

How to fix 5.7.20

  • Enable DKIM signing at every platform that sends as your domain, not only the main one
  • Verify the public key resolves at selector._domainkey.yourdomain.com using DKIM Record Checker
  • Send a test message and read the Authentication-Results header for the exact failure reason
  • Make sure the signing domain aligns with the From header so DMARC passes as well as DKIM
  • Re-publish the DNS record after any key rotation and allow for TTL before switching keys
  • For mail that traverses lists or forwarders, check whether ARC is preserving the original result

Frequently asked questions

What does SMTP error 5.7.20 mean?
It means the receiving server found no DKIM signature on your message that passed verification, and its local policy requires one. That covers two situations: the message was never signed, or it was signed and the signature failed. The receiver does not distinguish between them in the code, so the first diagnostic step is to determine which of the two you are looking at.
How do I tell whether my message was unsigned or the signature failed?
Send a test message to an account you control and read the raw headers. If there is no DKIM-Signature header, nothing signed it and the problem is at your sending platform. If the header is present, look at Authentication-Results for a dkim= result: dkim=fail with a body hash error means the message was modified in transit, while dkim=permerror or a key lookup failure means the public key is missing or malformed in DNS.
Why does DKIM fail only for some recipients?
Almost always because those recipients are behind a mailing list or a forwarding service that modifies the message. Adding a footer, rewriting a subject line, or converting the body invalidates the body hash and the signature fails even though it was valid when sent. ARC exists to carry the original authentication result across those hops, so check whether the intermediary is applying it.
Is 5.7.20 the same as an SPF failure?
No, and it is worth being precise because the two are easy to confuse. 5.7.20 is DKIM: no passing signature. A failed SPF check has its own registered code, 5.7.23, and an SPF evaluation error is 5.7.24. If both mechanisms failed and the domain publishes a DMARC policy, you are more likely to see 5.7.26.
Do I still need DKIM if SPF already passes?
Yes. Since February 2024 Google and Yahoo have required bulk senders to authenticate with both SPF and DKIM, and DKIM is the mechanism that survives forwarding while SPF does not. A domain relying on SPF alone will pass direct delivery and fail the moment a message is forwarded, which shows up as inconsistent, hard-to-reproduce delivery problems.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes