5.7.21 bounce: no acceptable DKIM signature found

What it means

X.7.21 is defined in RFC 7372 as “no acceptable DKIM signature found”. At least one signature verified cryptographically, but none satisfied the receiver’s local requirements. The signature works; it just is not the kind the receiver wanted.

Typical local requirements are a minimum key length (1024 bits is the floor at many receivers, 2048 is recommended), a signature that covers certain headers such as From and Subject, a signature that is not expired (x= tag), or a signer domain the receiver trusts for that sender.

Contrast 5.7.20, where nothing verified, and 5.7.22, where the issue is specifically that no passing signature matches the author domain. A 4.7.21 may appear when the receiver could not finish evaluating its policy and wants a retry.

Likely causes

• A 512-bit or 768-bit DKIM key that the receiver considers too weak.
• A signature that does not include the From header in its h= list.
• An expired signature, because the x= expiry tag is very short and the message was queued for a while.
• A signature only from a third-party platform domain that the receiver will not accept on behalf of your brand.

Checks that apply

• DKIM Check Shows the key type and length for your selector, so you can see whether a short key is behind the refusal.
• Email Header Analyzer Lists the signed headers, expiry and signing domain in a sample message, which is what receivers judge for 5.7.21.

FAQ

If DKIM passes, why is it not acceptable?

Passing only means the maths worked. Receivers may still require stronger keys, specific signed headers or a particular signing domain.

Do I need to change DNS to fix it?

Often yes, when it is a short key: publish a new 2048-bit key under a new selector and switch the signer to it.