5.7.21

Enhanced Status Code 5.7.21: No Acceptable DKIM Signature Found

Permanent failure High severity Authentication RFC 7372
What it means

Enhanced Status Code 5.7.21 means “No Acceptable DKIM Signature Found.” The message carried DKIM signatures that verified correctly, and the receiver rejected them anyway because none met its policy. Passing is not the same as being acceptable.

At a glance
Code5.7.21
Bounce typeHard (permanent)
SeverityHigh
CategoryAuthentication
What to doSuppress the address; do not retry
StandardRFC 7372
What it looks like in your mail logs 
550 5.7.21 No acceptable DKIM signature found: signing key does not meet policy requirements

What does 5.7.21 mean?

Enhanced status code 5.7.21 means no acceptable DKIM signature was found. RFC 7372 is precise about the difference from 5.7.20: here the message does contain one or more passing signatures, but none of them are acceptable to the receiver. Verification succeeded and policy still refused.

Acceptability is a local decision and receivers apply it differently. A signature may be rejected because the key is too short, and 1024-bit RSA keys are increasingly treated as weak where 2048 is expected. It may use a hash algorithm the receiver has retired, which is what happened to SHA-1. It may cover too little of the message, since a signature with a short l= body length tag leaves the remainder unprotected and can be exploited to append content. Or the signing domain may simply not be one the receiver is willing to accept for this mail.

This code is rarer than 5.7.20 but far more informative when it appears, because it tells you the mechanics are working and the problem is the quality of what you are signing with. It is usually fixed by rotating to a stronger key rather than by fixing DNS or signing configuration.

How 5.7.21 plays out

Your server attempts delivery
The recipient server returns a permanent 5.7.21 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.21 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.21 is✓ this code

Common causes of 5.7.21

  • The DKIM key is 1024-bit RSA where the receiver expects at least 2048
  • The signature uses a hash algorithm the receiver has retired, such as SHA-1
  • The signature carries an l= body length tag, leaving part of the message unprotected
  • The signature omits headers the receiver requires to be covered, such as From or Subject
  • The signing domain is not one the receiver accepts for this mail stream
  • The key has been published for so long that the receiver treats it as stale

How to fix 5.7.21

  • Rotate to a 2048-bit RSA key, or Ed25519 where both ends support it
  • Sign with SHA-256 and stop offering SHA-1
  • Remove the l= body length tag so the whole message body is covered
  • Ensure the signature covers From, Subject, Date and To at minimum
  • Rotate DKIM keys on a schedule rather than leaving one in place indefinitely
  • Confirm the signing domain aligns with From so DMARC is satisfied as well

Frequently asked questions

What is the difference between 5.7.20 and 5.7.21?
A significant one. 5.7.20 means no DKIM signature passed verification, so either nothing signed the message or the signature was broken. 5.7.21 means a signature did pass, and the receiver rejected it on policy grounds anyway. The first is a configuration failure, the second is a quality judgement about your key or signing practice.
Why would a valid DKIM signature be unacceptable?
Most often key length. A 1024-bit RSA key still verifies correctly but is increasingly treated as too weak, and receivers have been raising the floor to 2048. Retired hash algorithms, signatures using the l= body length tag, and signatures that fail to cover important headers are the other common reasons a technically valid signature is refused.
What is the l= tag and why does it matter?
It records how many bytes of the body the signature covers, so anything appended beyond that length is unsigned and can be altered without breaking the signature. That is exploitable, and receivers penalise or refuse signatures that use it. Sign the whole body: omit l= entirely.
How do I move to a 2048-bit DKIM key safely?
Publish the new key under a new selector first, leaving the existing one in place. Switch signing to the new selector and confirm messages verify against it. Only then remove the old DNS record, after enough time has passed for anything in flight to have been delivered. Rotating in place breaks mail that is already queued.
Is Ed25519 better than RSA for DKIM?
It produces much shorter keys and DNS records for equivalent strength, which sidesteps the record-splitting problems long RSA keys cause. Support is not universal, so the practical approach is to publish both an Ed25519 and a 2048-bit RSA signature and let each receiver use whichever it understands.

Related bounce codes

5.7.20 No Passing DKIM Signature Found 5.7.22 No Valid Author-Matched DKIM Signature Found 5.7.26 DMARC Authentication Failed 5.7.23 SPF Validation Failed 5.7.1 Delivery Not Authorized - Message Refused

Sources & further reading

RFC 7372 · The standard that defines this reply code RFC 7372 · Email authentication status codes, which define the DKIM and SPF codes IANA registry · The authoritative list of enhanced status codes and their meanings
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes