Reverse DNS does not match SMTP Banner

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
rhillsnapAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

DrDave242Commented:
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).
0
MAS (MVE)EE Solution Guide - Technical Dept HeadCommented:
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
1
David FavorLinux/LXD/WordPress/Hosting SavantCommented:
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

0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Mal OsborneAlpha GeekCommented:
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.
1
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
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
0
DrDave242Commented:
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.
2

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
DrDave242Commented:
No response from asker. The solutions in these comments will resolve the issue.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.