How to Understand an Exchange Non Delivery Report (NDR)

Posted on January 8, 2009 by Brien Posey in Exchange Server with

In the previous article in this series, I showed you how to create a postmaster address that could be used to intercept replies to non-delivery reports.  What you might not realize though, is that not all non-delivery reports are created equally.  In this article, I want to show you how to analyze the contents of a non-delivery report so that you can figure out why a message was not delivered.

What is a Non-Delivery Report (NDR)?

If you take a look at the NDR below, you can see a sample nondelivery report.  This nondelivery report contains all of the usual information such as the date and time that the message was sent, and the intended recipient.  If you take a look at the last line of the nondelivery report though, you can see the name of the Exchange server that attempted to send the message, along with a three digit status code.  It is this code that tells you the specific reason of why the message was not delivered.

This is what a typical NDR looks like.

In this particular case, the status code was 5.1.1. This is probably the most common status code that you will encounter.  This code indicates that the recipient’s e-mail address does not exist.  This particular error can occur for a variety of reasons.  The most common causes probably misspelling the recipient’s e-mail address.

The error can also occur if the recipient does not have an account on the server.  In some cases, you may find that the particular recipient once had a mailbox on the destination server, but that the mailbox has been moved to another server within the domain.  When that happens, the sender’s Outlook recipient cache may still contain the recipient’s previous information. When that happens, it is necessary to remove the recipient’s address from the senders Outlook recipient cache before the sender retransmits the message.

What is NDR Status Code 5.7.1?

Probably the second most common status code that you may encounter in a nondelivery report is 5.7.1. Unlike error code 5.1.1 though, there isn’t a single underlying cause to this code. If you look back at Figure A, you’ll notice that just above the status code is a plain text explanation of the condition that resulted in the error.  When you are analyzing a nondelivery report containing error 5.7.1, you’ll have to pay attention to this text.

NDR 5.7.1 Delivery Not Authorized

The 5.7.1 status code may come with text saying Delivery Not Authorized.  Typically this error occurs if the sender attempts to send a message to a distribution group for which they are not authorized to use.  Often times, distribution groups are configured in such a way so that only remembers are allowed to send messages to the group.  This particular error may also occur if the message being sent matches conditions stipulated within a transport rule that would forbid the message from being sent.

NDR 5.7.1 Unable to Relay

Another variation of the 5.7.1 status code is that the nondelivery report may indicate that exchange was unable to relay the message.  Generally speaking, this particular error message indicates that the sender attempted to anonymously use a mail server to pass a message through to its final destination.  The vast majority of the mail servers in the world prohibit messages from being relayed by non-authenticated users.

NDR 5.7.1 Not Authenticated

One final variation on the 5.7.1 status code is that the text may indicate that the client was not authenticated.  When you receive this particular message, it indicates that the sending mail server must be authenticated with the receiving mail system before delivery can take place.  However, this type of nondelivery report can also be generated if you attempt to accept anonymous SMTP mail from the Internet via a hub transport server.  Hub transport service can be configured to accept Internet mail, but by default, Microsoft assumes that you’re going to be using an edge transport server for this purpose.

There are a variety of other status codes that can be included in a nondelivery report.  These remaining status codes are not nearly as common as the one that I just talked about, but they are important to pay attention to because they can signal various types of problems.  The chart below describe some of the other status codes that you may encounter.

NDR Status Codes & Explanations

5.1.4 The status code indicates that two different recipients have the same e-mail address.  Often times, the status code points to an Active Directory error.

5.2.2 The status code indicates that the recipient’s mailbox is full.  This occurs when an administrator has placed a quota on the mailbox, and the quota has been reached or exceeded.  In such situations you cannot deliver new messages to the recipient until some of the mail has been removed from the recipient’s mailbox.

5.3.4 The status code indicates that the message that was sent exceeded the size limitation allowed by the recipient’s mailbox.  This type of nondelivery report is typically triggered when a message is sent with an excessively large attachment.

5.4.6 This status code indicates that a message loop has occurred. Suppose, for example, that you send a message to someone and got an out of office message in response.  Now imagine that your out of office message is also turned on, so an out of office message gets sent to the recipient.  Exchange Server has a mechanism in place to prevent infinite mail loops, and therefore generates this error.

5.5.3 This status code indicates the message has too many recipients.  This happens when there are too many recipients specified in the To, CC, and BCC fields of an outbound message.


In this article, I have explained that if you really want to find out why you have received a particular nondelivery report, it is important to look at the status code that is attached to the report.  I then went on to discuss the meanings of some of the more common status codes.

Related Articles

Register for this Webinar

How Replication Supports Your Company’s RTOs & RPOs
Join us for this free webinar

Can you have your workloads running within the agreed RTOs? Join this webinar with expert speakers from Veeam to exceed business objectives with an RPTO<15 min for ALL of your application and data.

Thursday, December 14, 2017 at 11 a.m EST