Why do emails bounce? Every cause, sorted by what the error is telling you

A bounce is the one deliverability failure that comes with an explanation attached. Spam-foldering is silent; a bounce mails you back a report, from "Mail Delivery Subsystem" or your platform's bounce handler, quoting the exact refusal the receiving server issued. Most senders skim past that text to the word "failed" and miss the useful part: the refusal states a cause, and each cause asks for a different response. This guide is a tour of those causes, in roughly descending order of how often they show up.

What a bounce actually is

Email delivery is a live conversation over SMTP. Your sending server looks up the recipient domain's MX record (you can do the same with the MX lookup), connects to the listed server, and offers the message. The receiver answers every step with a numeric code. Codes starting with 2 mean accepted; codes starting with 4 mean "temporary problem, try again later"; codes starting with 5 mean "permanent refusal, do not retry." That three-digit grammar comes from RFC 5321, the SMTP specification, and the extended X.Y.Z codes that usually accompany it (like 5.1.1, unknown user) are defined in RFC 3463.

The 4-versus-5 distinction is the entire taxonomy of bouncing. A 5xx refusal produces a hard bounce: the address or the message is being rejected permanently. A 4xx deferral, if it persists until the sending server gives up retrying (typically after a few hours to a few days), produces a soft bounce. Everything below sorts into one of those two families, and the operational playbook for each is covered in hard bounce vs soft bounce.

Cause one: the address does not exist

The most common hard bounce by a wide margin. The mailbox was mistyped at signup, was abandoned and later deleted by the provider, or belonged to an employee who left the company. The receiving server answers 550 5.1.1 or similar: no such user.

The response is non-negotiable: stop mailing the address, permanently, via your platform's suppression list. Repeatedly sending to nonexistent mailboxes is one of the clearest spam signals a receiver can observe, because legitimate senders with consented lists rarely accumulate many dead addresses, and some abandoned domains are recycled into spam traps. Prevention lives at the form: double opt-in catches typos and fakes before they ever reach your list, and routine list hygiene clears the addresses that die later.

Cause two: the mailbox or message hits a limit

The classic soft-bounce family. A full mailbox (452 or 552, mailbox over quota), a message too large for the receiver's limit, or a receiving server that is briefly overloaded or down. The address is fine; the moment is wrong. Sending platforms retry these automatically, and most resolve without you noticing. They matter only in aggregate: an address that soft-bounces every campaign for weeks is abandoned in all but name, and most platforms convert it to a suppression after a run of consecutive failures.

Cause three: the receiver is greylisting you

Some servers answer the first delivery attempt from an unfamiliar sender with a deliberate temporary refusal, then accept the retry a few minutes later. The technique is called greylisting, and it exists because crude spam software often never retries. To you it looks like a brief deferral in the log and a slightly delayed delivery. Nothing is wrong; nothing needs fixing. It becomes a problem only for time-critical mail like password resets, which is one reason transactional streams belong on infrastructure with established reputation.

Cause four: authentication failed and policy said reject

This is the bounce family that has grown the most in recent years. If a domain publishes a DMARC record with a p=reject policy, receivers are instructed to refuse mail that fails authentication for that domain outright, and the refusal arrives as a bounce citing DMARC or policy reasons. The mechanics of the failure itself are covered in DMARC fail; the policy levels in DMARC policy.

Two versions of this bounce exist, and they mean opposite things. If your own legitimate mail bounces against your own domain's policy, your SPF record or DKIM setup is incomplete for a sending service you actually use, and the fix is to repair authentication, verified end to end with the email authentication checker. If mail pretending to be your domain bounces, the policy is doing precisely its job. Since the mailbox providers' bulk-sender requirements made DMARC mandatory for high-volume senders, misconfigured authentication has become one of the most common causes of sudden, campaign-wide bounce spikes.

Cause five: the receiver distrusts the sender

The reputation family. The refusal names not the recipient but you: your sending IP appears on a blocklist the receiver consults, your domain's reputation is poor, or the receiver's filters rate the connection as spam-like. Wording varies: "listed at", "poor reputation", "message refused", sometimes with a URL explaining the block.

These are the bounces that deserve immediate attention, because they affect whole providers at once rather than single addresses. Check your sending IP and domain against major blocklists with the blacklist checker (the removal procedures are in email blacklist removal), and treat the bounce as one symptom of a broader sender reputation problem; the full diagnostic sequence is in why emails go to spam, because reputation bad enough to bounce mail is usually spam-foldering it at other providers first.

Cause six: the plumbing is wrong

A residual family of configuration causes: a recipient domain with no MX records at all (often a typo'd domain, gamil.com class), a sending server without valid reverse DNS, a bounce domain misconfigured so that the Return-Path itself fails verification, or DNS outages on either side. Individually rare, collectively worth one periodic sweep: the email deliverability score checks the sending-side records in one pass.

Reading your bounce rate

Individual bounces are information; the rate is a verdict. Receivers watch what fraction of your sends fail, because a high failure rate is the signature of a stale or purchased list. What counts as high, how to compute yours, and how to bring it down is its own guide: email bounce rate. The short version: investigate above 2%, treat 5% as an emergency, and remember that the fix is almost always list quality, not resending.

Related guides

• Hard bounce vs soft bounce — the operational playbook for each bounce family
• Email bounce rate — thresholds, math and reduction tactics for the aggregate number
• Why emails go to spam — the silent failure that reputation-family bounces predict
• Email blacklist removal — what to do when the bounce names a blocklist
• Blacklist checker — test your sending IP and domain against major DNSBLs
• Email deliverability score — one-pass check of your sending-side DNS and authentication

About this guide

Written by InboxRatio Editorial. Bounce classifications follow RFC 5321 and RFC 3463; provider-specific enforcement details come from the mailbox providers' published sender requirements. The threshold guidance quoted is practitioner convention and labeled as such. No vendor sponsorship influences it.

Methodology

InboxRatio's benchmark sends real campaigns through the platforms we review to a controlled seed list and records where each message lands. This guide draws on protocol and provider documentation rather than our measurements; the protocol is in how we test and our source rules in sources.

Last updated

19 September 2026. RFC references and provider requirement details reviewed quarterly.

Frequently asked questions

Why do emails bounce? Because the receiving server refused them, either permanently (hard bounce: nonexistent address, policy rejection, blocklist) or temporarily (soft bounce: full mailbox, server trouble, greylisting). The bounce message quotes the refusal code, and the code's first digit, 4 or 5, tells you which family you are in.

What is the difference between a hard bounce and a soft bounce? A hard bounce is a permanent 5xx refusal: remove the address. A soft bounce is a temporary 4xx deferral that exhausted its retries: leave the address but watch it, and suppress it if it soft-bounces repeatedly across campaigns.

Do bounced emails hurt my sender reputation? The bounces themselves are a symptom, but a high bounce rate does damage: repeatedly mailing dead addresses tells receivers your list was not collected with consent or has not been cleaned, both of which correlate with spam. Keeping the rate low through suppression and list hygiene protects your reputation.

Can an email bounce because of spam filtering? Yes. Reputation-family bounces, blocklist refusals, and DMARC p=reject policy bounces are all filtering decisions expressed as refusals rather than spam-foldering. If the bounce text names a blocklist or a policy, treat it as a deliverability problem, not an address problem.

What bounce rate is acceptable? Practitioner convention treats under 2% per campaign as normal, 2 to 5% as a list-quality warning, and above 5% as an emergency worth pausing sends for. Providers do not publish exact enforcement thresholds, so treat these as working guidance, not official limits.

Should I resend a bounced email? Not to hard-bounced addresses: the refusal is permanent and resending compounds the reputation damage. Soft bounces are already retried automatically by your platform, so a manual resend adds little; if the address keeps failing, suppress it.

The bounce report you skimmed past is the diagnosis. Read the code, sort it into its family, and let the blacklist checker and your suppression list handle their respective halves of the problem.