A customer reported that large numbers of automated in-response-to-users emails were not being received by users at the big email providers (Yahoo!, Hotmail, AOL, etc.), and this was killing their customer service. "I forgot my password" recovery, "you have new messages", "confirm your email address" were getting lost by the thousands into the ether.
Digging in, I found the problem to be with SPF (Sender Policy Framework) records which the customer provided in DNS. He had a subdomain allocated to the mailsender machines ("mailout.example.com"), and SPF lets you specify what amounts to a list of IP addresses which are allowed to send email with that domain.
Mailservers which check SPF look up a TXT record in DNS from the sender's domain and see if the IP address is listed. If so, it's passed: otherwise it's a forgery. Sites which publish no SPF data don't get any SPF verification or treatment.
The problem is that the customer published two TXT records, thinking they were cumulative. They had a long list of individual IP addresses of mailservers, so they were spread across two records. But this doesn't seem to be allowed, so sites asking for SPF data got only one of them at random. So half the time their email server's IP was in the TXT record which was discarded, and email was getting dumped in massive volumes.
Fortunately, the fix was easy: consolidate two records into one, and convert the list of individaul IP addresses into a smaller number of /24 ranges. Now it all fits in one record, is easier to read, and email stops getting bounced.
Moral of this story: bad SPF is worse than no SPF