Reverse DNS does not match SMTP Banner

rhillsnap
rhillsnap used Ask the Experts™
on
MX Tools says my Reverse DNS does not match SMTP Banner.  I attached a screenshot showing my PTR and my banner, and they do match, unless I am missing something.
rDNS ScreenshotrDNS.docx
rDNS.png
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
DrDave242Principal Support Engineer
Commented:
The host and PTR records match, but it looks like your SMTP banner consists of a long string of asterisks (the text immediately following the "220" in the output above).
MASEE Solution Guide - Technical Dept Head
Most Valuable Expert 2017
Commented:
If you are running Exchange server you can ignore this. Dont make additional change to make mxtoolbox happy.
They are checking hostname added in your default receive connector.
Just make sure your external IP resolves to your external name and vice-versa that is enough. You can check using this.
https://mxtoolbox.com/ReverseLookup.aspx
David FavorFractional CTO
Distinguished Expert 2018

Commented:
Looks like problem is resolved now...

imac> dig +short snapex03.snapdrape.com a
173.74.102.77

imac> dig +short -x 173.74.102.77
snapex03.snapdrape.com.

Open in new window

Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

1. The 220***************** is probably some sort of firewall, altering the SMTP transaction. Cisco devices usually do that.
2. Mismatched rDNS and PTR name are VERY common, probably occurs more often than not. Provided you have some sort of PTR in place that does not look like a home connection, that should be fine.
Daniel McAllisterPresident, IT4SOHO, LLC

Commented:
Mismatched rDNS and PTR records are TOO common -- and the BIG mail vendors (Google [gmail], Microsoft [hotmail, outlook, msn], AOL [yes, they're still big -- don't know why, but they are!], and many others) are starting to crack down on this because of the spoofing that goes on to PURPORT to be from one domain, but really isn't.

*IF* you cannot fix this issue, then at least make sure your DMARC, DKIM, and SPF entries are enabled and correct. If you knock on Google's door, have no SPF, no DKIM, no DMARC, and your FCrDNS (Forward Confirmed rDNS) fails -- your mail will either be blocked altogether, or minimally dropped into recopients' Junk folders.

SMTP is one of the Internet's OLDEST protocols, and it openness to abuse is LEGENDARY. But the abuse is (and has been) out of control, and the big players are leveraging their market share to FORCE smaller players to play by the MODERN rules (ca. 2010 vs 1990!).

It appears to me that you're trying to "do the right thing" -- and that's not easy. Getting a mail server up and running properly is a hard enough task, but making it play well with others -- especially the "big boys" is another, separate but equally challenging task!

Good Luck

Dan
Principal Support Engineer
Commented:
Just to be clear, the "problem" being reported by MXToolbox is not that the server's DNS host and PTR records don't match. They do match, as nslookup or any other DNS lookup tool will show. In fact, the second screenshot shows that they match; see the green check next to "SMTP Reverse DNS Mismatch."

What the MXToolbox report is saying is only that the server's SMTP banner (the text it returns when another server connects to it in order to deliver a message) doesn't contain the FQDN in the server's PTR record. Since the PTR record is correct, no changes should be made to DNS. Instead, if you want this warning to go away, the SMTP banner is what needs to be changed, as it's currently just asterisks.

I don't really know how common it is for a sending server to check a recipient server's SMTP banner against its PTR record, so I can't say how important it is to fix this. It's almost certainly less important than fixing a host/PTR mismatch. On the other hand, I'm not sure obscuring the server's name in its SMTP banner actually accomplishes very much, so I can't think of a good reason not to fix it.
DrDave242Principal Support Engineer

Commented:
No response from asker. The solutions in these comments will resolve the issue.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial