Using content analysis is one trick you can use to stop backscatter. Another is to use SPF records.
SPF records are designed to help combat backscatter on the theory that the recipient mail server will be able to figure out that your server didn't send it. Here's how it works:
So, SPF records are a way of not contributing to the SPF problem, but it is entirely dependent upon the recipient MTA. The recipient MTA must perform an SPF check on the message and then decide to not take its normal course of action on non-deliverable mail. Thus, logic must be built into the MTA to do custom actions depending on the authentication results.
Not every MTA will do this. SPF checks require DNS queries which are somewhat computationally expensive. It is quicker and easier to simply check to see if the message can be delivered and then take action, rather than check, verify and then take action after that. Still, using an SPF record with a -all in it means that you have given receiving MTAs the help they need in order to determine whether or not you actually sent the message. Whether or not they use this information is up to them.
PingBack from http://wordnew.acne-reveiw.info/?p=8691
Actually you should simply reject the SPF FAIL at your border and be done with it. Figuring out what to do if that was a legit mail (no spam), e.g., forwarded to you by a third party, or if the SPF policy is simply wrong, is the problem of the sender.
As soon as you accepted an SPF FAIL it is your problem, making the RFC 2821 dilemma painfully obvious: You can't bounce, most likely it is spam, confirmed by the FAIL. But maybe it wasn't, and then discarding a legit mail is "not optimal", putting it mildly.
What happens when you don't have a spf record. The company that has our DNS record doesn't support the spf record. But I have emails that seem to be bouncing consistently to hotmail.com and msn.com and can't seem to get past this issue.
What is your suggestion? Should I just move my domain to another company that supports spf records?