Delivery status notifications in Exchange Server and in Small Business Server

Applies to: Microsoft Exchange Server 2003 Enterprise EditionMicrosoft Exchange Server 2003 Standard Edition


Note This article is for informational use only. It contains no troubleshooting information. If you are searching for troubleshooting information that is not mentioned in this article, search the Microsoft Knowledge Base again by using the keywords that are listed in the following Microsoft Knowledge Base article:
242450 How to query the Microsoft Knowledge Base by using keywords and query words
This article describes delivery status notifications in Microsoft Exchange 2000 Server and in Microsoft Exchange Server 2003. Specifically, this article describes permanent failure messages and transient failure messages that frequently become permanent delivery errors. The following message is an example of a delivery status failure notification as viewed in an Outlook client:
Your message did not reach some or all of the intended recipients.

Subject:Original Message
Sent:7/11/2001 9:20 AM

The following recipient(s) could not be reached: on 7/11/2001 9:20 AM
The e-mail account does not exist at the organization this message was sent to.
Check the e-mail address, or contact the recipient directly to find out the
correct address.
< #5.1.1>

More Information

Non-delivery reports (NDRs) are system messages that report the delivery status of a message to the sender. The messages are a subclass of a general message information structure that is known as delivery status notifications. Delivery status notifications describe three kinds of situations:
  • Success (2.X.X numeric codes)
  • Persistent transient failure (4.X.X numeric codes)
  • Permanent failures (5.X.X numeric codes)
NDRs are generated when a message cannot be delivered. If the computer can detect the reason for the failed delivery, it maps the reason onto a status code, and a corresponding error message is printed. For NDRs, most numeric error codes are reported in the form of "5.X.X" and are described as permanent failures. However, certain transient conditions cause "4.X.X" codes.

Notice that the server that is reporting the problem is listed before the code number. In the example NDR in the "Introduction" section, the reporting server is Sometimes, the server that reports the problem is not the server that actually experiences the probhlem.

The following are the numeric error codes and the corresponding error conditions that most frequently occur:

  • Numeric Code: 4.2.2

    Note Available in Exchange 2000 Service Pack 2 or earlier versions. See error code 5.2.2.
  • Numeric Code: 4.3.1

    Possible Cause: This error may be caused by a resource problem, such as a full disk. This error also occur if the following conditions are true:
    • Your Simple Mail Transfer Protocol (SMTP) queue is located on a File Allocation Table (FAT) partition.
    • The service has reached a Windows-imposed limit on the number of concurrent file handles that can be opened by the SMTP Service.
    In this case, instead of receiving a "disk full" error message, you might receive an "out-of-memory" error message.

    Troubleshooting: Make sure that you have sufficient disk storage, and try to operate your Exchange Transport queues on an NTFS partition.
  • Numeric Code: 4.3.2

    First Available: Exchange 2000 Service Pack 1

    Possible Cause: The message was not delivered because of Administrator action through the queue viewer interface in Exchange System Manager.
  • Numeric Code: 4.4.1

    Possible Cause: The host is not responding.

    Troubleshooting: This code may be caused by transient network conditions. Exchange automatically tries to connect again and deliver the email message. If delivery still fails after multiple tries, a "permanent failure" NDR will be generated.
  • Numeric Code: 4.4.2

    Possible Cause: The connection was dropped between servers.

    Troubleshooting: This code may be caused by transient network issues or servers that are down. The server tries to deliver the message for a specific time period, and then generates additional status reports.
  • Numeric Code: 4.4.6

    Possible Cause: The max hop count value was exceeded for the message. This error may also occur if a loop situation exists between a sending server and a receiving server that are not in the same organization. In this scenario, the message bounces back and forth until the hop count is exceeded.

    Troubleshooting: The max hop count property is set for each virtual server. You can manually override this setting (the default setting is 15 for Exchange 2000 Server and 30 for Exchange Server 2003). Additionally, look for any situations that might cause loops between servers.
  • Numeric Code: 4.4.7

    Possible Cause: 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 expired. This NDR may also indicate that a message header limit was reached on a remote server or that some other protocol time-out occurred during communication with the remote server.
    Troubleshooting: This code typically indicates a problem on the receiving server. Verify the validity of the recipient address, and verify that the receiving server is configured to receive messages correctly. You may have to reduce the number of recipients in the header of the message for the host from which you are receiving this NDR. If you resend the message, the message is added to the queue again. If the receiving server is online, the message is delivered.
  • Numeric Code: 4.4.9

    First Available: Exchange Server 2003

    Possible Causes: This code indicates that a temporary routing error occurred or that a bad routing configuration exists. This problem may occur in one or both of the following scenarios:
    • An SMTP connector is configured to use DNS without a smart host and is also configured to use a non-SMTP address space, such as an X.400 address space.
    • A message was sent to a recipient who was identified as a member of a routing group that was deleted.

    Troubleshooting: If this problem persists, use the WinRoute tool to examine the routing groups in the tree view pane, and then examine the address spaces of the route that is taken by the problem message. For more information about the WinRoute tool, click the following article number to view the article in the Microsoft Knowledge Base:

    281382 How to use the WinRoute tool

  • Numeric Code: 4.6.5

    First Available: Exchange Server 2003

    Possible Causes: This code occurs when conversion of an incoming SMTP failed because the code page that is specified in the message is not installed on the receiving server. This delivery status notification contains only the original message headers. None of the original content is provided.

    Troubleshooting: View the MIME of the original message. Make sure that the required language files are installed on the server that is receiving the message.
  • Numeric Code: 5.0.0

    First Available: All numeric error codes that were first available with Exchange 2000 Service Pack 1 (4.3.2, 5.4.0, 5.4.4, and 5.5.0) were classified as 5.0.0 in Exchange 2000 Service Pack 1 and earlier versions.

    Possible Causes:
    • There is no route for the specified 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.
    • The routing group does not have a connector defined. Therefore, mail from one server in one routing group does not have a route to another routing group.
    • An SMTP protocol error occurred.
    1. Correct the address space, or add an address space that has a type of "SMTP" and a value of "*" (asterisk) to one or more SMTP connectors.
    2. Verify that DNS is working correctly.
    3. Make sure that the routing groups have connectors that connect them.
    4. If you are running Exchange 2000 without Service Pack 1, apply Service Pack 1 to help determine the actual problem.
  • Numeric Code: 5.1.0

    Possible Cause: This code indicates a general categorizer-based failure (bad address failure). An email address or other attribute could not be found in the directory. This problem may occur if contact entries do not have the targetAddress attribute set. This problem occurs most frequently when MDAccess receives "object not found" errors from DSAccess when the Categorizer is performing the homeMDB lookup on a user.

    This problem also occurs if you used Microsoft Outlook to save your email message as a file, and then someone opens and replies to this message offline. The message property preserves the legacyExchangeDN only when Outlook delivers the message. Therefore, the homeMDB lookup may fail.

    Troubleshooting: Verify the recipient address, and then resend the message. Verify that the recipient address is formatted correctly and that the categorizer was able to correctly resolve the recipient.
  • Numeric Code: 5.1.1

    Possible Cause:
    • The email account does not exist at the organization to which the message was sent. This problem may occur if there was a problem when users were moved between sites. For example, if a former Administrative_Group_1 user moves to Administrative_Group_2 and then replies to an old email message, or if the user does not re-create her Outlook profile, an old Administrative Group style LegDN address will be used, and an NDR is generated.
    • The message was sent to obsolete personal address book entries.
    Troubleshooting: Use the troubleshooting procedure that is described for error code 5.1.0.
  • Numeric Code: 5.1.3

    Possible Cause: Bad address syntax. For example, a contact is configured to use a targetAddress attribute that has no address type.

    Troubleshooting: Use the troubleshooting procedure that is described for error code 5.1.0.
  • Numeric Code: 5.1.4

    Possible Cause: Two objects have the same proxy address, and mail is sent to that address. This problem may also occur if the recipient does not exist on the remote server.

    Troubleshooting: Verify the recipient address, and then resend the message.
  • Numeric Code: 5.1.6

    First Available: Exchange 2000 Service Pack 2

    Possible Cause: The user directory attributes, such as homeMDB or msExchHomeServerName, may be missing or corrupted.

    Troubleshooting: Verify the integrity of the user directory attributes, and then run the Recipient Update Service again to make sure that the attributes that are required for transport are valid.
  • Numeric Code: 5.1.7

    First Available: Exchange 2000 Service Pack 2

    Possible Cause: The sender has a malformed or missing mail attribute in the directory structure. The Transport categorizer cannot deliver the mail item without a valid mail attribute.

    Troubleshooting: Verify the sender directory structure, and then determine whether the mail attribute exists.
  • Numeric Code: 5.2.1

    Possible Cause: Local mail is refused because the message is too big. A missing Master Account Security ID number (SID) on the recipient can also cause this error message.

    Troubleshooting: Verify access permissions in addition to the message size. Determine whether the recipient has an SID.
  • Numeric Code: 5.2.2

    First Available: Exchange 2000 Service Pack 3 (previously error code 4.2.2 in earlier releases).

    Possible Causes: The recipient's mailbox is over its storage limit.

    Troubleshooting: Verify the mailbox storage and the queue storage quota limit.
  • Numeric Code: 5.2.3

    Possible Cause: The message is too large for the local quota. For example, a remote Exchange user may have delivery restrictions that include a maximum incoming message size.

    Troubleshooting: Resend the message without attachments, or set the server-side limit or the client-side limit to permit a larger message size.
  • Numeric Code: 5.3.0

    First Available: Exchange Server 2003

    Possible Causes: Exchange Server 2003 has a feature that lets Exchange 2003 operate without the Message Transfer Agent (MTA). If a message was sent incorrectly by using the MTA route, this delivery status notification is returned to the sender.

    Note Although Exchange 2003 can operate without the MTA, we do not recommend or support this configuration.

    To turn on this feature and to prevent messages from queuing to the MTA, follow these steps:
    1. Disable the MTA service.
    2. Set the DWORD value to 0 in the following registry subkeys for every information store database and public folder store:
      HKLM\System\CurrentControlSet\Services\MsExchangeIS\<Server Name>\<PrivMDB_GUID>\Gateway In Threads

      HKLM\System\CurrentControlSet\Services\MsExchangeIS\<Server Name>\<PrivMDB_GUID>\Gateway Out Threads
      Note When you do this, you make available the store resources that are associated with MTA delivery.
    3. Restart the information store.
    Troubleshooting: Check your routing topology. Use the WinRoute tool to make sure that the routes are replicated correctly between servers and routing groups.
  • Numeric Code: 5.3.3

    Possible Cause: The Exchange 2000 remote server or the Exchange 2003 remote server is out of disk storage to hold mail. This problem occurs most frequently when the sending server sends mail that includes binary DATA (BDAT). This code may also indicate an SMTP protocol error.

    Troubleshooting: Make sure that the remote server has sufficient storage to hold mail, and examine the SMTP protocol log for errors.
  • Numeric Code: 5.3.5

    Possible Cause: A loop-back situation was detected. In this situation, the server is configured to loop back on itself.

    If you have multiple SMTP virtual servers configured on your Exchange computer, make sure that the virtual servers are serving unique incoming ports and that the outgoing SMTP port configuration is valid. This configuration helps avoid looping between local virtual servers. Check the configuration of the server's connectors for loops. For example, make sure that no connectors have the address space of the local organization, unless you share the domain and you do not select the Use DNS to route to each address space on this connector option. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

    321721 How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003

    Make sure that multiple virtual servers are not set to All Unassigned.
  • Numeric Code: 5.4.0

    First Available: Exchange 2000 Service Pack 1

    Possible Causes:
    • An authoritative host was not found in DNS.
    • The smarthost entry is incorrect.
    • An FQDN exists in the Hosts file. This problem was fixed in Windows 2000 Service Pack 3 (SP3).
    • A DNS failure occurred, or you constructed an invalid IP address for your smarthost.
    • SMTP VS does not have a valid FQDN, or your SMTP VS FQDN lookup failed.
    • A contact's SMTP domain does not resolve to any SMTP address spaces.
    Troubleshooting: Use Nslookup to check the DNS. Verify that the IP address is in IPv4 literal format. Verify that there is a valid DNS entry for the server or computer name in question. If you are relying on the FQDN in the Hosts file, ignore it, and update the entry in Exchange System Manager by using a valid IP address or correct name.
  • Numeric Code: 5.4.4

    First Available: Exchange 2000 Service Pack 1

    Possible Cause: No route to message, next hop not found. You have set up a Routing Group topology, but there is no Routing Group Connector set up between the Routing Groups.

    Troubleshooting: Add or configure your Routing Group Connector between Routing Groups.
  • Numeric Code: 5.4.6

    Possible Cause: A Categorizer forward loop was detected.
    The targetAddress attribute is set on a mailbox-enabled user. Hosting Pack: This is a common hosting configuration problem that is caused by an organizational unit (OU) conflict. The problem occurs when someone creates a contact in OU1 and then uses the provisioning tool to create a user in OU2 that has the same email address.

    • This problem occurs when contactA has an alternative recipient that points to contactB, and contactB has an alternative recipient that points back to contactA. Check the alternative recipient for every contact.
    • Remove the targetAddress attribute from mailbox-enabled users.
    • For hosting in which you want to send mail from one user in one company (OU) to another company (OU), it is best to specify the following related objects:
      User: SMTP proxy:
      Contact: targetAddress:; SMTP proxy:
  • Numeric Code: 5.4.8

    First Available: Exchange 2000 Service Pack 1

    Possible Cause: This code indicates a looping condition. This problem may occur if one of the recipient policies includes a local domain that matches the FQDN of an Exchange server in the organization. When the Transport Categorizer processes email that is destined for a domain that matches the FQDN of an Exchange server, an NDR that has this code is generated.

    Troubleshooting: If this problem occurs because of a domain that matches the FQDN of an Exchange server in the recipient policy, you must remove that entry.
  • Numeric Code: 5.5.0

    First Available: Exchange 2000 Service Pack 1

    Possible Cause: Generic protocol error (SMTP error). The remote SMTP responds to our EHLO by generating a 500 level error, and the sending system ends the connection and reports this NDR error. This indicates that the remote SMTP server cannot handle the protocol. (For example, if a account is no longer active, a 550 SMTP error occurs.)

    Troubleshooting: Run an SMTP log or a Network Monitor trace to deteremine why the remote SMTP server rejected the protocol request.
  • Numeric Code: 5.5.2

    Possible Cause: This refers to a general protocol error when SMTP protocols are out of sequence. For example, an SMTP protocol error occurs when AUTH is tried before EHLO. In one observation, this occurred when the system was experiencing an "out of disk" condition.

    Troubleshooting: Run an SMTP log or a Network Monitor trace to verify that there is enough disk storage and virtual memory for SMTP to operate.
  • Numeric Code: 5.5.3

    Possible Cause: There are too many recipients on the sent message.

    Troubleshooting: The recipient limit is a configurable limit on the receiving server. To resolve this problem, either increase the recipient limit, or break up the message into multiple messages to fit the server limit.

    Note The default recipient limit on a Simple Mail Transfer Protocol (SMTP) message is 5,000. To set this limit, start the Exchange System Manager, click the Global Settings node, right-click Message Delivery, and then click Properties. This can also be a per-user setting in Active Directory.
  • Numeric Code: 5.6.3

    First Available: Exchange Server 2003

    Possible Causes:
    1. The message contains more than 250 attachments. More than 250 attachments cause the MAPI_E_TOO_BIG error.
    2. Mail that had a malformed addr822 header was sent.

    1. Reduce the number of attachments in the message, and then resend the message.
    2. Correct the header. This error is misleading because it indicates that the NDR occurs because of the malformed P2 headers.
  • Numeric Code: 5.7.1

    Possible Causes:
    • General access denied, sender access denied; the sender of the message does not have the credentials required to complete delivery.
    • You are trying to relay your mail through another SMTP server, and that server does not allow you to relay.
    • The recipient might have mailbox delivery restrictions enabled. For example, a recipient's mailbox delivery restriction was set to receive from a Distribution List only, and the email message of a non-member is rejected and generates this error.
    • For Exchange Server 2003, a distribution list can be configured to restrict mail delivery from unauthenticated users. Mail that is sent by using an unauthenticated SMTP session is rejected.
    Troubleshooting: Check system permissions and attributes for the contact, and then try to send the message again. Also, make sure that you are running Exchange 2000 Service Pack 1 or a later version to account for other known problems.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:

256321 Enhanced status codes for delivery - RFC 1893

Additional Resources

For information about NDRs in Exchange Server 2007 and in Exchange Server 2010, see the following Microsoft TechNet topics: