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:

1. Bob has his own mail server and creates an SPF record for the domain bobsdomain.com:
   
   v=spf1  ip4:256.18.19.0/24   -all
   
   Properly interpreted, this means that any message that comes "from" bobsdomain.com must originate from the IP range 256.18.19.0-256.18.19.255.
   
   
2. Jerk Q. Spammer sends a message to my mail-protected-domain, tzink99@example.com and says it is from my other domain, tzink99@example.org; he spoofs the sender.  But, tzink99@example.com doesn't exist.  My mail server can't do the recipient lookup in real time so it has to 250 accept the body contents of the message.
   
   
3. Upon trying to deliver the message, my mail server figures out that tzink99@example.com doesn't exist.  In a normal world, my mail server would send a message back to tzink99@example.org (with null sender <> in the MAIL FROM) with a 5xx level error indicating that the message could not be delivered.
   
   However, my mail server is smarter than that.  When it accepted the message, it did some spam filtering.  It saw that the sending IP for the message was 288.41.18.19.  It then looked up the SPF record for example.com and saw it was 256.18.19.0/24.  It determines that the sending IP is not in the SPF range for the domain in the MAIL FROM.  My mail server sees that any mail coming from example.org that fails the SPF check has a hard fail, -all.  It assumes that the message is spoofed/forged and decides not to send an NDR back to tzink99@example.org, the purported sender.  Instead, it simply drops the message.  No backscatter is sent back to me thus helping to solve (ie, not contribute to) the problem of backscatter.

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.