MSExchangeGuru.com

Learn Exchange the Guru way !!!

 

Exchange Server – Troubleshooting internal/external mail flow issues

Let’s take a look at some mail flow basics and how to troubleshoot and resolve issues involving improper reception of incoming mails.

Sometimes for a properly working mail flow structure with a valid SMTP domain which is in the list of accepted domain, internal mail may not reach the recipient properly. This may be due to a number of reasons. To resolve this issue, we first check if a Non Delivery Report has been received by the sender.

In the absence of Non delivery report being received by the sender, we can check for any of the following options so as to resolve the issue:

MX Record

An MX record or a Mail Exchange Record is basically a record which redirects an email which is being sent to a user to that particular user’s computer. So it instructs the mail deliver agent the system to which the email is to be routed. If the MX record does not specify the correct IP address of the recipient, incoming mail will not be received by them. To check if the MX Record is pointing to the correct IP, we use the NSLOOKUP.

The NSLookup tool is used to check the configuration of the mail exchange records.

Performing the NSLookup

  • Go to Command Prompt
  • Key in NSLOOKUP and Press Enter
  • Enter server {required IP of DNS server}
  • Press Enter
  • Enter the following
    • Set q=MX
  • Now if you enter the domain name required and press enter, its particular MX record will be shown. This ensures that MX record has been properly configured.

Example:

C:\> NSLOOKUP

Default Server: ns1.domain.com

Address: 10.0.0.1

> set q=mx

> domain.com

Server: ns1.domain.com

Address: 10.0.0.1

mailhost.domain.com MX preference = 0, mail exchanger = mailhost.domain.com

Blacklist check

If the MX Record is properly configured, we check for any blacklisting issues. Usually blacklisting is checked for when there are multiple domains from which mail is not incoming. To run a blacklist check, we need a black list tool for the outbound IP address and the domain name of the remote server, which can be obtained from http://www.mxtoolbox.com

Once we obtain the tool, we check for any blacklists marked against the different domains IP addresses which are having inbound mailflow issues. If there is a blacklisting, we need to contact the providers of Blacklist so that we can resolve the issue by removing the domain from the blacklist. This will obviously require some time as per the blacklist server. If the issue needs to be resolved urgently, we can always try to change the outbound IP address and take a look into the reason behind blacklisting.

Submit email using Telnet

Next test is to use Telnet to submit an email. For this, we first go for a network which is also an exchange/HUB server that can have proper inbound mail reception and use telnet to resubmit the email. By doing this, we can ensure that the port 25 traffic is properly received by the server. After this test is passed, we check for the MX record of port 25 to obtain its IP address.

Check the port 25 listening accessibilities and find out if exchange is listening on port 25 or is it some other hosts. If an exchange verb is obtained as the response to the EHLO command in case of the MX showing an exchange/HUB server.

If the host is not exchange, then the issue might be in the configurations of the smart host. If there are no issues in the configuration of the smart host, the SMTP logs may be checked for errors against submission of inbound mail to exchange.

EXRCA:

Next, we check the SMTP verbs are properly returned by the tool https://www.testexchangeconnectivity.com/

Receive Connector (E2k7 & E2k10)

Next, if the exchange server is 2007 or 2010, we check the receive connector. This is done if a particular error is shown by the sender’s server namely, “530 5.7.1 Client was not authenticated and generate NDR”. Under such circumstances, we do the following

  • Check the properties of the receive connector.
  • Check if NIC specified for the receive connector is correct.
  • Check if the IP address specified in the receive connector is configured properly
  • Check if anonymous permissions are available for the receive connector configurations. This should be made available.
  • The receive connector should have SMTP protocol logging enabled to Verbose and check if the SMTP traffic is actually hitting the server.
  • The receive protocol logs may be verified so that there are no errors in them.

Default SMTP Virtual Server Properties (E2k3):

If the exchange version is 2003, we follow the following steps to check the SMTP virtual server properties:

  • Ensure that the IP address port binding is properly configure.
  • Verify the Default Virtual server IP address.
  • Check for the port configuration from General-> Advanced. The port should be configured as 25.
  • Navigate to Authentication from Access on the Default Virtual server properties and make sure that the Anonymous permission is enabled.
  • Check the connection control configurations from Properties à Access
  • Make sure that NCSA logging is enabled and find errors in them.

Backpressure:

Backpressure issues account to most of the email queue building issues. In simple words, backpressure means exchange is unable to process emails due to resource bottleneck issues.

Backpressure events look like this:

Log Name: Application
Source: MSExchangeTransport
Date: 4/17/2013 7:00:34 AM
Event ID: 15004
Task Category: ResourceManager
Level: Warning
Keywords: Classic
User: N/A
Computer: HUBServerName
Description:
Resource pressure increased from Normal to Medium.

Resource utilization of the following resources exceed the normal level:
Version buckets = 123 [Medium] [Normal=80 Medium=120 High=200]

Back pressure caused the following components to be disabled:
Inbound mail submission from the Internet
Mail submission from the Pickup directory
Mail submission from the Replay directory
Mail delivery to remote domains

The following resources are in the normal state:
Queue database and disk space (“Q:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\mail.que”) = 3% [Normal] [Normal=95% Medium=97% High=99%]
Queue database logging disk space (“Q:\Program Files\Microsoft\Exchange Server\TransportRoles\data\Queue\”) = 4% [Normal] [Normal=95% Medium=97% High=99%]
Private bytes = 16% [Normal] [Normal=71% Medium=73% High=75%]
Physical memory load = 40% [limit is 94% before message dehydration occurs.]

So, make sure that there are no 1500x events listed in the application logs of the event logs.

The following links are good resource for troubleshooting-

http://technet.microsoft.com/en-us/library/bb201658(v=exchg.141).aspx

Known issues

These are some known issues in improper inbound mail flow.

  • NDR of Sender shows the error “550-5.1.1 User unknown”

    Resolution

    This may be an AD Replication issue or an Edge Sync issue

Quite often, clients may face issues were multiple users within the exchange are unable to make email communications within the network or to other networks or sometimes both. Here, we shall look into the troubleshooting and resolution of such issues.

Under such circumstances, we take into account, some key information we collect from the client. They are

  • Availability of Non Delivery Report for senders. If there is an NDR available, we obtain the NDR and look up the error generated in the NDR and the generating server.
  • In the absence of an NDR, we need to know if the failed email has been housed in the users Outbox or in the Sent Items folder.
  • Next, we need to know if the user is able to get Incoming emails.
  • We also check if there is an issue with outbound email. In case of an issue, we need to know if the user is facing issues for all internet domains or just some specific domains.
  • Next, we need to gather some information regarding the environment. Is the environment a Mixed Environment or not, the number of Active directory sites in the environment etc.
  • Next, we need information regarding the configuration of the mailflow on which the user is facing issues. If it is inbound mailflow issues, ask for the MXrecord pointer.
  • Finally, check the type of connecter used for the internet- DNS or Smart Host. If the user is using a smart-host, the type and details of the smart-host is also required.

Now, we begin troubleshooting based on the type of mail flow that has been impacted.  

Mail being blocked at Exchange 2003 server: 

In case of mail being stuck at the exchange server, we follow these steps:

  • Use the exchange system manager to check the queue.
  • Check the additional information for the queue where the mail is being blocked. Additional Information can be found on the bottom left corner of the exchange system manager.
  • Check the anti-virus the server houses. If the antivirus has made any exclusions, disable them.
  • Check for the type of queue where the mail is being blocked. Use the following cases to solve for the appropriate queue viewer error.

Error- Unable to bind destination server in DNS.

In such cases, we utilize the NSLOOKUP tool to obtain the name resolution of the remote domain or remote bridgehead server.

Error – Connection was dropped off due to SMTP Protocol Event Sink

If the error returned is that the connection was dropped due to SMTP protocol event sink, we utilize Telnet to check the SMTP verbs of the remote server. Here we first check if anonymous submission of messages is pliable. If so then we have to verify the logs of NCSA protocols to check for the command at which we face the error.

If there are no information on the NCS log files, we verify that Netmon captures are available on the sending and recipient servers, preferably simultaneously.

Error in queue – Unable to open the message for delivery.

For such an error, we begin by verifying the queue for errors or warnings. If there are no events in the queue, we retry the queue after changing the transport component’s diagnostics logging to expert level.

Error in queue – The remote server did not respond to connection attempt.

Here, we once again utilize the NSLOOKUP tool to ensure that the resolution is towards the proper server. We also utilize Telnet to check the SMTP connectivity of the remote server and anonymous submission capabilities.

Error in Queue – An SMTP protocol error occurred.

Verify SMTP verbs and anonymous message submission capabilities using Telnet. If anonymous submission is available, check for the logs of NCSA protocol and verify the command at which error occurred.

If there are no information on the NCS log files, we verify that Netmon captures are available on the sending and recipient servers, preferably simultaneously.

Mail being blocked at Exchange 2007/2010 server:

  • Use the exchange system manager to check the queue. Find the queue in which the failed message is there and check for its status-Retry or Active.
  • Check the additional information for the queue where the mail is being blocked. Repeat the above section’s procedures for different types of errors.
  • In the SMTP virtual server, try enabling NCSA Logs.
  • Check the anti-virus the server houses. If the antivirus has made any exclusion, disable them.
  • Verify that the properties of the Routing Group Connector are properly configured. The cmdlet for this is:

Get-RoutingGroupConnector “Name of routing group connector” | fl

  • Enable the logging for Receive Connectors protocol at the recipient server to check the receive connector that has been chosen for Exchange 2003 server and find any errors in the SMTP communication.

    The cmdlet for checking the location of the Receive connector protocol log file is,

Get-TransportServer “Name of Hub transport server” | fl

  • Verify errors on the Application and system logs of the Exchange 2007/2010 target transport servers at the destination server.
  • Go to the receive connector logs location to obtain logs by going using the cmdlet,

    Get-transportserver | fl
    for both the receiving server.

Mails stuck on E2k7/2010 for Exchange 2003.

  • Use the queue viewer     to check the queue.
  • Check the Queue type, Last error and Next Hop Domain for the queue where the mail is being blocked. Use appropriate tool like nslookup, Intra-orgs send connector protocol logging, Telnet, netmon, Eventviewer, diagnostics logging based on the Last Error type to resolve the issue.
  • At the send connector, intra-org logging for can be increased using the command:

    Set-TransportServer “Hub server where message are queued up” –IntraOrgConnectorProtocolLoggingLevel

  • Verify the source and the destination servers using the Get-RoutingGroupConnector | fl command.
  • Verify the port 25 using telnet and verify the verbs.

Mails stuck on E2k7/10 for Exchange 2007/2010.

  • Use the queue viewer     to check the queue.
  • Check the Queue type, Last error and Next Hop Domain for the queue where the mail is being blocked. Use appropriate tool like nslookup, Intra-orgs send connector protocol logging, Telnet, netmon, Eventviewer, diagnostics logging based on the Last Error type to resolve the issue.
  • Check the status of the queue using get-queue | fl command.
  • At the send connector, intra-org logging for can be increased using the command:
  • Set-TransportServer “Hub server where message are queued up” –IntraOrgConnectorProtocolLoggingLevel
  • At the destination end (exchange 2007/10) server, verbose logging must be enabled.
  • Check for the properties of the Receive Connector on the target server i.e. Exchange 2007/10. The properties to be verified are:
    • Navigate to the RemoteIPRanges list. Find the various IPs listed there. Check if the Sending server’s IP is properly configured on the list.
    • Ensure that the exchange server authentication is enabled at the Authentication tab.
    • Navigate to Permission Groups and make sure that the option selected is Exchange server 
  • Use the following powershell cmdlet to facilitate Diagnostic Logging for MSExchangeTransport components at the target server:

    Get-EventLogLevelMSExchangeTransport\* | Set-EventLogLevel –Level Expert

  • Verify that errors like Back pressure (15004, 15005), temporary authentication failures (Kerberos), ADTopolgy events (2080) are absent in the Application and System Logs for events related to transport. If you see these, resolve these issues first.
  • Checking the Last error in queue can also be helpful in resolving the issue.

Sender receive NDR:

If the sender is receiving a non delivery report, obtain the following information from the NDR:

  • Whether more than one user is getting an NDR.
  • Is the NDR limited to users on a particular mailbox server or does this happen to multiple mailbox server.
  • Does mails sent to a particular recipient/DL/mailbox server/site/domain result in the NDR
  • Does the NDR appear for all instances of communications or do they happen at random points
  • In case of random NDRs find the frequency of occurrence of NDR
  • Was mail communication to the affected recipient in a working condition before the occurrence of NDR? Check for the duration from which the NDR was first seen and also check for changes made in the environment that resulted in the NDR.

    Obtain an NDR copy that can be saved.
    Verify the recipient information, generating server and the diagnostic information from the NDR

After obtaining the NDR, check the delivery status notification and the server generating NDR to resolve the issue. Also we can utilise the diagnostic logging at the application event logs to resolve the issue.

For the codes in the NDR, we can refer the article – http://technet.microsoft.com/en-us/library/bb124840(EXCHG.65).aspx

Mails getting stuck in Outbox and Drafts.

In the absence of NDRs and email tracking, check where the email is stuck. It should be in the Outbox in case of outlook and in the drafts folder for Outlook web app.

Further, verify the following details

  • Check if the issue persists for every mailbox in the server. Under such circumstances, follow:
    • Check if the submission service is working fine and properly configured for the sender’s mailbox server
    • Make sure that the transport service is working fine.
    • Restart the Microsoft exchange mail submission service.
    • Mail Submissions service running on the MBX server is the one responsible for alerting the HUB server to pick up the email
    • In the MSExchangeMailSubmission service check for any occurrences of 1009

If the issue is occurring for isolated mailboxes, then the issue may be because of different add-ins in the outlook or because of connectivity problems at the client side. Try sending emails from OWA under such circumstances.

Message Tracking:

During the absence of NDRs tools like Message tracking comes in very handy.

Tracking should be begun from the mailbox server of the sender. The server name under the tracking tool should be updated to the mailbox server of the sender. Any HUB transport server in sender’s site can be used to run the tracking.

We can also use power shell to perform message tracking.

http://blogs.technet.com/b/messaging_with_communications/archive/2011/04/22/how-to-track-message-in-exchange-2003-2007-2010.aspx

Troubleshooting Outbound Mail flow issues

Up until now, we were discussing issues with inbound mail messages. Now we shall look into troubleshooting of outbound mail issues.

There are three main characteristic natures by which we can distinguish an outbound email issue

In the first scenario, the sender is unable to send emails and the sender receives an NDR regarding the issue.

In the next scenario, sender is unable to send the email and he can see that the message is blocked in the queue.

And finally, the sender is able to send email but the delivery of the email message is uncharacteristically delayed.

Before we begin troubleshooting, we need to gather some basic info regarding the issue from the client.

  • Check if the internal mail flow was facing any issues. Also check if inbound mails are properly receiving by the user.
  • Find out the time from which the user started facing the issue and if the user was able to send emails prior to that. Also find out if any changes were made to the exchange environment which may have triggered the issue.
  • Find out whether the user has configured any smarthost or antispam apps for the outbound emails.
  • Also check if the user received any NDR or delayed deliver report regarding the failed email. If yes, collect the report.
  • Also find out if the issue is reproducible or not.
  • Check where the sent email (which failed) has been housed by outlook (sent Items/Outbox)
  • Ask if the issue persists for a single domain or multiple domains.
  • In case the user did not receive any NDR, ask if the email is blocked in the queue of the exchange server. If yes,
    • Track the email using message tracking tools
    • Collect the queue information like the queue name etc
    • Collect the error message written against the email in the queue
    • Ask for the result of the cmdlet execution Get-Queue|fl.
  • Ask for the send connector configurations (it can be obtained by executing Get-sendconnector | fl Cmdlet)
  • Find out if the user has installed antivirus or antispam software on the server. If there is one, try disabling it

Exchange 2003: E-mails stuck in queue

  • Use the exchange system manager to check the queue.
  • Check the additional information for the queue where the mail is being blocked. Additional Information can be found on the bottom left corner of the exchange system manager.
  • Find out the following details from the properties of SMTP Connector
    • The connector’s Address Space and Delivery Restrictions
    • Any smart host that the user is using to route the emails
      • If so, to the IP or FQDN of the smart host, perform Telnet and find the output
      • If connection is not going through, check whether the port 25 of the smart host is enabled to recieve emails from the server
      • If you are unable to complete the telnet to remote bridgehead, perform the telnet to some other target routing group server
    • If the user is using DNS to route the emails
      • Check if the issue is faced for all domains or just specific domains
      • Check if the MX record specify the correct IP address of the recipient using the NSLOOKUP tool.

        Performing the NSLookup

 

  • Go to Command Prompt
  • Key in NSLOOKUP and Press Enter
  • Enter server {required IP of DNS server}
  • Press Enter
  • Enter the following
  • Set q=MX

Now if you enter the domain name required and press enter, its particular MX record will be shown. This ensures that MX record has been properly configured

  • Make sure that NCSA logging is enabled and find errors in them.
  • From the Exchange Transport regedit, activate the diagnostic logging feature

Exchange 2007/2010: E-mails stuck in queue

  • Check the information for the queue and error message details using the cmdlet Get-Queue |fl
  • Find out if the send connector is based on DNS or Smart Host
  • Find out the configurational details of the send connector using Get-sendconnector | fl
  • If the client is running a smart host,
    • If so, to the IP or FQDN of the smart host, perform Telnet and find the output in the source server
    • If connection is not going through, check whether the port 25 of the smart host is enabled to recieve emails from the server
    • If you are unable to complete the telnet to remote bridgehead, perform the telnet to some other target routing group server
  • If the user is using DNS to route the emails
    • Check if the issue is faced for all domains or just specific domains
    • Check if the MX record specify the correct IP address of the recipient using the NSLOOKUP tool.
      • Performing the NSLookup
      • Go to Command Prompt
      • Key in NSLOOKUP and Press Enter
      • Enter server {required IP of DNS server}
      • Press Enter
      • Enter the following
      • Set q=MX
      • Now if you enter the domain name required and press enter, its particular MX record will be shown. This ensures that MX record has been properly configured
  • Resubmit the email using telnet from the server with HUB Transport. Check for the SMTP verbs and the IP address of the Outbound Service.
  • Also enable the Verbose Logging on the Sending Exchange 2007/2010 server
  • Make use of the message tracking tools to track the message
  • In case of remote/local server resetting the connection before completing the message transmission, using Netmon verify if any data packets were lost or retransmitted

NDR is received by the sender of the e-mail

If the sender is receiving a non delivery report, obtain the following information from the NDR:

  • The type of client from which the message was send-OWA/Outlook version etc.
  • Whether more than one user is getting an NDR.
  • Is the NDR limited to users on a particular mailbox server or does this happen to multiple mailbox server.
  • Does mails sent to a particular recipient/DL/mailbox server/site/domain result in the NDR
  • Does the NDR appear for all instances of communications or do they happen at random points
  • In case of random NDRs find the frequency of occurrence of NDR
  • The manner in which the recipient was chosen for the message( like from global address book, manual typing etc)

Once you get these basic information, fetch a copy of the NDR. Based on the NDR, check the User and Diagnostic Information.

Also make sure to note the delivery status notification code in the NDR and from the application event log keep the diagnostic logging of the message categorizer at level 7 / Expert level and obtain the application logs.

For the codes in the NDR, we can refer following table to troubleshoot accordingly and to find the cause.

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-Mailboxcmdlet. 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.  

Take a look at these Additional Information:

Using NSlookup:

http://support.microsoft.com/kb/200525

Using Telnet:

http://support.microsoft.com/kb/153119

EHLO Verbs between two Exchange servers:

http://support.microsoft.com/kb/812455

List of SMTP Verbs:

http://smtpfilter.sourceforge.net/esmtp.html

Enabling Protocol Logging on the Receive/Send Connector

http://technet.microsoft.com/en-us/library/bb124531.aspx

Definition of Queue : Queue Viewer

http://technet.microsoft.com/en-us/library/bb125105(v=exchg.65).aspx

Error Codes for NDR: Please refer to the KB 2297581

Ratish Nair

Microsoft MVP | Echange Server

Team @MSExchangeGuru

Keywords: How to troubleshoot mailflow issues, unable to send receive emails, exchange server mailflow issues.

25 Responses to “Exchange Server – Troubleshooting internal/external mail flow issues”

  1. Kottees Says:

    Hi Rathish,

    This is just awesome. Thanks for sharing such good troubleshooting steps.

  2. abhishek kiran Says:

    Wonderful article..

  3. Mohaseen Says:

    Very helpful thread, most of the e-mails issues are been covered, thanks…

  4. Blog Posts of the Week (28th July'13 - 03rd August'13) - The South Asia MVP Blog - Site Home - TechNet Blogs Says:

    […] Exchange Server – Troubleshooting internal/external mail flow issues […]

  5. Srimaya Says:

    Just Wow!!! Nicely described…..

  6. Anand Says:

    Rathish,

    Well prepared and very user friend and interactive article. I will be in touch for any query.
    Is your email id team@msexchangeguru. Please share if you have alternate email id.

  7. Prabhat Nigam Says:

    Hi Anand,
    We would recommend you to post the issues below the blog and we will try to answer your concerns. If at all we would need any information like log files or something else we will ask you to email with our email id.

  8. Junaid Ahmed Says:

    wow ! worked for me (:

  9. Akash Rajput Says:

    I have an issue in my exchange setup that users are unable to connect to mailbox through outlook but OWA is working fine. Could you please help me?

  10. Rajneesh Says:

    Mail delivery timeout/delay delivery, could it be issue due to Time Syncing within domain. I am having these issues from last few days from Apps Server, they are UNIX/Linux server. Normal mail delivery working fine, and no timeout/delay issue reported for that. I just sync the time on DC with external time source few days back. since then we are having this issue, nothing has change on any of the Exchange server. Any idea?

  11. Karthik Reddy Says:

    Only a true lover of exchange can take so much of pain and time to post for others….thanks a ton

  12. Colin Says:

    This fixed our problem. Thanks a lot!!!!

  13. Avdhesh Says:

    Very good article, Ratish.

  14. Steve T Says:

    Question on troubleshooting anonymous smtp relay in Exchange 2013:

    I have 2 CAS only servers. I’ve setup anonymous smtp relay on both servers and only works on 1 server. I created a custom receive connector for both servers. Permission are set for anonymous, bindings are set for a specific IP address, the Role is Frontend Transport, I’ve also ran the Get-ReceiveConnector “server\relay.domain.org” | Add-ADPermission -User ‘NT AUTHORITY\Anonymous Logon’ -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient command for this particular receive connector. I can send email internally, but I can’t send externally with the receive connector on the second CAS server. I turned on verbose logging and this what I get:

    2014-05-19T23:41:05.637Z,,08D141CEDD54FE1E,1,127.0.0.1:25,127.0.0.1:22069,>,421 4.3.2 Service not available,
    2014-05-19T23:41:05.637Z,,08D141CEDD54FE1E,2,127.0.0.1:25,127.0.0.1:22069,-,,Local
    2014-05-19T23:43:51.275Z,,08D141CEDD54FE3B,0,127.0.0.1:25,127.0.0.1:22309,+,,
    2014-05-19T23:43:51.275Z,,08D141CEDD54FE3B,1,127.0.0.1:25,127.0.0.1:22309,>,421 4.3.2 Service not available,
    2014-05-19T23:43:51.275Z,,08D141CEDD54FE3B,2,127.0.0.1:25,127.0.0.1:22309,-,,Local
    2014-05-19T23:44:04.433Z,,08D141CEDD54FE3C,0,127.0.0.1:25,127.0.0.1:22321,+,,
    2014-05-19T23:44:04.433Z,,08D141CEDD54FE3C,1,127.0.0.1:25,127.0.0.1:22321,>,421 4.3.2 Service not available,
    2014-05-19T23:44:04.433Z,,08D141CEDD54FE3C,2,127.0.0.1:25,127.0.0.1:22321,-,,Local
    2014-05-19T23:44:07.933Z,,08D141CEDD54FE3D,0,127.0.0.1:25,127.0.0.1:22328,+,,
    2014-05-19T23:44:07.933Z,,08D141CEDD54FE3D,1,127.0.0.1:25,127.0.0.1:22328,>,421 4.3.2 Service not available,
    2014-05-19T23:44:07.933Z,,08D141CEDD54FE3D,2,127.0.0.1:25,127.0.0.1:22328,-,,Local
    2014-05-19T23:44:11.120Z,,08D141CEDD54FE3E,0,127.0.0.1:25,127.0.0.1:22338,+,,
    2014-05-19T23:44:11.120Z,,08D141CEDD54FE3E,1,127.0.0.1:25,127.0.0.1:22338,>,421 4.3.2 Service not available,
    2014-05-19T23:44:11.120Z,,08D141CEDD54FE3E,2,127.0.0.1:25,127.0.0.1:22338,-,,Local
    2014-05-19T23:45:14.156Z,,08D141CEDD54FE4B,0,127.0.0.1:25,127.0.0.1:22454,+,,
    2014-05-19T23:45:14.156Z,,08D141CEDD54FE4B,1,127.0.0.1:25,127.0.0.1:22454,>,421 4.3.2 Service not available,
    2014-05-19T23:45:14.156Z,,08D141CEDD54FE4B,2,127.0.0.1:25,127.0.0.1:22454,-,,Local
    2014-05-19T23:46:05.706Z,,08D141CEDD54FE54,0,127.0.0.1:25,127.0.0.1:22511,+,,
    2014-05-19T23:46:05.706Z,,08D141CEDD54FE54,1,127.0.0.1:25,127.0.0.1:22511,>,421 4.3.2 Service not available,
    2014-05-19T23:46:05.706Z,,08D141CEDD54FE54,2,127.0.0.1:25,127.0.0.1:22511,-,,Local

    I’ve recreated this receive connector several times and still get unable to relay externally.

  15. Steve T Says:

    My default receive connector was alterned. Microsoft said not to change it. That fixed the issue.

  16. Tomek Says:

    For all seeking remedy for emails stuck in submission queue on Exchange 2007 – not all emails, just few selected ones, mainly with attachments (unfortunately these are most important). Check event logs for ID 1050. If you see “The execution time of agent ‘Transport Rule Agent’ exceeded 300000 (milliseconds) while handling event ‘OnRoutedMessage’….” – disable all Transport Rules you can under Organization Config. – Hub Transport. I was trigger-happy at fighting spam this way, but my server couldn’t take the load of rules and exceptions. Figuring it out made me sick of stress. Once I disabled 90% of my rules, mail flow returned. Next night I’m finally going to sleep well.

  17. Prabhat Nigam Says:

    Thank you for sharing your issue and resolution.

  18. Anil Says:

    Some times mails are bouncing back from one particular domain and getting below NDR message.

    # #SMTP#

    Kindly suggest.

  19. Prabhat Nigam Says:

    Where is the NDR?

  20. Shiv Says:

    Thank you Ratish

  21. chandran Says:

    excellent…simply superb..

  22. Jatin kakkar Says:

    hi Prabhat,

    Need one information on Public Folder as :

    99% of the PF data has been synced to the cloud, except of one content in the below folder which is approximately 77 MB was not copied as it was exceeded the message size.

    “A large item was encountered: Item (IPM.Note) Subject:””, Size: 77.2 MB (80,953,425 bytes),

    what should be best possible solution for fixing this

    Thank You

  23. Ishan Says:

    Mind Blowing !!

    Thankful to you 🙂

  24. Mohammed Says:

    Thanks for share information.
    I have issue that i am not able to receive emails from specific domains. also There is no NDR and NO log in Smtpreceive logs

    Thankful

  25. Prabhat Nigam Says:

    NDR would be there on the sender side or mails might be in the queue.
    Another place to check is your spam guard >> quarantine folder

Leave a Reply

ad

Categories

Archives