SMTP error 5.7.21 No acceptable DKIM signature found

What SMTP error 5.7.21 means

The message carried at least one DKIM signature that verified, and the receiver declined it anyway because none of the signatures met its standard. The cryptography worked; the policy did not accept the result. It arrives as 550 5.7.21 and is much less common than an outright verification failure. When it happens the answer is in the properties of the signature itself, most often a weak key, an expired signature or too little of the message covered.

Security or policy status
Sent by The receiving mail server, applying its own policy to a signature that verified correctly
Rare

What SMTP error 5.7.21 No acceptable DKIM signature found actually means

A signature can be mathematically valid and still be worth nothing to the site receiving it. Some receivers will not credit an RSA key shorter than 2048 bits, or a signature computed with SHA-1. Some require the signature to cover the headers they care about, so a signature over three headers that leaves the subject unprotected buys no trust. Some weigh the reputation of the signing domain and decline a signature from a shared platform name with a poor history behind it. RFC 7372 keeps this separate from a plain failure precisely so a receiver can say the difference out loud, and 5.7.22 narrows it further to the one case of the signing domain not matching the author. Only the permanent form is registered.

This status code is returned when a message contains one or more passing DKIM signatures, but none are acceptable. (This violates the advice of Section 6.1 of [RFC6376].)
— RFC 7372 with RFC 6376

How 5.7.21 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.21 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.21 on a business phone system

A 1024-bit key or an SHA-1 signatureShort keys were the norm a decade ago and get carried forward untouched through platform changes. They still verify, and a growing number of receivers score them as no better than unsigned.
The signature has expiredAn x= tag sets a wall-clock expiry on the signature. A message held in a queue or in a quarantine for longer than that window arrives with a signature that verifies against a moment which has passed.
Too few headers coveredThe h= tag lists what was signed. A minimal list leaves subject, date and reply-to unprotected, so an attacker could alter them without breaking anything, and a cautious receiver declines to treat the signature as meaningful.
A body length tag limiting what was signedThe l= tag signs only the first so many bytes of the body, which permits content to be appended afterwards without detection. Several receivers refuse such signatures on principle rather than accept a partial guarantee.
A signing domain the receiver does not rateWhere the signature belongs to a shared domain used by thousands of senders on a low-cost platform, some receivers treat it as carrying no useful reputation and reject rather than accept a signature that tells them nothing.

How to fix SMTP error 5.7.21

Read the tags on a rejected signatureThe DKIM-Signature header shows a= for the algorithm, h= for the headers covered, l= if body length is limited and x= for expiry. Those four values usually contain the answer without any further investigation.
Move to a 2048-bit key with SHA-256This is the current baseline and there is no argument for staying below it. Publish the stronger key alongside the old one, cut signing over once it resolves, and remove the old selector afterwards.
Sign a full header set and oversign the important onesCover From, Subject, Date, To, Reply-To and Message-ID at minimum, and list the critical headers twice so that adding a duplicate breaks the signature rather than sneaking past it.
Remove the body length tagIf your signer sets l=, turn it off. It exists to survive footers being appended, but the correct response to a footer problem is to stop appending after signing, not to sign less of the message.
Stop leaning on a platform's shared signing domainSigning under your own name gives the receiver a reputation to judge, which is the point of the exercise. It also removes any dependence on how other customers of that platform behave.

Fixing the underlying problem

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

Questions about SMTP error 5.7.21

One customer rejects us this way and nobody else does. Is it worth the effort?

Yes, if that customer matters commercially, and probably yes regardless. Receivers tighten these thresholds over time and the site rejecting you today is usually a year ahead of the rest. Whatever it objected to will start costing you elsewhere.

Will rotating our key fix it?

Only if you change something about the key while you rotate. Publishing a fresh 1024-bit key changes the value and none of the properties the receiver objected to. Rotate to 2048 bits with SHA-256 and the rotation becomes worthwhile.

How do we tell this apart from a signature that simply failed?

By the code. A signature that did not verify produces 5.7.20, which means the receiver had nothing valid to work with. This one means a signature verified and was judged insufficient, so your key and your signing configuration are where to look rather than your DNS.

Related SMTP status codes

Source. SMTP error 5.7.21 No acceptable 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