HELO has no matching DNS entry

fallriverelectric
fallriverelectric used Ask the Experts™
on
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?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
That sounds about right for that fix. Note that this should be the port 25 receive connector that you are changing.

Author

Commented:
It's the only connector I have listed in that specific location - is that location correct?
Adam BrownSenior Systems Admin
Top Expert 2010

Commented:
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.
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!

Author

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?

Author

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.
Senior Systems Admin
Top Expert 2010
Commented:
The original send connector spot that is blank is where you need to change it.

Author

Commented:
Ok, I will give it a try.  And my understanding is that a reboot is required before it will take effect - also correct?
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.
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.

Author

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.
Top Expert 2014

Commented:
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.

Author

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?
Oh yes, definitely.  Your banner has to match your public FQDN for the email server, not a ".local" address.

Author

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.
Top Expert 2014

Commented:
"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.

Author

Commented:
Thanks to everyone for the insights.

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