What Is a Delivery Status Notification (DSN) in Email?

A delivery status notification email — a DSN — is the automated report a mail server sends back to tell the sender what happened to a message. It is defined by RFC 3464, and it can report three outcomes: the message was delivered, it was delayed, or it failed. When people say a message "bounced," the thing that told them so was almost always a DSN.

What makes a DSN more than a plain bounce notice is that it is machine-readable. Alongside the sentence a human reads, it carries a structured block of fields and an enhanced status code — a three-number triplet from RFC 3463 that says, precisely, what went wrong. Learn to read that triplet and most delivery mysteries stop being mysteries.

This guide explains the DSN format part by part: the multipart/report structure, the fields inside it, and how to decode the status code — including what a 5.1.1 actually means. It also draws the line between a DSN and an NDR, which people use interchangeably and shouldn't.

How does a DSN work?#

A DSN is not a special protocol — it is an ordinary email with a specific structure. RFC 3464 defines it as a MIME multipart/report message, which means it is one email made of several parts, each with its own job. Your mail client shows you the friendly part; the mail system reads the rest.

A sender can ask for a DSN explicitly using the SMTP DSN extension, RFC 3461. That extension adds a NOTIFY parameter whose values are SUCCESS, FAILURE, DELAY, or NEVER — you tell the receiving server which outcomes you want reported. But most DSNs you actually see were never requested: a server generates a failure report on its own when it cannot deliver a message, because the sender needs to know.

The multipart/report message carries up to three parts, in a fixed order. The report-type is "delivery-status," which is how software knows this particular report is a DSN and not some other kind.

What do the fields in a DSN mean?#

The part that does the real work is the message/delivery-status block. It has two layers: a set of per-message fields that describe the reporting server, and one block of per-recipient fields for each address the report covers. A single DSN can report on several recipients at once, each with its own outcome.

The fields you will actually read are Final-Recipient (which address this concerns), Action (what happened to it), Status (the enhanced code), and Diagnostic-Code (the raw text the receiving server returned). The Action field is strict: RFC 3464 allows exactly five values — failed, delayed, delivered, relayed, and expanded. Whatever you decode starts with which of those five you are looking at.

How do you read the enhanced status code?#

The Status field holds the enhanced status code from RFC 3463, and it is the single most useful thing in the report. It is always three numbers separated by dots — a class.subject.detail triplet — read left to right, from general to specific.

The first number, the class, tells you the category of outcome, and there are only three you will meet. Class 2 is success. Class 4 is a persistent transient failure — a temporary problem the server keeps retrying. Class 5 is a permanent failure — resending the message as-is will not help. If you read only one digit, read that one.

The second number is the subject: what area the problem is in, such as addressing (X.1), the mailbox (X.2), the network (X.4), or security and policy (X.7). The third is the detail, which pins down the exact condition. Put together, 5.1.1 reads as permanent failure, addressing problem, bad destination mailbox address — the address does not exist. It is the code behind almost every "user unknown" bounce.

Why do DSNs matter?#

Without DSNs, a sender would have no reliable way to learn that a message never arrived. Email is store-and-forward: your server hands the message to the next server and moves on, so the failure often happens far downstream, minutes or hours later. The DSN is how that downstream failure travels back to you.

For anyone sending mail that matters — invoices, password resets, client replies — that feedback loop is the difference between fixing a bad address and silently losing a conversation. A 5.1.1 tells you to correct the address; a 4.2.2 tells you to wait; a 5.7.1 tells you the receiving server refused the message on policy grounds. Each points at a different fix.

DSN vs NDR: what's the difference?#

People use "DSN" and "NDR" as if they mean the same thing, and mostly they overlap — but not exactly. A DSN is the report format defined by RFC 3464, and it is neutral: it can report a success, a delay, or a failure. An NDR — Non-Delivery Report, the term Microsoft and Exchange use — is specifically the failure kind: a DSN whose Action is failed. It is what most people call a bounce.

So the relationship is one of container and contents. Every NDR is a DSN, but a DSN is not always an NDR, because a DSN can just as easily be telling you a message went through. When a delivery status notification failure lands in your inbox, that failure report is the NDR.

Common misconceptions about DSNs#

A few things about DSNs trip people up repeatedly.

• A DSN always means failure. It doesn't. A DSN can report a successful delivery (Action: delivered, class 2) or a delay (Action: delayed, class 4). You just notice the failures more, because those are the ones that demand action.
• The SMTP reply code and the enhanced status code are the same. They aren't. The basic reply (like 550) is SMTP's own three-digit code; the enhanced code (like 5.1.1) is a separate, finer triplet from RFC 3463, carried in the Status field. They travel together but say different amounts.
• The Status and the Diagnostic-Code are the same reason twice. Not quite. Status is the transport-independent enhanced code; Diagnostic-Code is the raw, server-specific text — often the literal SMTP response. Read both: the code gives you the category, the diagnostic gives you the specifics.
• A bounce in your inbox proves you sent something. Not always. Because return addresses can be forged, you can receive a DSN for mail you never sent. This is backscatter, and it is a reason not to trust a bounce report on sight.

How AI Emaily helps with delivery status notifications#

A DSN is a technical message, and most email clients show it to you raw — a wall of headers and codes you have to decode by hand. AI Emaily is an AI-native email client, so when a bounce report reaches your inbox you can ask its assistant what it means, and it reads the Action, the Status triplet, and the Diagnostic-Code and explains them in plain language — a 5.1.1 becomes "the address doesn't exist; check for a typo and resend."

Its spam and cold-email filters also absorb backscatter, so bounce reports for mail you never sent don't clutter the inbox you actually work in. One honest limit: AI Emaily is a mail client, not a deliverability monitor or an email service provider — it helps you read and act on the DSNs that reach you, not track bounce rates across a sending domain. For that you want your ESP's dashboard or a dedicated deliverability tool. We build AI Emaily; you can start a 7-day free trial and compare current plans on our pricing page.