DNS and PTR for SMTP: shared IPs and subdomains

Question

This question is similar to others about PTR and DNS for SMTP, but one specific aspect was unanswered: what if one machine does SMTP and HTTP on the same IP address. For example:

SMTP at mail.example.com, also HELO. (1.2.3.4) HTTP at www.example.com (1.2.3.4) general access like ssh at example.com (1.2.3.4)

What are the requirements for the PTR record on the address 1.2.3.4 to be accepted by spam filters? The 'main' hostname for 1.2.3.4 is example.com, but if reverse DNS lookups require an exact match, I have to set it to mail.example.com. That's stupid. I mean, reverse lookups of 66.102.13.106 don't result in mail.google.com.

Or, is it enough if a reverse lookup finds example.com and mail.example.com as MX record on it? In other words, should I set the PTR to example.com?

One could argue that I should make SMTP access and the HELO example.com, but that causes inflexibility, because then I can never move SMTP to another machine by simply changing the A record.

Edit: it seems unclear what I mean, so let me clarify:

The server in question hosts DNS, SMTP, WWW and a lot more. It does all of it's own DNS. Example.com points to that machine, say 1.2.3.4. Because mail is not its main thing, I don't want 1.2.3.4 to reverse resolve to mail.example.com

The server runs postfix and its HELO is mail.example.com, which also points to 1.2.3.4. For the PTR to match, 1.2.3.4 should reverse resolve to mail.example.com, but as I said, I want it to resolve to example.com, because mail is not the server's main task.

Does that mean I have to change the mailname to example.com, and having it at mail.example.com will cause some spam filters to reject it, even though mail is an mx record of example.com?

Solution 1

• 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.

Solution 2

HTTP Services do not need to have a corresponding PTR record. SMTP does and it should always correspond to a forward resolution response.

Your A record for a domain does not have to match a MX record, for instance:

@     IN A   1.2.3.4
      IN MX  10 mail
mail  IN A   1.2.3.5

Is perfectly valid.

By design applications try to locate your MX record, but if it is not set, they fall back to your A record. This is the part where flexibility as you call it comes to play. It is an error to not set your MX record if you are a valid SMTP.

Spam filters will mostly always drop you mail (or asign a high value/tag) if your PTR does not match your hostname for your outgoing smtp server. You should set it to mail.example.com if your MX refers to mail.example.com.

Usually your helo should also refer to your PTR/MX as this is another test for your server to score a low value in spam filters and not be marked as spam.

EDITED:

Following your edit, it does not matters which its main purpose is. What matters is what you need to not get high spam score on your MX.

That said, you MX does not have to point to mail.example.com, you could say:

@ IN A 1.2.3.4 IN MX example.com.

This is Bind syntax, and notice that example.com has a dot at the end. You could try this if you are desperate and need to register your PTR as example.com and be coherent with HELO.

Comments

[Halfgaar]

I think you misunderstood me. I know that I must have an MX record for incoming mail and I know it's not necessary for HTTP to have a PTR record. The PTR record is for outgoing mail. It's just that reverse resolving the IP address of the server should not result in mail.example.com but in example.com, because otherwise it would suggest mail.example.com is it's main hostname, where in reality it's just one of the hostnames the machine is accessible on. But if I do that, HELO and reverse DNS don't match. So hence my question if that match has to be exact or not.

[Torian]

That is why I explained that your A record for example.com has nothing to do with MX record. In case they are the same, there is still no problem ("mail in a 1.2.3.4" and "@ in a 1.2.3.4"). Reverse lookup should just be what you need, and the only thing that requires you to have a PTR is MX. HELO should point to that. The main host name is looked up by "dig a example.com" (or nslookup query=a). If what you have is a multipurpose box (or IP) as in HTTP, SMTP, etc, then just think of it as what is the services that needs the PTR, not which domain it servers for its services.

[Halfgaar]

Interesting about the HELO. I never knew.