Email not delivered? How to read SMTP error codes

Find the technical part of the bounce

Delivery failures are often returned as a delivery status notification, non-delivery report or bounce. Alongside a human-readable summary, the message may contain structured fields. Final-Recipient, Action, Status, Remote-MTA or the rejecting server, and Diagnostic-Code are particularly useful. These details apply to an individual recipient; a message with several recipients may be delivered to some and rejected for others.

Keep the complete technical bounce and the original headers. A screenshot with a truncated error often lacks the details needed for analysis. Do not circulate confidential message content unnecessarily, however: addresses or domains, time, message ID, status code and diagnostic line are usually enough for an initial investigation.

4xx is temporary; 5xx is permanent for that attempt

In classic three-digit SMTP replies, the first digit describes the basic outcome. A 4xx reply is a temporary negative response, so the sending server should retry later. A 5xx reply is a permanent negative response, so the same unchanged attempt should not be retried automatically. “Permanent” does not mean impossible to fix: correcting the address, configuration or message can make a new attempt appropriate.

Repeated manual resending does not solve a 4xx condition and can add load when a provider is applying volume or reputation limits. Check whether the message remains queued, when the next automatic attempt is scheduled, and whether the diagnostic response changes between attempts.

Read enhanced status codes as class, subject and detail

Enhanced status codes use the format X.Y.Z, such as 5.1.1 or 4.4.2. The first part indicates success, temporary failure or permanent failure. The second identifies the subject area: for example, 1 covers addresses, 2 the mailbox, 3 the mail system, 4 networking or routing, and 7 security or policy matters. The third part adds detail. IANA maintains the current registry of standardised codes.

The text following the code still matters. Providers combine standard codes with their own explanations, links or session identifiers. A generic 5.7.1 can describe a policy rejection, but on its own it proves neither a particular blocklist nor an SPF, DKIM or DMARC failure.

Interpret common groups correctly

• 5.1.1: bad destination mailbox address. Check spelling, aliases, recipient status and the platform that actually handles the domain.
• X.2.2: mailbox full. The class and diagnostic text determine whether the condition is being treated as temporary or permanent.
• 5.3.4 or X.2.3: the message exceeds a system or mailbox limit. Check total size including attachments and transport encoding; do not blindly resend the same attachments.
• 4.4.1 or 4.4.2: the destination did not answer or the connection failed. Check DNS, reachability and retries over an appropriate period.
• 5.7.1: delivery not authorised or message refused. Evaluate the complete provider response and transaction stage before deciding that authentication or reputation is the cause.

Use a diagnostic sequence instead of isolated guesses

First establish whether the sending application handed the message to the intended mail server. Then follow the server-side path: queue, DNS and MX lookup, connection, recipient acceptance and finally the response after the message content is transmitted. The stage at which the failure occurs determines the next check.

• Verify the address and domain exactly; for 5.1.x errors, do not start with spam filtering.
• For 4.4.x errors, check DNS, destination servers and connection history without treating a single timeout as a permanent outage.
• For size and content errors, consider the complete transmitted message, not only the visible file size of an attachment.
• For 5.7.x errors, assess the exact diagnostic text, linked provider guidance, and SPF, DKIM and DMARC results separately.
• Resend only after a specific correction; for temporary errors, allow the server's normal queue and retry process to operate first.

Example: why 550 5.7.1 is not a complete diagnosis

Two recipients can return the same numeric code with different diagnostic text. One provider may identify failed sender authentication, another a local recipient policy, and a third only a generic refusal. The code, complete text, rejecting host and provider reference therefore belong together. Public provider lists are examples, not universal translations for responses from other systems.

If SPF, DKIM or DMARC is explicitly mentioned, check the affected sending source and the results recorded by the trusted receiving system. A generic delivery failure is not a reason to change DNS records speculatively. Uncoordinated changes can disrupt other legitimate sending services.

Evidence that helps with escalation

• Time with time zone, sender and affected recipient or recipient domain.
• Message ID and complete DSN fields: Action, Status, Remote-MTA and Diagnostic-Code.
• Whether all recipients, one domain or only certain messages are affected.
• Results of automatic retry attempts and any specific change already made.
• Do not include passwords, private keys or unnecessary confidential message content.

Narrow down delivery problems faster

Business mail services should monitor queues, bounces and recurring error groups. One rejection is not a trend, but repeated 4xx responses for the same domain or several 5.1.1 failures after a migration can indicate a shared issue. Document thresholds and ownership so investigation does not depend on the first user report.

If the affected mail service is operated by NUXOA, send the technical details without credentials through the designated support or contact channel. The complete diagnostic response helps distinguish whether the address, routing, destination system, message or policy needs investigation.