Why emails bounce: hard vs soft bounces and the real causes

An email bounces when the receiving mail server refuses to accept or deliver it and sends back a rejection notice — a Non-Delivery Report, usually called an NDR or just "a bounce." That report travels back to the address in your MAIL FROM (your return path) and lands as a bounce in your sending system.

The useful question isn't whether something bounced — it's why, because the reason determines whether you should ever try that address again. Every bounce carries a reason, and almost all of them sort cleanly into two buckets: permanent and temporary.

This is the only distinction that really matters operationally.

A hard bounce is permanent. The receiving server is telling you, with confidence, that this address will never accept mail. The mailbox doesn't exist, the domain has no mail servers, or you've been explicitly blocked. The correct response is to stop mailing that address. Re-sending won't help and actively hurts your reputation.

A soft bounce is temporary. The address might be fine; the server just can't take the message right now. The inbox is full, the server is busy, you got greylisted, or the message tripped a temporary limit. The correct response is to wait and retry, which most mail systems do automatically for a while before giving up.

The line between them is encoded directly in the SMTP reply code the server returns. Under RFC 5321, a 5xx code (like 550) is a permanent failure — a hard bounce. A 4xx code (like 451 or 452) is a transient failure — a soft bounce. If you only remember one thing about why emails bounce, remember that first digit.

Hard bounces are the ones worth preventing, because they map almost perfectly to bad data. The common causes:

• The mailbox doesn't exist. A frequent cause. The domain is real and its servers are running, but the local part — jane in [email protected] — was never created, or was deleted when someone left the company. The server replies 550 5.1.1 No such user or similar.
• The domain can't receive mail. The domain has no usable MX records (and no A-record fallback), or doesn't resolve at all. There is nowhere to deliver, so every address at that domain hard-bounces. Common with typo'd domains (gmial.com) and abandoned company domains.
• You've been blocked. The receiving server recognizes your sending IP or domain and refuses outright — often a reputation problem, an SPF/DKIM/DMARC authentication failure, or an explicit block-list entry. This bounce isn't about the recipient's address; it's about you.
• The address is a spam trap or known-bad. Some addresses exist only to catch senders mailing stale or purchased lists. These may not "bounce" in the classic sense, but they're addresses you should never have mailed — which is what a do_not_mail verdict is for.

Notice the pattern: the first two causes are visible before you send. A nonexistent mailbox refuses an SMTP probe the same way it refuses real mail; a domain with no MX is undeliverable to anyone. That's the entire premise of email verification — ask the server the question before you commit to a campaign.

Soft bounces are noisier and usually not your fault. The common causes:

• The inbox is full. The mailbox exists but is over quota. The server returns something like 452 4.2.2 Mailbox full. It may clear up; it may not, if the account is abandoned.
• Greylisting. A deliberate anti-spam tactic: the server temporarily rejects mail from senders it hasn't seen before with a 4xx, betting that spammers won't retry and that legitimate servers — which maintain retry queues — will. Your message gets through on a later attempt, often minutes later.
• Throttling and rate limits. Large providers cap how much mail they'll accept from one sender in a window. Exceed it and you get deferred — a soft bounce that says "slow down," not "go away."
• Server-side or temporary DNS issues. The receiving server is down for maintenance, overloaded, or having a transient DNS problem. These typically resolve on their own.
• Content or size limits. A message that's too large, or that trips a temporary content filter, can be deferred rather than rejected outright.

The honest catch: a soft bounce can become a hard bounce. If an inbox stays full or a server keeps deferring, your mail system eventually gives up after enough retries and reports a permanent failure. Persistent soft bounces are a signal to stop, too.

There are two layers to a bounce, and confusing them causes a lot of grief.

The SMTP reply, in the moment. If the server rejects mail during the SMTP conversation — at RCPT TO or DATA — your sending server sees the 4xx or 5xx immediately. This is a synchronous bounce, and it's the cleanest signal you get.

The async NDR, later. Sometimes a server accepts the message (250 OK), then discovers afterward that it can't deliver — and emails a bounce message back to your return path minutes or hours later. This is an asynchronous bounce.

Inside those reports, well-behaved servers attach an enhanced status code (RFC 3463) — the 5.1.1 in 550 5.1.1. The structure is class.subject.detail: 5.x.x is a permanent failure, 4.x.x is transient, and the rest narrows it down (x.1.1 = bad destination mailbox, x.2.2 = mailbox full, x.7.x = security or policy). When you're debugging why emails bounce, that enhanced code is the most precise clue you'll get — read it before the human-language text, which providers word however they like.

The response follows directly from the bucket:

• Hard bounce → suppress permanently. Remove the address from your list and don't mail it again. Most ESPs do this automatically and for good reason: continuing to hit known-bad addresses is one of the fastest ways to wreck your sender reputation.
• Soft bounce → let retries run, then watch. Your mail system already retries soft bounces on a schedule. Don't fight it. But track which addresses soft-bounce repeatedly across multiple sends — chronic soft-bouncers are effectively dead and worth suppressing.
• Block / reputation bounce → fix yourself, not the list. If you're seeing 5.7.x policy rejections, the problem is authentication or reputation. Check your SPF, DKIM, and DMARC; check whether your IP is on a block list; review your sending volume and complaint rate.

The strategic move is to prevent hard bounces in the first place. Verify addresses at the point of capture (the signup form) and clean existing lists before a big send. A verifier runs the same syntax → DNS/MX → live RCPT TO checks the receiving server would, so a nonexistent mailbox or dead domain gets flagged as invalid before it ever costs you a bounce. You can run any address through the full pipeline in the free playground, or wire the real-time API into your forms.