The simple question to ask here is;
What IP is returned when you ping mydomain.com or www.mydomain.com?
Is it the correct address?
If not, then you've either cached a response, have not reloaded the zone or have not edited correctly.
I'd assume the response should now be a public IP rather than a private.
You should also query the DNS server directly as opposed to 'pinging';
dig @dns_server_ip mydomain.com A
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 someone@example.com, 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.
Best Answer
Your DNS setup is OK to get redundancy on the "receiving" part.
The problem of syncing the mails still persists. I don't know how you are solving this. I even don't know if your server software is able to handle the situation that a user could purge the mails from one server while the other still delivers to the mailbox and simultaneously the syncing process copies mail from one to the other.
Nonetheless you still need to switch the POP3 server in case of a fault. Or how should they know that their POP3 server is changing from mail1 to mail2?