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

Inbound mail flow is comprised of all messages received by the SMTP virtual server and destined for a recipient on the local server running Exchange Server 2003.

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

What is the basic process for inbound mail flow?

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

  1. The sending SMTP server queries Domain Name System (DNS) to locate the mail exchanger (MX) resource record of the recipient's SMTP mail server. This MX record resolves to a corresponding host (A) record that resolves the IP address of the recipient's SMTP mail server.
  2. The sending SMTP server initiates a conversation on the recipient's SMTP server (using port 25). On an Exchange Server gateway, the recipient's SMTP server is the SMTP virtual server on the Exchange server that is configured to accept inbound mail.
  3. If the message is destined for a recipient of its SMTP mail domain, the SMTP server accepts the inbound message, as defined by recipient policies. For more information about defining recipient policies, see the following Microsoft Knowledge Base articles:
  4. When the message is accepted, the message is persisted in the \Queue folder on the Exchange server. The SMTP virtual server submits the message to the Advanced Queuing Engine, which then submits the message to the message categorizer. For more information about the Advanced Queuing Engine, see the following Microsoft Knowledge Base articles:
  5. The message categorizer validates the recipients of the message, checks for proper recipient attributes, applies limits and restrictions, flags the message for local delivery, and then returns the message to the Advanced Queuing Engine.
  6. The Advanced Queuing Engine submits the message to the Local Delivery queue.
  7. The Exchange store receives the message from the Local Delivery queue.
  8. Mail messages are delivered to the client (for example Outlook, Outlook Express, or Outlook Web Access).

What are the minimum requirements for inbound mail flow?

The following are the minimum requirements for inbound 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 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.
  • Recipient policies must be configured and applied correctly. Recipient policies will stamp the SMTP virtual server and the recipient's mailbox with the correct e-mail address.

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 SMTP 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 of 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 inbound mail flow problem?

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

  • Firewall   Do you have a firewall? Have there been any changes to the firewall? If you have made recent changes, load a previously-saved, good configuration. Restart the firewall or firewall services. If the Message Screener component of Internet Security and Acceleration (ISA) Server is enabled, verify that message screening is configured correctly. Is TCP port 25 open on the firewall? (Port 25 must be open for Exchange Server mail flow to work properly.) Does mail function correctly behind the firewall?
  • Internet Domains   Can Internet domains send messages to you? If all external domains are unable to send mail, verify the MX record on the Exchange server and that the IP address associated with the MX record is the IP address of the Exchange server or the firewall. If some domains cannot send mail, are you getting non-delivery reports (NDRs)? Is the SMTP connector configured properly? For more information about verifying that domains can send mail, see Microsoft Knowledge Base article 153119, Telnet to Port 25 to Test SMTP Communication.
  • Domains Hosted by Exchange Server   Are all domains affected? If yes, check the recipient policy and verify that the Exchange server is authoritative for all of the hosted domains. Is port 25 open on the firewall? Check to see if any senders are receiving NDRs. If some domains are affected, does the recipient policy indicate that the Exchange Server organization is authoritative for the affected domain? Has any recipient filtering been configured that would prevent mail from reaching the affected domain?
  • Receiving Mail   If you have been able to receive mail and are now experiencing problems, try to identify when the problem began. What changes are associated with the problem? New software? New configuration? New users? Is the problem intermittent? If yes, is there a pattern? Does the problem occur when associated with specific services, components, or third-party applications? If not, check the MX records, verify that port 25 is configured properly, and that the IP address for the Exchange server can be recognized from another machine in the network.

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

In a scenario where only some users are affected by an inbound mail flow problem, consider the following:

  • Services   The following Exchange Server services must be running in order for inbound mail to function properly:
    • Microsoft Exchange System Attendant
    • Microsoft Exchange Information Store
    • Microsoft Exchange Routing Engine
    • Simple Mail Transfer Protocol (SMTP)
      If any of these services are stopped, restart them. Next, check the event log to identify why the service was stopped.
  • Queues   Are messages getting stuck in queues? For more information, see the question "What queues should I monitor?" later in this article.
  • Client   Frequently, when only a few users on the same Exchange server are experiencing similar problems, client software can be the cause. If this is the case, verify that users can send mail to themselves (or to any other users on the same server) using the client software normally available to them.
  • Administrative Options   Have administrators configured any restrictions on the particular group of users? Is there a size limit on inbound messages? Is there a storage limit on a particular user's mailbox? Can the affected users receive mail from 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 queues should I monitor?

Messages will pass through the following queues during inbound 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 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 inbound mail flow, see the following resources: