Another NDR that we commonly see is the one below. In this post, I will walk through how to troubleshoot this NDR.
When Exchange routes an email, it first needs to determine whether the email is within the organization or not. If not in the organization, the email is passed onto the SMTP services to send the email. Each Send Connector on Exchange is configured to send email for a particular domain or for all domains (*). It's also configured with a cost and source server. Exchange uses this information to work out which Send Connector needs to be used to send the email.
When sending an email to an external recipient, Exchange either sends the email through a smart host or directly to the external recipient's mail server. If unable to resolve the IP of the smart host or the recipient mail server, Exchange reports the error above.
To troubleshoot, look at the recipient's domain in the NDR:
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.
The following organisation rejected your message: smtp.domain.co.uk.
Generating server: svr01.domain.co.uk
smtp04.domain.com #550-The domain in the email address 'email@example.com' does not 550 exist. Sorry. ##
Original message headers:
Received: from svr01.domain.co.uk ([fe80::35af:17b0:3c1f:1f34]) by
svr01.domain.co.uk ([fe80::35af:17b0:3c1f:1f34%19]) with mapi id
14.03.0224.002; Tue, 15 Sep 2015 22:19:42 +0100
From: Mark Gossa <firstname.lastname@example.org>
To: "email@example.com" <firstname.lastname@example.org>
Date: Tue, 15 Sep 2015 21:19:41 +0000
Accept-Language: en-GB, en-US
Here we can see that the email address that the sender has sent an email to is email@example.com instead of firstname.lastname@example.org. This is an obvious one but some are not so obvious. In which case, you will need to confirm if there are any DNS resolution issues on you server. To do so, check that you are unable to find any MX records for the domain while using a reliable DNS server. I tend to use Google's DNS servers for this purpose.
You can either check with nslookup or use the Resolve-DNS cmdlet if you are using PowerShell 3.0 or higher which is found in Windows 8 and Server 2012 and later.
The commands you need for nslookup are below:
The command you need if using Resolve-DNS are below:
Resolve-DNS -Type MX hotmail.co.ik -Server 18.104.22.168
If you find that these commands don't provide MX records for the recipient's domain and the email address is correct then it may be a problem with the recipient's DNS configuration where they no longer have a valid MX record or their name servers are unavailable.
If all email through this smart host is failing delivery with this error then check that the Exchange server can resolve the smart host IP. Some smart hosts don't automatically register their names in DNS when configured so you'll need to set one up.
If, however, you find that these commands provide MX records for the recipient's domain and your Exchange server has provided the above NDR then you will need to troubleshoot DNS. If you're not using a smart host then you need to troubleshoot DNS resolution on the Exchange server and if you are using a smart host then you need to troubleshoot DNS resolution from the smart host. In either case, use a methodical approach such as below:
- Run nslookup/Resolve-DNS commands on the smart host or Exchange server as applicable
- Run nslookup/Resolve-DNS commands on each DNS server configured in your smart host or Exchange server IP settings
- If a problem is found with any of the DNS servers, troubleshoot the DNS server then test the forwarders configured on the DNS server and troubleshoot if needed.
If your DNS server is not resolving the MX records correctly, it may be a problem with one of the below:
- DNSSEC lookups not configured on the firewall (eDNS0, larger packet size not configured)
- DNS server or forwarder has an incorrect MX or NS record cached for the domain. This may be a result of DNS poisoning.
- The DNS server is unable to contact its DNS forwarders or the root hints.
Hopefully you'll find the issue is either a problem with your DNS setup, the recipient domain name or the recipient DNS configuration.