What this code means
The destination system exists and normally accepts mail, but its condition caused a general DSN to be generated. Because the code begins with 2, it describes success, not a message rejection.
Technical meaning
The X.3.0 pattern means another or undefined mail system status: the destination system exists and normally accepts mail, but something about that system caused the DSN to be generated. In the 2.3.0 variant, the result class is success.
Delivery status
The leading digit 2 denotes success. Code 2.3.0 does not indicate a temporary or permanent error and is not itself a bounce or rejection signal, even when it appears in a DSN.
- Class
- Success
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Do not retry based on code 2.3.0 alone because it is a success status. Retrying could create a duplicate; if the expected outcome is not visible, inspect the full event context first.
Suppression decision
Do not add the recipient to a suppression list based solely on code 2.3.0. Before changing the recipient's state, inspect the report context and independent events that confirm any rejection.
Common causes
- The reporting system used the general X.3.0 status in a success DSN without a more specific mail system status.
- The processing layer retained the general 2.3.0 code but did not expose more detailed report context.
Diagnostic steps
- Inspect the raw SMTP response or DSN and confirm that the enhanced code is exactly 2.3.0.
- If the code accompanies an SMTP reply, confirm that the basic reply is in the 2xx class and agrees with the enhanced 2.x.x class.
- Correlate the report with the intended message and send attempt, then review the surrounding context and later events to establish the final outcome.
- If the system displays 2.3.0 as a bounce or rejection, trace the parser, normalization rules, and event mapping.
Actions by owner
Sender administrator
- Classify 2.3.0 as success; do not trigger a retry or automatic suppression solely because of this code.
- Retain the raw report and correct event mapping if the code was routed into rejection handling.
Recipient administrator
- If independent signs of a problem exist, inspect destination-system logs for the correlated transaction; do not infer a rejection or outage from code 2.3.0 alone.
- When the receiving system generated the report, retain the code with enough context to distinguish success from an error.
Provider
- Preserve the raw response or DSN and its success class when normalizing the event.
- Do not present 2.3.0 as a rejection; if a more specific mail system status is available, retain it alongside the general code.
Sources and verification
The code meaning and class assignment were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248. The retry, suppression, diagnostic, and owner-action recommendations are separate operational guidance; they are not standards facts or statements of provider practice.
- iana-smtp-enhanced-status-codesT0 source
Enumerated Status Codes / X.3.0
- rfc5248T0 source
Section 2.1: registry fields and non-exclusive Associated Basic Status Code
- rfc2034T0 source
Section 4: enhanced status class agrees with SMTP reply class
- rfc3463T0 source
IANA registry reference for X.3.0
Last verified:
