• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1705
  • Last Modified:

Reverse DNS for email record

Hello Experts - I've been having a problem getting email delivered to some destinations and suspect an issue with reverse DNS lookups on my mail record.  I have two mail records:

mx1.spiezle.com
mx2.spiezle.com

When I ping mx1 I get 64.235.154.66.  If I do a ping -a for 64.235.154.66 instead of resolving back to mx1.spiezle.com it goes to mail.ess.barracuda.  Same story for mx2.  From my understanding if it was setup properly the name should resolve to either mx1 or mx2 rather than the barracuda address.  Is this correct?  Could this be causing the following error found on the barracuda for some destinations?

#< #4.0.0 X-Spam-&-Virus-Firewall; connect to mxi7p.craigslist.org[208.82.236.86]: server refused mail service> #SMTP#

If that is indeed the problem what would need to be done to correct it?  Many thanks in advance!
0
danbrown_
Asked:
danbrown_
  • 5
  • 3
  • 2
  • +1
1 Solution
 
Zephyr ICTCloud ArchitectCommented:
Might be your PTR record yes ... In other words reverse DNS not matching your domain.

Might be something else as well, but I'd start with that.

Remember to check mxtoolbox.com to test your DNS/SMTP setup...
0
 
danbrown_IT ManagerAuthor Commented:
mxtoolbox.com claims reverse DNS is working properly but I don't see how if, when I do a ping -a, it returns a different address that what the initial ping to mx1.spiezle.com shows:

      SMTP Transaction Time      6.193 seconds - Warning on Transaction Time       More Info
      SMTP Reverse Banner Check      OK - 64.235.154.66 resolves to mail.ess.barracuda.com
      SMTP Reverse DNS Mismatch      OK - Reverse DNS matches SMTP Banner      
      SMTP TLS      OK - Supports TLS.      
      SMTP Connection Time      1.544 seconds - Good on Connection time      
      SMTP Open Relay      OK - Not an open relay.
0
 
Zephyr ICTCloud ArchitectCommented:
When I do a diagnostics test on mxtoolbox it shows me the SMTP Reverse DNS Mismatch - warning ...

But I am using the spiezle.com domain, not the mx.spiezle.com directly...

Strange result though:

220-gator3037.hostgator.com ESMTP Exim 4.82 #2 Mon, 14 Apr 2014 09:54:47 -0500 220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail.

Test      Result      
      SMTP Reverse DNS Mismatch      Warning - Reverse DNS does not match SMTP Banner       More Info
      SMTP Reverse Banner Check      OK - 50.87.150.232 resolves to 50-87-150-232.unifiedlayer.com
      SMTP TLS      OK - Supports TLS.      
      SMTP Connection Time      0.780 seconds - Good on Connection time      
      SMTP Open Relay      OK - Not an open relay.      
      SMTP Transaction Time      3.167 seconds - Good on Transaction Time
0
SMB Security Just Got a Layer Stronger

WatchGuard acquires Percipient Networks to extend protection to the DNS layer, further increasing the value of Total Security Suite.  Learn more about what this means for you and how you can improve your security with WatchGuard today!

 
danbrown_IT ManagerAuthor Commented:
Ok, when I ran it again against the domain I got the same results.  So clearly this is a misconfiguration that I need to cleanup.

When I ask network solutions to make a DNS change how would I phrase it so they perform the correct operation?
0
 
footechCommented:
Your MX records have nothing to do with sending email, so there is nothing to be concerned about with any mismatch of PTR records in that regard.  You can receive email on totally different IPs than those you send email from.  So for sending email, it is important that the IP that you are sending from has a PTR record that refers to a FQDN, and there should be an A record for that same FQDN that points at the IP the email originates from.  When you're sending from the same IP that you receive on, then your MX record will also reference this same FQDN.

Next, the SMTP banner should also be set to the same FQDN mentioned above.  Depending on your email system, testing sites like MXToolbox will falsely report a mismatch because of how they test (this occurs with Exchange 2007 and up).  A better check is to follow the instructions at http://cbl.abuseat.org/helocheck.html
0
 
SandyCommented:
Agree with  footech :D

TY/SA
0
 
danbrown_IT ManagerAuthor Commented:
Hi Footech - thanks so much for the reply, I see what you are saying.  If I could trouble you to help me understand what needs to be done in order to stop some domains rejecting my emails I would really appreciate it.

My email domain is mail.spiezle.com.  The IP address that email comes to/from is 64.206.154.179 which is a Barracuda spam filtering appliance.  When I ping mail.spiezle.com it correctly resolves to 64.206.154.179 but what I do a ping -a for that IP it resolves to mx1.spiezle.com.  Is this the problem area?  From what I've read it looks like a ping -a against .179 should resolve to mail.spiezle.com instead of mx1.spiezle.com.  Sound right?
0
 
footechCommented:
Not sure what you mean when you say your email domain is "mail.spiezle.com".  Typically this means that all your email addresses would be in the form of "XXX@mail.spiezle.com".  If your addresses are in the form of "XXX@spiezle.com" then your email domain is "spiezle.com".

If you performed the HELO check as instructed and you got back an email that said your HELO for IP 64.206.154.179 was "mail.spiezle.com", then yes, the PTR record for 64.206.154.179 should reference "mail.spiezle.com".  You should contact your ISP (not your domain registrar or host) to have this changed.
0
 
danbrown_IT ManagerAuthor Commented:
I actually get back barracuda.spiezle.com when I ran the HELO check.  Would I just ask the ISP to change this to mail.spiezle.com?  How can I confirm who is holding the DNS record for this?
0
 
footechCommented:
PTR records are controlled by your ISP (with few exceptions).  Your other DNS records (A, MX, CNAME, etc.) are managed elsewhere, like Network Solutions.  You should be able to log in and change your own DNS records.  There's no need to change the SMTP banner reported by the HELO check.
0
 
danbrown_IT ManagerAuthor Commented:
Wonderful, thank you so much!
0

Featured Post

[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

  • 5
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now