Apache HTTPD – Stop Reverse DNS Requests for Client IPs

• You can have as many A RRs as you want point to 1.2.3.4.
• You must have one PTR point back to a name.
• Therefore all you need is to make sure that the PTR points to the name you want and that this name points back to 1.2.3.4.

This means that you can have:

example.com. IN A 1.2.3.4

example.com. IN MX 10 mail.example.com.

server.example.com. IN A 1.2.3.4

www.example.com. IN A 1.2.3.4

mail.example.com. IN A 1.2.3.4

and:

4.3.2.1.in-addr.arpa. IN PTR server.example.com.

Why is this the requirement? Because when your SMTP server connects to a remote SMTP server to deliver mail the SMTP server knows only the address of your server and not the name. With the address at hand (1.2.3.4) it queries the DNS and gets the PTR response (server.example.com). The remote server now will ask the DNS again "what is the address of server.example.com" and it expects that answer to be 1.2.3.4.

What you send in the HELO string should not frighten you. You can read about the purpose of the SMTP HELO and find about the exceptions where it is allowed to block based on what is given in the HELO string.

To answer your new question first: No, PTRs don't tell you anything about the sender's domain. See below for the explanation.

Now back to your original question:

Receiving mail servers check none, one, many or all of the following:

1. Is the HELO name equal to the hostname (A record)?
2. Is PTR of the IP equal to the A record of the hostname (hostname ==(PTR)==> IP ==(A)==> hostname)?
3. Is the IP part of the provided SPF record?
4. Does the sender's domain have at least one MX record? Which doesn't have to match IP/hostname.

Receiving mail servers that check if the sending server is also the MX server are badly configured and should be eliminated from the Internet.

Edit: The PTR does absolutely prove nothing about the email domain. It is never meant to prove this. There are thousands of domains hosted at Google, Amazon, AOL and others. But none of them match the hostname or PTR of Google, Amazon, AOL and others. They all have the servernames of the providers. And there is nothing bad about that.

The PTR only proves the identity of the server but not the identity of the hosted domains. Point.

2nd Edit: A good example for a working environment would be

• HELO = mail.example.com
• hostname = mail.example.com
• A record of mail.example.com = 172.20.25.25
• PTR of 172.20.25.25 = mail.example.com
• Domains hosted on this server/system = example.com, *.example.com, *.example.net, *.example.org, mycompany.invalid and many many more.
• SPF records of hosted domains (optionally) = v=spf1 a:mail.example.com -all
• MX record of hosted domains can be anything. E.g. mx1.example.com, mx2.example.com, mailfilter.anti-spam-corp.invalid, mail.example.com, postini.google.invalid, ...