Export (0) Print
Expand All

Understanding DSNs and NDRs

Exchange 2010
 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Topic Last Modified: 2011-05-20

This topic describes how to read and interpret non-delivery report (NDR) delivery status notification (DSN) messages in Microsoft Exchange Server 2010.

In Exchange 2010, NDRs have been designed to make them easier to read and understand by both end-users and administrators. Information that is displayed in an NDR is separated into the following two areas:

  • A user information section

  • A Diagnostic information for administrators section

The information in each section is targeted to the readers of that section. The user information section appears first and contains feedback to help the user understand in nontechnical terms why the delivery of the message failed. The Diagnostic information for administrators section provides deeper technical information such as the original message headers, to help e-mail administrators troubleshoot a delivery issue that may exist. 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 user information section of an NDR generated by Exchange 2010 contains information that you want to communicate to an end-user who has sent a message that is later returned with an NDR. The text that is displayed in this section is inserted by the Exchange server that generated the NDR.

The text in the user information section is designed to help the end-user determine why the message was rejected and how to resend the message successfully if the message should be resent. When applicable, the fully qualified domain name (FQDN) of the server that rejected the message is included in the user information section. If delivery fails to more than one recipient, the e-mail address of each recipient is listed and the reason for the failure is included in the space below the recipient's e-mail address.

You can modify the text in the user information section by using the New-SystemMessage cmdlet. By creating a custom message, you can provide specific information to end-users, such as a telephone number to use to contact the helpdesk department or a hyperlink to use to obtain self-service support. For more information about how to customize the text that is displayed in the user information section, Create a Custom DSN Message.

The Diagnostic information for administrators section contains more 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. The following fields are present in most NDRs and are visible in the "NDR sections" figure earlier in this topic:

  • Generating server   The generating server is the SMTP server that created the NDR. The generating server takes the enhanced status code that is explained later in this topic. This code creates an easy-to-read NDR. If no remote server is listed below the e-mail address of the sender in the Diagnostic information for administrators section, the generating server is also the server that rejected the original e-mail message. If message delivery fails when the message is sent to another recipient in the Exchange organization, the same server typically rejects the original message and generates the NDR.

  • Rejected recipient   The rejected recipient is the e-mail address of the recipient to which delivery of the original message failed. If delivery to more than one recipient has failed, the e-mail address for each recipient is listed. The rejected recipient field also contains the following sub-fields for each e-mail address listed:

    • Remote server   The remote server field contains the FQDN of the server that rejects delivery of the message during the Simple Mail Transfer Protocol (SMTP) conversation. The remote server field is only populated when delivery has been attempted to a remote server, and that delivery attempt has been rejected before the receiving server successfully acknowledges the message after the message body is sent. If the original message is successfully acknowledged by the receiving server and is then rejected because of content restrictions, for example, the remote server field is not populated.

    • Enhanced status code   The enhanced status code is the code returned by the server that rejected the original message. The enhanced status code indicates why the original message was rejected. The enhanced status code is not rewritten by Exchange 2007 but is used to determine what text to display in the user information section. The enhanced status codes you're most likely to encounter are listed in "Common Enhanced Status Codes" later in this topic. For a detailed list of enhanced status codes, see RFC 3463.

    • SMTP response   The SMTP response is the machine readable text returned by the server that rejected the original message. The SMTP response typically contains a short string that provides an explanation of the enhanced status code that is also returned. The SMTP response is not rewritten by Exchange 2010. Additionally, this response is always presented in US-ASCII format.

  • Original message headers   The original message headers section contains the message headers of the rejected message. These headers can provide useful diagnostic information, such as information that can help you determine the path that the message took before it was rejected or whether the To field matches the e-mail address that is specified in the rejected recipient field.

The following sections provide examples of two ways that NDR messages can be generated:

  • By the same server

  • By different servers

The following example shows what happens when a remote e-mail organization accepts delivery of an e-mail message through an Edge Transport server, and then rejects that message because of a policy restriction on the recipient's mailbox. In this case, the sender is not allowed to send messages to the recipient. Edge Transport servers do not perform message size validation so the Edge Transport server in this example accepts the message because it has a valid recipient address and the message does not violate another content restrictions. Because the remote e-mail organization accepts the whole message, including the message contents, the remote e-mail organization is responsible for rejecting the message and for generating the NDR message to be sent to the sender.

NDR generated and message rejected by the same server

NDR showing same generating and rejecting server

Also, messages that are rejected when they are sent to recipients that are part of the same Exchange 2010 organization are typically rejected by the same e-mail server that generates the NDR message. Messages sent to local recipients can be rejected for various reasons, such as mailboxes that have exceeded their quota, lack of authorization to send messages to the recipient address, or hardware failures that result in an extended loss of connectivity to other servers in the organization.

In both situations, no remote server is included under the e-mail address of the recipients listed in the NDR message.

The following example shows what happens when a remote e-mail organization rejects delivery of an e-mail message before it ever accepts the message. In this example, the remote server rejects the message and returns an enhanced status code to the local sending server because the specified recipient does not exist. The rejection happens before the receiving server ever acknowledges the message. Because the receiving server doesn't successfully acknowledge the message, the receiving server is not responsible for the message. Therefore, the local sending server generates the NDR message and sends it to the sender of the original message.

NDR generated and message rejected by different servers

NDR showing different generating/sending servers

The following table contains a list of the enhanced status codes that are returned in NDRs for the most common message delivery failures.

 

Enhanced status code Description Possible cause Additional information

4.3.1

Insufficient system resources

An out-of-memory error occurred. A resource problem, such as a full disk, can cause this problem.

Instead of getting a disk full error, you might be getting an out-of- memory error.

Ensure that your Exchange server has enough disk storage.

4.3.2

System not accepting network messages

This NDR is generated when a queue has been frozen.

You can resolve this condition by unfreezing the queue.

4.4.1

Connection timed out

The destination server is not responding. Transient network conditions can cause this error. The Exchange server tries automatically to connect to the server again and deliver the mail. If delivery fails after multiple attempts, an NDR with a permanent failure code is generated.

Monitor the situation. This may be a transient problem that may correct itself.

4.4.2

Connection dropped

A connection dropped between the servers. Transient network conditions or a server that is experiencing problems can cause this error. The sending server will retry delivery of the message for a specific time period, and then generate further status reports.

Monitor the situation as the server retries delivery. This may be a transient problem that may correct itself.

This situation can also occur when the message size limit for the connection is reached, or if the message submission rate for the client IP address has exceeded the configured limit.

4.4.7

Message expired

The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred. This message can also indicate that a message header limit has been reached on a remote server, or some other protocol time-out occurred while communicating with the remote server.

This message usually indicates an issue on the receiving server. Check the validity of the recipient address, and determine if the receiving server is configured correctly to receive messages.

You may have to reduce the number of recipients in the message header for the host about which you are receiving this error. If you send the message again, it is placed in the queue again. If the receiving server is available, the message is delivered.

5.0.0

HELO / EHLO requires domain address

This situation is a permanent failure. Possible causes include:

  • There is no route for the given address space; for example, an SMTP connector is configured, but this address does not match.

  • DNS returned an authoritative host that was not found for the domain.

  • An SMTP error occurred.

Some potential resolutions include:

  • On one or more SMTP connectors, add an asterisk (*) value as the SMTP address space.

  • Verify that DNS is working.

5.1.0

Sender denied

This NDR is caused by a general failure (bad address failure). An e-mail address or another attribute could not be found in Active Directory. Contact entries without the targetAddress attribute set can cause this problem. Another possible cause could be that the homeMDB attribute of a user could not be determined. The homeMDB attribute corresponds to the Exchange server on which the user's mailbox resides.

Another common cause of this NDR is if you used Microsoft Office Outlook to save your e-mail message as a file, and then someone opened the message offline and replied to the message. The message property only preserves the legacyExchangeDN attribute when Outlook delivers the message, and therefore the lookup could fail.

Either the recipient address is incorrectly formatted, or the recipient could not be correctly resolved. The first step in resolving this error is to check the recipient address and send the message again.

5.1.1

Bad destination mailbox address

This failure may be caused by the following conditions:

  • The recipient e-mail address was entered incorrectly by the sender.

  • No recipient exists in the destination e-mail system.

  • The recipient mailbox has been moved and the Microsoft Office Outlook recipient cache on the sender's computer has not updated.

  • An invalid legacy domain name (DN) exists for the recipient mailbox Active Directory.

This error typically occurs when the sender of the message incorrectly enters the e-mail address of the recipient. The sender should check the recipient's e-mail address and send again. This error can also occur if the recipient e-mail address was correct in the past but has changed or has been removed from the destination e-mail system.

If the sender of the message is in the same Exchange organization as the recipient, and the recipient mailbox still exists, determine whether the recipient mailbox has been relocated to a new e-mail server. If this is the case, Outlook may not have updated the recipient cache correctly. Instruct the sender to remove the recipient address from sender's Outlook recipient cache and then create a new message. Resending the original message will result in the same failure.

Other issues may cause this error, such as an invalid legacy distinguished name (DN) in Active Directory. Examine and correct the legacy DN of the recipient's mailbox. Then instruct the sender to remove the recipient address from sender's Outlook recipient cache and then create a new message. Resending the original message will result in the same failure.

5.1.2

Invalid X.400 address

The recipient has a non-SMTP address that can't be matched to a destination. The address does not appear to be local, and there are no connectors configured with address spaces that contain the recipient's address.

Verify that the recipient's address was entered correctly. If the recipient's address is in a non-SMTP e-mail system that you specifically want to provide mail delivery to, you will need to add the appropriate type of connector to your topology and configure it to provide service to the recipient's e-mail system.

5.1.3

Invalid recipient address

This message indicates that the recipient address appears incorrectly on the message.

Either the recipient address is formatted incorrectly, or the recipient could not be correctly resolved. The first step in resolving this error is to check the recipient address and send the message again.

Also, examine the SMTP recipient policy and ensure that each mail domain for which you want to accept mail appears correctly.

5.1.4

Destination mailbox address ambiguous

Two or more recipients in the Exchange organization have the same address.

This error typically occurs because of a misconfiguration in Active Directory. Possibly because of replication problems, two recipient objects in Active Directory have the same SMTP address or Exchange Server (EX) address.

5.1.7

Invalid address

The sender has a malformed or missing SMTP address, the mail attribute in the directory service. The mail item cannot be delivered without a valid mail attribute.

Check the sender directory structure, and determine if the mail attribute exists.

5.2.1

Mailbox cannot be accessed

The mailbox cannot be accessed. The mailbox may be offline, disabled, or the message has been quarantined by a rule.

Check to see if the recipient database is online, the recipient mailbox is disabled, or the message has been quarantined.

5.2.2

Mailbox full

The recipient's mailbox has exceeded its storage quota and is no longer able to accept new messages.

This error occurs when the recipient's mailbox has exceeded its storage quota. The recipient must reduce the size of the mailbox or the administrator must increase the storage quota before delivery can be successful. If the recipient resides in the local Exchange 2010 organization, see Configure Storage Quotas for a Mailbox.

5.2.3

Message too large

The message is too large, and the local quota is exceeded. For example, a remote Exchange user might have a restriction on the maximum size of an incoming message.

Send the message again without attachments, or set the server or the client-side limit to allow a larger message size limit.

5.2.4

Mailing list expansion problem

The recipient is a misconfigured dynamic distribution list. Either the filter string or the base DN of the dynamic distribution list is invalid.

Set the categorizer event logging level to at least the minimum level, and send another message to the dynamic distribution list. Check the application event log for a 6025 event or a 6026 event detailing which attribute is misconfigured on the dynamic distribution list object.

5.3.3

Unrecognized command

When the Exchange remote server reaches capacity of its disk storage to hold mail, it could respond with this NDR. This error usually occurs when the sending server is sending mail with an ESMTP BDAT command. This error also indicates a possible SMTP protocol error.

Ensure that the remote server has enough storage capacity to hold mail. Check the SMTP log.

5.3.4

Message too big for system

The message exceeds a size limit configured on a transport or mailbox database and can't be accepted. This failure can be generated by either the sending e-mail system or the recipient e-mail system.

This error occurs when the size of the message that was sent by the sender exceeds the maximum allowed message size when passing through a transport component or mailbox database. The sender must reduce the size of the message for the message to be successfully delivered. For more information about how to configure message size limits in an Exchange 2010 organization, see Configure Message Size Limits for a Mailbox or a Mail-Enabled Public Folder.

5.3.5

System incorrectly configured

A mail-looping situation was detected, which means that the server is configured to loop mail back to itself.

Check the configuration of the server's connectors for loops, and ensure that each connector is defined by a unique incoming port. If there are multiple virtual servers, ensure that none are set to "All Unassigned."

5.4.4

Invalid arguments

This NDR occurs if no route exists for message delivery, or if the categorizer could not determine the next-hop destination.

Check that the domain name specified is valid, and that a mail exchanger (MX) record exists.

5.4.6

Routing loop detected

A configuration error has caused an e-mail loop. By default, after 20 iterations of an e-mail loop, Exchange interrupts the loop and generates an NDR to the sender of the message.

This error occurs when the delivery of a message generates another message in response. That message then generates a third message, and the process is repeated, creating a loop. To help protect against exhausting system resources, Exchange interrupts the mail loop after 20 iterations. Mail loops are typically created because of a configuration error on the sending mail server, the receiving mail server, or both. Check the mailbox rules configuration of the recipient and sender to determine whether automatic message forwarding is enabled.

5.5.2

Send hello first

A generic SMTP error occurs when SMTP commands are sent out of sequence. For example, a server attempts to send an AUTH (authorization) command before identifying itself with an EHLO command.

It is possible that this error can also occur when the system disk is full.

View the SMTP Log or a Netmon trace, and ensure that there is adequate disk storage and virtual memory available.

5.5.3

Too many recipients

The combined total of recipients on the To, Cc, and Bcc lines of the message exceeds the total number of recipients allowed in a single message.

This error occurs when the sender has included too many recipients on the message. The sender must reduce the number of recipient addresses in the message or the maximum number of recipients must be increased to allow the message to be successfully delivered. To configure the maximum number of recipients that can be included in a message, use the RecipientLimits parameter on the Set-Mailbox cmdlet. For more information, see Set-Mailbox.

5.5.4

Invalid domain name

The message contains either an invalid sender or an incorrect recipient address format.

One possible cause is that the recipient address format might contain characters that are not conforming to Internet standards.

Check the recipient address for nonstandard characters.

5.5.6

Invalid message content

This message indicates a possible protocol error.

Check Event Log for possible failures.

5.7.1

Delivery not authorized

The sender of the message is not allowed to send messages to the recipient.

This error occurs when the sender tries to send a message to a recipient but the sender is not authorized to do this. This frequently occurs when a sender tries to send messages to a distribution group that has been configured to accept messages only from members of that distribution group or other authorized senders. The sender must request permission to send messages to the recipient. On an Exchange 2010 server, the following cmdlets accept the AcceptMessageOnlyFrom and AcceptMessagesOnlyFromDLMembers parameters. These enable you to determine who is authorized to send messages to the recipients that you configure:

This error can also occur if an Exchange 2010 transport rule rejects a message because the message matched conditions that are configured on the transport rule. For more information about transport rules, see Understanding Transport Rules.

5.7.1

Unable to relay

The sending e-mail system is not allowed to send a message to an e-mail system where that e-mail system is not the final destination of the message.

This error occurs when the sending e-mail system tries to send an anonymous message to a receiving e-mail system, and the receiving e-mail system does not accept messages for the domain or domains specified in one or more of the recipients. The following are the most common reasons for this error:

  • A third party tries to use a receiving e-mail system to send spam, and the receiving e-mail system rejects the attempt. By the nature of spam, the sender's e-mail address may have been forged and the resulting NDR could have been sent to the unsuspecting sender's e-mail address. It is difficult to avoid this situation.

  • A domain name service (DNS) mail exchanger (MX) record for a domain points to a receiving e-mail system where that domain is not accepted. The administrator responsible for the specific domain name must correct the DNS MX record or configure the receiving e-mail system to accept messages sent to that domain, or both. For more information about how to accept messages for a domain, see Managing Accepted and Remote Domains.

  • A sending e-mail system or client that should use the receiving e-mail system to relay messages does not have the correct permissions to do this. For more information about transport permissions, see Understanding Permissions.

5.7.1

Client was not authenticated

The sending e-mail system did not authenticate with the receiving e-mail system. The receiving e-mail system requires authentication before message submission.

This error occurs when the receiving server must be authenticated before message submission, and the sending e-mail system has not authenticated with the receiving e-mail system. The sending e-mail system administrator must configure the sending e-mail system to authenticate with the receiving e-mail system for delivery to be successful. This error can also occur if you try to accept anonymous messages from the Internet by using a Hub Transport server that has not been configured to do this. We recommend that you put an Edge Transport server in a perimeter network between the Hub Transport server and the Internet. For more information, see the following topics:

Configure Internet Mail Flow Directly Through a Hub Transport Server

Configure Internet Mail Flow Through a Subscribed Edge Transport Server

5.7.3

Not Authorized

The sender prohibited reassignment to the alternate recipient.

 

 © 2010 Microsoft Corporation. All rights reserved.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft