3

I need some help on clarification of the reverse DNS and MX record setup. I wasn't able to find definitive answer on google. The case is following. Say I have domain "mydomain.com", I have a SMTP server named "mail.mydomain.com", which is hosted by myprovider.com. I want to send/receive mails from domain mydomain.com. So I add MX record like this:

mydomain.com MX mail.mydomain.com

I also have A record, pointing to the myprovider.com server IP (suppose it is 1.2.3.4):

mail.mydomain.com A 1.2.3.4

Now, I want to make sure my mails will be delivered, so I check reverse DNS for this. I got following results:

mail.mydomain.com -> DNS check resolves to 1.2.3.4,

1.2.3.4 -> reverse DNS check resolves to s1.myprovider.com

Now - does it mean that anty-spam reverse DNS check fails, because 1.2.3.4 doesn't resolves back to mail.mydomain.com? BUT: it's a shared server, so it will never resolve to my domain.com - it will always resolve to myprovider.com - right? Does it mean the mail mail will be potentially marked as span? OR: the anti-spam filter will do one more DNS check, checking IP of s1.myprovider.com:

s1.myprovider.com -> DNS check resolves to 1.2.3.4

so it will decide that reverse DNS matches? Which one is true?

Perhaps I should do it different way, I should point my MX record directly to s1.provider.com, this way:

mydomain.com MX s1.myprovider.com

Then s1.provider.com resolves to 1.2.3.4, and 1.2.3.4 resolves to s1.provider.com, so everything is ok, right? (The only problem is that I'm not sure how stable is this "s1.myprovider.com" domain name - maybe they change it from time to time, and sometimes it is "s2.myprovider.com", and such setup will fail?)

Greg
  • 63
  • 2
  • 6
  • aslong as your domain has the mail.domain A entry pointing to the ip and the mail.domain MX record point to the right domain and the ip is a static ip with the PTR well assigned to a FQDN youre fine to send emails. if the PTR reverses to something not well defined it will be verifyed on most MTAs before being accepted and besides that most IP ADDRESS are checked against RBLS to ensure they are not spammers, besides those there are aswell other verification which vary from server to server, so i don't belive your email will be marked as spam, but it also depends on it is content. – Prix Aug 23 '10 at 12:11
  • http://www.experts-exchange.com/Software/Server_Software/Email_Servers/A_2427-Problems-sending-mail-to-one-or-more-external-domains.html – Prix Aug 23 '10 at 12:13

2 Answers2

2

I think you are confusing incoming and outgoing mail exchangers. I'll try to answer your question by treating both separately:

Incoming mail

When another MTA has a message for $localpart@$yourdomain it does a DNS query (type MX, data $yourdomain). The answer is get is mail.$yourdomain (and probably also it's IP). It uses this to connect to your machine on port 25 and try to deliver the mail. Since the other machine is sending (not accepting), it will not to anti-spam checks based on your machine.

Outgoing mail

You want to send an e-mail from $localpart@$yourdomain to somebody else. Your machine (this does not have to be the same as the MX record) connects to the remote mail server and tries to deliver the mail. Now the remote machine will do anti-spam checks. It has two pieces of information from your machine: The 'HELO/EHLO name' and the IP address.

Nowadays most servers demand that the 'HELO name' is a fully qualified domain name and that it resolves to your IP address. Some demand that your IP address has reverse DNS that does not look dynamic (like dyn-127-0-0-1.example.com). I have encountered some servers that applied rate-limiting or greylisting when the 'HELO name' did not match the reverse DNS, but never full rejection.

My recommendations

  • Keep your MX record as mail.$yourdomain.
  • If you also use this machine for outgoing mail, set the 'HELO name' to mail.$yourdomain.

A shared machine for outgoing mail is far from ideal, abuse from other users can easily get you on DNS-bases blacklists.

schot
  • 666
  • 5
  • 11
  • To make it sure I understand correctly: If my web server running some Java service tries to send notification mail to say "friend@gmail.com", and it uses myprovider.com server as SMTP server, then the HELO/EHLO conversation occurs between myprovider and gmail server (not between myprovider and my web server), right? Then I probably have no much control on what myprovide sends in HELO message, but probably it sends "s1.myprovider.com", so reverse DNS should return the same. – Greg Aug 23 '10 at 13:38
  • @Greg Yes, you'll just have to assume that your provider has a properly configured mail server. – schot Aug 23 '10 at 14:02
1

You have a higher likelihood of becoming spammed if your hostname is an IP address (or contains a string similar to an IP address such as 1.2.3.4.yourprovider.net), if the hostname doesn't point to your server, or if you don't have reverse DNS setup.

As far as I am aware, as long as the reverse DNS points to a hostname which resolves to your server, and as long as your hostname is a hostname which resolves to your server, you will be fine. It doesn't matter if the reverse DNS and the hostname is different as long as they point to the same place.

James L
  • 6,025
  • 1
  • 22
  • 26