5.1.0Generic address-status rejection, evidenced for both sender and recipient addresses

IANA's generic catch-all detail in the addressing subject family is registry pattern X.1.0 ("Other address status"), for cases where no more specific address-status code applies; code 5.1.0 assigns it a permanent class. Mechanical IANA confirmation for X.1.0 in this catalog covers no class at all: the registry's Associated Basic Status Code reads "Not given," and the catalog's canonical mirror records the pattern's resolution status as unresolved. This concrete class-5 code is published only on exact, corpus-collected production evidence: two providers (Orange, Rackspace) use 5.1.0 to reject an invalid or unauthorized envelope sender, while a third capture (a non-delivery report relayed through a Cisco-hosted inbound gateway, iphmx.com) uses the same code, in direct reply to RCPT TO, to reject the envelope recipient address instead. Because the underlying detail code is generic and names "address status" without identifying which address, always read the full response text and the SMTP stage (MAIL FROM vs RCPT TO) rather than inferring one meaning from "5.1.0" alone.

Exact corpus evidence spanning two distinct address problems is why concrete code 5.1.0 (class 5, permanent) is published here. Orange and Rackspace return "501 5.1.0" / "550 5.1.0" to reject a message whose envelope sender (Return-Path) is invalid or not authorized to send for the claimed domain; a separate capture shows a receiving system behind Cisco's hosted inbound gateway (iphmx.com) returning "550 #5.1.0 Address rejected." in direct reply to the RCPT TO command, rejecting the envelope recipient address rather than the sender. The X.1.0 pattern is IANA's generic/undefined status within the addressing subject family (subject 1): "Something about the address specified in the message caused this DSN." RFC 3463 (Section 3.2) defines the subject/detail scheme without settling a class for every pattern; for X.1.0 specifically, the registry's Associated Basic Status Code is "Not given," and this catalog's canonical mirror records classApplicability.resolutionStatus as "unresolved" (basis: iana_missing_class_evidence). Neither class 4 nor class 5 is mechanically confirmed by IANA for this pattern. The generic detail code does not itself distinguish sender-side from recipient-side address problems; the SMTP command being replied to and the response wording do.

The leading digit 5 denotes a permanent failure: in each accepted example, the rejection follows from a condition that will not clear by itself — an unauthorized sender identity or a rejected address — so resending the identical message to the identical address will fail again for the identical reason. This differs from a hypothetical class-4 use of the same X.1.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: every accepted example is class 5, so the identical send will fail again until the underlying address or authentication problem is fixed. If the response text points to the sender identity (as in the Orange and Rackspace examples), stop sending from the misaligned domain until SPF/Return-Path alignment is corrected. If the response text points to the recipient address (as in the Cisco-routed example), stop retrying that address and verify it with the recipient through another channel before resending.

Do not suppress the recipient address based on 5.1.0 alone without first reading the full response text: the code covers two different situations in this catalog's evidence, and only one of them (a rejected recipient address) is actually about that address. When the text names a sender-identity or authentication problem, route the signal to the sending domain's authentication owner instead of the list-hygiene process; suppress the recipient address only when the exact text names that address as the one rejected.

• The message's envelope sender (Return-Path) uses a domain whose SPF record does not authorize the sending IP, or whose Return-Path domain is not aligned with the From: header domain — the cause named directly in the accepted Orange and Rackspace examples ("Invalid Sender" / "Sender is not allowed to send from example.com").
• The sending system's HELO/EHLO identity or authenticated account does not match the domain in the envelope sender, so the receiving system treats the sender address itself as invalid for this connection.
• The envelope recipient address is rejected during RCPT TO by a receiving system, or by an inbound security gateway placed in front of it (such as Cisco's hosted iphmx.com gateway in the accepted example), for a reason the provider files under this generic "address status" code rather than a more specific detail such as X.1.1.
• Because X.1.0 is IANA's undefined catch-all for the addressing subject, individual providers attach it to whichever address-related condition does not fit a more specific detail code in their own implementation — the exact response text, not the enhanced code, identifies the actual cause.

1. Inspect the raw SMTP response or delivery report and confirm the enhanced code is exactly 5.1.0; note the basic reply code (501 in the Orange example, 550 in the Rackspace and Cisco-routed examples) and the exact SMTP stage — MAIL FROM for a sender-identity rejection, RCPT TO for a recipient-address rejection.
2. Read the full response text before assuming a cause: if it names the sender, envelope-from, Return-Path, or an authentication mechanism (SPF/DKIM/alignment), treat this as a sender-side rejection; if it names the recipient address or appears in direct reply to RCPT TO with no sender-side language, treat it as a recipient-side rejection.
3. For a sender-side 5.1.0, check the sending domain's SPF record for the sending IP and confirm Return-Path/From: alignment; check whether the HELO/EHLO or authenticated submission identity matches the envelope sender domain.
4. For a recipient-side 5.1.0, confirm the recipient address is correctly formed and currently valid, and check whether the response was relayed through an intermediate inbound security gateway (a hosted spam/security filter placed in front of the destination domain's own mail servers) that can reject addresses independently of the destination mailbox itself.