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.