Undeliverable, bounced, rejected: what your ESP dashboard actually means

"Undeliverable," "bounced," and "rejected" are dashboard words, not SMTP terms. No mail server has

ever sent a reply that says "bounced" - it sent a three-digit reply code, and your sending

platform or CRM translated that code into one of these labels using its own, often inconsistent,

internal rules. Different tools map the same underlying SMTP reply to different labels, which is

why the same failure can show up as "bounced" in one system and "rejected" in another.

What each label usually means, and what it actually doesn't tell you

• "Bounced" is the vaguest of the three. Most tools use it for any failure at all, hard or

soft, temporary or permanent, collapsing a 421 connection refusal and a 550 5.1.1

nonexistent mailbox into the same word. If your tool distinguishes "hard bounce" from "soft

bounce," that distinction maps roughly to the 5xx/4xx split - but confirm it, because some

tools get this wrong, classifying a 552 5.2.2 (mailbox full, a 5xx reply but genuinely

temporary in practice) as a hard bounce purely because of the leading digit.

• "Undeliverable" usually means the platform received a bounce notification (an NDR/DSN) back

from the recipient's system *after* initially accepting the message, rather than a rejection at

send time. This matters: it means your own send attempt got a 250 OK, and the failure

happened one hop downstream, which is a meaningfully different diagnostic starting point than a

rejection your own server saw directly.

• "Rejected" typically means the receiving server refused the message during the live SMTP

transaction itself - you have (or your sending platform has) the literal reply code from that

moment, which is the most useful of the three labels if your tool exposes it.

The real distinction that actually matters

Finding the real code behind the label

$ grep -A2 "550\|551\|552\|553\|554" /var/log/mail.log | tail -10
Oct 14 11:02:11 mx1 postfix/smtp[9021]: ABC123: to=<test@mailpilots.in>,
    relay=mx.example.net[203.0.113.20]:25, delay=1.2, status=bounced
    (host mx.example.net[203.0.113.20] said: 550 5.1.1 The email account
    that you tried to reach does not exist (in reply to RCPT TO command))

The line "(in reply to RCPT TO command)" and the quoted 550 5.1.1 are the actual facts. The word

"bounced" earlier in the same log line is Postfix's own label, applied using exactly the same

kind of internal convention your ESP dashboard uses - useful as a quick filter, not as the

diagnosis itself.

The ordered approach

1. Find out whether your platform exposes the raw SMTP reply code anywhere - a bounce detail

view, a webhook payload, a raw log export. If it does, use that, not the summary label, for

any decision more consequential than a quick glance.

1. Check your platform's own documentation for what its labels mean, since the mapping is

not standardised across tools. One platform's "soft bounce" may include conditions another

platform would call "deferred" or simply not report as a bounce at all.

1. Treat "undeliverable" and "delayed" as a signal to look one hop further. The problem is

not in your own send attempt; it is somewhere between acceptance and final delivery.

1. Never build suppression rules on a dashboard label alone. Build them on the actual

enhanced status code family: suppress only on confirmed 5.1.x (addressing) failures, never

generically on "bounced."

1. Audit your platform's hard/soft classification periodically against a few real examples -

cross-check a handful of flagged "hard bounces" against their actual reply codes to confirm

the mapping is behaving the way you assume it is.

What not to do

• Do not assume every tool uses the same definition for "bounced." The word alone is not

portable information between platforms, even within the same organisation using two different

tools.

• **Do not suppress an address based on a generic "bounced" or "undeliverable" label without

checking the underlying reply class.** A 552 5.2.2 mailbox-full condition and a 550 5.1.1

dead address can both show up under the exact same dashboard word in a poorly designed tool.

• Do not treat "delayed" as equivalent to "failed." A delayed message is often still in

transit and may still succeed.

• Do not export bounce data for analysis without also exporting the raw reply text, if your

platform offers it - the label alone loses the one piece of information that actually explains

what happened.

MailPilot reports the literal SMTP reply and enhanced status code behind every delivery event

rather than only a paraphrased status label, specifically so that "undeliverable," "bounced," and

"rejected" never have to be guessed at - the real three-digit answer is always available

underneath.