Guide
An email bounce is a delivery failure returned by the receiving mail server. A hard bounce is permanent - the address does not exist, or will never accept mail - and that address should never be mailed again. A soft bounce is temporary - a full mailbox, a server outage, a message too large - and delivery may succeed on a retry. The complication is that the code telling you which one you got is not always right, and a large share of bounces do not arrive in a form anything can read.
Last reviewed September 2026
Most explanations go straight to the hard-versus-soft taxonomy. That skips the part that decides how your system has to be built, because a bounce is not one event. It is two different events that get filed under the same word, and they reach you by completely different routes.
The sending server opens a connection to the receiving server and offers the message. The receiver refuses it there and then, with a three-digit reply code and a line of text, before it has taken responsibility for the message. Nothing was accepted, nothing needs returning, and the sender knows within the same second.
This is the common case, by a wide margin. The one outside document this page leans on, the Sender Best Common Practices published by M3AAWG - the Messaging, Malware and Mobile Anti-Abuse Working Group, whose members include the major mailbox providers - puts it plainly: an email returned to the sender "is usually returned synchronously, or 'rejected' in the SMTP conversation initiated by the sender", and "in practice, most NDRs occur synchronously". NDR is the industry term - a non-delivery report.
The receiving server accepts the message, ending its part of the conversation with a success code, and only afterward discovers it cannot deliver. It then generates a new message and sends it to the return path of the original. That message is the bounce.
This is the less frequent path, and the slower one: an asynchronous bounce can arrive hours or even days after the original send. B2B mail carries a higher rate of asynchronous bounces than consumer mail. That is a function of how corporate mail is built: a gateway takes the message on the perimeter, filters or relays it internally, and finds the problem after the connection has closed.
A message can be both delivered and bounced. The receiver accepted it, so the delivery was real; it later returned a failure notice, so the bounce is real too.
Omnivery's event log records exactly this, showing a message with both a Delivered and a Soft-bounced or Hard-bounced action. The two most common causes are a remote mail server that runs its anti-spam filtering after the handover, and one that relays the message onward to another server that then refuses it.
A rejection arrives on a connection you opened. An asynchronous bounce arrives as inbound mail, at your domain, which means it only reaches you if something is listening. This is the part that catches people out when they set a domain up and then tidy the DNS afterward.
Omnivery's domain records are split into sending records and a receiving record, and the receiving record is not optional decoration for people who want inbound routing. It is where remote bounces arrive, alongside unsubscribe emails, feedback loop reports and any mail addressed to the domain itself. Remove that record and asynchronous bounces stop arriving, which means they stop being classified, which means the addresses behind them are never suppressed. Nothing breaks visibly. The suppression list simply stops learning.
The same point holds as a capacity requirement rather than a DNS one. A sending system has to receive and process returns at the same volume and rate at which it sends, so every sender needs to size for both directions. A platform that can send a million messages and not read the replies is half a platform.
On the reporting side, both kinds of failure surface the same way. Omnivery generates webhook events for every message-level action - accept, reject, delivery and bounce - alongside the recipient actions of open, click, unsubscribe and complaint. One thing to build for: those calls are asynchronous and events can arrive out of order, an open before a delivery, so sequence your own records on the timestamps in the event data rather than on arrival time.
A hard bounce is a permanent failure: the receiving mail server indicating that a message cannot be delivered because the address no longer exists or never existed, or because the domain no longer exists or never existed. That is the industry definition, and it is the one this page uses.
The causes are a short list, and they all share the property that repeating the send changes nothing:
@ resolves, or it resolves but publishes no MX record. Enhanced status 5.1.2.A hard-bounced address must never be mailed again. That is not list hygiene as an aesthetic preference; it is the single clearest negative signal a sender can generate, because it is unambiguous evidence that the list is not being maintained.
Receivers penalize a sending IP that keeps producing permanent failures, and they do it deliberately: the volume of permanent failures is one of the indicators they use to build a reputation for a sender and to decide how to treat its future mail. What a high hard-bounce volume tells them is unflattering and usually accurate. It says the registration process is poorly managed, or the list is old, or the list is being used for something it was not collected for.
If the receiver is telling you there is no one at that address, the message must not be retried and the address must be suppressed from every future send.
There is no version of this that involves waiting to see. The receiver has already answered the only question that matters.
Google's sender guidelines give senders the same instruction from the receiving side, listing among its recommended practices that you "automatically unsubscribe recipients who have multiple bounced messages". Yahoo's, under a heading titled "Remove invalid recipients", asks senders to "monitor hard and soft bounces as well as inactive recipients" and to "remove invalid recipients from your list promptly". These are not competing schools of thought. Every party in the chain is asking for the same behavior.
Permanently undeliverable addresses go onto the Bounce suppression list automatically, and that list then prevents any further sending to them. It is the busiest of the four lists, and it exists for one reason: to protect you from the reputational impact of attempting delivery to non-existent addresses. That is the mechanism in the paragraph above, running without anyone having to remember it.
One detail worth knowing, because it runs the other way from what people expect. Transactional messages are exempt from the unsubscribe and complaint suppression lists, on the grounds that a password reset should not be withheld because someone opted out of a newsletter. They are not exempt from the bounce list. Bounce and block still suppress, whatever the message type, because a non-existent address cannot receive a password reset either and the attempt still costs reputation.
A soft bounce is a temporary failure: the receiving server indicating that a message cannot be delivered right now because of a full mailbox, a connection problem, a technical issue at the provider, or throttling of the connecting IP to slow down the rate at which it delivers.
That definition is worth reading twice, because two of its four examples have nothing to do with the recipient. A connection problem and a throttle are conditions of the receiving server and of your sending reputation respectively. The address in question may be perfectly good.
A soft bounce should be retried. That is what the code is asking for, and a sending platform handles the retry schedule for you. The judgment call is at the other end: when does an address that keeps soft-bouncing stop being temporarily unreachable and start being dead?
Nobody publishes a hard number, and any page that gives you one has invented it. The closest thing to an industry position frames it as a pattern across campaigns rather than a count of attempts:
"It is a recommended best practice that addresses should be removed from a list if they consistently bounce with any failure code or descriptive text over multiple consecutive campaigns. How many campaigns and over what length of time are up to the individual sender but generally it is considered a best practice to remove an address from the list if it bounces consecutively at least two times over two weeks or more."
M3AAWG Sender Best Common Practices, August 2026. The two-week span is doing real work in that sentence: the interval is there to allow for server issues on the receiving side that could have produced an erroneous bounce.
The principle underneath is that time matters more than count. Ten failures inside an hour is one outage. Two failures a fortnight apart is a mailbox that has been abandoned and left full, and no amount of further patience will empty it.
A distinction that gets lost in reporting. A message that soft-bounces and is still within its retry window has not failed yet; it is deferred, and it may well be delivered. A message that soft-bounces until the queue gives up has failed, and is now a bounce in the sense that matters to your metrics. Systems that count the first as a bounce make a bad day at a mailbox provider look like a list quality problem, and the two call for opposite responses.
Every rejection and every bounce carries a reason, and the reason has two parts: a numeric status code and a line of descriptive text. Both matter, and most guides cover only the first.
RFC 5321 defines the basic SMTP reply. Three digits, each narrower than the last: the first says whether the request succeeded, failed temporarily or failed permanently; the second says roughly what kind of thing went wrong; the third is the fine detail. Two of the four first-digit values concern us here.
"4yz Transient Negative Completion reply. The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again."
"5yz Permanent Negative Completion reply. The command was not accepted and the requested action did not occur. The SMTP client SHOULD NOT repeat the exact request."
RFC 5321, section 4.2.1.
The specification also supplies a test for deciding which class a condition belongs in, and it is a better mental model than "temporary versus permanent". A reply is 4yz if it "can be successful if repeated without any change in command form or in properties of the sender or receiver" - that is, if nothing has to change for the identical attempt to work next time. If something has to change, it is 5yz. That is why a full mailbox is transient (the recipient deletes some mail and nothing about your send changes) while a nonexistent address is permanent (only a different address will do).
RFC 5321 is careful not to overclaim on that second class, and the caveat is one this page returns to below: "even some 'permanent' error conditions can be corrected".
Three digits turned out not to be enough. RFC 3463 defines a second, longer code that travels alongside the first, in the form class.subject.detail:
So 5.1.1 is permanent, address-related, mailbox does not exist. 4.2.2 is transient, mailbox-related, mailbox full. 5.7.1 is permanent, security or policy, delivery not authorized. The enhanced code is worth parsing in preference to the reply code wherever both are present, because it distinguishes a bad address from a rejected sender - a difference the three-digit code cannot express and which decides whether you suppress the recipient or fix your own configuration.
RFC 3463 also asks clients to fail gracefully into the general case: report the subject when you do not recognize the detail, and report the class when you do not recognize the subject. New detail codes are added over time, so a parser that only understands the codes that existed when it was written should degrade rather than throw.
Bounce codes
The wording in the second column is RFC 5321's own, from the reply code listing in section 4.2.3. The third and fourth columns are what the code means in practice and what a sending system should do about it. Enhanced status codes vary by receiver, so the ones shown are the common pairings rather than a fixed mapping.
| Code | Class | RFC 5321 text | Usually means | What to do |
|---|---|---|---|---|
| 421 | Transient | <domain> Service not available, closing transmission channel | The receiver is shutting down, busy, or throttling you. Gmail returns 421 for connection expiry, server load, missing PTR records and low IP reputation | Retry later. Investigate your own side if it persists, since several 421 variants are about the sender, not the recipient |
| 450 | Transient | Requested mail action not taken: mailbox unavailable (e.g., mailbox busy or temporarily blocked for policy reasons) | The mailbox exists but will not take the message right now. Commonly per-recipient rate limiting, or greylisting | Retry. Do not suppress |
| 451 | Transient | Requested action aborted: error in processing | Something failed inside the receiving system. A timeout, a protocol violation, a temporary internal fault | Retry. This is the code most often abandoned too early, because the failure is the receiver's and the address is fine |
| 452 | Transient | Requested action not taken: insufficient system storage | Mailbox full, or too many recipients in one transaction. Gmail uses 452 with 4.2.2 for an inbox out of storage space | Retry. Suppress only on a repeated pattern over time, not on one occurrence |
| 550 | Permanent | Requested action not taken: mailbox unavailable (e.g., mailbox not found, no access, or command rejected for policy reasons) | The most overloaded code in email. Covers both "no such address" (5.1.1) and "we refuse your mail" (5.7.1), which are unrelated problems | Read the enhanced code and the text before acting. Suppress on 5.1.1; on 5.7.1 fix authentication or reputation and leave the list alone |
| 551 | Permanent | User not local; please try <forward-path> | The recipient is not on this server and the server is naming where to send instead. Rare in modern practice | Do not auto-follow the redirect. Correct the address at source |
| 552 | Permanent | Requested mail action aborted: exceeded storage allocation | Quota exceeded, or the message is too large. Gmail uses 552 with 5.3.4 for size limits and with 5.2.2 for an inbox that is both full and inactive | Distinguish the two. A size failure is about your message; a quota failure is about the mailbox and is often temporary |
| 553 | Permanent | Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect) | The address is malformed, or the domain does not exist. Gmail returns 553 with 5.1.2 when it cannot find the recipient domain | Suppress, and fix the collection form that let the address in |
| 554 | Permanent | Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") | A catch-all refusal. Frequently a spam filter or blocklist rejection dressed as a generic failure | Read the text. If it names a blocklist, this is a reputation problem and suppressing recipients makes it worse |
Sources: RFC 5321 section 4.2.3 for the reply code text, RFC 3463 for the enhanced status codes, and Google's published Gmail SMTP error reference for the example pairings. Linked in full below.
The four-versus-five rule is the first thing every guide teaches and the last thing a real bounce processor relies on. Not because receiving servers are careless - most mail server software and most mailbox providers return an honest, accurate status code that follows the specifications - but because the code was never designed to answer the question a sender is actually asking.
"The numeric status codes 4xx and 5xx tell the sending mail server what to do. These numeric codes were not designed with marketers and other senders of bulk email in mind and do not clearly state whether or not the address should be removed from the mailing list or not."
M3AAWG Sender Best Common Practices, August 2026. Its conclusion: senders "must look at the descriptive text to determine how to handle the specific address on their list".
Two questions are being conflated. Should this delivery attempt be repeated? is what the reply code answers, and it answers it well. Should this address stay on the list? is a different question, and the code frequently gives the wrong answer to it - sometimes because the condition genuinely does not fit the classes, sometimes because the receiver picked the wrong one.
The best evidence that the numeric class cannot be trusted alone is that RFC 5321 tells clients to disregard it. When a server hits its limit on recipients per message, the correct reply is 452. Some servers return 552, following an error in the original 1982 specification that was never fully unlearned. RFC 5321 does not ask them to stop; it asks the client to compensate:
"RFC 821 incorrectly listed the error where an SMTP server exhausts its implementation limit on the number of RCPT commands ('too many recipients') as having reply code 552. The correct reply code for this condition is 452. Clients SHOULD treat a 552 code in this case as a temporary, rather than permanent, failure."
RFC 5321, section 4.5.3.1.10.
A permanent code, a transient condition, and a standards-track instruction to override the class based on what the response means. Overriding the class is not a workaround. It is in the protocol specification.
The commonest case in production. RFC 3463 is unambiguous that a full mailbox is transient: the code for it "should be used as a persistent transient failure", because the recipient can delete messages and make space. Plenty of servers return it as a 5xx anyway.
Google's own error reference shows how much precision is available to a receiver that wants it. An inbox that is out of storage space returns 452 4.2.2 - transient, retry. An inbox that is out of storage space and inactive returns 552 5.2.2 - permanent, stop. That is the correct distinction, drawn exactly where it should be: the mailbox being full is temporary, the account being abandoned is not. A sender who keys on the numeric class gets both of those right. A sender who keys on the phrase "out of storage space" gets one of them wrong. A sender facing a smaller provider that returns 552 for a merely full mailbox gets the first one wrong too, and permanently suppresses a subscriber who will be reading mail again next Tuesday.
Not a hypothetical. These two rows appear in Google's published Gmail SMTP error reference, carrying an identical sentence:
Word for word the same condition, from the same provider, published in the same table, once as transient and once as permanent. Rate limiting is temporary by definition; it is the receiver asking you to slow down. A system that hard-bounces on a 550 will suppress a live Gmail user for the offense of receiving a lot of mail, and it will never find out, because the suppression is silent and the recipient has no idea they were dropped.
550 is the most overloaded number in email. It carries 5.1.1, meaning the address does not exist, and it also carries 5.7.1, meaning the receiver refuses your mail. Google documents the second case explicitly: 550 with 5.7.1 means "messages are rejected because the sending server's IP address is on an IP suspended list", and adds that you "might get this error if you're sending email using a shared IP with a poor reputation".
Every recipient at that domain returns the same 550 for as long as the condition lasts. A processor that suppresses on the number alone will empty an entire domain's worth of valid addresses out of a list because of a reputation problem, and then the list looks clean, the bounce rate falls, and the actual fault is invisible.
The classes can also flatly contradict each other. The same Google reference returns 421 5.7.32 for a message whose From header is not aligned with an authenticated SPF or DKIM domain: a transient reply code paired with a permanent enhanced status. Neither class is describing the real situation, which is a sender-side configuration error that will keep failing identically until someone fixes DNS.
The two errors are mirror images and both are silent.
Which is why the classification should be driven by what a response means - the enhanced status code, the descriptive text, and the pattern the same address and the same receiver have shown over time - rather than by the first digit alone.
Everything above assumes the bounce arrives in a form a machine can read. A synchronous rejection always does, because it is a reply code on an open connection. An asynchronous bounce is an email, and emails are written by whoever wrote the mail server.
RFC 3464 defines the delivery status notification: a structured report, carried in its own MIME part, with machine-readable fields for the failed recipient, the action taken, the status code and the reporting server. Its stated requirements are precise about the dual audience - a DSN "must be readable by humans as well as being machine-parsable" - and two of its listed purposes describe this page's problem directly.
"(c) Allow mailing list exploders to automatically maintain their subscriber lists when delivery attempts repeatedly fail... (f) Allow language-independent and medium-independent, yet reasonably precise, indications of the reason for the failure of a message to be delivered."
RFC 3464, section 1.1, on the purposes of delivery status notifications.
Automatic list maintenance and language independence, written into the design in 2003. Where the standard is followed, bounce processing is close to trivial. The problem is entirely with the mail that does not follow it.
Worth separating out, because it is usually described as though all non-English bounces were equally hard, and they are not.
European-language bounces are comparatively tractable. They share the Latin alphabet, so pattern matching degrades gracefully rather than failing outright: a rule can still catch a recognizable substring, an email address, a domain, or a status code embedded in unfamiliar prose. You lose precision, not the whole message.
Bounces in Korean, Chinese and Japanese offer none of that. There is no shared script to partially match against, so a Latin-based pattern set does not degrade - it simply returns nothing. These are the hardest bounces to process reliably, and translating them is what makes them tractable at all.
This is a global problem, not a regional one, and it is worth being clear that the hard cases are not the European ones. Any sender with recipients in East Asia has a portion of their bounce traffic that a conventional English rule set cannot see.
This is the part that makes it more than a tidiness issue. If a sending platform cannot determine that a bounce means "this address does not exist", the address is never suppressed. The sender keeps mailing it. Every subsequent send produces another permanent failure, and repeated delivery attempts to non-existent addresses are one of the indicators receivers use to build a reputation for a sender.
So a parsing gap becomes a reputation problem, silently, and the sender has no way of knowing. The bounce is not in the reports, because it was not recognized as a bounce. The address is not on the suppression list, because nothing told the list to add it. Everything looks fine.
The addresses most likely to go unsuppressed are exactly the ones on the least standard servers and in the hardest to parse languages. The international portion of a list quietly degrades in quality while the domestic portion stays clean.
A sender looking at an acceptable overall bounce rate can still be accumulating a growing tail of dead addresses they never stop mailing, because the bounces that would have told them are the ones their platform could not read.
Handling the standard case is table stakes. What decides whether a suppression list stays accurate is how much of the non-standard case a platform recovers, and that is built up over years against real traffic rather than derived from a specification.
The binary is not a simplification anyone asked for. It is what a platform shows when it has stopped reading the bounce at the class digit, and it hides exactly the detail a customer needs to work out why mail to one receiver started failing. The industry's own guidance to service providers is blunt about this: detailed non-delivery data should be available to customers, and hiding it behind aggregate hard and soft counts is a failing rather than a convenience.
Omnivery's analytics carry the categorization through to the customer rather than stopping at the aggregate. The timeline chart can be switched from the delivery overview to a bounce view, a separate bounce chart breaks down the categories for whatever range the timeline is showing, and the event log holds the per-message record: Accepted or Rejected at submission, then Delivered, Soft-bounced, Hard-bounced or Suppressed, with recipient actions alongside. That is the difference between being told your bounce rate went up and being able to see which receiver, which category and which messages.
Broader bounce recognition means more addresses are correctly identified and suppressed. Fewer repeated attempts to dead addresses means less of the signal that receivers use to downgrade a sender. The chain is short and the effect is real.
It is also, by its nature, invisible when it works. Nobody notices the bounce that was correctly parsed, the address that was suppressed on the first failure instead of the twentieth, or the Korean-language non-delivery report that turned into a suppression entry rather than a silent hole in the list. This is infrastructure work whose entire visible output is the absence of a problem: a sender simply does not accumulate a slow-growing tail of undeliverable addresses that never get suppressed, and never has the conversation about why their reputation is drifting.
Bounce rate is the proportion of messages sent that failed to deliver. The honest answer to what counts as acceptable is that none of the mailbox providers who judge it has published a number, so any page quoting you an industry threshold is quoting its own invention. What a sending platform can honestly give you is the line it works to itself, and Omnivery's is below.
That absence is informative rather than an oversight, because the same organizations are perfectly willing to publish thresholds when they have one. Google's sender guidelines tell bulk senders to keep the spam rate reported in Postmaster Tools "below 0.10%" and to "avoid ever reaching a spam rate of 0.30% or higher". Yahoo asks senders to remain below 0.3% on complaints. Neither publishes an equivalent figure for bounces, and neither does M3AAWG, whose sender best practices discuss bounce handling at length without ever naming a rate.
Because the same rate means different things depending on what produced it, and receivers are judging the cause rather than the ratio:
So the first comparison is against your own baseline, per receiver, over time. The second is against the line your platform actually works to. Omnivery treats a bounce rate above 3% as a warning sign that something is wrong: not a penalty threshold, but the point at which a rate stops being a trend to watch and becomes a cause to find. The contractual ceiling in our terms of service is separate and looser: bounced messages must stay under 5% of messages sent over a rolling one-month period, alongside limits on unsubscribes, suppressions and spam complaints. A list that is validated at collection and suppressed properly does not get near either figure, and when one does cross 3% the cause is almost always in the data rather than in the sending, which is the next section.
The single most useful diagnostic on this page. Bounce rate moves slowly when it moves for delivery reasons and jumps when it moves for data reasons. A step change on one send, from a stable baseline, points at what went into the list rather than at what is happening to the mail:
The exception that catches people, and the reason to break the rate down by receiver before acting on it. A global bounce rate is good for spotting a major problem and bad at saying what it is. An unusual rate at one specific mailbox provider points somewhere else entirely: SPF, DKIM or DMARC authentication failing at that receiver, a routing loop, a missing or invalid PTR record, connection limits for that domain being exceeded, or the sending IP's reputation there, up to and including blocklist inclusion.
Every one of those produces bounces at one provider while the rest of the list delivers normally, and none of them is fixed by removing recipients. If the rate jumped at exactly one domain, the problem is between you and that domain.
Bounce rate matters because of what a high one is evidence of. Receivers are not penalizing the ratio; they are reading it as a proxy for how the list was built and how it is maintained. A large volume of permanent failures reads as a poorly managed registration process, or an old list, or a list being used for something it was not collected for, and it costs points against the IP's reputation that then cost deliveries. The rate is the symptom. The registration process is the disease.
Almost all of this happens before the send. By the time a message bounces, the decision that caused it was made when the address was collected, and the only remaining move is to stop mailing it.
Yahoo publishes the shortest version of the whole discipline, under a heading called "Remove invalid recipients": monitor hard and soft bounces as well as inactive recipients, reduce the number of invalid recipients by using double or confirmed opt-in, remove invalid recipients from the list promptly, and consider sending a reconfirmation email to inactive subscribers periodically. Everything below is that list with the reasoning attached.
None of this is exotic and all of it compounds. A validated form and a confirmation step remove most hard bounces before they exist; a suppression list nobody prunes keeps them from coming back; and the pattern watching catches what the first two miss.
The short version, with links to the full docs at the end.
Two things that surprise people, both of which are working as intended:
Details, categories and the migration options are documented under suppressions and allowlists. Event types, formats and endpoint response handling are documented under webhooks.
At a glance
Questions
An email bounce is a delivery failure returned by the receiving mail server. It arrives in one of two ways. Most often the receiver refuses the message during the SMTP conversation, with a three-digit reply code, before it has accepted responsibility for it - the industry term for that is a rejection. Less often the receiver accepts the message and then discovers it cannot deliver, and sends a separate message back to the return path hours or even days later. That second one is a bounce in the strict sense, and it is the harder of the two to process, because it arrives as ordinary inbound email written in whatever format the remote server happens to use.
Permanence. A hard bounce is a permanent failure - the receiving server is saying that the address or the domain no longer exists or never existed - and the address should be suppressed immediately and never mailed again. A soft bounce is a temporary failure such as a full mailbox, a server outage, a message over a size limit, or the receiver throttling your sending rate, and delivery may well succeed on a retry. The practical difference is what you do next: a hard bounce ends the relationship with that address, a soft bounce means wait and try again.
Four things, in rough order of frequency. The mailbox does not exist, usually because of a typo at signup or a deleted account. The domain does not exist or publishes no MX record, which is the mistyped-domain case and is more common than people expect. The mailbox has been permanently disabled, typically because someone left an organization. Or the address is syntactically invalid and no server will accept it. All four share the property that repeating the send changes nothing, which is exactly the test RFC 5321 uses to define a permanent failure.
A full mailbox, a receiving server that is temporarily down or overloaded, a message that exceeds a size limit, greylisting - where the receiver deliberately refuses an unfamiliar sender on first contact and accepts the retry - or rate limiting because you are sending faster than that mailbox or domain will accept. Note that two of those have nothing to do with the recipient at all. A throttle is a statement about your sending reputation and a server outage is a statement about the receiver, and neither is a reason to remove anyone from a list.
It depends entirely on what follows it, which is why 550 is the most misread code in email. RFC 5321 defines it as "Requested action not taken: mailbox unavailable", and gives three example causes: mailbox not found, no access, or the command rejected for policy reasons. Those are unrelated problems. A 550 carrying enhanced status 5.1.1 means the address does not exist and should be suppressed. A 550 carrying 5.7.1 means the receiver is refusing your mail - Google documents this case as the sending IP being on a suspended list - and suppressing the recipient is precisely the wrong response, because every address at that domain will return the same code until the reputation problem is fixed. Read the enhanced status code and the descriptive text before acting on a 550.
A 4xx is a transient negative reply: the action did not happen, but the condition is temporary and the client should try again. A 5xx is a permanent negative reply: the action did not happen and the client should not repeat the same request. RFC 5321 offers a useful test for which is which - a reply belongs in the 4xx class if the identical attempt could succeed later without anything changing about the message, the sender or the receiver. If something has to change first, it belongs in the 5xx class. Enhanced status codes use the same first digit with the same meaning, so 4.2.2 and 5.1.1 carry transient and permanent respectively.
Yes, and a sending platform will do it for you on a schedule. That is what the transient class is asking for. The judgment is not whether to retry but when to stop: a message still inside its retry window is deferred rather than bounced, and may still be delivered. Counting a deferral as a bounce makes a bad afternoon at a mailbox provider look like a list quality problem, and the two call for opposite responses.
When the pattern says the address is dead rather than the server having a bad day. Nobody publishes a definitive number, and any page that gives you one has invented it. The closest thing to an industry position is M3AAWG's, which recommends removing an address that bounces consistently across multiple consecutive campaigns and suggests, as a general rule, at least two consecutive bounces over two weeks or more. The two-week span is the important half: it is there to allow for receiver-side faults that produced an erroneous bounce. Time matters more than count - ten failures in an hour is one outage, two failures a fortnight apart is an abandoned mailbox.
There is no industry-published threshold, and the absence is informative. Google and Yahoo both publish spam complaint rate targets - Google asks bulk senders to stay below 0.10% and never reach 0.30%, Yahoo asks for below 0.3% - and neither publishes a bounce rate equivalent, nor does M3AAWG. That is because the same rate means different things depending on what produced it: a B2B list bounces more than a consumer list and always will, a list idle for eighteen months bounces heavily on its first send back, and transactional mail bounces close to never. What a platform can give you is its own line. Omnivery treats a bounce rate above 3% as a warning sign that something is wrong, and its terms of service set a contractual ceiling of under 5% of messages sent over a rolling one-month period. Compare against your own baseline, per receiving domain, over time, and treat 3% as the point where a trend becomes a problem to find.
Bounce rate drifts slowly when the cause is delivery and jumps when the cause is data. A step change from a stable baseline usually points at a bad import, a signup form without validation, a purchased list, or a resumed send to a segment nobody has mailed in a year. There is one important exception worth checking first: break the rate down by receiving domain. If the jump is at one provider while the rest of the list delivers normally, the problem is between you and that provider - authentication failures, routing loops, missing or invalid PTR records, exceeded connection limits, and blocklist inclusion are the usual causes. None of those is fixed by removing recipients.
Hard bounces do, and directly. Receivers read a high volume of permanent failures as evidence about how a list was built and maintained. A large volume of hard bounces reads as a poorly managed registration process or an old or misapplied list, and it subtracts from the sending IP's reputation and causes further delivery problems. The rate itself is not what is being penalized; it is what the rate implies. Soft bounces matter much less in isolation, though a rising soft bounce rate at a specific provider is often the first visible sign of a reputation problem developing.
No. A hard bounce means the address will not accept mail, so another attempt cannot succeed and only produces another permanent failure for the receiver to count. The pressure to remove addresses from a suppression list usually arrives with a list-size target attached, and it does not recover a subscriber - it recovers a delivery attempt that will fail again and cost reputation again. Google's own sender guidelines recommend automatically unsubscribing recipients with multiple bounced messages, which is the same instruction from the receiving end.
No, and the SMTP specification is the clearest evidence of it. RFC 5321 notes that "even some permanent error conditions can be corrected", and in one case instructs clients to override the class outright: when a server exhausts its recipient limit it should reply 452, but some reply 552, and RFC 5321 tells clients to treat that 552 as a temporary failure. RFC 3463 classifies a full mailbox as a persistent transient failure, yet plenty of servers return it as a 5xx anyway. So a 5xx should be read as the receiver's instruction not to repeat this exact attempt, which is not the same statement as the address being permanently dead.
Usually because the receiving server is not being careful, since RFC 3463 explicitly classifies a full mailbox as a persistent transient failure on the grounds that the recipient can delete messages and make space. But there is a legitimate version of it too. Google returns 452 with 4.2.2 for an inbox that is out of storage space, and 552 with 5.2.2 for an inbox that is out of storage space and inactive. The second one is correct: the mailbox being full is temporary, the account being abandoned is not. Which means neither "trust the numeric class" nor "look for the words mailbox full" is a safe rule on its own, and both are wrong on one of those two cases.
Yes, in both of the ways that matter. A receiving server can return a permanent code for a temporary condition, most commonly a full mailbox, in which case a sending system that trusts the code suppresses a subscriber whose address still works and never finds out, because it has stopped sending. And a permanent code can describe something other than the recipient: a 550 with 5.7.1 is the receiver refusing your mail, not a statement that the address is invalid. A sending system that treats it as a hard bounce will empty a whole domain's worth of valid addresses out of a list because of a reputation problem.
The address is never suppressed, and the sender keeps mailing it. That is the whole problem in one sentence. There is no error, no alert and no entry in the reporting, because the bounce was never recognized as a bounce. Every subsequent send produces another permanent failure at the receiver, and repeated attempts to non-existent addresses are one of the signals receivers use to build a reputation on a sender. So a parsing gap becomes a reputation problem silently, and by the time it shows up as a delivery problem it looks like something else entirely.
No. RFC 3464 defines a structured delivery status notification format specifically so that failures can be reported in a machine-parsable, language-independent way, and plenty of mail servers follow it. Plenty do not. Bounces arrive as ordinary HTML email, as human-readable paragraphs with no structured status data anywhere in the message, or in vendor-specific shapes that follow no published specification. Even where the status code is correct, the text beside it is not standardized - the descriptive message is the receiver's to write, varies greatly between receivers, and may only loosely follow the RFC, while being exactly what senders have to categorize on.
Badly, by most systems, and the difficulty is not evenly distributed. European-language bounces are comparatively tractable because they share the Latin alphabet, so a rule set degrades gracefully - it can still catch an address, a domain or a status code embedded in unfamiliar prose. Bounces in Korean, Chinese and Japanese offer nothing to partially match against, so a Latin-based pattern set does not degrade, it returns nothing. Omnivery automatically translates bounce messages that arrive in languages which would otherwise prevent reliable pattern detection, so the same classification logic applies regardless of the language the remote server answered in.
Yes. Permanently undeliverable addresses are added to the Bounce suppression list as they are found, and that list then prevents further sending to them. It is one of four suppression lists - Bounce, Unsubscribe and Complaint are populated by the system, Block is under your control and accepts whole domains as well as individual addresses. One exception worth knowing: transactional messages are exempt from unsubscribe and complaint suppression, so a password reset is not withheld because someone opted out of a newsletter, but they are not exempt from bounce suppression, because a nonexistent address cannot receive a password reset either.
Yes. Suppression data can be imported from an existing provider during onboarding using the migration tooling, or uploaded as CSV, or entered address by address. This matters more than it sounds: a suppression list is the accumulated record of everything a sender has learned about who cannot be mailed, and starting a new platform without it means relearning all of it by generating the bounces again, at exactly the point where a new sending setup is least able to afford them.
Every external claim on this page traces to one of these. Statements about Omnivery's own platform link to the relevant documentation where they are made, rather than being listed here.
Vendor error tables change. The Google and Yahoo pages cited here were checked in September 2026. The M3AAWG document is the current revision at that date; earlier revisions differ on several points, so check the version before quoting it. Statements about Omnivery's bounce processing describe the approach rather than any measured proportion of bounces handled, and no figure is claimed for how many formats, languages or patterns are covered.
Bounces are the visible symptom of decisions made earlier: how the address was collected, how the domain was introduced to receivers, and which addresses the mail leaves from. These cover those.
Standard delivery status notifications parsed structurally, non-standard and HTML bounces matched on patterns built from real traffic, and bounces in languages a Latin pattern set cannot see translated first. Categorized rather than reduced to hard and soft, with the classification overridden where a receiver got the code wrong, and reported in real time by webhook. Bring your existing suppression lists with you.