NDR

We verify billions of email addresses precisely so our customers never have to open one of these. An NDR is the paper trail a bad send leaves behind, and by the time one lands in your inbox, the damage — a bounce against your sender reputation, a metric ticking up, a customer who never got their receipt — has already happened. Here is what an NDR actually is, what it tells you, and why the smart move is to never generate one at all.

What an NDR is

NDR stands for Non-Delivery Report: the automated message a receiving mail server generates when it cannot deliver a message, then routes back to the original sender. It is generated on the receiving side, not the sending side, which is why it can take anywhere from a few seconds to a few days to arrive depending on how long the receiving server was willing to keep trying first.

“NDR” is the formal name, most associated with Microsoft Exchange and Outlook, but the same event goes by several names depending on which system generates it. Gmail labels it a “Mail Delivery Subsystem” notice. Plenty of people just call it a bounce message. Some mail systems use the more formal Delivery Status Notification, or DSN. All of them describe the same underlying event: a message that did not reach its destination, reported back to whoever sent it.

What’s inside one

A well-formed NDR is built from a handful of consistent parts, even though the exact formatting varies by provider. Nearly every one includes the original recipient address you were trying to reach, so you can match the failure back to a specific send. Alongside it sits a plain-language explanation, something like “the recipient’s mailbox is full” or “address not found,” written for a human to read without any technical background.

Below that plain-language line, most NDRs also quote the technical detail that actually triggered the failure: the SMTP response code the receiving server returned, plus a raw diagnostic string from the mail transaction itself. That technical section is easy to skim past, but it is the part that tells you, with certainty, whether the failure was permanent or worth trying again.

Permanent vs temporary NDRs

The single most useful thing an NDR can tell you is which side of that line it falls on, and the plain-language text alone is not always reliable enough to tell. A phrase like “mailbox unavailable” can mean the address does not exist, that it exists but is full, or that it has been temporarily suspended by an administrator, and the wording rarely says which.

The underlying SMTP code resolves the ambiguity every time. An NDR built around a 5xx code is a hard bounce: the failure is permanent, and the address should come off your list rather than get mailed again. An NDR built around a 4xx code is a soft bounce: the failure is temporary, and a sending server will typically retry automatically over the following hours before finally generating the NDR you see, which is also why an NDR can show up days after the original send even though nothing changed on your end.

Common causes

A handful of causes account for the overwhelming majority of NDRs we see across the addresses we verify:

• Mailbox full. The recipient’s inbox has hit its storage limit and the server is refusing new mail until space frees up, usually a temporary condition.
• Address does not exist. A typo, a deleted account, or an employee who left the company, all resolving to the same permanent 550-class rejection.
• Blocked by a spam filter. The receiving server or a security gateway in front of it decided the message looked suspicious enough to reject outright.
• Message size exceeded. An attachment or total payload larger than the receiving server’s configured limit, rejected before it ever reaches the mailbox.

Notice that only one of these, a nonexistent address, is something verification catches before you ever send. The others are conditions at the moment of delivery, which is exactly why NDRs never disappear entirely, but why the single biggest chunk of them is preventable.

Why parsing NDRs at scale matters

Reading one NDR by eye takes a minute. Reading ten thousand of them, sorting the permanent failures from the temporary ones, and updating your sending list accordingly is not a task a person should ever do by hand. At real sending volume, NDR parsing has to be automated: a script or platform that opens each report, extracts the underlying code, and applies the same permanent-vs-temporary logic consistently across every message.

Even automated, that is still work happening after the damage is done. The bounce has already counted against your bounce rate, the mailbox provider has already logged the failed attempt against your sending reputation, and whatever that email was supposed to deliver — a receipt, a password reset, a marketing offer — never arrived. Verifying an address before you send means the bad address is caught up front, so there is rarely an NDR to parse in the first place.

For teams sending at real volume, where every NDR is a reputation hit you have already taken by the time you read it, the economics of catching bad addresses up front instead of parsing the fallout are on the pricing page.