Deliverability

Bounces and feedback loops

When a message does not arrive, the system says so. It only says so to an address hardly anyone reads, in a format hardly anyone processes — and that is precisely where deliverability comes apart later on.

Where a bounce goes

Not to the address in From:. Bounces go to the envelope sender from MAIL FROM — the distinction is on the page about envelope and letterhead.

That is deliberate: a newsletter should collect its bounces in a processing mailbox, not with the editorial team. The practical consequence, though, is that for many senders they land in a mailbox nobody ever looks into.

Hard and soft

A hard bounce is final: address does not exist, domain does not exist, mailbox deleted. Reply code 5xx. Anyone writing to such an address a second time is doing so against better knowledge — and recipient systems score exactly that.

A soft bounce is provisional: mailbox full, server temporarily unreachable, greylisting. Reply code 4xx. The sending server tries again by itself over hours or days; there is nothing to do here.

The format that is barely used

For machine-readable bounces there has been a defined format since 2003: a multipart message with a section that gives recipient, status and reason in clearly named fields.

Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.com

Final-Recipient: rfc822; bert@example.com
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 <bert@example.com>: Recipient
    address rejected: User unknown in local recipient table

Status: 5.1.1 means "recipient address does not exist" — unambiguous, language-independent, with no need to interpret the error message underneath.

Even so, many senders process bounces as text, or not at all. The reason is banal: it works without doing so. One invalid address in a list does not hurt at first — until the list as a whole does.

Why this costs deliverability later

A high bounce rate is a clear signal to receiving systems: this list is not maintained. Bought, stale, or assembled without confirmation.

It gets worse. Some providers keep abandoned addresses and reactivate them after a long interval — not for a new owner but as a trap. Mail to such an address proves that sending happens without ongoing confirmation, and hits the sender's reputation accordingly.

The back channel for complaints

Besides bounces there is a second kind of feedback: when a recipient reports a message as spam, some large providers send that information back to the sender — provided the sender has signed up for it.

Anyone taking part can remove the person concerned from the list at once and stop complaints accumulating. Anyone not taking part learns of the problem only when delivery gets worse overall — without knowing why.

Backscatter

A side effect that hits the uninvolved: if a server accepts a message first and only then finds that the recipient does not exist, it has to generate a bounce — to the envelope address, which in the case of spam is forged. The bounce then goes to somebody who never sent anything.

The countermeasure is simple and standard today: reject unknown recipients during the SMTP dialogue, before the message is accepted. Then there is no bounce, only a refusal to the party actually submitting.

What follows from this

Bounces are the only feedback the system offers of its own accord. They are incomplete — about a message that was delivered and then quietly filed into the spam folder they say nothing. But they are all there is.

Ignore them and you lose the only available information about your own mail, and learn of the problem only when a customer rings up and asks why no reply ever came.