What’s the difference between “rejected” and “bounced”?

Rejected and bounced both mean "your mail did not get delivered," but they happen at different moments. The difference matters because one gives you an answer in milliseconds and the other can take hours, or never come back at all.

Rejection: the door slams during the SMTP conversation

When your sending server connects to the receiving server, it goes through a back-and-forth defined in RFC 5321. The receiver can refuse the message at any step in that conversation. You see the refusal on the wire. Nothing gets queued. Nothing is sent later.

Here is what a rejection looks like in an SMTP transcript:

S: 220 mx.example.com ESMTP ready
C: EHLO sender.example.net
S: 250-mx.example.com
S: 250 SIZE 52428800
C: MAIL FROM:<alice@sender.example.net>
S: 250 2.1.0 Ok
C: RCPT TO:<nobody@example.com>
S: 550 5.1.1 User unknown
C: QUIT

The 550 5.1.1 User unknown is the rejection. Your sending MTA logs it, raises a permanent failure for that recipient, and moves on. The receiver never generates a DSN because it never accepted responsibility for the message in the first place. Your own outbound system is the one writing the bounce record into your logs or your ESP's reporting.

This is what we call a synchronous bounce. The signal is in your hand before the connection closes. See also the breakdown of 4xx vs 5xx codes for which rejections are temporary and which are permanent.

Bounce: accepted now, returned later

A bounce in the strict sense happens after the receiving server says 250 OK to your DATA command. At that point the receiver owns the message. If something goes wrong later, the mailbox got deleted between MX acceptance and queue processing, the user is over quota, a forwarding loop blew up, a filter that runs post-acceptance flagged the content, the receiver has to tell you about it separately.

That separate message is called a Delivery Status Notification (DSN), formatted per RFC 3464. It arrives as an email from MAILER-DAEMON or postmaster, sent back to the Return-Path address you put in MAIL FROM. Your ESP or your own bounce handler parses it and matches it to the original send. The mechanics live in how bounce messages get generated and the basics of an NDR.

Why the distinction matters in practice

1. Speed of signal. A rejection feeds your suppression list inside a second. An async bounce can take minutes, hours, or days. If you are sending 200,000 messages and 8% of the addresses are dead, rejections let you stop wasting connections almost in real time.

1. Reliability of signal. Rejections are always reported to the sender because the sender is on the wire. Async DSNs travel back over open SMTP and can be lost. The Return-Path domain might be misconfigured, a spam filter might quietly drop the DSN, or the receiver might silently discard the message after acceptance without ever sending a notification. That last one is called blackholing, and it is how you end up with bounces that affect deliverability without you ever knowing.

1. Attribution. A rejection is unambiguous. The SMTP reply codes plus the enhanced status codes from RFC 3463 tell you exactly why. A DSN can be vague, malformed, or written in the receiver's local language.

1. Reputation cost. Most mailbox providers, Gmail and Microsoft included, reject bad addresses at SMTP time rather than accept-and-bounce, because rejecting at the door protects them from looking like a backscatter source. If a sender keeps hitting 550s on the same addresses and ignores them, that pattern is what burns sender reputation faster than the raw volume itself. See Google's Postmaster Tools sender guidelines for the official line.

Quick rule of thumb

If the failure code shows up on the same log line as the recipient address during the send, it was a rejection. If the failure shows up later as an inbound message with MAILER-DAEMON in the From and your original recipient quoted inside, it was an async bounce. Both end up in the same suppression bucket in a well-run ESP. Only one gives you the chance to react while the send is still running.