An enhanced status code is a structured clue, not a complete incident report. “5.7.1” can narrow the investigation toward security or policy, but it cannot identify the policy owner, affected route or correct configuration change on its own. Keep the complete diagnostic beside the code throughout troubleshooting.
Read all three components
RFC 3463 defines enhanced status codes with class, subject and detail components. The class distinguishes success, persistent transient failure and permanent failure. Subject categories distinguish areas such as addressing, mailbox state, routing and security or policy. The detail narrows the condition within that subject. The ordinary three-digit SMTP response remains part of the evidence. RFC 3463.
Do not treat the final number as a global error identifier. The meaning depends on the complete enhanced code and applicable registration or provider documentation. A receiving system can also return useful prose without an enhanced code. If the basic and enhanced classes appear inconsistent, preserve the exact bytes and investigate provider behavior rather than silently rewriting the log.
Separate SMTP replies from delivery reports
An SMTP reply occurs during a conversation. A delivery-status notification can report outcomes later and can describe multiple recipients. RFC 3464 defines fields including Final-Recipient, Action, Status, Remote-MTA and Diagnostic-Code. Read the per-recipient blocks independently; one failure does not prove every recipient failed. RFC 3464 section 2.
Action and Status answer different questions. Action: failed means the reporting MTA has stopped attempts for that recipient. Status: 4.2.2 can still describe the transient mailbox-full cause after retries are exhausted; failed plus a 4.x.x Status is valid in a DSN, not an inconsistent SMTP reply. For example, an expired item with those fields will not resume automatically merely because capacity returns. Check the actual queue before authorizing any replacement. See RFC 3464 section 2.3.3.
A human-readable bounce subject is useful for triage but can omit the decisive fields. Obtain the machine-readable report or sending log when possible. Keep the reporting server separate from the remote server, and distinguish a report's timestamp from the timestamp of the failed SMTP command.
Read a hypothetical recipient block
Suppose a sending log records RCPT TO for missing@example.test followed by 550 5.1.1. An illustrative DSN recipient block could contain Final-Recipient: rfc822; missing@example.test, Action: failed, Status: 5.1.1, Remote-MTA: dns; mx.example.test and Diagnostic-Code: smtp; 550 5.1.1 No such user. These are invented field values, not an executed transaction or a complete MIME report.
The failed action is final for this recipient, while the diagnostic points to addressing. It does not establish why the address is unavailable or what happened to other recipients. Obtain those answers from their own blocks and trusted logs. Final-Recipient, Action and Status are required per-recipient fields; Remote-MTA and Diagnostic-Code are conditional or optional. Their absence is not permission to invent a rejecting host or error text.
For unfamiliar registered details, consult the current IANA enhanced status registry and the cited specification, then the provider's current explanation. RFC 3463 supplies the framework, not an exhaustive list of every later code.
Turn the code into a testable hypothesis
For an addressing code, confirm the intended address and receiving-system behavior. For a routing code, inspect the failed next hop and route configuration. For a security or policy code, identify the named requirement and its owner. Avoid starting with a preferred DNS change and then interpreting every response as support for it.
Record one hypothesis, the evidence it predicts and the smallest authorized test. A corrected message should be compared with the original on the relevant route and recipient class. Preserve a contradictory result as useful evidence rather than forcing it into the original explanation. Escalation packets should include timestamps, exact response, affected scope and changes already tested, with message content and personal data minimized. A code lookup is the beginning of diagnosis, not its completion.
Build a useful escalation packet
- Identity: retain the message and queue identifiers, failing envelope recipient and affected scope.
- Timeline: record submission, failed attempt and report arrival separately.
- Diagnosis: include the exact SMTP reply, command stage and per-recipient DSN fields.
- Ownership: distinguish the reporting system from the rejecting system, with evidence for each.
- Next step: state one testable cause, the smallest authorized check and any contradictory evidence. Minimize personal data.