In this article we’re going to look at troubleshooting email delivery problems from external senders, focusing on SMTP connectivity. To begin with we’ll use a simple scenario of an external sender emailing a person in the organization. This organization is very simple, with just a single Exchange server receiving email directly from the internet via the firewall.
For reports of email that has gone missing in transit I generally start my search closest to the source. In this case that would mean taking an “outside in” approach to troubleshooting the SMTP connectivity from external senders.
Usually the external email server is one that you will have no access to for troubleshooting, but that doesn’t mean you can’t do your own external testing.
- Are your MX records configured correctly?
- Is your firewall accepting connections on TCP port 25, and NATing them to the Exchange server?
- Is your Exchange server accepting connections on TCP port 25? Protocol logging is useful for looking at this on the Exchange server.
- Is your Exchange server accepting email submissions? A common issue here is back pressure.
You can test each of those things individually with simple tools like Telnet and nslookup, but during the initial investigation one quick way to test all of them is to use the Inbound SMTP Email test from the Remote Connectivity Analyzer. Send yourself an email from the RCA, which will actually send one email to each of your MX records (so if you have two MX records you’ll receive two test messages, and so on).
A successful inbound SMTP test will confirm that an MX record can be found, an SMTP connection to that MX record was possible, and the test email was submitted successfully. It will also test your MX record for open relay issues. But don’t just assume a green tick is good. You still need to look at the results carefully.
- What if your MX record is pointing to the wrong DNS name? Perhaps you’ve recently changed MX records for a migration.
- What if that DNS name is resolving to the wrong IP address?
In more complex routing topologies you may also need to consider:
- What if the server it’s connecting to is your inbound email security appliance (or a cloud hosted service), not your Exchange server, and the emails are getting stuck there?
- What if the inbound SMTP connections are being load balanced, and the test happens to have been load balanced to a healthy server instead of an unhealthy server?
You’ll be able to answer some of the above simply by the fact of whether the test email messages arrived in your inbox or not. If they did not arrive then clearly there is a problem somewhere that needs further investigation. For example, you may need to look in the logs or queues of your email security appliance/service.
If the test email messages did arrive, you can check the message headers to verify that they took the route you were expecting and that there were no significant delays.
If the test email has not arrived, and you’ve eliminated all of the potential causes above (MX records, firewall ports) then you can also check the protocol logs on the Exchange server itself to confirm that the SMTP connections are hitting the Exchange server, and whether the Exchange server is accepting or rejecting them. Protocol logging needs to be enabled on each receive connector on the server that you want to log for troubleshooting purposes. My tip here is to always enable it so that you have the log data already being generated when it comes to troubleshooting scenarios.
- Troubleshooting Email Delivery with Exchange Server Protocol Logging
- Configuring Unique Receive Connector SMTP Banners in Exchange Server (also a useful tip by Jeff Guillet)
You can use the protocol logs to verify any combination of problem scenarios, such as:
- Inbound SMTP from all external senders is working (i.e. no rejections or SMTP errors visible in the protocol logs for that time/date)
- Inbound SMTP from some external senders is working (i.e. you can see successful connections for some senders, but not for the sender that was reported to you in the support ticket)
- Inbound SMTP is not working for any external senders (i.e. the ExRCA test and all other inbound SMTP traffic seems to be getting rejected with errors, or not connecting at all which may be due to DNS or firewall issues)
Assuming that inbound SMTP connections look healthy you can progress onto other troubleshooting such as message tracking.
I get the following message.. Everything before was a green tick..
Can you advise??
The server returned status code 530 – The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM
Exception details:
Message: The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM
Type: System.Net.Mail.SmtpException
Stack trace:
at System.Net.Mail.MailCommand.CheckResponse(SmtpStatusCode statusCode, String response)
at System.Net.Mail.MailCommand.Send(SmtpConnection conn, Byte[] command, MailAddress from, Boolean allowUnicode)
at System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, Boolean allowUnicode, SmtpFailedRecipientException& exception)
at System.Net.Mail.SmtpClient.Send(MailMessage message)
at Microsoft.Exchange.Tools.ExRca.Tests.SmtpMessageTest.PerformTestReally()
cómo solucionarlo en mi bb
Thank you very much for contributor.
Please kindly guilds is.
1.We have exchange 2013 =4 Servers.
1.1 CAS = 2 server a
1.2 DAG mailbox server roles =2
2.firewall NAT policy.
2.1 NAT CAS Internet facing protocol TCP 80,443,25
Question.
Firewall NAT policy is enough for smtp CAS external smtp?
in the paragraph….
You can test each of those things individually with simple tools like Telnet and nslookup, but during the initial investigation one quick way to test all of them is to use the Inbound SMTP Email test from the Remove Connectivity Analyzer. Send yourself an email from the RCA, which will actually send one email to each of your MX records (so if you have two MX records you’ll receive two test messages, and so on).
I think this should be Remote Connectivity Analyzer.
Fixed, thanks.