HELO has no matching DNS entry

We recently got an undeliverable message in response to an email a user tried to send.  It says:

Your message was rejected by this user and was not delivered. Reason: Messages from your location are rejected, identification (HELO) has no matching DNS entry. Protection provided by: MagicMail version 3.0 For more information, please visit the URL: http://www.linuxmagic.com/best_practices/resolve_helo_domain.html or contact your ISP or mail server operator. 1bb22856-ac5e-11e8-a57d-005056bbe21e

All other mail seems to be flowing fine, and this is the only rejection we've received.  From what I have researched and found so far, it looks like the cause of the issue is that the Exchange (2010) server is showing an incorrect SMTP banner of servername.domain.local.  And when I look in the EMC under Organization Configuration > Hub Transport > Send Connectors > External Mail Connector, the "Specify the FQDN this connector will provide in response to HELO OR EHLO" field is empty.  I assume I just need to enter our public SMTP server address here.  

This is my guess as to how to fix this problem, but since I'm not sure I'm hesitant to make this change.  Can anyone verify, or point me in a new direction if this is not accurate?
fallriverelectricAsked:
Who is Participating?
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.

Adam BrownSr Solutions ArchitectCommented:
That sounds about right for that fix. Note that this should be the port 25 receive connector that you are changing.
0
fallriverelectricAuthor Commented:
It's the only connector I have listed in that specific location - is that location correct?
0
Adam BrownSr Solutions ArchitectCommented:
Sorry. I misread the location you have there and misunderstood the problem. Yes, the send connector would be what you need to change. You may also need to get a reverse DNS lookup configured on your public IP address for the email to go through. That has to be done by your ISP, but they should be willing to make the change if you call them.
0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

fallriverelectricAuthor Commented:
I also see an option in EMC under Server Configuration > Hub Transport > Receive Connectors and there is one that is "Client Exchange" with port 587, and another one that is "Default Exchange" with port 25.  This one does list the servername.domain.local - are you saying this is the correct spot to change it, and not the first place I mentioned where the field was blank?
0
fallriverelectricAuthor Commented:
I did also have the same thought about my ISP and called them prior to opening this question.  They said they could not do anything for us but it's possible they misunderstood the question.
0
Adam BrownSr Solutions ArchitectCommented:
The original send connector spot that is blank is where you need to change it.
0

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
fallriverelectricAuthor Commented:
Ok, I will give it a try.  And my understanding is that a reboot is required before it will take effect - also correct?
0
Hypercat (Deb)Commented:
No reboot, but you need to restart the Microsoft Exchange Transport service.  If you can, it would be advisable actually to restart all of the Exchange services after making this change.  You can do this by finding the Microsoft Exchange Active Directory Topology service and restarting that, which will restart all the other necessary Exchange services.

BTW, the reverse DNS lookup, otherwise known as a PTR or rDNS record, does need to be created by your ISP if you don't already have one. That doesn't seem to be what caused the problem you're facing, but it could cause problems if you don't have it in place.  You can check it yourself by going to MXToolbox.com and running a test against your domain there.
0
Hypercat (Deb)Commented:
OOPS! - to do a lookup for a PRT/rDNS record you have to put in your public IP address, not the domain name, and then select "Reverse Lookup" from the orange drop-down list.
0
fallriverelectricAuthor Commented:
When I check the reverse DNS in MXToolbox, I see the correct result I would expect to see.  

I will make the send connector change after close of business tonight.
0
footechCommented:
As verification, you can see what SMTP banner you're using when sending by sending an email to helocheck@abuseat.org and you will get a reply with the info.  See here for info:  https://www.abuseat.org/helocheck.html

If you send and receive email from different IPs, the FQDN used in the banner should match an A record which points to the IP used to send.
0
fallriverelectricAuthor Commented:
I tried sending an email to the address you indicated and got a rejection:

emmex.spamhaus.org gave this error:
*** The HELO for IP address x.x.x.x was 'server.domain.local' (valid syntax) ***

I guess that just reaffirms the need to update the banner?
0
Hypercat (Deb)Commented:
Oh yes, definitely.  Your banner has to match your public FQDN for the email server, not a ".local" address.
0
fallriverelectricAuthor Commented:
I have applied the change to the SMTP banner in the send connector, and sending another test email to helocheck@abuseat.org now shows the changed address.  Do I assume at this point that all is well?  I will also send another email to the original email address that started us investigating this issue in the first place, but I'm not sure how else to know for sure that it's all working the way it should be.
0
footechCommented:
"All is well" is a bit too broad for us to say.  We can only give recommendations on the info provided, but it appears your SMTP banner issue is corrected.
0
fallriverelectricAuthor Commented:
Thanks to everyone for the insights.
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.