Reverse DNS to match Sophos name, or mail server name

I think you are confusing incoming and outgoing mail exchangers. I'll try to answer your question by treating both separately:

Incoming mail

When another MTA has a message for $localpart@$yourdomain it does a DNS query (type MX, data $yourdomain). The answer is get is mail.$yourdomain (and probably also it's IP). It uses this to connect to your machine on port 25 and try to deliver the mail. Since the other machine is sending (not accepting), it will not to anti-spam checks based on your machine.

Outgoing mail

You want to send an e-mail from $localpart@$yourdomain to somebody else. Your machine (this does not have to be the same as the MX record) connects to the remote mail server and tries to deliver the mail. Now the remote machine will do anti-spam checks. It has two pieces of information from your machine: The 'HELO/EHLO name' and the IP address.

Nowadays most servers demand that the 'HELO name' is a fully qualified domain name and that it resolves to your IP address. Some demand that your IP address has reverse DNS that does not look dynamic (like dyn-127-0-0-1.example.com). I have encountered some servers that applied rate-limiting or greylisting when the 'HELO name' did not match the reverse DNS, but never full rejection.

My recommendations

• Keep your MX record as mail.$yourdomain.
• If you also use this machine for outgoing mail, set the 'HELO name' to mail.$yourdomain.

A shared machine for outgoing mail is far from ideal, abuse from other users can easily get you on DNS-bases blacklists.

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.