Bounces, complaints and feedback loops

SMTP reply codes in plain English, how bounces get classified, who sends complaint reports back to senders, and why suppression lists are non-negotiable.

Last updated 19 July 2026

Email talks back. Every message you send gets an answer from the receiving server. Some recipients answer with a spam report, and mailbox providers run formal channels to deliver those verdicts to senders who ask. This return channel is how you find out who to stop mailing, and acting on it automatically is most of what "list hygiene" means in practice. This lesson walks the machinery: the reply codes, the bounce handling built on them, the complaint reporting on top, and the one thing the whole apparatus is blind to.

What the receiving server says

Delivery happens over SMTP, the conversation from the first lesson of this course, and every step of that conversation gets a numeric reply. Three families matter, and the first digit tells you which you're in.

A 2xx reply means accepted. 250 OK is the receiving server taking responsibility for the message. Note carefully what it doesn't promise: accepted means "I'll take it", never "the inbox". We'll come back to that.

A 4xx reply means temporarily rejected: try again later. The mailbox is full, the server is busy, you're sending faster than the receiver will take, or the receiver is deliberately deferring you (a technique called greylisting, which weeds out crude spam software that never retries; real mail servers always do). Nothing is dead yet. The sending server queues the message and retries on a schedule, usually for a few days, before giving up and reporting failure.

A 5xx reply means permanently rejected: stop, and don't retry. The address doesn't exist, the domain won't accept your mail, the message was refused by policy, or the receiver has blocked you. Retrying a 5xx is at best pointless and at worst a signal that your software ignores instructions.

Replies often carry a more precise second code and some human-readable text:

550 5.1.1 <someone@example.com>: Recipient address rejected: User unknown

That 5.1.1 is an enhanced status code meaning "no such mailbox", the classic dead address. RFC 5321 defines the base reply codes and RFC 3463 the dotted enhanced ones, if you want the primary sources. You rarely read these raw, but when a delivery problem escalates, the exact code and text in your ESP's logs is the difference between guessing and knowing.

From reply codes to bounces

A bounce is any of this failure information making its way back to you. It arrives two ways. Synchronous rejection happens live in the SMTP conversation: the receiver says 550, the message never lands. Asynchronous bounces arrive later as an actual email, when a server accepted the message and then discovered it couldn't deliver it. That bounce message is sent to the address in the Return-Path header, which is the entire reason that hidden bounce address exists, and why our checks grade the health of the Return-Path domain separately: a broken bounce domain means this whole return channel fails silently.

Raw codes then get classified. A hard bounce is a permanent failure, roughly the 5xx family with "user unknown" as its flagship. A soft bounce is a temporary one, roughly 4xx. Roughly, because the mapping is imperfect in ways that keep bounce-classification engineers employed: receivers use codes inconsistently, some send policy blocks as 4xx to be gentle, and the text alongside the code often says more than the number. Your ESP parses all of it.

Which brings up what ESPs automate, because you shouldn't be doing any of this by hand. Any serious sending platform retries soft bounces on a schedule and suppresses an address the moment it hard-bounces. Addresses that soft-bounce persistently across sends get retired too. This machinery works well, and your main job is to not sabotage it. The classic sabotage, one worth naming because it keeps happening: exporting contacts and re-importing an old CSV, which resurrects addresses the platform had suppressed for bouncing. The list came back; so did the dead.

Feedback loops: complaints, reported to you

Bounces cover delivery failures. Complaints, a recipient pressing report-spam, are a different signal, and by default you can't see them at all: the click happens inside the mailbox provider's interface, and no bounce comes back.

Feedback loops (FBLs) are the formal fix. A mailbox provider offers senders a registration, and once registered, the provider sends you a report each time a recipient marks your mail as spam, in a standard format called ARF (RFC 5965). Yahoo runs a complaint feedback loop; Microsoft runs its equivalent (the Junk Mail Reporting Program) for its consumer domains. The expected response to an FBL report is mechanical: suppress that recipient immediately. They didn't unsubscribe, but they told the provider they don't want your mail, which is the same instruction with a penalty attached.

Gmail is the deliberate exception. It offers no per-message feedback loop that identifies which recipient complained; Google treats that as a privacy line. What Gmail exposes instead is Postmaster Tools, which shows your aggregate spam complaint rate as a trend over time. You learn how many, never who. Both models drive the same behavior at different granularity: Yahoo tells you whom to suppress; Gmail tells you whether your practices overall are working, against the same 0.3% ceiling the bulk sender rules lesson covered.

In practice your ESP is registered for the per-message FBLs on your behalf and auto-suppresses complainers. Postmaster Tools, though, is on you, and verifying your domain there takes minutes. If you send any volume at all, register: it's free, and it is the only place on earth where your Gmail complaint rate is visible. I have no stake in that advice; it's Google's own tool.

The suppression list

All roads in this lesson end at one structure: the suppression list, the permanent ledger of addresses you will never mail again. Hard bounces go on it. Unsubscribes go on it. FBL complainers go on it. It's append-mostly by design, and your ESP maintains one whether or not you've ever looked at it.

Two rules about it are absolute. First, suppressing a complainer is non-negotiable. Someone who reported you as spam and then hears from you again doesn't reconsider; they report you again, and now the complaints compound on the metric Gmail and Yahoo enforce. No campaign and no quarterly target justifies mailing a known complainer. Second, the list outranks every other instruction: an address on it stays unmailed no matter what a segment, an import or a campaign filter says. Unsubscribes arriving through the one-click header belong on it too, and the 2024 rules require honoring those within two days. When you migrate ESPs, the suppression list migrates first, before a single contact. Moving your contacts without it is the re-imported-CSV disaster with a change of scenery.

What the return channel can't tell you

Now the honest close, because this machinery has a blind spot exactly where modern deliverability problems live.

Go back to 250 OK. Accepted means taken, and spam-foldering happens after acceptance. A foldered message generates no bounce. No reply code you'll ever see distinguishes inbox from junk folder, and a recipient who never saw the message files no complaint. From where your ESP sits, a spam-foldered send is indistinguishable from a wildly unpopular one: everything delivered, nobody clicked. Silence.

So the return channel reports the loud failures and misses the quiet one. A sender can watch a clean bounce dashboard and a flat complaint graph while an authentication problem folders half their mail, for months. That is the normal shape of a deliverability incident: the mechanical signals stay green, the first visible drop shows up in the sender's own open rates, and the cause (a DKIM key gone stale, an SPF record over its lookup limit) had been sitting in public DNS the whole time, checkable from outside. Bounce and complaint handling is necessary hygiene, and this course's next module is about measuring the part it can't see. In the meantime, the silent half has a two-minute test: send an email to your test address, or run the free health check, and read what receivers actually compute about your mail. The return channel won't volunteer it.

Those complaint thresholds stopped being advice, by the way. The bulk sender rules are where the numbers grew teeth, and they are next.

Terms from this lesson

SMTP reply code - the numeric answer a receiving server gives at each step of delivery. 2xx accepted, 4xx temporary failure, 5xx permanent failure.
greylisting - a receiver tactic of deferring first-time senders with a 4xx to filter out spam software that never retries.
enhanced status code - the dotted second code in a reply (5.1.1 means no such mailbox) that gives a more precise reason than the three-digit code alone.
asynchronous bounce - a failure notice sent as an email to the Return-Path address after a message was initially accepted, rather than refused live in the SMTP session.
feedback loop (FBL) - a mailbox provider's program for sending complaint reports to registered senders, typically in ARF format, so complainers can be suppressed.
Postmaster Tools - Google's free dashboard exposing a domain's aggregate Gmail spam complaint rate and reputation. The only view into Gmail complaints, since Gmail runs no per-message FBL.
suppression list - the permanent ledger of addresses never to mail again: hard bounces, unsubscribes, complainers and manual blocks. It migrates before your contacts do.