HELO has no matching DNS entry
We recently got an undeliverable message in response to an email a user tried to send. It says:
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?
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?
Adam Brown
That sounds about right for that fix. Note that this should be the port 25 receive connector that you are changing.
ASKER
It's the only connector I have listed in that specific location - is that location correct?
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.
ASKER
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?
ASKER
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.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
ASKER
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.
I will make the send connector change after close of business tonight.
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.
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.
ASKER
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?
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.
ASKER
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.
"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.
ASKER
Thanks to everyone for the insights.