What Is an Email Bounce? Hard vs Soft Bounce Explained

You hit send on an email. A few seconds — or a few hours — later, a message lands in your inbox from something called "Mail Delivery Subsystem" or "postmaster," with a subject like "Undeliverable" or "Delivery Status Notification (Failure)." Inside is a wall of technical text, a copy of the message you sent, and somewhere in the middle a three-digit number you do not recognize. That message is a bounce, and it is your mail system's way of telling you the email did not reach the person you sent it to.

Bounces are one of those parts of email that everyone runs into and almost nobody is taught. They look alarming, they are written in jargon, and they leave you guessing whether the problem is on your end or the recipient's. The good news is that bounces follow a small, consistent set of rules. Once you know what a bounce is, the difference between the two kinds, and how to read the code inside the notice, the whole thing becomes legible — you can tell at a glance whether to fix the address, wait, or stop sending entirely.

This guide is the plain-English reference for email bounces. We start with a clear definition, then split bounces into the two categories that matter most — hard and soft — and explain why that split changes what you should do. We walk through the bounce message itself (the NDR), decode the common SMTP status codes you will actually see (550, 552, 421, 451, and friends), and lay out the real reasons emails bounce: bad addresses, full mailboxes, blocks and filters, and DNS problems. Then we get practical: how to read a bounce you have received, how to fix the underlying cause, how to prevent bounces before they happen, and why your bounce rate quietly shapes whether future emails reach the inbox at all.

We will keep it accurate and concrete — real status codes, real bounce text, and clear steps, not vague reassurance. Near the end we look briefly at where an AI-native email client fits, because some of the work of spotting and acting on bounces should not need your attention on every message.

What is an email bounce?

An email bounce is a message that fails to be delivered to its intended recipient and is returned to the sender, usually with an automated notice explaining that the delivery failed. The name is literal: the message is sent toward a destination, cannot be accepted, and bounces back the way it came. The notice that comes back is generated by a mail server — not by a person — and its job is to tell you that the email did not arrive and, ideally, why.

To see where a bounce comes from, it helps to picture how an email travels. When you send a message, your mail client hands it to your outgoing mail server. That server looks up the recipient's domain in DNS to find the right destination server (via its MX record), then connects and tries to hand the message over using SMTP, the protocol email servers use to talk to each other. The receiving server gets to decide whether to accept the message. If it accepts, the email is delivered. If it refuses — because the address does not exist, the mailbox is full, the message looks like spam, or for any number of other reasons — it returns an error, and somewhere along the chain that error is turned into the bounce message you receive.

The key thing to understand is that a bounce is a delivery failure, not a delivery success that the recipient ignored. If your email is delivered to someone's inbox or spam folder and they simply do not read it, that is not a bounce — the message arrived. A bounce specifically means the message could not be handed to the recipient's mailbox at all. That distinction matters because it changes the fix: a bounce is a transport problem (the address, the server, the connection), while an unread email is an attention or content problem.

Bounces come in two fundamentally different flavors, and almost everything practical about handling them rests on telling the two apart. A permanent failure — the address does not exist, full stop — is a hard bounce. A temporary failure — the server is busy right now, the mailbox is momentarily full — is a soft bounce. We will spend the next sections on exactly that distinction, because it is the single most useful thing to know about bounces.

What is the difference between a hard bounce and a soft bounce?

Every bounce is either hard or soft, and the difference is permanence. A hard bounce is a permanent delivery failure: the receiving server is telling you that this email can never be delivered to this address as things stand. A soft bounce is a temporary delivery failure: the message could not be delivered right now, but the same address might accept it later. That single distinction — permanent versus temporary — decides whether you should give up on the address or try again.

A hard bounce usually means something fundamental is wrong with the destination. The most common cause is an address that does not exist: a typo, a mailbox that was deleted, or a domain that is no longer real. Because the failure is permanent, retrying does not help — the server will reject the message every time. The correct response to a hard bounce is to stop sending to that address and, if it was a typo, correct it. Sending repeatedly to addresses that hard-bounce is one of the fastest ways to damage your sending reputation, which we cover later.

A soft bounce means the address is real and the destination is reachable, but something temporary got in the way. Classic examples: the recipient's mailbox is full and cannot accept more mail until they clear space; the receiving server is temporarily overloaded or down for maintenance; the message is larger than the server will accept at the moment; or a temporary rate limit ("greylisting") asked your server to try again shortly. Mail servers handle soft bounces by automatically retrying for a period — typically up to around 72 hours — before giving up. So a soft bounce is often invisible to you: your server quietly retries, and many soft bounces eventually deliver without you ever seeing a notice.

There is an important grey area: repeated soft bounces. If an address soft-bounces over and over — the mailbox stays full for weeks, or the server never recovers — most sending systems will eventually treat it like a hard bounce and stop trying. A temporary problem that never resolves is, in practice, a permanent one. So the hard/soft line is not perfectly rigid; it is about whether the failure is expected to clear on its own. The table below lays out the contrast.

What is a bounce message (NDR), and what is in it?

When an email bounces, the notice you get back has a formal name: a non-delivery report, or NDR — also called a delivery status notification (DSN), a bounce message, or a non-delivery receipt. It is an automated email generated by a mail server to tell the original sender that delivery failed. You can recognize it instantly: it comes from an address like MAILER-DAEMON@, postmaster@, or "Mail Delivery Subsystem," and the subject is something like "Undeliverable," "Delivery Status Notification (Failure)," or "Returned mail: see transcript for details."

An NDR is denser than a normal email because it is built for machines as much as for people, but it contains a predictable set of parts. There is a human-readable explanation at the top — a sentence or two saying the message could not be delivered. There is the failing recipient address, so you know exactly which email failed (useful when you sent to several people). There is a status code and a diagnostic message — this is the technical heart of the NDR, the SMTP reply that the receiving server gave, including the three-digit code and often a short text reason. And there is usually a copy of the original message's headers, sometimes the full original message, attached so you can see what bounced.

Two numbering systems appear in most NDRs, and it is worth knowing both. The first is the classic three-digit SMTP reply code (like 550 or 421). The second is the enhanced status code, a three-part number like 5.1.1 or 4.2.2 (defined by the email standards), which gives a more precise reason than the basic code alone. In 5.1.1, the leading 5 means permanent, the 1 in the middle is the subject (addressing), and the final 1 is the detail (the mailbox does not exist). You do not need to memorize the enhanced codes, but knowing the leading digit — 4 for temporary, 5 for permanent — instantly tells you whether you are looking at a soft or hard bounce.

The most useful habit when reading an NDR is to find the diagnostic line — skip the boilerplate and look for the line with the status code and the server's own words, like "550 5.1.1 The email account that you tried to reach does not exist." That line is the real reason your email failed, and it is what you act on.

What do the SMTP bounce codes mean (550, 552, 421, and more)?

The number inside a bounce is an SMTP reply code, and it is the most reliable way to understand why an email failed. SMTP codes are grouped by their first digit: 2xx means success, 4xx means a temporary (transient) failure, and 5xx means a permanent failure. So the single most important glance is at that first digit — 4 tells you soft bounce (retry may work), 5 tells you hard bounce (it will not). The second and third digits, and the accompanying enhanced code, narrow down the specific reason.

In practice you will see a fairly small set of codes again and again. The most common permanent code is 550, the all-purpose "mailbox unavailable" or "rejected" code — it shows up for non-existent addresses, blocked senders, and policy rejections, with the text after it telling you which. On the temporary side, 421 (service not available / try again later) and 451 (local error, try again) are the workhorses; servers issue these when they are busy, throttling you, or greylisting. The table below decodes the codes you are most likely to encounter and what each one means for what you should do.

A couple of cautions on reading codes. First, the same code can carry different meanings depending on the server's text — 550 covers both "this address does not exist" and "we are blocking you," which are very different problems with very different fixes. Always read the words after the number, not just the number. Second, 552 is a genuine grey area: the standard ties it to a mailbox over its storage quota or a message too large, which some systems treat as temporary (the mailbox might clear) and others as permanent. When you see 552, look at whether it says the recipient is over quota (likely to resolve, so soft-ish) or your message is too big (you must shrink it, so act now).

Enhanced status codes ride alongside the basic ones and add precision. You will see 5.1.1 (bad destination mailbox — the address does not exist), 5.2.2 (mailbox full), 5.2.3 (message too large), 5.7.1 (delivery not authorized / blocked, often a policy or authentication rejection), and on the temporary side 4.2.2 (mailbox full but temporarily), 4.4.1 (no answer from the receiving host), and 4.7.x (temporary policy or reputation throttling). The leading digit always agrees with the basic code's class, so they reinforce each other: 5.x.x is permanent, 4.x.x is temporary.

Why do emails bounce?

Bounces trace back to a handful of root causes, and grouping them makes the whole topic easier to hold. Broadly, an email bounces because the address is wrong, the mailbox cannot accept it right now, the receiving server is blocking it, or the plumbing (DNS and routing) that gets mail to the domain is broken. Each group maps cleanly to hard or soft and to a different fix.

Bad or non-existent addresses are the most common cause of hard bounces. A typo in the local part ("jsmiht" instead of "jsmith"), a mailbox that was deleted when an employee left, an address someone made up to get past a signup form, or a domain that no longer exists — all of these produce a permanent 550 / 5.1.1 because there is simply nowhere to deliver the message. These are unfixable except by correcting or removing the address, which is exactly why list hygiene matters.

Full mailboxes and oversized messages are the classic soft-bounce causes. If the recipient is over their storage quota, the server returns a 552 / 5.2.2 (mailbox full) and the message waits for retry — it often delivers once they clear space. If your message itself is too large for the server's limit (a giant attachment), you get 552 / 5.2.3 (message too large), which you fix by shrinking or linking the attachment rather than by retrying. Temporary server problems — the destination server is down for maintenance, overloaded, or briefly unreachable — produce 421 / 4xx soft bounces that auto-retry usually clears.

Blocks and content filtering are a large and growing category. The receiving server may reject your message because it looks like spam, because your sending IP or domain is on a blocklist, because you tripped a rate limit by sending too fast, or because your message failed authentication checks. These often appear as 550, 554, or 5.7.1 with text mentioning spam, policy, or a blocklist. They are reputation and content problems, not address problems — the address is fine, but the server does not trust the sender. Finally, DNS and routing problems sit underneath everything: if the recipient domain has no valid MX record, or DNS lookups fail, mail servers cannot find where to deliver and the message bounces (often 5.1.2, "bad destination system," or a temporary 4.4.x while DNS is flaky). The table groups the causes against their fixes.

One cause deserves a closer look because people misread it constantly: the authentication-related block. Receiving servers increasingly reject mail that fails sender authentication — the checks (SPF, DKIM, and DMARC) that prove your mail genuinely comes from the domain it claims. If your domain's authentication is missing or misconfigured, a strict receiver may bounce the message with a 5.7.1 or similar, even though the recipient address is perfectly valid. The bounce text will mention authentication, SPF, DKIM, or DMARC. This is not an address problem and retrying will not help; the fix is on your side, getting your domain's authentication records right.

It is also worth separating bounces from two things people confuse them with. An autoresponder (an out-of-office reply) means your mail was delivered and a mailbox sent an automatic answer — the opposite of a bounce. And a message landing in the spam folder is still a delivery; it arrived, just not in the inbox. A bounce is strictly a failure to deliver at all.

How do you read a bounce message you received?

Reading a bounce is a quick, repeatable process once you know where to look. The goal is to answer three questions in order: which address failed, is the failure permanent or temporary, and what is the specific reason. Everything you do next follows from those three answers. Here is the routine, step by step.

1. 1

   Confirm it is actually a bounce

   Check the sender. A real bounce comes from MAILER-DAEMON, postmaster, or "Mail Delivery Subsystem," with a subject like "Undeliverable" or "Delivery Status Notification (Failure)." If it claims to be a bounce but comes from an odd address or asks you to click something, treat it as suspicious — backscatter and fake bounces are used in phishing.

2. 2

   Find the failing recipient address

   Locate the line naming the address that failed (often labeled "Final-Recipient" or shown near the diagnostic). If you emailed several people, this tells you exactly which one bounced so you do not assume the whole send failed.

3. 3

   Read the leading digit of the code

   Find the status code and look at its first digit. A 5 means a permanent (hard) failure — the message will not deliver as-is. A 4 means a temporary (soft) failure — your server will retry, and it may well succeed. This one digit decides whether you act now or wait.

4. 4

   Read the diagnostic text

   Look at the words after the code — the server's own reason. "Account does not exist" points to a typo or dead address. "Mailbox full" / "over quota" is a soft bounce to wait out. "Blocked," "spam," "policy," or a blocklist URL points to a reputation problem. "Message too large" means shrink the attachment.

5. 5

   Match the reason to the right action

   Permanent + bad address: correct it or remove it. Temporary + full mailbox or busy server: do nothing, let auto-retry run. Permanent + spam/block/authentication: fix the sending side, not the address. Too large: shrink or link the attachment and resend.

6. 6

   Check whether it is a pattern

   One bounce to one address is routine. The same address bouncing repeatedly, or many addresses bouncing at once, signals a bigger issue — a stale list, a DNS problem on your side, or a reputation/blocklist event. Patterns get investigated, not retried.

How do you fix a bounced email?

Fixing a bounce means matching the cause to the right remedy — and crucially, knowing when there is no remedy and the right move is to stop sending. Because the cause is written in the bounce itself, fixing one is mostly a matter of following the diagnostic to its corresponding action. Here is how to handle the common cases.

1. 1

   Bad address: correct the typo or remove it

   For a 550 / 5.1.1 "does not exist," check for an obvious typo (transposed letters, wrong domain, .con instead of .com). If you can confirm the correct address, fix it and resend. If you cannot, remove the address — repeatedly mailing a dead address only hurts your reputation.

2. 2

   Full mailbox or busy server: wait, do not resend

   For a soft 4xx or a 552 "over quota," do nothing manual. Your mail server automatically retries for around 72 hours; most of these deliver once the mailbox clears or the server recovers. Manually re-sending just adds duplicates. Only act if it keeps failing past the retry window.

3. 3

   Message too large: shrink or link the attachment

   For 552 / 5.2.3, the size is the problem. Compress the file, send a link (cloud storage) instead of an attachment, or split the message. Resending the same oversized email will bounce again.

4. 4

   Spam or policy block: fix the sending side

   For 554 / 5.7.1 mentioning spam or policy, the address is fine — the server distrusts you. Review the message for spam triggers (link-heavy, misleading subject, risky attachment), make sure you are not sending too fast, and confirm the recipient actually wants your mail. Retrying unchanged will not help.

5. 5

   Blocklist: identify and resolve the listing

   If the bounce names a blocklist (it often includes a URL), check whether your sending IP or domain is listed and why. Resolve the underlying cause (compromised account, spam complaints, bad list), then follow the blocklist's delisting process. This is a sending-infrastructure fix, not an address fix.

6. 6

   Authentication failure: fix SPF/DKIM/DMARC

   If the bounce mentions authentication, SPF, DKIM, or DMARC, your domain's email authentication is missing or wrong. Verify the records are published and aligned. Until they are, strict receivers will keep rejecting otherwise-valid mail. This fix lives in your DNS, not in the recipient list.

7. 7

   DNS/routing problem: verify the recipient domain

   For a 5.1.2 "bad destination system" or repeated DNS-related failures, confirm the recipient's domain is spelled correctly and actually has valid MX records. If your own domain is the one failing to route outbound mail, check your DNS and outbound server configuration.

How do you prevent email bounces?

The cheapest bounce is the one that never happens. Most bounces — especially the reputation-damaging hard ones — are preventable with good habits on the sending side. Prevention falls into two buckets: keeping the addresses you send to clean, and keeping your sending trustworthy so receivers do not block you. Both reduce bounces and, as the next section explains, protect your ability to reach the inbox at all.

On the address side, the single highest-leverage habit is list hygiene: do not send to addresses you have no reason to believe are valid. Use a confirmed opt-in (the recipient verifies their address before you mail them) so typos and fake addresses are caught at the door. Remove addresses that hard-bounce immediately and permanently — never retry them. Periodically clean out addresses that have not engaged in a long time, since they are more likely to have been abandoned or turned into spam traps. And validate addresses at the point of entry: a simple format and domain check on a signup form stops the most obvious bad addresses before they ever enter your list.

On the trust side, the goal is to look like a legitimate sender to receiving servers so they accept your mail instead of bouncing it. Set up email authentication — SPF, DKIM, and DMARC — so receivers can verify your mail is genuinely from your domain; missing authentication is a growing cause of bounces. Warm up new sending domains and IPs gradually rather than blasting a large volume on day one, which trips rate limits and reputation throttles. Keep your content honest (no misleading subjects, sane link-to-text ratio, no risky attachments). Monitor blocklists so you catch a listing before it causes a wave of bounces. And respect volume and rate limits — sending too fast to one provider invites 421 throttling.

These habits compound. A clean, opt-in list mailed by an authenticated, warmed-up sender at a reasonable pace sees very few bounces, and the bounces it does see are mostly the unavoidable kind. A dirty list mailed by an unauthenticated sender in a burst bounces heavily and trains receivers to distrust everything that follows.

• Use confirmed opt-in so addresses are verified before you ever send to them.
• Remove hard-bounced addresses permanently and immediately — never retry a 5.x.x address.
• Validate address format and domain at signup to catch typos at the door.
• Set up SPF, DKIM, and DMARC so receivers can authenticate your mail.
• Warm up new domains and IPs gradually instead of sending a large volume at once.
• Keep content honest and monitor blocklists so a listing does not cause a bounce wave.
• Respect each provider's rate limits to avoid 421 throttling.

How do bounces affect your bounce rate and deliverability?

Bounces are not just individual failures — in aggregate they form your bounce rate, and your bounce rate quietly shapes whether your future emails reach the inbox at all. Bounce rate is the percentage of sent messages that bounce: divide bounced emails by emails sent and multiply by 100. Send 1,000 emails and have 20 bounce, and your bounce rate is 2%. It is one of the headline numbers any sender watches, because it is a direct read on the quality of your list and your sending.

What counts as a healthy bounce rate? As a rule of thumb, under 2% is generally considered healthy, and many practitioners aim for under 1%. Climb past about 2% and mailbox providers start to take notice; sustained high bounce rates — especially driven by hard bounces — are a strong signal of a poor list or a careless sender, and providers respond by trusting you less. That loss of trust is the real cost, because it does not stay contained to the bounced messages.

Here is the connection that ties this whole topic together: bounces feed sender reputation, and sender reputation drives deliverability. Mailbox providers track how your mail behaves — how much of it bounces, how often it is marked as spam, how recipients engage. A high hard-bounce rate tells them you are mailing addresses you should not, which is exactly what spammers do, so your reputation drops. As reputation drops, providers route more of your mail to spam or reject it outright — meaning a high bounce rate today causes more bounces and more spam-foldering tomorrow. It is a feedback loop, and it runs in both directions: keep bounces low and reputation stays strong, which keeps deliverability high.

This is why the hard-versus-soft distinction matters beyond the individual message. Hard bounces hurt reputation the most because they reflect list quality you control; a few soft bounces are normal and largely ignored. So the priority is clear: drive hard bounces toward zero through list hygiene, let your server handle soft bounces with automatic retries, and watch your bounce rate as an early-warning gauge. A rising bounce rate is usually the first visible sign that your list, authentication, or reputation needs attention before it costs you the inbox.

How does AI Emaily relate to email bounces?

For most people, bounces are a personal-email annoyance, not a marketing metric: you send a message, it bounces, and you have to notice the NDR, figure out whether the address is wrong or the mailbox is just full, and decide what to do. The friction is that the bounce arrives as a separate, jargon-heavy message that is easy to miss in a busy inbox — so a typo'd address quietly never reaches anyone, and you do not realize until it matters.

AI Emaily is an AI-native email client that connects your existing accounts — Gmail, Outlook, and any IMAP provider — in one place, so bounce notices across all of them surface together rather than scattering. When a message you sent bounces, the point is that you actually see it and understand it: a plain-language read of whether the failure is permanent or temporary and what to do next, instead of a wall of SMTP text. It works alongside the deliverability basics this guide covers — it does not replace fixing a bad address or setting up authentication, but it helps you notice the bounce and act on it.

And it stays private by design: your mail is yours, used to help you manage your own inbox, not to train models for anyone else. In its default Copilot mode you keep control — AI Emaily surfaces and drafts, and you decide. If reading and acting on bounces is something you would rather not do by hand on every stray NDR, that is exactly the kind of small, repetitive judgment an AI-native client is built to take off your plate. You can start free at app.aiemaily.com/signup.

The bottom line on email bounces

An email bounce is a message a mail server could not deliver and sent back with a failure notice. The most important thing to know is the split: a hard bounce is permanent (the address does not exist, you are blocked) and means stop; a soft bounce is temporary (mailbox full, server busy) and means retrying may work — and your server usually retries automatically. The bounce notice, an NDR, carries an SMTP code whose leading digit tells you which you have: 5 for permanent, 4 for temporary.

Reading a bounce is a quick routine: confirm it is genuine, find the failing address, read the leading digit, read the diagnostic text, and match the reason to the right action. Bad address — correct or remove it. Full mailbox or busy server — wait. Spam, blocklist, or authentication block — fix the sending side, not the address. Too large — shrink the attachment. And prevention beats fixing: clean, opt-in lists and authenticated, well-paced sending stop most bounces before they happen.

Bounces matter beyond the single message because they feed your bounce rate, and your bounce rate feeds your reputation and deliverability. Keep hard bounces near zero, let soft bounces resolve themselves, and watch a rising bounce rate as the early warning it is. Do that, and bounces go from a confusing nuisance to a clear, manageable signal — one that tells you exactly what to fix and when.