TL;DR
Permanent rejection: DKIM verified but no signature met the receiver acceptance rules. Align selector, domain, and policy before retrying. Authentication gaps can damage sender reputation and deliverability. Do not retry unchanged.
What this code means
One or more DKIM signatures can pass cryptographic verification and still fail local acceptance; registry pattern X.7.21 then surfaces as code 5.7.21. Class 5 marks a permanent security-policy refusal for this attempt. Verification succeeded for at least one signature, but local acceptance rules rejected every passing option. The status does not explain which rule failed, whether selector, signing domain, or receiver policy is at fault, or which party owns the gap. By definition this violates the guidance in RFC 6376 Section 6.1.
Technical meaning
Passing DKIM verification without any of those signatures meeting the receiving system's acceptance criteria is the X.7.21 case. By definition that outcome violates the advice in Section 6.1 of RFC 6376. Code 5.7.21 applies this detail in the permanent-failure class.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. The code confirms that at least one DKIM signature passed verification, but it does not explain why none was accepted or identify which party is responsible for the result.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after establishing the cause and making a confirmed change that allows at least one passing signature to be accepted; check suppression again first.
Suppression decision
Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.21 alone. Inspect the complete response, DKIM results, configuration of the systems involved, and event history, then make the suppression decision according to the confirmed cause and applicable policy.
Common causes
- The direct reason for rejection was that at least one DKIM signature passed verification, but the receiving system did not consider any passing signature acceptable.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm the exact 5.7.21 code and a basic reply in the 5xx class; retain the complete response text.
- Correlate the response with the intended message, attempt time and stage, and system that returned the code. In the message copy from the evaluation point, inspect DKIM-Signature headers and available verification results to confirm that at least one signature passed.
- Inspect logs and configuration across signing, transport, and the receiving DKIM evaluation to establish why no passing signature was accepted; do not assign responsibility from the code alone.
- Stop unchanged retries. After a confirmed correction, verify that at least one passing signature is accepted, check suppression again, and make one controlled attempt.
Actions by owner
Sender
- Do not repeatedly send the same unchanged message; give the administrator the complete response and attempt time without exposing message content or secrets.
Sender administrator
- Inspect the sent-message copy and signing and transport logs and configuration; confirm which DKIM signatures passed verification and coordinate diagnosis of why none was accepted.
- After the correction, confirm that at least one passing signature is accepted, check suppression again, and make one controlled attempt instead of retrying the unchanged message.
Recipient administrator
- If you manage the system that returned the code, inspect its DKIM evaluation logs and configuration for the specified attempt; establish why no passing signature was acceptable and correct a confirmed problem or safely give the sender the result needed for remediation.
Provider
- If you operate a managed signing, transport, or DKIM evaluation layer, inspect its logs and configuration for the attempt, correct a confirmed problem in that layer, and do not trigger suppression from the code alone.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 7372 — Email Authentication Status Codes — Status codes for SPF, DKIM, DMARC and related authentication results.
- RFC 6376 — DomainKeys Identified Mail (DKIM) Signatures — DKIM signature standard for authenticating email domains.
Last verified:
