Email Rejections due to Invalid Reverse PTR Record

We just purchased a Barracuda SPAM Filter to replace our old eSOFT Spam Filter appliance.  The SPAM Filter inspects messages and forwards them to our internal Exchange Server.  The SPAM FIlter sites on our LAN along with our Exchange Server, and both sit behind our Corporate Firewall.

Needless to say, every since I switched to the Barracuda, our email's are getting rejected by some Domains. For example, we can't send to "Comcast.net".  In our SMTP log on our Exchange server, I see an error regarding an invalid Reverse PTR record.   Our ISP hosts our DNS for our mail server, and I had them switch the hostname to resolve to the hostname of our Barracuda SPAM filter.  However, I still can't sent to comcast.  The emails are sitting in our Exchange server queue for up to 24 hours, and eventually we receive an NDR.  

Finally, according to some of the free DNS online tools, my MX record seems to resolve properly.  Any suggestions?
elecdaveAsked:
Who is Participating?
 
SteveConnect With a Mentor Network ManagerCommented:
You need to get your ISP to check the 'in-arpa' addresses for you.. you'll find that even though they've changed your DNS to resolve correctly.. the reverse DNS is still setup to the wrong name.. once they change that and restart their DNS it'll be fine..

0
 
elecdaveAuthor Commented:
PsychoFelix,

Thanks for your quick response.  Meanwhile, I'll contact our ISP this morning, but their's one other piece to this puzzle.  When I implemented the Barracuda, our internal Private IP Addressing scheme changes.  We went from a 169.254.92.0 to a 192.168.1.0  for our LAN.   Our internal DNS servers are are only servicing our AD domain, and they are acting as DNS forwarders for all external resolution.  You don't think that our internal DNS servers have anything to do with this issue, do you?  
0
 
MesthaConnect With a Mentor Commented:
Internal DNS would have nothing to do with this. It is purely down to how your server is seen by the internet. PTR records and preferably how the appliance announces itself, the SMTP banner or EHLO/HELO banner.

Simon.
0
 
elecdaveAuthor Commented:
I found my solution.  The issue was related to our Cisco ASA.  For some reason, the ASA NAT policies were not functional any longer.  We had seperate NAT policies for SMTP, POP and HTTS. For some reason STMP was redirecting out of hte default interface for packets that weren't specific to the NAT policies. Needless to say, we resolved the issue on our ASA and all is well.  Thanks again for your help.
0
 
elecdaveAuthor Commented:
Thanks again for all your help.  Since neither issue was correct, I split the points between the two experts who replied.  If I could, I'd give you both a million points just for your quick responses!!!
0
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.

All Courses

From novice to tech pro — start learning today.