5.2.0Generic mailbox-status rejection, evidenced as a DMARC policy failure

Mechanical IANA confirmation for registry pattern X.2.0 ("Other or undefined mailbox status") covers no class at all in this catalog: the registry lists Associated Basic Status Code as "Not given," and the canonical mirror leaves the pattern's resolution status unresolved. Code 5.2.0 nonetheless puts a permanent class on that generic catch-all detail in the mailbox subject family when no more specific status code fits. The concrete class-5 entry exists purely from exact, corpus-collected production evidence (the Comcast 550 5.2.0 response below, which names a DMARC policy rejection), not from any IANA class confirmation. Because that detail code is generic, the code does not establish one cause; providers can and do attach different specific reasons to the same enhanced code, so always read the full response text rather than treating "5.2.0" alone as a single diagnosis.

Comcast answers "550 5.2.0" when a message's sending domain fails DMARC authentication and alignment, pressing the generic detail code into service for a delivery-eligibility failure enforced by the recipient's mail system, not for a literally full or disabled mailbox; that exact corpus evidence is the sole reason concrete code 5.2.0 (class 5, permanent) appears here. Within the mailbox subject family (subject 2), X.2.0 is IANA's generic/undefined status: "the mailbox exists, but something about the destination mailbox has caused the sending of this DSN." RFC 3463 lays out the subject/detail scheme without fixing a class for every pattern. For X.2.0 itself, the registry's Associated Basic Status Code remains "Not given," and this catalog's canonical mirror stores classApplicability.resolutionStatus as "unresolved" (basis: iana_missing_class_evidence), so neither class 4 nor class 5 has mechanical IANA confirmation for the pattern.

The leading digit 5 denotes a permanent failure: in the accepted example, the rejection follows directly from the sending domain's own published DMARC policy and the message's authentication result at the time of the attempt, so resending the identical message will fail again for the identical reason. This differs from a hypothetical class-4 use of the same X.2.0 detail, which would describe a condition expected to clear on its own — no such class-4 concrete code is published in this catalog on the evidence available.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Do not retry the identical message unchanged: a DMARC-driven 5.2.0 will recur on every attempt until the sending domain's SPF/DKIM alignment or DMARC policy changes. Stop automatic retries of this send; escalate to the domain's authentication owner (sender_admin), and only resend after the domain's SPF, DKIM, or DMARC configuration has been corrected and re-verified.

Do not suppress or hard-bounce the recipient address based on 5.2.0 alone: the accepted example describes a sender-domain authentication failure, not an invalid or unreachable address. Route the signal to the team responsible for the sending domain's authentication rather than the list-hygiene process, and only apply suppression if an independent, address-specific signal (not this code) justifies it.

• The sending domain's DKIM signature is missing, invalid, or not aligned with the From: header domain, so DMARC has no passing, aligned mechanism.
• The sending domain's SPF record does not authorize the sending IP, or the Return-Path domain is not aligned with the From: domain, removing the SPF path to a DMARC pass.
• The sending domain publishes a DMARC policy of p=reject (or the receiving system escalates p=quarantine to an outright rejection), and this specific message has no aligned pass, so the receiving system rejects it during the SMTP session rather than delivering it.
• The same generic X.2.0 detail code can also appear for unrelated, provider-specific "undefined mailbox status" conditions; the exact response text — not the enhanced code alone — identifies the actual cause.

1. Inspect the raw SMTP response and confirm the enhanced code is exactly 5.2.0 with a 550 basic reply (the accepted example); read the full response text, since the generic enhanced code does not disambiguate the cause on its own — in the accepted example the text names DMARC explicitly.
2. Pull the authentication results for this exact message: SPF result and alignment, DKIM result and alignment (signing d= domain versus the From: header domain), and the sending domain's published DMARC policy (dig txt _dmarc.<domain>).
3. If DKIM fails, check whether the signing key or selector rotated or broke, and whether an intermediate hop (forwarder, mailing-list expansion, security gateway) altered the message and invalidated the signature in transit.
4. If the response text does not reference DMARC or authentication, treat 5.2.0 as this provider's generic mailbox-status catch-all and correlate with other available signals before assuming an authentication cause.