SMTP Bounces & the Null Reverse-Path: Handling Delivery Failures

When the SMTP delivery chain encounters a permanent failure — a non-existent recipient, a rejected domain, a mailbox that has exceeded its quota — the receiving MTA generates a bounce message to inform the sender.

Bounces are distinct from Delivery Status Notifications. A DSN is a machine-readable protocol extension requested at submission time; a bounce is an ordinary email message generated automatically by the MTA whenever delivery fails, regardless of whether DSN was requested.

How Bounces Work

When delivery fails permanently (e.g., the recipient address does not exist), the receiving MTA generates a new email sent back to the Return-Path address (the envelope MAIL FROM). This bounce contains:

The original message headers (or a subset).
A human-readable explanation of the failure.
A machine-readable status code (e.g., 5.1.1 — mailbox does not exist).

The bounce itself is delivered via regular SMTP — it is just another email sent to the Return-Path domain’s MTA.

Sender's MTA                    Recipient's MTA
      |                               |
      | -- MAIL FROM: <sender...> --> |
      | -- RCPT TO: <[email protected]> |
      | -- DATA (message body) -----> |
      | <-- 550 5.1.1 (rejected) -----|
      |                               |
      | *** The sending MTA generates a bounce ***
      |                               |
      | -- MAIL FROM: <>(null) -----> |   (null envelope = no further bounces)
      | -- RCPT TO: <sender...> ----> |
      | -- DATA (bounce message) ---> |

The Null Reverse-Path

When a bounce message itself fails to deliver, the sending MTA must avoid creating an infinite bounce loop. It does this by setting the envelope MAIL FROM to <> (the null reverse-path). Receiving MTAs recognise <> as a signal that no further DSN or bounce should be generated for this message — a concept known as the null reverse-path defined in RFC 5321, Section 4.5.5.

Without the null reverse-path, a delivery failure of a bounce would trigger another bounce, which could itself fail, triggering another, and so on. The null reverse-path is the circuit breaker that prevents this chain reaction.

Practical Implications

Monitor Your Return-Path Inbox

Bounces sent to the Return-Path MUST be processed — either by automatically suppressing invalid addresses or by alerting postmasters. An unmonitored Return-Path inbox can fill with bounces, causing deliverability issues and wasting server resources.

Set a Meaningful Envelope From

Some providers use a separate subaddress (e.g., [email protected]) to separate bounces from personal mail. This makes it easier to automate bounce processing without mixing it with user-facing email.

Variable Envelope Return-Path (VERP)

Large senders use a unique Return-Path per recipient to automatically identify which address bounced:

[email protected]

When a bounce arrives at bounces.sender.tinkmail.me, the local part bob+recipient=example.tinkmail.me can be parsed to extract the original recipient address ([email protected]). This technique, called VERP, is commonly used by mailing list managers such as Mailman.

Bounce Classification

Modern bounce-handling systems classify failures into:

Category	Example	Action
Hard bounce	`550 5.1.1` (no such user)	Suppress address immediately.
Soft bounce	`450 4.2.2` (mailbox full)	Retry with backoff; suppress after repeated failures.
Complaint	Abuse feedback loop report	Suppress address; investigate sending practices.
Technical	`452 4.3.1` (insufficient storage)	Retry; does not indicate a problem with the address.