SMTP Error Codes: What Each Bounce Means for a Cold Email Campaign
Summarize with AI
SMTP error codes tell you whether another attempt may work and what needs attention first. Read the complete response from left to right. A basic three-digit 4xx code means a temporary failure, while 5xx means the exact request should not be repeated unchanged. A dotted status narrows the affected area, such as an address, mailbox, route, message, or policy. The diagnostic text can then identify the specific condition. Retry a 4xx response through a finite queue. For a 5xx response, change the address, message, route, or sending setup before trying again.
How to Read SMTP Error Codes
A rejection can look like 550 5.1.1 <person@example.com>: Recipient address rejected. It contains three useful parts:
550is the basic SMTP reply code.5.1.1is the enhanced status code.- The remaining text is the receiving system's diagnostic.
RFC 5321 defines the basic three-digit replies. The first digit controls the broad action. A 4xx reply is a transient negative completion, so the client should try again. A 5xx reply is a permanent negative completion, so the client should not repeat the exact request in the same sequence.
The other digits in the basic code provide broad context, but they are not as descriptive as the digits in a dotted code. For basic SMTP replies, the second digit groups syntax, information, connection, or mail-system responses. The third digit gives finer detail within that group.
RFC 3463 defines dotted status codes in class.subject.detail form. The class is 2 for success, 4 for persistent transient failure, or 5 for permanent failure. The subject identifies the affected area:
| Dotted subject | Area identified by the standard | First owner to check |
|---|---|---|
| x.0.x | Other or undefined status | Mail operations |
| x.1.x | Addressing | Contact data |
| x.2.x | Mailbox | Recipient condition or contact data |
| x.3.x | Destination mail system | Mail operations |
| x.4.x | Network or routing | Mail operations |
| x.5.x | Mail delivery protocol | Sending platform or mail operations |
| x.6.x | Message content or media | Message owner |
| x.7.x | Security or policy | Sending setup owner |
The basic and dotted codes must agree on class when a server uses the extension. RFC 2034 requires a 4xx reply to carry a 4.x.x dotted code and a 5xx reply to carry a 5.x.x code. The numbers after that first digit do not have to match.
4xx SMTP Error Codes: Retry Without Guessing
A 4xx response says the command failed under a temporary condition. RFC 5321 says the action may be requested again and the client should retry. It does not prescribe one universal retry count, delay, or stop time for every sending system.
Use delayed retries under a documented policy. If the same response keeps returning, stop adding attempts and investigate the repeated condition. This is our operating practice, not an Internet-wide threshold.
| Basic code | Meaning in RFC 5321 | Cold email action |
|---|---|---|
| 421 | Service not available, closing transmission channel | Leave queued for retry; check whether the receiving service or connection remains unavailable |
| 450 | Mail action not taken because the mailbox is unavailable | Retry later; use the diagnostic text to distinguish a busy mailbox from a temporary policy block |
| 451 | Requested action aborted because of a local processing error | Retry later; group repeats by receiving system and sending route |
| 452 | Requested action not taken because system storage is insufficient | Retry within policy; do not treat it as proof that the address is invalid |
| 455 | Server cannot accommodate the supplied parameters | Preserve the rejected parameters and route the event to mail operations |
What 421 4.7.0 tells you
The pair 421 4.7.0 combines two layers. 421 says the service is unavailable and is closing the transmission channel. 4.7.0 says the failure is temporary and belongs to the security or policy category, with no more specific detail defined by the dotted code.
That pair does not establish one universal cause such as rate limiting, authentication, or reputation. Read the diagnostic text to learn what the receiving system reported. Pause volume increases while the sending setup owner checks the named condition.
What 450 and 452 do not tell you
A 450 response can cover a mailbox that is busy or temporarily blocked for policy reasons. A 452 response reports insufficient system storage. Neither basic code proves that the recipient address is permanently bad.
Keep those recipients out of the permanent suppression path unless a later response or authoritative data establishes a permanent address failure. Our soft bounce vs hard bounce guide covers the wider retry and suppression workflow.
5xx SMTP Error Codes: Change Something Before Retrying
A 5xx response means the exact request should not be repeated in the same sequence. Some permanent conditions can be corrected, but a person or system must change the relevant input or condition first.
| Basic code | Meaning in RFC 5321 | Cold email action |
|---|---|---|
| 500 | Command unrecognized or syntax error | Fix the SMTP command or sending implementation |
| 501 | Syntax error in parameters or arguments | Correct the named parameter or address syntax |
| 502 | Command not implemented | Stop relying on that command for this server |
| 503 | Bad sequence of commands | Fix the SMTP command order |
| 504 | Command parameter not implemented | Remove or change the unsupported parameter |
| 550 | Mailbox unavailable, including not found, no access, or policy rejection | Use the dotted code and text to choose suppression, access repair, or policy investigation |
| 551 | User not local, with a forward path supplied | Validate the supplied destination before changing the contact record |
| 552 | Requested mail action aborted because storage allocation was exceeded | Read the dotted code to locate the size or storage limit before resending |
| 553 | Mailbox name not allowed, such as incorrect syntax | Correct only from an authoritative source, otherwise suppress the invalid destination |
| 554 | Transaction failed, or no SMTP service at connection opening | Preserve the complete response and fix the named transaction or service condition |
| 555 | MAIL FROM or RCPT TO parameters are unrecognized or unsupported | Remove or correct the unsupported parameter |
Why 550 is not a diagnosis
RFC 5321 gives 550 several broad examples: mailbox not found, no access, or rejection for policy reasons. Pair it with the dotted code before acting.
550 5.1.1 is specific. RFC 3463 defines x.1.1 as a destination mailbox that does not exist and says the detail is useful only for permanent failures. Suppress that exact address, record its source, and do not invent a replacement mailbox pattern.
A 550 5.7.x response belongs to security or policy. It does not prove that the mailbox is invalid. Preserve the text and route the event to the owner of authentication, permissions, relay policy, or the other control named in the response. Our email bounce back code guide explains that owner-based routing in more detail.
Why 554 needs its diagnostic text
The basic 554 reply means transaction failed. RFC 5321 also permits it at connection opening to mean that no SMTP service is available there. The code alone does not tell you whether the failure came from the connection, command sequence, message, or policy.
Do not assign a provider-specific meaning that the response did not state. Capture the command stage and every line of the reply, then correct the condition named by the receiving system.
Preserve the Full SMTP Diagnostic
A normalized status code makes failures sortable, but it can be less precise than the transport's actual diagnostic. RFC 3464 defines the Diagnostic-Code field in delivery status notifications so the transport-specific information can be retained.
Keep the unedited reply even when your sending tool creates a friendlier label. Record whether the response came from the remote mail transfer agent or your reporting system. Also keep the last-attempt time and affected recipient. Those details let an operator reconstruct what failed without guessing from a dashboard category.
A practical routing sequence is:
- Check the first digit and choose retry or change.
- Use the dotted subject to assign the likely owner.
- Inspect the detail digit and full diagnostic text.
- Preserve the raw evidence before changing the contact, message, or sending setup.
- Group repeats by receiving domain, sending domain, route, campaign, and data source.
Ready to Route Every SMTP Failure Correctly?
We can review your campaign fit, sending path, bounce records, and ownership boundaries, then show where retry, suppression, or repair decisions need a clearer process. Book your free discovery call →
Frequently Asked Questions
A strong positive reply rate for B2B cold email is 1.5–3%. Top-performing campaigns with tight targeting and personalized copy can hit 4–5%. If you're below 1%, it usually signals a deliverability or messaging problem, not a volume problem.
The safe range is 30–50 emails per inbox per day for warmed inboxes. That's why outbound systems use multiple inboxes (we use 80) to reach 40,000+ monthly sends while keeping each inbox well within safe limits. Sending more than 50/day from a single inbox risks spam folder placement.
Yes. The CAN-SPAM Act permits unsolicited commercial email as long as you include a physical address, an unsubscribe mechanism, accurate headers, and non-deceptive subject lines. Unlike GDPR in Europe, the US does not require prior opt-in consent for B2B cold outreach.
Domain warm-up typically takes 2–3 weeks. During this period, sending volume gradually increases while the email warm-up tool generates positive engagement signals (opens, replies) to build sender reputation. Skipping or rushing warm-up is the most common cause of deliverability problems.
Cold email is targeted, relevant outreach to a specific person based on their role, industry, or company, with a clear business reason. Spam is untargeted mass messaging with no personalization or relevance. The distinction matters legally (CAN-SPAM compliance) and practically (deliverability depends on relevance signals).
Sofia Urrego
Account Success, LeadHaste
Looks after LeadHaste accounts end to end, from targeting and copy through to the conversations that come back, so each client keeps improving month over month.
