DNS - A records for mail

[paul23]

I am hoping someone can offer a bit of clarification on dns zone settings, specifically for A records in regards to mail.

Specs: FC3 with Plesk 7.5 Reloaded using PSA out of the box
Issue: a number of large providers (Yahoo, Hotmail and the likes) have been tagging our email as spam/bulk mail even when it is just one recipient at a time sent either through webmail (either SquirrelMail or Horde) and POP using Outlook. This box is 1 years old and never sent an email campaign or any scripting mail from it.

Say you have a domain hosted on a shared ip called domain.com (ip 10.10.10.2) which is a different domain than the nameservers domain ns1.nameserver.com (ip 10.10.10.1) which is also the primary IP of the server.

Question: Does it matter if you point the mail.domain.com A record to the server ip address or to the shared ip address?

We have always pointed to the shared ip address but things were just not working so we ran a test pointing this A record to the server IP address and instantly our messages stopped being blocked.

I understand the best method is to setup the correct reverse records for our shared domains but for some reason our provider controls these reverse records and their naming convention for the reverse records do not point to domain.com but to 10-10-10-2.dedicatedhost.company.com (using the real ip address) but we think this ISP style domain is triggering the SPAM/Bulk filter.

Our reasoning this was triggering the filter:
Understanding the mail server is actually running on 10.10.10.1, the server ip address, and answers a telnet call to domain.com 25 as "10-10-10-1.dedicatedhost.company.com" (also the hostname). The querying mail server or the mail server performing the reverse lookup sees a mismatched name as to what it is expecting.

one last note, once we made this change a dnsreport query shows all mail record errors as resolved.

Can someone shed some light? I apologize if it seems I rambled on about nothing...

 

[faris]

This is interesting.

I don't think the IP of the sending server and the IP of where the hosting is need to be the same. It is extremely common for an email server to be on a different IP, so it would be madness to block on the basis that the MX points to a different IP than the one where the mail is coming from. E.g. a customer may send email via their dial-up/broadband ISP's mailservers, but host their domain with you. The IPs will be totally different.

But your tests seem to show that the IPs have to match. This is very odd. I don't see why/how. Do you have spf records? AOL seems to like them. Not sure about yahoo.

It is also common for rDNS not to match the hostname of the server. This one is easily fixed though -- just change the hostname to the rDNS, and set up a hosting account for that domain in Plesk. I'm not sure how important it is for them to match though...I didn't think it mattered..maybe someone else will comment.


Faris.

 

[paul23]

Thanks for your response, Faris!

I agree with you. It makes absolutely no sense to block based on different IPs for hosting vs. sending servers. More to the point, I have clients (and tested myself) sending through their ISPs and there has never been a problem with mail being delivered to a Bulk folder.

I do have SPF records on a handful of domains but have never had a problem with AOL blocking because of SPF or lack of SPF. Yahoo seems to be more interested in Domainkeys but I am pretty sure they have not fully implemented any sort of block/filter based on this. FYI, I did implement domainkeys on one domain to see if that would rid us of this Yahoo/Hotmail Bulk Folder issue and it did not.

You bring up a good point with hostnames. I have another server (out of the scope of what I discussed above) that is an exact clone of the server at question. Everything is the same except for hostname and hosted domains - we are using different nameservers but setup Identically. On this box, we changed the hostname and had our provider set the rDNS to the correct shared domain names (shareddomain.com). We also left the A records pointing to shareddomain.com so the zone looks like this:

shareddomain.com IN A 10.10.10.15
webmail.shareddomain.com IN A 10.10.10.15
mail.shareddomain.com IN A 10.10.10.15
shareddomain.com IN MX mail.shareddomain.com

rDNS: points to shareddomain.com
hostname: serverdomain.com (also set up as a hosted domain on this box) (IP 10.10.10.11)

Here is the best part: Any rDNS lookup on the domain will take 5-10 minutes. A dnsreport query will fail on the mail section. Hotmail will deliver messages to the bulk folder but yahoo will deliver to the inbox. The yahoo delivery to the inbox is only because we went through the task of getting server IP whitelisted in their system. I highly recommend getting whitelisted but it is not and end-all-be-all solution.

The issue comes full circle to the rDNS and hostname. I understand what our tests have shown although I don't neccessarily believe this is a final solution. Our zone for domain.com (from my first post) now looks like this: (again, this zone passes all tests and mail is delivered to the inbox)

domain.com IN A 10.10.10.2
webmail.domain.com IN A 10.10.10.2
mail.domain.com IN A 10.10.10.1
domain.com IN MX mail.domain.com

rDNS: points to 10-10-10-2.dedicatedhost.company.com
hostname: 10-10-10-1.dedicatedhost.company.com (IP 10.10.10.1)

compared to what it was: (did not pss mail tests and mail was delivered to a bulk folder)

domain.com IN A 10.10.10.2
webmail.domain.com IN A 10.10.10.2
mail.domain.com IN A 10.10.10.2
domain.com IN MX mail.domain.com

rDNS: points to 10-10-10-2.dedicatedhost.company.com
hostname: 10-10-10-1.dedicatedhost.company.com (IP 10.10.10.1)

Is it that when an rDNS query would come from a receiving mail server, the rDNS says to lookup 10-10-10-2.dedicatedhost.company.com at ip 10.10.10.2 (or on the 10.10.10.1 server) and when this lookup occurs our MX/A records are pointing to the shared IP address and returns 10-10-10-2.dedicatedhost.company.com as the response which receiving server is expecting to the hostname but when it verifies this information with the mail header it rejects/filters the message?

And is working now, because the lookup now points the MX/A records to the server ip and through the rDNS query the response is 10-10-10-1.dedicatedhost.company.com (the hostname) and can verify this as correct with the mail headers?

I am running another test to have the rDNS point to the true hosted domain name instead of this ISP style name. Once DNS propagates, I will post my results.

again, Faris, thanks for your post! I know I am not the only one experiencing this issue although I haven't seen it discussed on this forum.

 

[faris]

Here is the best part: Any rDNS lookup on the domain will take 5-10 minutes.

I don't understand this. Something must be *really* wrong.

We really need someone who lives and breaths dns to chip in on this one -- I'm obviously missing something fundamental here because I can't figure out what is going on for you. Sorry :-(

Faris.

 

[paul23]

How about the basics...

Does it make sense to point the A record to the primary IP address of the server since that is where the actual mail server runs? Is this "legal" or RFC compliant? and will this break the mail for this domain?