DNS and Exchange 2007-HELO\EHLO Test Fails

Hello,

I have a problem with exchange 2007 and HELO/EHLO verification. When I do an SPF check at http://www.kitterman.com/spf/validate.html  it is showing that my HELO test fails (HELO/EHLO Results - FAIL Message may be rejected) I am confident that the settings in exchange are correct, our SPF record and our reverse DNS are also correct and when I telnet into the exchange server it gives me the correct HELO address (remote.domain.com). The only cause I can think of for this is that we are on BT Broadband which crashed yesterday and when it came back up our IP address had changed. The first we knew about it was when people were not receiving my emails and I think this is because of this HELO test fail.  I am hoping this will resolve itself when DNS updates are complete. Is this assumption correct? Or is there any further action I need to take on the exchange server?

Thanks
LVL 1
DeclaroAsked:
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.

Paul MacDonaldDirector, Information SystemsCommented:
That seems very likely.  Can you force DNS updates or do you have to wait for your ISP to do it for you?
0
.Commented:
This can also happen if your ehlo statement does not match your PTR, if you was ever successful in getting BT to set this....
0
PapertripCommented:
Keep in mind that HELO mismatch does not mean you mail will be rejected.  Any receiving server that rejects a mail based purely on that is not RFC compliant.

You said your DNS records match, but that your external IP may have changed?  Can you telnet to the IP that you expect it to be on?  This should be able to be solved relatively easily...  either you are still listening on that IP or you are not.

What are the DNS updates that you mentioned you are waiting for?
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

PapertripCommented:
My apologies I misread a key part of your question.

Goto http://network-tools.com/ and put in your hostname and IP and see if your changes have been pushed out yet.  Depending on the TTL of those records before you updated them will determine the maximum amount of time you will have to wait for full propagation of the new records.  Any servers that didn't have the old result cached will only see the updated records.
0
DeclaroAuthor Commented:
External IP now matches again and I can telnet into the server, when I do and type HELO or EHLO I get the response of remote.domain.com which is what I'd expect

i did get BT to change the reverse DNS and it is correct

SPF is v=spf1 mx -all and only the exchange server sends mail through DNS not a smarthost, the MX record for the domain is remote.domain.com and there is an A record for the entry which resolves to the servers IP address with my hosting company

I wouldn't know if I could force a DNS update, I presumed it would just take up to 72 Hours to update DNS servers over the internet or do I have to do something to the DNS on my SBS2008 server

Hope this extra information helps shed some light on this, if you need to know any more let me know.

Thanks for the help so far.
0
PapertripCommented:
I wouldn't know if I could force a DNS update, I presumed it would just take up to 72 Hours to update DNS servers over the internet or do I have to do something to the DNS on my SBS2008 server
Depending on the TTL of those records before you updated them will determine the maximum amount of time you will have to wait for full propagation of the new records.  Any servers that didn't have the old result cached will only see the updated records.

So, unless you had an obnoxious TTL that is greater than a day, your changes are probably propagated everywhere by now.  Send some test mails to a Gmail account and look through the headers for results of all the Authentication checks.
0
DeclaroAuthor Commented:
I'll give it 24 hours to see if the issue resolves itself properly

Thanks for your help so far, I'll keep you updated.

Dave
0
PapertripCommented:
No need to wait, you can just query your authoritative servers to see what they have.

Goto http://www.kloth.net/services/dig.php

1.  Put either your hostname or IP into the Domain box, change Query type to NS, and that will tell you your authoritative nameservers.

2.  Put either your hostname or IP into the Domain box, change Query type to either A or PTR depending on what you put into Domain, then put the your nameserver into the Server box.

That way you don't have to worry about the TTL, because you are getting a "fresh" result and not a result from cache.  That assumes of course your nameservers aren't allowing cached results for domains they master to external queries -- that would be very not smart if they did!
0
DeclaroAuthor Commented:
That all appears to be correct but when I test the SPF record on here... http://www.kitterman.com/spf/validate.html using the correct IP address, SPF, email address and HELO it says the HELO failed and emails may be rejected, do you think it's simply because the site uses cached DNS data and it will resolve itself when it's fully updated, I will be honest I use that site because it's easy to understand how to do the tests :)

Thanks for your time and patience Papertrip
0
PapertripCommented:
That is quite possible.  An easy way to determine if that testing tool is using old cached data is to query your NS to find the TTL like I explained in my previous post.  

If, for example, the TTL is 300 (5 minutes), then that server shouldn't cache the old information for more than 5 minutes.  If however your TTL is like 172800 (48 hours), then you are almost definitely hitting a cached result in this case.
0
DeclaroAuthor Commented:
Ahh, lightbulb moment LOL TTL on my nameserver is 12 hours... so should be showing as correct but alas the HELO still says its failing, i'm still hoping it's a propogation thing and it will right itself.

I can't thank you enough for taking the time tonight to help out with this problem, it's appreciated, I owe you a beer.

If you have any other thoughts on the issue i'd gladly hear them, if not i will award the points as deserved.

Cheers

Dave
0
PapertripCommented:
I can't thank you enough for taking the time tonight to help out with this problem, it's appreciated, I owe you a beer.
Fat Tire please! ;)

Just to be clear, you completed both steps 1 and 2 of my earlier suggestion, right?  Just making sure you are looking at the TTL of A/PTR record as opposed to the TTL of the NS record(s) itself.

If you could provide me with your hostname and/or IP of your mail server, I can check all of this for you very easily.  I understand you may be hesitant to post that information, but I must say that all questions I've had of this sort have been quickly resolved by providing that information so I can test it all myself.

If I were in your situation, I would give me the info.  Up to you!
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
DeclaroAuthor Commented:
not so sure if i did do it right now :)...
mydomain1.com xxx.xx.xx.251

also hosting mydomain2.com and mydomain3.com

cheers
0
DeclaroAuthor Commented:
And mines a Bathams :D
0
PapertripCommented:
[root@broken ~]# dig txt mydomain1.com +short
"v=spf1 mx -all"
[root@broken ~]# dig txt mydomain2.com +short
"v=spf1 mx ip4:xxx.xx.xx.251 -all"
[root@broken ~]# dig txt mydomain3.com +short
"v=spf1 mx ip4:xxx.xx.xx.251 -all"

Open in new window

Make those look like
"v=spf1 ip4:xxx.xx.xx.251 -all"

Open in new window

I'm leaving that as a hardfail since you probably won't have DKIM working right away.  That is the only sending IP correct?


DNS is fine.  You do however have a 1 day TTL on the PTR record which could have given you false positives in earlier tests.
[root@broken ~]# dig @ns1.livedns.co.uk remote.mydomain1.com +short
xxx.xx.xx.251
[root@broken ~]# dig @ns2.livedns.co.uk remote.mydomain1.com +short
xxx.xx.xx.251
[root@broken ~]# dig @ns3.livedns.co.uk remote.mydomain1.com +short
xxx.xx.xx.251

Open in new window

[root@broken ~]# dig @rbsdns01.bt.net -x xxx.xx.xx.251 +short
remote.mydomain1.com.
[root@broken ~]# dig @rbsdns02.bt.net -x xxx.xx.xx.251 +short
remote.mydomain1.com.
[root@broken ~]# dig @rbsdns03.bt.net -x xxx.xx.xx.251 +short
remote.mydomain1.com.
[root@broken ~]# dig @rbsdns04.bt.net -x xxx.xx.xx.251 +short
remote.mydomain1.com.

Open in new window



From my tests, everything checks out.  Since the tool you were using was only complaining about HELO, I ran it through another online test and it checks out, which matches everything I verified myself.

You should be good to go.
0
DeclaroAuthor Commented:
I've changed the SPF records and yes you're right, it is the only IP that is sending mail for the domains

I haven't posted many questions on here but everytime I have I've had great help from friendly people and this time is no exception...

Thanks Papertrip :) You're a star

Dave
0
PapertripCommented:
Woops the link I posted for mxtoolbox should be http://mxtoolbox.com/SuperTool.aspx?action=smtp%3aremote.mydomain1.com
0
PapertripCommented:
Hah hey man no problem.  The main reason I initially joined EE last month was to help primarily with mail and DNS issues, which I have extensive experience with.  There is so much bad information out there... I felt compelled to help clean that up.
0
DeclaroAuthor Commented:
I haven't added the question to the KB because of the info that is in the answers, definately not because of the quality of the help which was excellent
0
unluckynelsonCommented:
I don't believe this has anything to do with SPF settings in your DNS, although those are necessary.
You will always get spf failures if you are on a dynamic IP range. Mail servers HAVE to be on a fixed IP all time!
Apply for a fixed IP from your ISP and all your mail problems will go away...

Joe
0
DeclaroAuthor Commented:
Hi Joe,

The IP is static and all was fine until BT's authentication servers blew up blacking out most of the UK BT broadband network, when it came back up nothing worked correctly and i noticed they had changed the IP on us which I think caused the problems

Thanks
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
DNS

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.