5.2.0SMTP 5.2.0: Generic mailbox status requires the full reply

X.2.0 is the mailbox-status subject with the other or undefined detail, and this catalog carries no IANA class confirmation for the pattern. Concrete 5.2.0 is corpus-evidenced rather than class-confirmed: Comcast uses it for a DMARC rejection, and Microsoft documents it in Exchange Online for a missing or invalid recipient primary SMTP address and for permanent exceptions raised while the mail store processes the message. Those uses do not agree on a cause, which is what the undefined detail means in operational terms.

The digits report that a mailbox-status condition applied and that the responder assigned no defined detail to it. Three distinct conditions are documented behind them: a sender-domain authentication policy result, which concerns the sending domain and not the mailbox; a recipient primary SMTP address that is missing or invalid in the receiving directory; and a permanent exception raised while the recipient mail store processed the message. No one of those is the universal meaning of 5.2.0. The free text that accompanies the code is the only part of the reply that identifies which condition applied.

Class 5 is permanent for the unchanged send, and both 550 and 554 basic replies are documented carrying this detail, the 554 pairing in Exchange Online only. Permanence describes the attempt as it was sent, not the recipient address: it does not prove an invalid mailbox and does not mandate global suppression.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Stop unchanged retries; the same message on the same route returns the same result. A new attempt is authorized only after the condition named in the response text has been changed and re-verified: sender-domain SPF, DKIM, or DMARC configuration where the response names a domain policy, or the recipient object in the receiving directory where the response names the recipient primary SMTP address or a permanent processing exception in the mail store. Sending to a different address is a new route, not a retry of this attempt.

The digits 5.2.0 alone never justify automatic suppression of the recipient. The code carries no evaluation of whether the address exists or accepts mail: a domain-policy branch evaluates the sending domain, and a directory or mail-store branch reports a defect on the receiving side that its administrator can correct. Suppress only where the full response text independently establishes that the address is not deliverable, and store that text with the decision.

• The receiving system applied a sender-domain authentication policy and reported the result under this generic detail. Comcast Xfinity Mail SMTP is documented returning “550 5.2.0 Message rejected due to DMARC” with a pointer to its own error-code reference.
• The recipient primary SMTP address is missing or invalid in the receiving directory, so the receiving system cannot resolve the recipient object it already accepted. Microsoft documents this for Exchange Online as “550 5.2.0 RESOLVER.ADR.BadPrimary; recipient primary SMTP address is missing or invalid”, published at https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/badprimary-ndr.
• The recipient mail store raised a permanent exception while processing an already accepted message. Microsoft documents two Exchange Online cases under these digits: “554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException.MapiExceptionNotFound; Failed to process message due to a permanent exception with message Cannot get ID from name”, published at https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr/mapiexceptionnotfound-ndr, and a meeting-invite case reported as “554 5.2.0 STOREDRV.Deliver.Exception:DelegateUserValidationException; Failed to process message due to a permanent exception with message Delegate user validation failed for user”, where the documented line continues with a delegate-name placeholder the server fills in at rejection time and a processing-stage marker, published at https://learn.microsoft.com/en-us/troubleshoot/exchange/email-delivery/ndr-5-2-0-when-sending-meeting-invites.

1. Confirm that the enhanced code is exactly 5.2.0 and record which basic reply carried it. Both 550 and 554 are documented with this detail, 554 in Exchange Online only, and the basic reply does not by itself identify the condition.
2. Identify the system that issued the response and whether it arrived in the SMTP session or as an asynchronous non-delivery report, then retain the full response text, the sending domain, the recipient address, the receiving host, the message identifier, and the attempt time.
3. Read the free text after the digits to separate the candidate causes. A sender-domain policy result such as a DMARC rejection points at the sending domain; a recipient subcode such as RESOLVER.ADR.BadPrimary points at the recipient object in the receiving directory; a STOREDRV.Deliver.Exception subcode points at a permanent processing exception in the recipient mail store. Assign no branch the text does not name.
4. Send again only after the owner of the named condition has changed and re-verified it. An unchanged message on the same route reproduces the same result regardless of which branch applied.