A bounce is not a sentence, it is a structured report: a delivery status notification with a status code, a reporting MTA, and the original headers attached. Parsing the human text is the reason bounce handling is unreliable.
The fields that matter
message/delivery-status carries per-recipient blocks with Action (failed, delayed, delivered, relayed), Status (the three-digit enhanced code) and Diagnostic-Code. A 5.1.1 means unknown recipient; a 4.2.2 means mailbox full; a 5.7.1 usually means the receiver blocked you. Those three lead to completely different actions.
The original message id is in there
The third part of a DSN is the original message headers. That is how you correlate a bounce with the send that caused it — not by matching the recipient address, which may appear in several campaigns. Without the correlation, a bounce cannot update the right record.
Delayed is not failed
Action: delayed arrives hours before a failure and after the message eventually succeeds. Treating it as a bounce suppresses valid addresses and makes the dashboard look worse than reality. Store it as a state, not as a failure.
One detail that prevents a support loop
Keep the Diagnostic-Code verbatim. When a customer forwards a bounce, the remote server's sentence is the only thing that distinguishes a full mailbox from a blocklist, and your own classification will not carry that nuance.
Volanea parses DSNs into action and status per recipient and keeps the raw diagnostic next to the original send.
Top comments (0)