Frequently Asked Questions: Troubleshooting Outbound Mail Flow in Exchange Server 2003

  • Article

Outbound mail flow is comprised of all messages sent from clients in your Microsoft Exchange Server organization. After messages pass through the Exchange Server transport core, they are sent from the Exchange Server SMTP virtual server to the SMTP connector for outbound Internet delivery.

The following information provides you with answers to the most frequently asked questions about outbound mail flow.

What is the basic process for outbound mail flow?

Outbound mail flows through an Exchange Server deployment in the following manner:

  1. Mail messages are sent from a client (Microsoft Outlook, Outlook Express, or Outlook Web Access, for example) and are submitted to the local Exchange store.
  2. The Exchange store submits the message to the Advanced Queuing Engine.
  3. The Advanced Queuing Engine submits the message to the message categorizer.
  4. The message categorizer validates the recipients of the message, checks for proper recipient attributes, applies limits and restrictions, flags the message for local or remote delivery, and then returns the message to the Advanced Queuing Engine.
  5. If for local delivery, the Advanced Queuing Engine submits the message to the Local Delivery queue, and the Exchange store receives the message from the Local Delivery queue. For more information about the Advanced Queuing Engine, see Microsoft Knowledge Base article 260973, Setting Up SMTP Domains for Inbound and Relay E-Mail in Exchange 2000 Server and Exchange Server 2003.
  6. If for remote delivery, the Advanced Queuing Engine submits the message to the Routing Engine. The Routing Engine determines the most efficient route for mail delivery, returns the message to the Advanced Queuing Engine, and, in turn, submits the messages for remote delivery. The messages are then sent via SMTP to a remote SMTP host or to the Internet.

What are the minimum requirements for outbound mail flow?

The following are the minimum requirements for outbound mail flow:

  • Exchange Server must have access to the Internet on port 25. This access should not be blocked by firewalls or other network settings. Anonymous connections should be allowed.
  • The Exchange Server SMTP virtual server should be configured to use the default settings. For more information about configuring the Exchange Server SMTP virtual server, see Microsoft Knowledge Base article 266686, How to Configure a SMTP Virtual Server Part 1.
  • The public mail exchanger (MX) resource record configured on your public Domain Name System (DNS) service should be accessible to all other Internet domains. The MX record should point to the Exchange server and must be identified before messages can be sent or received.

How can I identify the scope of a problem?

Mail flow problems are often identified as mail not being delivered to or received by the client. The causes of specific problems can vary — for example a queue may be backing up or mail may be returned as non-deliverable. Finding the answers to the following questions can help you identify the scope of a problem in your Exchange Server organization:

  • Does this affect some or all Exchange Server users? If only some users are affected, do they share a common variable? For example, are they using the same client application or are they all sharing the same local Exchange server?
  • Does this affect one or multiple Exchange servers? If multiple Exchange servers are affected, are core Windows Server components (such as DNS) configured properly for Exchange Server?
  • Does this affect multiple users on multiple Exchange servers? Are all domains hosted by your Exchange server affected? Are all users affected?
  • When did the problem begin? Did it begin when you first noticed the problem or has it existed unnoticed for some time?
  • If you are currently experiencing a problem with a particular feature or technology in Exchange Server, has this feature or technology ever worked in your deployment? If yes, when did it stop working? When is the last time you knew it was working properly?
  • What has changed? If this worked previously and is not working now, something changed. Did you move one or more mailboxes? Create one or more new users? Did a router fail? Is a service not running? Are any queues backed up?
  • What version of Exchange Server are you running? Are any service packs or updates applied? If yes, are they applied to all of the same-version servers in your organization?
  • Are you running any third-party software, such as anti-virus software? Did you perform any customizations that use event-sinks such as custom anti-virus filtering?
  • Are Windows Server components such as DNS, Active Directory, IIS, and SMTP functioning correctly? Are the services associated with Windows Server (and required by Exchange Server) running? For information about the services required for Exchange Server, see "Appendix B: Services That Are Used by Exchange Server" in the Exchange Server 2003 Administration Guide.
  • Is the MX record on the Exchange server configured properly? For information about MX records, see Microsoft Knowledge Base article 203204, How to obtain Internet Mail Exchanger records with the Nslookup.exe Utility.
  • Are recipient policies configured properly? For information about configuring recipient policies, see "Configuring Recipient Policies" in "Chapter 7: Connecting to the Internet" of the Exchange Server 2003 Transport and Routing Guide.
  • Are users able to send messages?
  • Are users able to receive messages?

What can I do if all users are affected by an outbound mail flow problem?

In a scenario where all users are affected by an outbound mail flow problem, consider the following:

  • Has outbound mail flow worked before?   If outbound mail flow has worked before, what has changed? If this hasn't worked before, is DNS able to resolve the MX record of the Exchange server? Is the SMTP connector configured properly? Is a smart host reachable from the Exchange server?
  • What happens to the message?   When a message is sent, what happens? Do you receive non-delivery reports (NDRs)? Does the message sit in Outlook? Does the message sit in a queue in the SMTP virtual server? Does the message appear to be sent, but is not delivered successfully?

What can I do if only some users are affected by an outbound mail flow problem?

In a scenario where only some users are affected, consider the following:

  • Queues   Are messages getting stuck in queues? For more information, see the question "What queues should I monitor?" later in this article.
  • Non-Delivery Reports   Are users receiving non-delivery reports (NDRs)? For more information, see the question "What do I do if a user receives a non-delivery report (NDR)?" later in this article.
  • Administrative Options   Have administrators configured any restrictions on the particular group of users? Is there a size limit on outbound messages? Have the users exceeded their quota? Can the affected users send mail to any domain or is it specific to one domain? Use message tracking and send mail to that user and follow the path it takes through your Exchange Server organization.

What do I do if a user receives a non-delivery report (NDR)?

If any of your users receives an NDR, be sure to reference the NDR message and the error code. Error codes that indicate a persistent transient failure begin with a 4 and error codes that indicate a permanent failure begin with a 5. The following are some questions you should consider when using non-delivery reports (NDRs) to troubleshoot issues with outbound mail flow:

  • What types of clients are in use? Which version?
  • Do one or more users receive NDRs when they send mail to a specific recipient or to every recipient?
  • Can other users send mail successfully to the same recipient on the same server?
  • Do users on other servers experience the same issue?
  • Is the issue site-specific or does it occur across multiple sites?
  • Can the issue be reproduced?
  • What type of recipient is experiencing the problem?
  • Where does the recipient physically reside?
  • How was the recipient entered in the To field of the message?

For more information about NDRs, see "Chapter 13: Troubleshooting Non-Delivery Reports" in the Exchange Server 2003 Transport and Routing Guide.

How do I identify mail loops?

A message is considered to be in a loop when it bounces back and forth between gateways without delivery. The primary indicator of a mail loop is a non-delivery report (NDR). The following NDRs indicate message loops:

  • 4.4.6   Triggered when the maximum number of hops is reached, as indicated by the SMTP "received" header, configured in the SMTP virtual server. The default maximum number of hops in Exchange Server 2003 is 30.
  • 5.3.0   Triggered when a serious error caused the Advanced Queuing Engine to send SMTP mail to the message transfer agent (MTA).
  • 5.3.5   Triggered when an Exchange server attempts to send mail to a target server and that target resolves back to itself. Causes for this error include the following:
    • There may be more than one SMTP virtual server using non-unique FQDNs.
    • The destination server names may be configured in DNS with the same IP address as the sending server
    • The SMTP connector with an address space of asterisk attempted to forward to the sending server as a smart host.
  • 5.4.6   Triggered when the Exchange Server message categorizer detects a condition that fails under its loop detection logic. Causes for this error include the following:
    • Mail was sent to contacts, mail-enabled users, or foreign one-off recipients with the SMTP domain in the TargetAddress that matches a domain that is authoritative in any recipient policy.
    • Mail was sent to mailbox-enabled users that have a TargetAddress attribute.
    • Mail was sent to a list of internal recipients with the "journal recipient" as the first recipient.
    • Mail was sent to a mailbox that has AlternateRecipients or forwardingAddress attributes that point back to the mailbox.
  • 5.4.8   Triggered when a server in the Exchange Server organization has a fully-qualified domain name (FQDN) that matches a recipient policy domain. For more information about NDR 5.4.8, see Microsoft Knowledge Base article 288175, Recipient Policy Cannot Match the FQDN of Any Server in the Organization, 5.4.8 NDRs.

For more information about NDRs, see "Chapter 13: Troubleshooting Non-Delivery Reports" in the Exchange Server 2003 Transport and Routing Guide.

What queues should I monitor?

Messages will pass through the following queues during outbound mail flow. If problems exist with the queues, messages may not be delivered. Consider using Queue Viewer in Exchange System Manager to monitor the status and state of the following queues:

  • Messages Pending Submission   Also called the pre-submission queue. This queue contains messages accepted by the SMTP service. Messages in this queue have not yet been processed by the message categorizer. If messages are accumulating in this queue, it may indicate a performance problem on the Exchange server, or it may indicate a problem with an event sink (such as custom SMTP processing code for anti-virus screening).
  • Messages Awaiting Directory Lookup   Also called the pre-categorization queue. This queue contains messages that have passed through the pre-submission queue and are waiting to be processed by the message categorizer. Messages will accumulate in this queue when the message categorizer is unable to process messages. Reasons the message categorizer may be unable to process messages include the following:
    • The message categorizer may not be able to access the global catalog to attain recipient information.
    • The global catalog lookup may be performing slowly.
    • If this is a front-end server, the required mailbox store may be disabled on a front-end server.
  • Local Delivery   Contains messages destined for recipient mailboxes that reside on the local Exchange 2003 server. Messages can accumulate in this queue if the Microsoft Exchange Information Store service is not accepting messages or if it has a performance problem.
  • Messages Waiting to be Routed   Contains messages destined for remote delivery. Messages can accumulate in this queue if problems exist with routing.
  • Remote Delivery   Contains messages that are destined for remote delivery. If this queue is in a Retry state (that is, the connection has failed), use Telnet.exe to try to connect to the intended destination host. Restart the SMTP virtual server to immediately retry sending queued messages.
  • Messages with an Unreachable Destination   Contains messages that cannot reach their final destination server. Reasons that messages may not be able to reach their destinations include the following:
    • The route cannot be determined
    • The routes are unavailable
    • A connector is down
  • Messages Queued for Deferred Delivery   Contains messages that are queued for later delivery. Reasons that messages will be placed in this queue include the following:
    • Messages are sent by previous versions of Microsoft Outlook (such as Outlook 2000)
    • A message is sent to a user's mailbox while the mailbox is being moved
    • The user does not yet have a mailbox and no master account security ID (SID) exists for the user
    • SMTP message routing is configured in a way that causes a message to loop (looping messages are moved to this queue)
  • DSN Messages Pending Submission   Contains delivery status notifications that are waiting to be rendered by Exchange Server. For example, NDRs are delivery status notifications. Reasons that messages will accumulate in this queue include the following:
    • The Microsoft Exchange Information Store service is unavailable or not running
    • A mailbox store is not mounted,
    • Issues exist with the IMAIL Exchange store component.
  • Failed Message Retry   Contains messages that failed queue submission. Messages can fail for several reasons, including if the message is corrupted or if system resources are low. If messages appear in this queue, review your server configuration to determine whether you have non-Microsoft programs or event sinks installed (such as virus scanners) that can interfere with message queuing. If the system is responding slowly, use Windows Task Manager to identify processes with system resources. Restarting Internet Information Services (IIS) may solve the problem temporarily and allow you more time to identify the root cause of the problem.

For more information about using Queue Viewer, see Microsoft Knowledge Base article 823489, How to use Queue Viewer to troubleshoot mail flow issues in Exchange Server 2003.

For More Information

For more information about troubleshooting outbound mail flow, see the following resources: