Bounce handling: read the failure, then act on it
A bounce is a machine-readable report, not a notification. It carries a reply code, an enhanced status code and a line of text from the receiving side, and those three fields decide whether the address should be retried, held, or never used again. Treating the whole category as one thing is what produces the two expensive mistakes: suppressing valid contacts after a temporary failure, and hammering a permanent one until the receiver stops accepting anything from you. This category covers the reading and the reaction.
Two classifications, and they disagree
The standard classification is the enhanced status code, defined in RFC 3463 and read as class, subject and detail. The one you see in a dashboard is your platform’s own bucketing, which is coarser and not identical between vendors. An address marked hard by one platform can be soft at the next, so a suppression list exported from one system needs re-reading before it is trusted in another.
Start from the code rather than the label: hard versus soft, with the codes behind each, then the finer categories that platforms actually use when two buckets are not enough to drive a retry policy.
The three things a bounce can mean
The address is wrong
Unknown user, mailbox closed, domain that never existed. Permanent by nature, and the only correct reaction is to stop sending to it.
The route is broken
A zone with no mail server, a host that does not answer, a lookup that fails. The address may be perfectly valid; the failure is in DNS.
You are being refused
Policy, reputation, rate limits or a listed address. The recipient exists and the route works; the receiver has decided about the sender.
Parsing, in production
A delivery status notification is structured, and parsing the structure beats matching strings against the human-readable part, which every receiver words differently and changes without notice. The DSN parsing guide covers the report format, the fields worth extracting and the fallbacks for the receivers that send something looser than the standard describes.
Whatever the parser concludes has to be written somewhere durable. A per-campaign exclusion is not enough, because the next import brings the address back: the point of a suppression list with a schema and a retention rule is that every future send consults it, including sends from a platform you have not migrated to yet.
Complaints are not bounces
When a reader presses the spam button, the message was delivered. Nothing bounces, and unless you are enrolled in a feedback loop, nothing reaches you at all: the address keeps receiving mail it has already rejected socially, which is the fastest way to damage a sending reputation. Enrolment and the report format are covered in feedback loops and ARF parsing, and complaints belong on the same suppression list as hard bounces.
Sustained failures point upstream rather than at the list. Repeated deferrals and policy rejections are a reputation problem, covered in sender reputation and IP warming; a named list in the rejection text belongs to blocklists and spam monitoring; and failures that start in the zone rather than at the mailbox are collected in email DNS errors.
