5.1.2Recipient address rejected as an invalid destination

RFC 3463 glosses registry pattern X.1.2 ("Bad destination system address") as a destination system that does not exist or cannot accept mail at all, locates the fault on the address part to the right of the "@" sign, and limits the detail to permanent failures; code 5.1.2 marks that pattern with a permanent class. This catalog's IANA mirror gives X.1.2 no Associated Basic Status Code confirmation at any class: neither 4.1.2 nor 5.1.2 is mechanically registry-confirmed here. This concrete code exists and means what it means only because of exact, corpus-collected production evidence (the Gmail 553 5.1.2 response below). That evidence rejects recipient-address format; it does not establish a domain-does-not-exist condition, and so reads narrower and more provider-specific than the registry gloss.

The available evidence (Gmail's 553 5.1.2 response) rejects the recipient address itself as not conforming to RFC 5321's mailbox syntax at the RCPT TO stage: an address-format judgment, not a finding that the destination domain lacks a working mail system. Pattern X.1.2 names a destination system that does not exist or cannot accept mail at all. For an Internet mail address, RFC 3463 places the fault on the part to the right of the "@" sign and treats the detail as useful only for permanent failures. No class of X.1.2 carries a mechanical IANA Associated Basic Status Code confirmation in this catalog, so code 5.1.2 is published here from exact corpus evidence rather than a registry confirmation for this class.

The leading digit 5 denotes a permanent failure. Repeating the same attempt with an unchanged address is not the appropriate response; a new send is justified only after the address has been corrected from a trusted source. Do not conflate this with 5.1.3, the confirmed code for bad destination mailbox address syntax, even though the evidence text below also invokes address-format validity.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Do not automatically or manually retry delivery to the same unchanged address. Treat 5.1.2 like any other hard-bounce addressing failure: stop sending to this exact address until it has been corrected from a trusted source, and do not guess a replacement value.

Do not apply unconditional or blanket suppression across a domain based on a single 5.1.2. Confirm the rejection targets this exact address, inspect the full response text, and apply your addressing-failure policy to that one recipient; a malformed or mistyped address is often sender-side data quality, not evidence against the domain or other recipients there.

• The recipient address as submitted does not conform to the syntax RFC 5321 requires for a valid SMTP mailbox address — for example a malformed local-part or domain segment — and the destination system rejects it outright at RCPT TO.
• The sending application built, copied, or imported the address incorrectly (truncation, stray characters, or an encoding problem), producing a value close to a real address but not itself valid.
• In the accepted Gmail example, the response names RFC 5321 directly rather than a mailbox-existence or quota condition, distinguishing this rejection from causes like a deleted account or a full mailbox.

1. Inspect the raw SMTP response or delivery report and confirm the enhanced code is exactly 5.1.2 (not 5.1.1 or 5.1.3), and that the basic reply is in the 5xx class (553 in the accepted example).
2. Compare the exact recipient address against RFC 5321's mailbox syntax rules and against the value held in your trusted source system; look specifically for malformed characters, missing or duplicated segments, or encoding damage introduced before the send.
3. Trace the address to where it entered your sending data (import, form submission, API call) to find whether the corruption happened at capture time or later in your pipeline.
4. Do not resend to the same address; treat it as a hard bounce and route it through your standard permanent-failure handling once the exact code and full response are confirmed.