Export (0) Print
Expand All

DSNs and NDRs in Exchange Online and Office 365

Exchange Online
 

Topic Last Modified: 2014-03-08

When there's a problem delivering a message, Microsoft Exchange Online sends a system-generated status message to the message sender. These status messages are called delivery status notifications (DSNs). The most common type of DSN is a non-delivery report (NDR) that indicates the message couldn't be delivered which is also known as a bounce message. However, a message sender may also receive a DSN when delivery of a message is temporarily delayed. If the condition that's causing the delay is ultimately fixed, the message may be delivered successfully without any intervention by the sender. Not every DSN is an NDR, but for the purpose of clarity in this topic, the terms DSN and NDR may be used interchangeably.

Contents

NDR sections

Interpret an NDR

Common NDRs you may encounter

In Exchange Online, NDRs are designed to be easy to read and understand by both users and administrators. Information that is displayed in an NDR is separated into the following two areas:

  • User information   This section appears first and contains a user-friendly summary to help the sender understand why delivery of the message failed.

  • Diagnostic information for administrators   This section provides deeper technical information, for example, the original message headers and SMTP error codes, to help administrators troubleshoot the message delivery problem.

The following figure shows the user information section and Diagnostic information for administrators section of an NDR.

NDR Sections

NDR showing User and Administrator Diagnostic Info

The main purpose of the user information section is to provide a summary about what went wrong. The text is designed to help the message sender determine why the message was rejected and, if possible, how to resend the message successfully. The email address of each recipient is listed, and the reason for the failure is included in the space below the recipient's email address. The name of the mail server that rejected the message may also be included in this section.

If you need to know more about what happened, you’ll find the information in the Diagnostic information for administrators section. This section contains detailed information about the specific error that occurred during delivery of the message, the server that generated the NDR, and the server that rejected the message. This section uses the following format:

Diagnostic information for administrators

Generating server: <server name>

<rejected recipient>
<remote server> <enhanced status code> <SMTP response>

Original message headers

<message header fields>

The fields, values, and sections are described in the following list:

  • Generating server   This field indicates the name of the SMTP mail server that created the NDR. If no remote server is listed below the sender's email address, the generating server is also the server that rejected the original email message. When the remote mail server acknowledges and accepts the message, but later rejects the message, for example, because of content restrictions, the remote server generates the NDR. If the remote mail server never acknowledges and never accepts the message, the sending server in Exchange Online generates the NDR.

  • <Rejected recipient>   This value is the email address of the recipient. If delivery failed to more than one recipient, the email address for each recipient is listed. The following information is also included for each failed recipient:

    • <Remote server>   This value is the name of the mail server that rejected the message. If the original message is successfully acknowledged by the receiving server, but is later rejected, the remote server value isn't populated.

    • <Enhanced status code>   This value is assigned by the mail server that rejected the original message and indicates why the message was rejected. These codes are defined in RFC 3463, and use the format abc x.y.z, where the placeholder values are integers. For example, a 5.x.x code indicates a permanent error, and a 4.x.x code indicates a temporary error. Although the enhanced status code is often generated by an external mail server, Exchange Online uses the enhanced status code value to determine the text to display in the user information section.

    • <SMTP response>   This value is returned by the mail server that rejected the original message. This text provides an explanation for the enhanced status code value. The text is always presented in US-ASCII format.

  • Original message headers   This section contains the message header fields of the rejected message. These header fields can provide useful diagnostic information, such as the path that the message took before it was rejected, or whether the To field value matches the rejected recipient value.

Return to top

Here's an example. Suppose you receive an NDR that contains the following information:

Delivery has failed to these recipients or groups:

Ronald Slattery
Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery. The following organization rejected your message: mail.contoso.com.

Diagnostic information for administrators:

Generating server: bigfish.com

ronald@contoso.com
mail.contoso.com #<exchange.contoso.com #5.7.1 smtp;530 5.7.1 Client was not authenticated> #SMTP#

Original message headers
...

From the user information section, you can determine that the recipient is Ronald Slattery, and the message was rejected by the mail server mail.contoso.com, which isn't an Exchange Online or Exchange Online Protection mail server.

From the Diagnostic information for administrators section, you can see that bigfish.com, which is Microsoft Exchange Online Protection, attempted to connect to the server mail.contoso.com to deliver the message to the recipient ronald@contoso.com. However, mail.contoso.com responded with the error 530 5.7.1 Client was not authenticated. Even though bigfish.com generated the NDR, mail.contoso.com actually rejected the message, so the administrators at contoso.com are responsible for understanding and fixing the problem. This particular error indicates the server mail.contoso.com is configured not to accept anonymous email from the Internet.

Although the Original message headers are omitted from this example due to their length and complexity, you can typically extract useful information from the following header fields:

  • To:   This field may be helpful if the email address was mistyped.

  • Received:   These fields can tell you what the path was for the message, and the last hop that generated the DSN if it isn’t easy to tell from the Generating server value in the NDR.

  • Received-SPF:   If this value is anything other than pass, you should check the Sender Policy Framework (SPF) DNS record for your domain. For more information, see Customize an SPF Record to Validate Outbound Email Sent from Your Domain.

Return to top

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft