What information is usually included in a bounce message (DSN)?

You send a campaign, and a chunk of emails come back. The bounce message sitting in your queue looks like a wall of technical text. But if you know what to look for, it tells you exactly what happened and what to do next.

Every bounce message (formally called a Delivery Status Notification, or DSN) is split into three parts. There's a plain-text section written for humans, a machine-readable section with structured fields, and sometimes a copy of the original message headers. The human-readable part is the place to start. It's usually one or two lines that say something like "User unknown" or "Mailbox full" or "This domain does not accept mail."

The part that really matters for diagnosing deliverability issues is the status code. You'll see it in a format like 5.1.1 or 4.2.2. The first digit tells you the most important thing right away. A 5.x.x code is a permanent failure (a hard bounce). The address is gone or invalid, and you should remove it immediately. A 4.x.x code is a temporary failure (a soft bounce). The receiving server had a hiccup and your ESP may retry automatically.

The second and third digits get more specific. Here are the codes you'll see most often:

• 5.1.1. The address doesn't exist. Classic hard bounce. Remove it.
• 5.1.2. The domain doesn't exist or can't receive mail. Remove it.
• 5.7.1. The receiving server rejected your message, usually because of a reputation or policy issue. This one is worth investigating further.
• 4.2.2. The mailbox is full. A soft bounce. Could clear up on its own.
• 4.4.7. The connection timed out or the message sat in queue too long. Often a temporary infrastructure issue on their end.

After the status code, look for the Diagnostic-Code field. This is the raw SMTP response from the receiving server, and it's often the most honest thing in the whole message. A real example might look like this:

Diagnostic-Code: smtp; 550 5.1.1 The email account that you tried to reach does not exist.

That's Gmail telling you plainly that the address is gone. No ambiguity there.

The Remote-MTA field tells you which server rejected the message. That's useful when you're trying to figure out if the problem is specific to one mailbox provider or happening everywhere. If bounces are all coming from the same Remote-MTA, that's a signal worth paying attention to.

A few other fields you'll spot: Final-Recipient shows the address the bounce is actually for (useful when forwarding is involved), and Will-Retry-Until appears on soft bounces to tell you how long your ESP will keep trying before giving up.

The key takeaway is this: hard bounces (5.x.x) need to come off your list the same day. Soft bounces (4.x.x) are worth watching but not worth panicking over, unless the same address keeps soft-bouncing across multiple sends. That pattern usually means the address is on its way to being a hard bounce anyway.

If you're trying to read bounce messages at scale, take a look at parsing them automatically. Manual triage doesn't scale past a few hundred sends.

And if you want to catch bad addresses before they ever bounce, our RME Clean service flags invalid addresses before they hit your sending reputation. Worth a look if your bounce rate is creeping up.