This question already has an answer here:
I'd like to feel more confident setting up mail for my clients with regards to false positives. Here's what I know:
SPF records are good, but not every spam filter service/software (SFSS) uses them.
reverse DNS (PTR) records are pretty much a necessity.
Open relays are bad.
(Here's "other tips" I've read):
the reverse lookup of the IP address of your mail server should resolve to the domain that you're sending mail out from.
your server should say HELO FQDN.of.your.mail.server.com when speaking to other mail servers.
the A host records in MX records should be (or resolve to to the IP address) your FQDN.of.your.mail.server.com
Feel pretty good about 1 and 3. Here's where I'd like some clarification/suggestions:
2 and 4: I did alot of digging and this seems to be incorrect as most spam-filters are looking for a PTR in general and one that's not generically-assigned by the ISP; it doesn't appear that the domain you send mail out as has anything to do with this (i.e. if you owned two domains you used for mail, you'd need to send out from two IP addresses with PTRs for each?)
This makes sense, but does it care what that FQDN resolves to? Should it resolve to the IP address that's currently sending said HELO?
Again, another one from various Google searches; don't see how this would work if you used Postini as your gateway service (or any other smarthost for that matter).
And what about sending on behalf of another domain that you're not authoritative for? I have some clients (some.branchdomain.tld) that are required to send mail out as @some.corporatedomain.tld, even though said corporate HQ won't setup a relay/smarthost for them to use. corporatedomain.tld can create SPF records to show that some.branchdomain.tld is allowed to send mail, but would that still be considering "spoofing", especially if said SFSS doesn't check SPF records? Should I be concerned about this?