I have a pretty common error that I get asked about pretty frequently. I wanted to take a moment to hopefully share some information on what the error is, what to focus on, and what tools you need to fix and monitor.
First of all, please understand this paper covers the simplest of scenarios. Multiple sites, Smart Hosts, Bridgeheads, and multiple Accepted Domains will quickly muddy the waters, but for a basic Exchange Server, This Article Applies directly.
Exchange Server 2013 SMTP banner does not match reverse lookup. or
Warning – Reverse DNS does not match the SMTP Banner
First be aware, there is a lot of misinformation out there. Stop and read and understand, before you decide which articles are telling you the truth. This error is likely to pop up in a few situations. I wanted to take a minute to clarify this message and what is needed to clear this up.
First you must understand this error is directional and relative to a point in mail flow. So you really have to nail down your situation before you set out on solving the problem. You risk getting yourself more confused. Speaking of that, let me try to hopefully explain in a simple way.
First let me say the SMTP Banner is more generally a problem for outbound mail. You may still get an error for inbound connectors, but mail will not usually fail either. Internal mail uses Internal banner (host) and DNS, and external mail uses External Banner and DNS. An error comes about, generally where you have mail received across the public internet, where a reference is made to an internal FQDN in the SMTP Header.
So if you think you have an inbound banner issue, just go into your inbound mail connector, and then try to save it, without making changes. If there is a problem, you should get a pop up message similar to figure A
Figure A. Inbound Banner issues are identifiable
Exchange will promptly give you an error when your inbound connector has a banner issue. Why you ask? Because the Banner is checked by Exchange, against the security settings. Think of it like a security Guard. They always check you coming in, but once you have cleared security, it is not as difficult to leave.
So I won’t go into the explanation of inbound banners, except to say, by the time your mail hits this server, the lookup is internal, so the Banner should always be internal. In addition, you have a server, with a certificate, matching this FQDN, so it should make sense that these should all be the same name. Do what the error says and set the Banner to the Internal FQDN.
Outbound is really the same sort of thing, for any outbound Internal Connectors. Internal connector, Internal FQDN. The change comes when you have an outbound Internet connector. So this connector will be the banner for your reverse look ups by external recipients. That is, unless you have a third party device doing store and forward for you, in which case, you should be able to set the SMTP banner there as well. Assuming you don’t use a smart host, your Send connector header would look like this:
Figure B. Send Connector Scoping Tab.
This should make sense. You see this is the external facing send connector. Once mail leaves this connector, the mail will be called External Mail. From this point mail will have to rely on MX, DNS or a Smart host to propagate.
So.. What do you think gets queried for the reverse lookup? The mail server at the destination Is going to query public records it finds, against the header and other information it has received, when it looks your mail domain up. So the checks done include reverse lookup, Public MX record, A record, Text Record and SPF record. So all you need to do to is make sure these records contain your correct Public IP address for your Exchange server, the correct resolution of the Banner to an IP address, and verify the other records contain the same Name and or IP addresses.
A light conversation
So now we get to brass tacks. So I want to focus you to the main things you would need to set correctly. This is:
- Public MX record -Domain.com resolves to target mail.domain.com at PUBLIC IP address
- An “A Record” that is the value of the Banner “Mail.domain.com”
- An “A record” for values for your setup like “auto-discover.domain.com”
- TXT or (PTR) record for your Reverse Lookup DNS record. One domain should be assigned to one PTR record- this is what should match the “send” banner
- SPF record. – . Special record with special format for Domain verification by Anti-Spam. SPF record tool will help generate your record
Tools you can use to make sure your records are correct:
- Install Dig on your client machine for windows- Dig -x Public IP (will find your PTR record)
- Dig domain.com will give you your “A” record.
- Dig mail.domain.com txt – will show your SPF record.
- Dig mx domain.com to query MX record, or Dig @nameserver.domain.com yourdomain.com
So with this Dig tool, you can check and cross check. If you have an IP address in this mix, that you are not aware of, or are not using, then you will need to fix this.
I am not going into too much detail here, but if you have all these records in place, and make sure they point to the public IP address, which sends the exchange server its mail, then you should be happy. Use the web site IPCHICKEN.COM on your Exchange Server. It will tell you your Public IP, normally used for Setting Public DNS records. For non-smart host or bridgehead customers, your value of IPCHICKEN, should be your Public IP values for these records.
You have the public information you need to set records above. Set this correctly. Second, go to Exchange Server and set the FQDN correctly and you should no longer have SMTP banner failing to match the reverse lookup:
- Send Connector Mail Flow -> Send Connector-> Scoping-> FQDN
- Receive Connector Mail Flow -> Send Connector-> Scoping-> FQDN
Make sure these FQDN matches its function. Internal connector is internal FQDN.
Send Connector is Public FQDN. Then make the Records match the correct public values and this issue will be resolved.
In closing Here are some tools you can use to troubleshoot:
Dig Bind Tool
MX Tool Box
I hope this is helpful and explains what you are seeing, and how you can fix your SMTP banner issue.