2

I have an interesting DNS question (well interesting to me atleast).

I just installed an hmail server in our remote office to act as an MX backup in the event our exchange server goes down.

The 2 host names are

mail.campbellsurvey.com mail2.campbellsurvey.com

mail points to the address 98.XXX.91.XXX mail2 points to the address 70.XXX.190.XXX

How would I setup a PTR record on the ISP end to reflect both hostnames?

UPDATE

I actually found out from my ISP that I cannot have a backup MX in the office where I wanted it. The reason is our connection in the office has a dynamic IP and they won't assign a PTR to the address. So this question was useful informational wise, but is a bust in the physical sense. Thanks anyway everyone.

Does the PTR have to point to EXACTLY mail.campbellsurvey.com or can it point to just campbellsurvey.com?

because right now anything passing through the primary static address in our pool (the one used for standard internet) is identified as mail.campbellsurvey.com. My only idea to fix this was to move the mail server to the next available address and give it only it the name mail.campbellsurvey.com but I wanted to see if there was another way.

Thanks in advance.

Improve this question

3 Answers 3

Reset to default
1

Set up the pointer for each server to indicate the name of the server on that address. This should be the same as your mail server is using in its banner messages and when issuing HELO commands. PTR records are not significant for incoming messages as the remote server will trust your DNS MX records.

You will want to configure two MX records one for each server with different priorities. The MX records must point to A records. If your SPF records specify MX in the list of permitted senders, you should have no problems with your server addresses.

The PTR records you need are:

98.103.91.146     mail.campbellsurvey.com 
70.XXX.190.XXX    mail2.campbellsurvey.com

Get the appropriate ISP to setup the PTR record for the address they host. You appear to be missing an A record for your mail2 server. There may also some issues with verifying addresses on the second server.

EDIT: So if I was mailing from example.com but my sender's PTR resolved to mta532.mail.google.com or some.other.thing12.smtp.rackspace.com or canner46.blah.brightmail.com, you wouldn't trust my message?

rDSN does not apply to the domain on the senders address. If your envelope address is [email protected], I would check the SPF record for example.com. If example.com had an SPF record with a -all policy, I would refuse your email. Otherwise, it would be accepted unless it was otherwise flagged as Spam.

If your server claimed to be mail.example.com, that would trigger some actions on my side designed to determine if your server is a Spambot which it most likely would be. The lack of a valid rDNS setup would also increase your Spam spore. I have separate limits for HAM (unlikely to be not Spam), and SPAM. The messages which fall between these limits is almost entirely email from automated systems, and Spam. The person to person emails I receive almost always have correct rDNS for either or both of the IP address and name used in the HELO command.

If the DNS servers do not respond for any of the DNS lookups required to check the rDNS status of your IP address, I give a softfail. Recently, I have found this is successfully blocking a fair number of spambots. Until a few months ago this rule was rarely triggered. I believe a number of ISPs have configured there rDNS to fail for dynamic addresses ranges. If you, I appreciate their effort in reducing Spam.

Improve this answer
4
  • I see so everything has to match. I can't just setup a PTR for *.campbellsurvey.com and still have it work. Right? I just want to be sure that everything I thought is not wrong.
    – AtomicPorkchop
    Jun 22, 2011 at 22:58
  • The PTR records belong to the IP address, and I don't believe they support wildcards. Each of your two mail servers will have their own IP and respond with their own names. These are likely controlled by the ISP who provided you the addresses.
    – BillThor
    Jun 22, 2011 at 23:26
  • Ah ok so what I was originally thinking was correct.
    – AtomicPorkchop
    Jun 23, 2011 at 3:09
  • @Solignis / @BillThor See my eidt...
    – SmallClanger
    Jun 23, 2011 at 8:40
5

While there's certainly no harm in it, your PTR records do not need to exactly match (or even vaguely resemble) your mail domain name. Certainly on your receiving servers, there's no reason to have them match anything. Senders will connect to the IPs identified by your MX records in order. PTRs don't enter in to it.

If both of these server are yours, then configure them with a PTR that identifies their hostnames; nothing more. If those hosts have other duties or one of them happens to be your primary gateway, then the fact that they're called bert.campbellsurvey.com and ernie.campbellsurvey.com (or whatever) will not be a problem. If you're using a shared host or some other provider where you can't set the PTR, then that's not a problem either.

In short: PTR records have no relation to mail provision, so you don't need to worry.

EDIT

To clarify on what I'm saying and correct some misconceptions.

Receiving Mail:

You've specified two MX records. Something along the lines of:

mail1.campbellsurvey.com          IN    MX   10    1.2.3.4
mail2.campbellsurvey.com          IN    MX   20    1.2.3.5

A sender will lookup these IPs and attempt to connect to them in preference order to deliver your message.

Sending Mail:

Your MTA will do the same when sending mail to other domains. When it connects to mail1.example.com the first thing that it sends will be some variant of:

EHLO mta.campbellsurvey.com

It will be connecting from an IP address that is some egress point on your network. (Perhaps: gateway.campbellsurvey.com). The IP of this gateway will have a corresponding PTR record.

8.7.6.5.in-addr.arpa. 86341 IN    PTR    gateway.campbellsurvey.com

If you control these IPs, then most ISPs will allow you to set the PTR record to match the primary name of your domain.

With this in mind, the following applies:

  • I think everyone agrees that the PTRs of your MXs have no impact on your ability to receive mail at all.

  • When sending, the 2nd-level domain (campbellsurvey.com) specified on your EHLO greeting should match your email domain. That is a reasonable anti-spam measure.

  • It's general good practice to set the PTR records of any IP addresses you control to the primary hostname of the machine on which that IP resides.

  • SPF records (if you publish them) should specify the PTR record and/or IP address of all your sending servers. This allows servers to reject messages purporting to be form your domain from anything not in that list.

    • If a receiving mail server finds a published SPF record for your domain and the sending IP or its PTR don't match what you've specified as legitimate mail server, then it will likely reject your message. This is what SPF is for.

  • If the receiving server looks up the PTR record of your sending IP and rejects because it doesn't match your mail domain, then it is broken. This measure will reject legitimate mail.

    • If it rejects because the PTR doesn't exactly match, then it is very broken. This measure will rejects lots of legitimate mail
    • If this was a valid method for blocking spam then every shared mail host (Google, Rackspace, take your pick) would have to have a separate IP address and custom PTR for every domain they host. This would be silly.

@Solignis: Sorry to hijack your original question, which was only about your MX records, but I thought this needed clearing up.

Improve this answer
10
  • Then why does a tool like MXtoobox tell me that my reverse dns does not match my SMTP banner. As far as I was aware that is the whole reason you need a PTR record for a domain that hosting email.
    – AtomicPorkchop
    Jun 22, 2011 at 22:30
  • 2
    That's stupid propaganda made by antispam people: when you receive mail it's up to you to accept or deny traffic, it isn't the sender looking up your reverse and deciding if you're worth its email. On the other hand, it is best practice (if not plain needed) to have matching PTR records when sending out mail, since your recipients will check your reverse lookup and smtp banner. But you were talking about inbound MX (Mail eXchangers).
    – Luke404
    Jun 22, 2011 at 22:35
  • @Luke404: Check the current RFCs the reverse DNS should match a forward record. It should also match the name used in the HELO message from the server. Failure to do so is a strong indicator of spam. Non spam not doing so is likely an automated system.
    – BillThor
    Jun 22, 2011 at 22:41
  • 1
    @BillThor, please check the current RFCs: SMTP servers do not send HELO / EHLO messages. That is, as I wrote, a client side issue and it is really important for SMTP clients to have matching PTR records and HELO messages. Of course it would be good practice if every host on the internet had correctly set up PTR records, but that's another story.
    – Luke404
    Jun 23, 2011 at 8:32
  • Actually, the domain name in EHLO/HELO is a loop-detection mechanism for a problem that didn't exist after 1983.
    – JdeBP
    Jun 23, 2011 at 10:53
1

I'm not sure exactly what SmallClanger means by "mail provsion" in the statement "PTR records have no relation to mail provision," But it's certainly true that PTR records shouldn't affect your servers' ability to receive mail.

Another MTA that's trying to send to you doesn't care about your PTR records.

It's when your servers are sending messages out that you want them to match. So you need SPF records that specify both your mail servers.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .