While BATV is a good technique, we've seen that there can be some limitations with it when combining it with an SPF policy.  What else do we have to consider with BATV?

1. Catch-all addresses or non-deliverable addresses - Some MTAs will look up the recipient in the SMTP conversation.  For example, in a hosted service, some companies will upload their valid email addresses and upon an inbound message, the hosted service checks to see if the user exists to whom the sender is delivering.  It allows the customer to not have to deal with a bounce, instead it's done upstream.  Similarly, catch-all addresses will deliver non-existent mail to the catch-all instead of bouncing it.
   
   Because BATV changes the recipient email address on all bounces, then you need to make sure that your MTA properly parses the BATV-signed recipient address.  Otherwise, your MTA will get the incoming message, check the recipient that list of valid email addresses will say "No, it doesn't exist because it's got this prvs=012345AbCd= in front of it, and none of my valid addresses contain it."
   
   So, you need to make sure that you upgrade your inbound MTA to make sure it strips the leading BATV tag before doing a lookup.
   
   The next few points are paraphrased from the internet draft.
   
   
2. Mailing Lists - BATV will cause problems with some mailing lists that identify posters by their bounce address. The list will not recognize the identical MailFrom addresses, because it will interpret the differing BATV attributes as part of the address. These services will either reject postings or pass them all to the moderator.
   
3. Greylisters - Greylisting is sending a 4xx-level notification to a sender which means "Hey go away, come back later" on the theory that a spammer won't return but a legit sender will.  A correct BATV implementation will only result in routine delays in this case. However the result of BATV tagging MUST be a constant local-part, for a given message, and not (say) created at delivery time such that each retry gets a different validation string, which would prevent it from ever getting through to a greylisting site.
   
   
4. Whitelisting/safe senders - If you send outbound mail and suddenly start signing it, people who have whitelisted your MAIL FROMs will suddenly stop recognizing your mail because the MAIL FROM will be different every day.  The solution to this, of course, is to update your MTA software such that it supports BATV and is capable stripping the BATV component of the MAIL FROM before doing sender lookups.
   
5. Challenge-Response Systems - Meh.  If this doesn't work, no big loss.

So, to summarize, make sure you make a list of possible things that can break before implementing BATV.  Unintended consequences can be a major headache if customers start to complain and you have to re-roll out a feature.