What are the key fields to look for in a bounce message?

You sent an email, it bounced, and now you're staring at a wall of cryptic text. What actually matters in there? Not everything. A bounce message (formally called a DSN, or Delivery Status Notification) can look overwhelming, but a handful of fields do all the heavy lifting.

Here are the ones worth knowing:

Status is your first read. It's a three-part code in X.Y.Z format, and the first digit tells you everything about permanence. A 5.x.x means permanent failure. A 4.x.x means temporary. That one digit decides whether you suppress the address or just wait and retry. Common codes like 5.1.1 (unknown user) and 4.2.2 (mailbox full) are defined in RFC 3463 and are consistent across providers.

Action backs this up in plain English. You'll see failed for a hard bounce, delayed when the receiving server is still trying, and delivered on positive DSNs. If you're building automation, this field is a clean binary to route on.

Diagnostic-Code is where the real story lives. This is the raw SMTP response from the receiving server, and it often includes a human-readable reason that the Status code alone doesn't give you. Something like smtp; 550 5.1.1 The email account that you tried to reach does not exist tells you far more than the code by itself. Providers like Gmail and Outlook sometimes add their own specific language here too, which helps with troubleshooting edge cases.

Final-Recipient is the address that actually failed. This is the one you suppress. It sounds obvious, but if a message was forwarded before it bounced, the Final-Recipient may differ from the address you originally sent to. Always use this field for your suppression list, not the envelope address.

Remote-MTA tells you which server rejected the message. That's useful when you're trying to figure out if a problem is specific to one provider (say, all your Yahoo bounces are spiking) versus something broader with your sending reputation.

Arrival-Date is lower priority but worth logging. It timestamps when the failure occurred, which helps when you're cross-referencing bounces against a campaign send or debugging a delay pattern.

In practice, the three you'll rely on most are Status (permanent or temporary?), Diagnostic-Code (what exactly went wrong?), and Final-Recipient (who do I suppress?). The rest is context. If you want to go deeper on using bounce data to diagnose deliverability issues, or automating your bounce parsing, both are worth reading next.

Not sure if your bounce rates are within a healthy range? You're welcome to bring your data to our SOS hotline and we'll take a look with you, no pitch involved.