Soft bounce vs hard bounce: what the SMTP code inside the bounce tells you to do with that address.

Definition

Email bounces are messages a receiving mail server refuses, returned to the sender as a bounce message. The soft bounce vs hard bounce split separates a temporary refusal, which the sending server may retry, from a permanent one, where the same request should not simply be sent again.

The split comes from SMTP itself. RFC 5321, the standard for the Simple Mail Transfer Protocol, gives every server reply a three digit code. A reply that starts with 4 is a transient negative completion: the command was not accepted, but the error condition is temporary.

A reply that starts with 5 is a permanent negative completion. The command was not accepted, the action did not occur, and the standard tells your sending server not to repeat the exact request in the same sequence.

Soft bounce and hard bounce are not terms in the standard. None of the RFCs cited on this page define them. They are vendor vocabulary: the labels email platforms put on those two classes of reply, and each platform draws the line in its own place.

So the code inside the bounce, not the label in the dashboard, is what tells a seller whether to wait, to suppress the email address, or to fix something on the sending side.

Email bounce meaning, and what a bounce message really is

The plain email bounce meaning is this: your message did not reach the mailbox, and something in the mail chain told you so. That refusal can happen in two places, and the difference decides what you receive and when.

• Rejected during the SMTP conversation. The receiving server answers the RCPT TO or DATA command with a 4yz or 5yz reply, and your sending server never hands the message over. Your own server then writes the bounce.
• Rejected after acceptance. The server answers 250 OK, takes responsibility for the message, then fails to deliver it. RFC 5321 says it must then mail a notification back to the address in the envelope return path.

That notification is the bounce you see in your inbox or in your sending tool. RFC 3464 calls it a delivery status notification, or DSN. Microsoft's documentation uses the same term, says it is also known as a bounce message, and calls the most common type a nondelivery report, or NDR.

What a bounced email looks like in your inbox

Yahoo's Sender Hub describes the familiar version: mail from a MAILER-DAEMON or a Mail Delivery Subsystem, with a subject similar to Failed Delivery. It says such messages normally have two parts, the reason for the bounce and a copy of your original message.

The reason is the part to read. In a standard DSN it sits in structured fields, and the raw reply from the remote server sits in a Diagnostic-Code field. A sending tool may show only a summary, so open the full bounce when the summary is vague.

What is not a bounce

An out of office reply is not a bounce. The message was delivered, and a person or a rule answered it. A message filed in spam is not a bounce either. In both cases there is no failure report, so neither belongs in your bounce numbers.

Soft bounce vs hard bounce, side by side

One caution before you trust either column. A 4.X.X code is a persistent transient failure, which RFC 3463 defines as a valid message delayed or abandoned because a temporary condition persisted. When that condition outlives your queue, the same address produces a failure report anyway.

The reverse also happens. A 5yz reply about policy, such as 5.7.1, is permanent for that message, yet the address itself may be fine. RFC 5321 notes that a person can correct some permanent conditions later, for example after a spelling change or a change in account status.

Hard and soft are vendor labels, not standard terms

Because the labels belong to platforms, two tools can file the same bounced email in different buckets. The official help pages of two email marketing platforms show it clearly, and the differences matter when you compare reports across tools.

Neither platform is wrong. Each one turns many server replies into a few buckets that drive its own suppression rules. The point for a seller is that a hard bounce count from one tool and a hard bounce count from another are not the same measure.

Where the standards themselves blur the line

• A 552 that should be retried. RFC 5321 says clients should treat a 552 reply for too many recipients as temporary, because the older RFC 821 listed 552 for that case, where 452 is correct.
• A 550 with a 4.x.x status. Microsoft documents its expired message report as 550 4.4.7: a permanent looking reply code carrying a transient enhanced status.
• A soft fail in an RFC. RFC 6647, on greylisting, describes a 4xx reply as a transient (soft) fail. That is still a reply class, not a bounce category.

Where in the send a bounce happens

The lookup step is worth noting, because a domain with no working mail servers cannot accept anything at all. If you are not sure what that step does, the entry on MX records covers it.

When the lookup itself fails, the bounce is about the whole domain, not one mailbox. That case has its own codes and its own tests, covered in domain not found.

SMTP reply codes behind a soft bounce, the 4xx class

RFC 5321 defines the 4yz class as transient: the command was not accepted, the action did not occur, but the error condition is temporary and the action may be requested again. These are the codes your queue retries.

Google publishes the exact strings its servers return. The documented examples include 452 4.2.2 for a recipient inbox that is out of storage space, 450 4.2.1 for a user receiving email too quickly, and a family of 421 4.7.28 replies for an unusual rate of email from your IP address or domain.

Yahoo groups its temporary errors the same way. Its error code page says a 421 or 451 indicates a temporary problem, lists causes from busy servers to traffic that looks like spam, and says you may retry sending later.

SMTP reply codes behind a hard bounce, the 5xx class

A 5yz reply is a permanent negative completion. RFC 5321 tells the client not to repeat the exact request in the same sequence, and notes that a person may correct some causes later, for example after a spelling change or a change in account status.

Note what code 550 covers. The same number carries both "this person does not exist" and "we refuse your mail". Google's published replies show the difference in the text: 550 5.1.1 says the account does not exist, while 550 5.7.1 says the message is likely unsolicited and has been blocked.

Yahoo states the handling rule plainly. Its error code page says you should not retry an email that comes back with a 5xx error, and that list managers should have a policy for removing email addresses that generate 5xx bounces.

The second number: enhanced status codes

Modern servers add a second code in the form X.Y.Z, defined in RFC 3463. The first digit repeats the class: 2 for success, 4 for persistent transient failure, 5 for permanent failure. The second digit says where the problem sits, and the third names the precise condition.

What the middle digit tells you

The middle digit is the fastest way to decide who owns the problem. RFC 3463 assigns each subject an owner, and that owner tells you whether the fix is in your data, in your sending, or out of your hands.

This is the level a seller should read. The bare code 550 tells you only that a message failed. The pair 550 5.1.1 tells you to retire the record, while 550 5.7.1 tells you to leave the record alone and fix your sending.

RFC 5248 set up the IANA registry for these codes, so new ones are registered rather than invented by each vendor. Vendors still attach their own meanings: Microsoft uses 5.1.10 for recipient not found, while RFC 7505 registers 5.1.10 for a recipient domain that publishes a null MX.

Real provider codes, and what to do with each

Gmail, Microsoft and Yahoo all publish their bounce text. Reading the actual string beats guessing from the label your tool assigned to the bounced email, because the same number can carry more than one meaning.

Microsoft also documents 5.7.1 as delivery not authorized, meaning the sender is not allowed to send to that recipient, and says it often happens with distribution groups that accept mail only from members. No amount of list cleaning will change that.

Gmail's own use of codes can differ from the registry. Its reference uses 550 5.7.27 for a message that failed SPF, while RFC 7505 registers 5.7.27 for a sender domain with a null MX. Read the text next to the number every time.

Common hard bounce reasons

• The person left. The mailbox was removed or disabled after a departure. Microsoft notes a 5.1.1 can occur when an address was valid before and was later changed or removed, which is how records go through data decay.
• The address was guessed. A pattern such as first.last was inferred and never verified, so the part before the @ sign does not exist.
• The domain is wrong or gone. A typo, a rebrand, an acquisition or an expired domain, reported as a bad destination system address. Google's wording is that it was not able to find the recipient domain.
• Syntax errors in your file. Trailing spaces, two addresses in one cell, or a stray comma. Gmail answers 553 5.1.3 when the recipient address is not a valid RFC 5321 address.
• You are refused by policy. The server returns a permanent code because of filtering, authentication or reputation, not because anything is wrong with the address.

A domain that declares it takes no mail

RFC 7505 lets a domain publish a null MX, a single MX record with a dot as its target, to say it accepts no email. A server rejecting mail for that reason should reply 556 with status 5.1.10, so the failure shows up on the first attempt.

The same RFC says a domain with no MX record and no mail listener can leave senders retrying for a long period, typically a week. A null MX turns that slow soft failure into an immediate hard one, which is better for everyone, including you.

Common soft bounce reasons

• Mailbox full. RFC 3463 classes a full mailbox as a persistent transient failure, because the recipient can delete messages and free space.
• Rate limits. The receiver is throttling you or the recipient, as in Google's documented 450 4.2.1 and 421 4.7.28 replies.
• Server or connection trouble. No answer from host, a busy server, or insufficient system storage on the receiving side. Yahoo lists busy servers among its temporary errors.
• Your reputation or content. Yahoo says temporary deferrals can follow user complaints, content with characteristics of spam, a poor IP reputation or unusual traffic patterns.
• Temporary authentication or DNS failure. Yahoo names a name server that was temporarily unavailable, and authentication results that could not be determined because of a temporary error.

Greylisting: a refusal designed to be retried

RFC 6647 describes greylisting as degraded service for an unknown or suspect source, typically lasting minutes or a few hours. In its narrow sense, it means answering a new sender with an SMTP temporary failure and accepting the retry later.

The technique works because, as the RFC explains, much spam software does not retry after a temporary failure. A legitimate server retries, and the second attempt gets through. That is why a first send from a new mailbox can show soft bounces that clear on their own.

The RFC also says some confusion in the industry treats any temporary failure as greylisting. A 4.7.28 rate limit is not greylisting. It is a statement about your volume, and it needs a response from you.

Retry behavior: what happens after a soft bounce

After a 4yz reply, your sending server queues the message. RFC 5321 sets the shape of what follows, and leaves the exact parameters to each system: it says the retry algorithm must be configurable.

• A delay is required. The sender must wait after a failed attempt, and the retry interval should generally be at least 30 minutes.
• Retries back off. The standard describes two connection attempts in the first hour a message sits in the queue, then one every two or three hours.
• There is a give-up point. Retries continue until the message is transmitted or the sender gives up, and the give-up time generally needs to be at least 4 to 5 days.
• You may get a delay notice first. RFC 3464 defines an Action value of "delayed" for a message the server is still trying to deliver, separate from "failed", and an optional Will-Retry-Until date.

Two practical consequences. A soft bounce is not final until the queue expires, so resending the same message from another tool the same day is wasted effort. And a bounce that lands days later belongs to a message you sent days ago, not to today's step.

How to read the bounce message itself

A delivery status notification carries structured fields, defined in RFC 3464. Four of them answer almost every question a seller has about a failed send.

RFC 3464 makes one distinction explicit: Action and Status are not the same thing. A message with a temporary status of 4 can be reported as "delayed" while the server keeps trying, then reported as "failed" once it gives up, with the same status code both times.

The standard also explains why the diagnostic line matters. The Status field exists so any system can parse the report, but it is sometimes less precise than the actual reply, so the Diagnostic-Code field keeps the original text.

A handling rule you can apply without thinking

Bounce handling breaks down when every bounce is a judgment call. Turn it into three branches, read from the code in the diagnostic line rather than from the wrapper your tool displays. The rule below is this page's recommendation.

1. Status 5.1.x, or 5.2.1 with an inactive account: the address is wrong

   Suppress it in every campaign and mark the record in the CRM. Then decide whether to replace the contact at that account, which is a lead enrichment task, not a sending one.

2. Status 4.x.x: the condition is temporary

   Do nothing. Let the queue retry on its own schedule. Suppress only after the address soft bounces across several separate sends, a number you write down in advance.

3. Status 5.7.x, or 4.7.x repeating: the problem is you

   Stop the sending mailbox, not the contact. Check authentication, volume and targeting, and treat it as a deliverability incident rather than a data cleanup.

The sorting step matters more than the actions. A rule that suppresses everything that bounced quietly deletes good contacts whose servers were busy, and hides the block that is actually costing you replies.

Bounce rate, and what mailbox providers publish

Bounce rate is the share of messages in a send that bounced. The formula used on this page is bounced messages divided by messages sent, times 100, counted per sending mailbox and per campaign, because that is the level at which something can be paused.

A worked example written for this page, with invented round numbers: 400 emails sent from one mailbox, 8 bounced, a bounce rate of 2 percent. Split those 8 by status before you react. Six 5.1.1 replies and two 4.7.28 replies call for two different fixes.

The provider pages cited here do not set a bounce rate threshold. What they publish is a set of requirements and a few direct instructions about bounces, and mailing addresses that do not exist works against them.

• Google, for mail to personal Gmail accounts: authenticate with SPF or DKIM, use a TLS connection, publish valid forward and reverse DNS records, and keep spam rates reported in Postmaster Tools below 0.3%.
• Google, above 5,000 messages a day: SPF and DKIM plus DMARC, a From domain aligned with SPF or DKIM, and one-click unsubscribe on marketing and subscribed messages.
• Google, on bounces: if messages start bouncing or being deferred, reduce sending volume until the SMTP error rate decreases, then increase slowly again. Google also lists automatically unsubscribing recipients with multiple bounced messages.
• Yahoo, all senders: SPF or DKIM, a valid forward and reverse DNS record for sending IPs, and a spam rate below 0.3%. Bulk senders must also publish DMARC and honor unsubscribes within 2 days.
• Yahoo, on bounces: monitor hard and soft bounces as well as inactive recipients, and remove invalid recipients promptly. Its error page also has an excessive unknown recipients error, which tells senders to remove addresses that generate bounces.

The routine that keeps that rate low, from capture checks to a suppression list, is email hygiene. This page stays on the bounce itself.

Bounce handling in a sequencing tool

An outreach tool sits between you and the mail server, so its bounce settings decide how much damage a bad list can do. These are the settings worth checking before a sales cadence starts.

• Stop the sequence on a hard bounce. Otherwise step two goes to the same dead mailbox, and the pattern repeats on every later step.
• Share the suppression list. A bounce in one campaign has to block that address in all of them, and in future imports.
• Do not count a bounce as a reply. Bounce messages land in the reply mailbox, where they can end a sequence or mark a dead lead as engaged.
• Alert per mailbox, not only per campaign. A cluster of 4.7.x replies on one sending mailbox is a reputation event, even when the campaign looks fine.
• Store the status code, not just the word bounce. HubSpot, for one, says a bounced one-to-one email shows less detail than a marketing email, with the full response in your own inbox.

The same logic applies to a mass send from a marketing platform, covered in email blast. The difference is that outbound tools send from real mailboxes, so the reputation cost of a bad list lands on the mailbox your reps also reply from.

Catch-all domains and bounces that arrive late

Some domains accept mail for every address, real or not, and sort it out afterwards. A check before the send cannot confirm a mailbox there, because the server will not say whether it exists. The entry on catch-all email covers those domains.

The result is a bounce that arrives after acceptance. The server answered 250 OK, took responsibility for the message, found no mailbox, and mailed a nondelivery report back. RFC 5321 requires exactly that behavior for a delivery failure that follows acceptance.

RFC 5321 also says some failures after acceptance are unavoidable, for example when a server cannot validate every address during the conversation, when the target is a mailing list, or when the server is only relaying.

For a seller this means two things. A clean check on a catch-all domain proves little, and the bounce number for a campaign is not final on the day it sends. Read it again a few days later.

Blocks, spam folders and silent drops

No bounce does not mean the inbox. A message can be accepted and filed in spam. RFC 5321 acknowledges that dropping mail without notifying the sender is permitted in practice, while warning that it should be considered only where there is very high confidence that a message is seriously fraudulent or otherwise inappropriate.

That gap is why bounce rate alone is a weak deliverability measure. It counts only the failures loud enough to announce themselves. Reply rate per sending mailbox, and spam rate in the providers' own postmaster tools, catch quiet failures that bounces never show.

The wider picture, from authentication to placement, is in email deliverability. A warm sending setup before volume matters too, a topic covered in email warm up and across the cold email hub.

Backscatter: bounces for mail you never sent

Backscatter is a nondelivery report you receive for a message you did not send. Microsoft describes the mechanism: spammers use real email addresses as the From address, and when a nonexistent recipient receives the spam, the destination server sends the NDR to the forged sender.

Two details from RFC 5321 explain the limits. Notifications must be sent with a null reverse path, an empty pair of angle brackets in the MAIL FROM command. When the return path is already null, the receiver must not send a notification at all, which stops bounce loops.

The same standard says that when a message is rejected for hostile content, bounce messages should not be sent unless the receiving site is confident they will be usefully delivered.

Microsoft says its service tries to drop messages from dubious sources without generating an NDR, but that sending absolutely no backscatter is almost impossible given the volume of email flowing through it.

For a sales team, backscatter looks like a pile of bounces in a reply mailbox for campaigns that do not exist. Do not import those addresses as suppressions, and do not auto-reply to them. Check whether the volume followed a spam run against your domain, and check your authentication records.

Reducing bounces before the send

In this page's view, data work does most of it. The rest is sending setup: correct records for the domain, a real mailbox behind the address, and a volume that does not look like a burst to the receiving server.

Mistakes with email bounces

• Suppressing every bounce, soft ones included, and losing contacts whose mailbox was simply full that week.
• Reading the label in the dashboard instead of the diagnostic code inside the bounce.
• Comparing hard bounce counts across two tools as if both used the same definition.
• Treating a 5.7.x policy refusal as a data problem, then cleaning the list while the real block stays in place.
• Reading a vendor code with the registry meaning, such as Microsoft's 5.1.10 or Gmail's 5.7.27.
• Pushing the rest of a send through a bounce spike instead of reducing volume, as Google advises.
• Re-importing a bounced address next quarter because suppression lived inside one campaign.
• Counting a bounce as a reply, so a dead contact is marked as engaged and the sequence stops.
• Judging a campaign on send day, before the late bounces from catch-all domains arrive.
• Answering backscatter, or adding it to a suppression list as if those addresses were your prospects.

In a sequence

A hard bounce at a target account is information, not only a data error. A 5.1.1 can mean the person left, and the account may still have the problem you sell against. The message below asks a colleague, and says plainly why you are writing to them. It was written for this page.

Subject: Wrong person at {{companyName}}?

Hi {{firstName}},

I wrote to {{formerContact}} about {{problem}} last week, and the message came back saying that account no longer exists.

Your name came up as the person who owns {{area}} at {{companyName}} now. If that is right, is {{problem}} still on your list this quarter?

If it sits with someone else, tell me who and I will leave you out of it.

{{senderName}}

Frequently asked questions