See the discussion after my answers.
- If you implement BATV (Bounce Address Tag Verification), you can block them as they come in. Most of these messages are likely to userids which don't exist on your system, and should be refused on that basis.
- If you set and publish strong policies (SPF, DKIM, and DMARC), many servers will refuse the spam and you should see less of it in a few days. (Some of the servers sending this "backscatter" spam, may stop sending based on these policies.)
I ran into this issue with a domain a few year ago. My first step was to setup a restrictive SPF policy on the domain. This cut the bounces down significantly very quickly. Try adding a TXT record to the DNS for the domain containing v=spf1 a mx -all. A policy like this will enable mail exchange servers to reject the mail as soon as the MailFrom command is issued. (Some of the sending addresses were harvested by other spammers and it was years before email to them tapered off.)
There are two types of spam that show up as bounces to your domain. A small portion is likely to be spam sent as faked bounce messages. This will likely be targeted to valid addresses in your domain. It is also quite likely that the sending server will not have the correct DNS records to pass rDNS (reverse DNS) validation.
The rest is "backscatter" spam which results from organizations which accept mail before validating it. The then bounce the messages after validation. If the sender is faked and they send the bounce message, the message does not go back to the sending server. If you determine that these messages are "backscatter" you may want to notify postmasters at the sending domains that they are generating "backscatter spam". Some of them may fix their configuration.
You can use Bounce Address Tag Validation (BATV) to reject this backscatter spam. However, you should wait a week or two after you start signing outgoing messages before you start rejecting unsigned bounces. I have documented how to implement this in my article on Signing Return Path Addresses with Exim.
You could also consider Implementing DKIM to sign outgoing messages. This is another way that recipients can verify messages sent from your domain. Your public key will need to be added to your DNS records.
You can publish you SPF and DKIM policies using DMARC which is an upcoming method to verify senders. Like SPF and DKIM, this is done by adding records to DNS. It provides a mechanism for recipients to notify how well mail claiming to be from your domain complies with your polices.
All the above techniques work best if you have policies in place stating that all outgoing mail for your domain originates from your mail servers.
