Troubleshooting Mail Flow and SMTP

  • Article

 

Even after you have successfully configured Simple Mail Transfer Protocol (SMTP) in your Microsoft® Exchange Server organization and taken every measure to secure it, you might experience mail flow problems. This topic discusses many of the common problems that you may encounter and methods to help resolve them.

Specifically, you will learn how to:

  • Use Telnet

  • Use the SMTP and X.400 queues

  • Use Message Tracking Center

  • Use Event Viewer

  • Configure diagnostic logging for SMTP

However, before considering the troubleshooting recommendations in this topic, first ensure that Exchange Server is configured correctly to send and receive mail. The lists below briefly summarize the requirements for inbound and outbound mail to flow properly.

For incoming Internet mail to flow correctly:

  • Your recipient policies must be configured correctly.

  • Your SMTP virtual server that accepts Internet mail must be configured on port 25 and allow anonymous connections.

  • A mail exchanger (MX) resource record for your domain must exist on an internet DNS server, and the MX record must point to the external or Internet domain of your mail server.

  • Your Internet mail server must be accessible to remote servers on the Internet.

For outgoing Internet mail to flow correctly:

  • Your SMTP virtual server that sends Internet mail must be configured to use port 25.

  • If you are using SMTP connectors, at least one connector must contain an address space of *, which specifies all external domains.

  • Your Exchange server must be able to resolve external DNS names. You can resolve external DNS names in the following ways:

    • Use an internal DNS server that forwards mail to an external DNS server.

    • Configure your SMTP virtual server to use a specific external DNS server.

    • Route mail to a smart host that performs DNS resolution.

For more information about how to configure Exchange Server to send and receive e-mail messages, see Verifying DNS Design and Configuration.

For detailed information on how to use Telnet to test SMTP, see the following topic:

Using the SMTP and X.400 Queues

SMTP uses the SMTP queues to deliver mail internally and externally. Exchange Server version 5.5 servers, MAPI clients (such as Microsoft Office Outlook®), and other mail connectors (such as Microsoft Exchange Connector for Lotus Notes and Microsoft Exchange Connector for Novell Groupwise) use the X.400 queues to send mail to and receive mail from Exchange Server. The following sections explain how to use both the SMTP and X.400 queues to troubleshoot message flow.

Understanding the SMTP Queues

During message categorization and delivery, the advanced queuing engine sends all mail through the SMTP queues of an SMTP virtual server. If there is a problem delivering the message at any point in the process, the message remains in the queue where the problem occurred.

Use the SMTP queues to isolate the possible causes of mail flow issues. If a queue is in a "Retry" status, you should check the properties of the queue to determine the cause. For example, if the queue properties display a message that is similar to "An SMTP error has occurred," you should review your server's event logs to locate any SMTP errors. If there are no events in the log, you should increase the SMTP Protocol logging level. For more information about how to increase the SMTP Protocol logging level, see How to View the Application Log in Event Viewer and How to Modify Logging Settings for MSExchangeTransport.

The following table lists the SMTP queues, including their descriptions, and troubleshooting information for message accumulation in each queue.

Descriptions of SMTP queues and associated troubleshooting information

SMTP queue Description Troubleshooting

[Local domain name] (Local Delivery)

Contains messages that are queued on the Exchange server for local delivery to an Exchange mailbox or public folder store.

Messages can accumulate in this queue if the Exchange server is not accepting messages for local delivery. Slow or sporadic message delivery can indicate a looping message or a performance problem.

This queue is affected by the Exchange store. Increase diagnostic logging for the Exchange store as described in How to Modify Logging Settings for MSExchangeTransport.

Messages awaiting directory lookup

Contains messages to recipients that have not yet been resolved against Microsoft Active Directory® directory service. Messages are also held here while distribution lists are expanded.

Generally, messages accumulate in this queue because the advanced queuing engine is unable to categorize the message. The advanced queuing engine may not be able to access the global catalog servers and access recipient information, or the global catalog servers are unreachable or performing slowly. Additionally the following may cause messages to accumulate:

  • Active Directory is unavailable (because the categorizer uses Active Directory to categorize messages).

  • Active Directory may be excessively loaded (if many messages are queuing in the pre-categorization queue).

  • A failure in conversion. The categorizer also handles content conversion.

  • Message categorizer cannot find the mailbox stores.

  • If SMTP was reinstalled or removed, that may invalidate the following IIS metabase keys: /smtpsvc/DsUseCat and /smtpsvc/vsi#/DsUseCat. Determine whether SMTP was reinstalled or removed.

The categorizer affects this queue. Increase diagnostic logging for the categorizer as described in How to Modify Logging Settings for MSExchangeTransport.

Messages waiting to be routed

Holds messages until their next-destination server is determined, and then moves them to their respective link queues.

Messages accumulate in this queue if Exchange Server routing problems exist. Message routing may be backed up. Increase diagnostic logging for routing as described in How to Modify Logging Settings for MSExchangeTransport.

Remote delivery

[Connector name|

Server name| Remote domain]

Holds messages that are destined for remote delivery. The name of the queue matches the remote delivery destination, which may be a connector, a server, or a domain.

If messages accumulate in this queue, you must first identify the status of the queue. If the queue is in "Retry," check the queue properties to determine the reason it is in this state. For DNS issues, use Nslookup and telnet to troubleshoot. If the host is unreachable, use telnet to ensure that the remote server is responding.

Final destination currently unreachable

The final destination server for these messages cannot be reached. For example, Exchange cannot determine a network path to the final destination.

Messages can accumulate in this queue if no route exists for delivery. Additionally, any time a connector or a remote delivery queue is unavailable or in "Retry" for a period of time, and no alternate route exists to the connector or remote destination, new messages queue here. This allows an administrator to fix the problem or define an alternate route. To get new messages to flow to their remote destination queue so you can force a connection and get a Network Monitor (Netmon) trace, restart the SMTP virtual server.

Pre-submission

Holds messages that have been acknowledged and accepted by the SMTP service. The processing of these messages has not begun.

Messages that are accumulating constantly may indicate a performance problem. Occasional peaks in performance can cause messages to appear in this queue intermittently.

DSN messages pending submission

Contains delivery status notifications, also known as non-delivery reports that are ready to be delivered by Exchange.

Note   The following operations are unavailable for this queue:

  • Delete All Messages (no NDR)

  • Delete All Messages (NDR)

Messages can accumulate in this queue if the Microsoft Exchange Information Store service is unavailable or not running, or if problems exist with the IMAIL Exchange store component, which is the component that performs message conversion.

Check the event log for possible errors with the Microsoft Exchange Information Store service.

Failed message retry queue

Contains messages that failed some type of queue submission, often before any other processing has taken place. By default, messages in this queue are reprocessed in 60 minutes.

Possible causes for failed messages are:

  • Corrupted messages.

  • Third-party programs or event sinks may be interfering with message queuing or fidelity.

  • Low system resources could cause the system to respond slowly or cause other performance issues. Restarting IIS may temporarily improve resource issues, but you should determine the root cause.

Messages queued for deferred delivery

Contains messages that are queued for delivery at a later time, including messages that were sent by older versions of Outlook. (You can set this option on Outlook client computers.)

Previous versions of Outlook depend on the message transfer agent (MTA) for message delivery. Now, however, SMTP handles message delivery, not the MTA. Therefore, messages that are sent by older versions of Outlook treat deferred delivery differently.

These messages remain in this queue until their scheduled delivery time.

Possible causes for message accumulation are:

  • If a message is sent to a user's mailbox while the mailbox is being moved, messages can queue here.

  • When the user does not yet have a mailbox and no master account Security ID (SID) exists for the user. For more information, see Microsoft Knowledge Base article 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts."

  • The message may be corrupt or the recipient may not be valid.

  • To determine if a message is corrupt, check its properties. If a message is not accessible, it may be a corrupt message. You can also check that the recipient is valid.

For more information about troubleshooting mail flow and SMTP, see the following topics: