Email Bounce Codes: Every SMTP Error Explained (Hard Vs Soft)

Introduction

The campaign went out at nine. By ten there were forty bounce messages in the sending mailbox, and they did not agree with each other. One said "550 5.1.1 The email account that you tried to reach does not exist". Another said "421 4.7.28 ... temporarily rate limited". A third said "554 5.7.1 Service unavailable; client host blocked" and named a list. All three are bounces. Only one of them means the address is bad.

Here is the short version. An SMTP reply starting with 4 is a soft bounce: the problem is temporary and the message can be retried later. A reply starting with 5 is a hard bounce: the server refused the message and resending it unchanged will not help. The dotted code after it, such as 5.1.1 or 5.7.1, says why, and that second code matters more than the first. A 5.1.1 means the mailbox does not exist and the address should never be mailed again. A 5.7.1 means the server refused you, the sender, and the address may be perfectly good. A full mailbox (5.2.2) is a real person who should be retried, even when it arrives under a 552.

How SMTP Reply Codes Work

Every command a sending server issues (MAIL FROM, RCPT TO, DATA) gets a three-digit reply. RFC 5321, section 4.2.1 defines what each digit means. The first digit is the verdict:

The RFC's own rule of thumb for choosing between the two failure classes is useful for reading them too: a reply is 4yz if the same command could succeed later "without any change in command form or in properties of the sender or receiver". A 5yz means something has to change first: the address, the message, or the sender's setup.

The second digit groups the reply by subject: x0z is syntax, x1z information, x2z the connection, and x5z the mail system. x3z and x4z are listed as unspecified. The third digit is the finest detail. The text after the code is for humans, and the RFC calls it recommended rather than mandatory, which is why the same code reads differently at every provider.

Enhanced Status Codes: The Dotted Part

Three digits were never enough to say why a message failed, so RFC 3463 added enhanced status codes, written class.subject.detail. Servers that support them put one straight after the basic code: 550 5.1.1. The class repeats the verdict (2 success, 4 persistent transient failure, 5 permanent failure). The subject says what area failed, and the detail narrows it down. The full list is kept in the IANA enhanced status code registry, defined by RFC 5248.

When a bounce carries both codes, trust the enhanced one. 550 alone can mean an unknown user, a blocked sender or a policy refusal; 550 5.1.1 and 550 5.7.1 tell those apart.

Hard Vs Soft Bounces, And The Exceptions

"Hard bounce" and "soft bounce" are not terms from the RFCs. They are the sender's decision about what to do next: a hard bounce means stop mailing the address, a soft bounce means try again later. Mapping 5xx to hard and 4xx to soft is right most of the time. These are the cases where it is not:

• Mailbox full, even under a 552. The registry says 5.2.2 Mailbox full "should be used as a persistent transient failure", because the owner can delete mail and make room. Many servers still report it as 552 5.2.2. The person behind it is real, so treat it as soft. If the same address stays full across several campaigns over weeks, it has probably been abandoned.
• Policy and blocklist rejections, 5.7.x. 550 5.7.1 and 554 5.7.1 are permanent for this message from this sender, but they are about you, not the recipient. Suppressing the address would punish your list for your reputation. Fix the cause (authentication, a listing, content, volume) and the same addresses usually accept mail again.
• Throttling under 421 and 450. 421 4.7.28 at Gmail and 421 RP-001 at Outlook.com are soft bounces that mean "slow down". Retrying at the same pace makes them worse, and Gmail's 5.7.28 variant shows where persistent unsolicited volume ends up: a permanent rejection.
• Too many recipients under 552. RFC 5321, section 4.5.3.1.10 says the correct code for "too many recipients" is 452, and that clients SHOULD treat a 552 for this as temporary, because an older RFC listed it wrongly.
• Failures that were never about the address. A 5xx in reply to MAIL FROM or DATA, an authentication error such as 530 or 535, a refused connection or a timeout says nothing about whether the recipient exists. Only a refusal of the recipient itself, normally the reply to RCPT TO or a delivery status notification naming the recipient, is evidence that the address is bad.
• Greylisting. Some servers reject the first attempt from an unknown sender with a temporary 450 or 451 and accept the retry. RFC 6647 describes the technique. A sender that never retries loses that mail for good.

SMTP Reply Codes Reference: 4xx And 5xx

Most lists of SMTP error codes online mix three kinds of entries without saying so: codes defined in RFC 5321; codes added by later RFCs, such as 521 from RFC 7504 and 530 from the SMTP authentication extension, RFC 4954; and codes no standard defines. Most of the non-standard ones, such as 422, 431, 441, 442, 446, 447, 471, 510, 511, 512, 517, 531 and 541, read like enhanced status codes with the dots taken out: 4.2.2, 4.3.1, 4.4.1 and so on. The table says which is which, so you know when to trust the number and when to read the text instead.

The Enhanced Status Codes You Will Actually See

These are the dotted codes behind most bounces in a cold email campaign. Meanings come from the IANA registry; where Gmail or Microsoft uses a code for something more specific, the provider's meaning is given too.

Note how Gmail reuses numbers: in the registry, 5.7.27 means the sender's domain publishes a null MX, while Gmail uses it for "didn't pass SPF authentication". Read the code to find the family, then read the text for the provider's actual reason.

Real Bounces From Gmail, Microsoft And Spamhaus

Gmail 550 5.1.1: The Account Does Not Exist

550 5.1.1 The email account that you tried to reach does not exist. ...

This is the textbook hard bounce, listed in Google's Gmail SMTP errors and codes. Suppress the address immediately and never mail it again, from any campaign. If many 5.1.1s come from one list, the list is the problem: it is old, scraped or full of guessed addresses. Clean it before the next send; our guide to cleaning an email list covers the order.

Gmail 421 4.7.28: Rate Limited

421 4.7.28 Gmail has detected an unusual rate of email. To protect our
    users from spam, email has been temporarily rate limited. ...

A soft bounce, and a warning. Google's variants of it name what the rate was measured on: the IP address, the DKIM or SPF domain, a URL domain in the message, or a repeated Message-ID. Retrying is fine, but retrying at the same pace is not. Lower the daily volume per mailbox, spread sends across the day, and check whether a new mailbox or domain was pushed too fast; the warmup ramp shows a safer pace. If the volume continues, the permanent 550 5.7.28 follows.

Gmail 550 5.7.26: Unauthenticated Sender

550 5.7.26 This email has been blocked because the sender is
    unauthenticated. ...

Gmail uses 5.7.26 for three cases: no passing SPF or DKIM at all, an SPF hard fail (-all) that did not pass, and a DMARC failure on a domain whose policy rejects. It is a policy rejection, not a bad address. Google's sender guidelines require every sender to have SPF or DKIM, and senders of more than 5,000 messages a day to Gmail accounts to have SPF, DKIM and DMARC, with the From domain aligned to one of them. Check what is missing with SPF, DKIM and DMARC explained, fix it, and resend: the same addresses will accept the message once it authenticates. The temporary 421 4.7.26, 4.7.30, 4.7.32 and 4.7.40 replies are the same problem caught earlier, as a rate limit rather than a block.

Microsoft 550 5.7.1 And The S3150 Block

550 5.7.1 Unfortunately, messages from [203.0.113.7] weren't sent.
    Please contact your Internet service provider since part of their
    network is on our block list (S3150).

Microsoft does not publish a meaning for the bracketed S-numbers, but the text says what matters: the sending IP, or the range around it, is on Microsoft's own block list for Outlook.com consumer mailboxes. Public blocklist checkers cannot see that list. If you send through a provider's shared servers, the provider has to act; if you run the server, use Microsoft's Outlook.com sender support form, which Microsoft says is for problems reaching Outlook.com, Hotmail and Live addresses only.

Mail to businesses on Microsoft 365 returns different codes, documented in nondelivery reports in Exchange Online. 5.7.606 to 5.7.649, "Access denied, banned sending IP", goes through the delist portal at sender.office.com. 5.7.511, "banned sender", does not: Microsoft asks you to email [email protected] with the full bounce and IP. 5.7.509 means your From domain failed DMARC with a reject policy, and 5.7.515 at Outlook.com means a domain sending more than 5,000 messages a day there without the required SPF, DKIM and DMARC. Outlook.com's own throttling replies are 421 RP-001 to RP-003, for exceeding its message rate, per-connection rate or connection limit. The blacklist removal guide has the step-by-step process for each portal.

554 5.7.1: Listed By Spamhaus

554 5.7.1 Service unavailable; Client host [203.0.113.7] blocked using
    zen.spamhaus.org

The receiving server looked up your sending IP in Spamhaus's ZEN zone and found it listed. ZEN combines several lists that mean very different things: spam seen from the IP, a compromised machine on the network, or a range that should never send mail directly. Look the IP up at Spamhaus's checker to see which one, fix the cause, and only then request removal; listed on Spamhaus goes through each list. Outlook.com reports the same kind of external listing as 550 OU-001 and points to Spamhaus for removal. Do not suppress the recipients: once the listing is gone, their servers will accept your mail.

Yahoo: 4xx Means Retry, 5xx Means Stop

Yahoo's SMTP error codes page states the rule plainly: a 421 or 451 is temporary and "you may retry sending at a later time", while a 553 or 554 is permanent and an email that comes back with a 5xx error should not be retried. Its sample for an unknown user is 554 delivery error: dd This user doesn't have a yahoo.com account, and its causes for 5xx include an invalid address, failed DKIM or DMARC checks, and a Spamhaus listing.

What To Do About Bounces

1. Suppress hard bounces at once. A 5xx with a 5.1.x code, or a clear "user unknown", means the address does not exist. Remove it from every list and campaign, not just the one that bounced. Sending to it again is the clearest signal of a careless list.
2. Retry soft bounces, with growing gaps. RFC 5321's retry guidance says a sender MUST wait before retrying a destination, that the interval SHOULD generally be at least 30 minutes, and that giving up generally needs to take at least 4 to 5 days. For throttling replies, slow the whole mailbox down, not just the one message.
3. Keep policy rejections apart from address bounces. A 5.7.x is a problem with your authentication, your reputation or your content. Count it, fix it, and keep the contact.
4. Watch the bounce rate per campaign. Mailbox providers publish no bounce limit, so any figure is a working line rather than a rule. Eklow treats a bounce rate above 2% as elevated and worth pausing to investigate. Work out yours, split into hard and soft, with the email bounce rate calculator.
5. Authenticate every sending domain. SPF, DKIM and DMARC, aligned with the From domain, remove a whole family of 5.7.x rejections at Gmail, Yahoo and Outlook.com.
6. Check blocklists when 5.7.1 rejections cluster. If many unrelated recipients bounce with the same policy text, the cause is on your side. Run the sending domain and IP through a blacklist checker and follow that list's own removal process.

Complaints have published limits even though bounces do not: Google asks senders to keep the reported spam rate below 0.10% and never reach 0.30%. A list that bounces badly is usually a list that complains badly too, because both come from mailing people who never expected to hear from you.

Email Bounce Code Questions

What Is The Difference Between A Hard And A Soft Bounce?

A hard bounce is a permanent refusal, usually a 5xx reply with a 5.1.x code such as 5.1.1 user unknown: the address will not work, so stop mailing it. A soft bounce is temporary, usually a 4xx reply such as a busy server, a rate limit or a full mailbox: the same message can be delivered later. A full mailbox reported as 552 5.2.2 is treated as soft too, and 5.7.x policy rejections are a third case, about the sender rather than the address.

What Does SMTP Error 550 Mean?

RFC 5321 defines 550 as "Requested action not taken: mailbox unavailable", covering a mailbox that was not found, no access, or a command refused for policy reasons. The enhanced code tells you which: 550 5.1.1 is an unknown user and a hard bounce, while 550 5.7.1 or 550 5.7.26 is a policy rejection of the sender, usually over authentication or reputation.

Is 554 A Hard Bounce?

Not always. 554 means "transaction failed" and is used for both unknown users and policy refusals. Blocklist rejections such as "554 5.7.1 ... blocked using zen.spamhaus.org" are about your sending IP, not the recipient, and the address will accept mail once the listing is resolved. Read the enhanced code and the text before suppressing anyone.

How Long Should I Keep Retrying A Soft Bounce?

RFC 5321 says the give-up time generally needs to be at least 4 to 5 days, with retries at least 30 minutes apart. For campaign mail, also look across sends: an address that soft-bounces in campaign after campaign, especially with a full mailbox, is probably abandoned and worth removing.

What If The Bounce Has No Enhanced Code?

Fall back to the first digit and the text. A 5 with "user unknown", "no such user" or "does not exist" is a hard bounce. A 5 with "blocked", "policy", "spam" or a list name is a policy rejection. A 4 is temporary either way.

How Eklow Handles This

Eklow reads every failed send the way this guide does. A permanent refusal of the recipient, a 5xx reply to RCPT TO, is a hard bounce: the address is suppressed and the rest of its sequence is cancelled. Two kinds of 5xx are deliberately not treated as bounces: any 5.7.x, because that is the server refusing the sender rather than the address, and 5.2.2, because a full mailbox belongs to a real person, whatever class the server reported it under. Rejections of MAIL FROM or DATA, mailbox login failures, timeouts and refused connections are not bounces either, so your own outages never suppress a contact. A failed send is retried automatically, with a growing delay between attempts.

When a rejection happens further along the route, the bounce usually arrives later as a delivery status notification in the sending mailbox rather than as a reply to the send. For mailboxes connected with inbox access, Eklow reads those reports too and applies the same rules, so a policy rejection or a full mailbox is judged the same way whichever path reported it. When a campaign's bounce rate first crosses 2%, workspace admins are notified so the campaign can be paused and the list cleaned before more goes out.