What can be done depends on how much of the infrastructure you have control over, and whether you are using your own domain name or simply have an address under a domain controlled by somebody else.
If you have your own domain, it is easy to switch to a new email address under the same domain. Additionally you can set up DNS records to tell the world that all emails from your domain is supposed to be digitally signed. (SPF, DKIM, and DMARC are the terms to search for if this is the approach you want to take.)
You cannot expect everybody to verify these signatures, so even if you do setup DNS records indicating that email from your domain must be signed, there will still be abusers sending unsigned emails claiming to be from your domain and receivers accepting those unsigned emails.
If you do not control the domain, then changing the email address is not as easy, and you have little influence on whether DNS records are used to limit the ability to spoof the domain in outgoing emails.
The problem with spam messages using a spoofed source address causing bounces coming back to the legitimate address is at least in principle easy to solve.
You can record the Message-ID of all emails you are sending. All bounces need to include the Message-ID of the original message somewhere - otherwise the bounce is completely useless anyway, because that is what tells you which message got bounced. Any bounced message which does not contain a Message-ID you have previously send can be send straight to the spam folder or be rejected at receiving time (which has the nice benefit of pushing the problem one step closer to the source).
Bounces can be told apart from other emails by the MAIL From address. Bounces always have an empty MAIL From address, other emails never have an empty MAIL From address.
So if MAIL From is empty - and the DATA does not contain a Message-ID you previously send, the mail can be safely rejected.
That's the principle. Turning it into practice is a bit harder. First of all the infrastructure for outgoing and incoming emails may be separate, that makes it problematic for the infrastructure for incoming emails to always know about every Message-ID which has gone through the infrastructure for outgoing emails.
Additionally some providers insist on sending bounces that do not conform with common sense. For example I have seen providers sending bounces containing no information whatsoever about the original email which was bounced. My best recommendation for such useless bounces is to treat them as spam, even if they originate from an otherwise legitimate mail system.
Remember that whoever has obtained the list of email addresses can put any of the addresses as source address and any of the addresses as destination address. Thus unless you have additional information you can't be sure the leak even happened from your own system. It may be any of your contacts who leaked the list of addresses including yours.
The more you can figure out about which addresses are on the leaked list and which are not, the better you will be able to figure where it was leaked from. It might be you have already done this and concluded that the leak must have originated from your contact list since none of your contacts would have known all of the addresses confirmed to have been leaked.
My approach to that is to use my own domain and a separate email address under that domain for each contact I communicate with. I include the date of first communication with the contact in the mail address, such that it could look like kasperd@mdgwh.04.dec.2015.kasperd.net if I were to write an email to a new contact today. That approach obviously isn't for everybody, but for me it surely helps know exactly who has been leaking a list of email addresses where one of mine is on. It also means I can close the individual addresses such that only the person who leaked my address has to update their contact information for me.