Time is the first suspect. Business addresses die at roughly 22 to 30% a year, concentrated around people resigning, and a list verified three months ago has moved. Nothing about the original check was wrong.
The second is a verdict that was never earned. If the verifier marked a catch-all domain as valid, the server had accepted an invented address just as readily, and no verification happened at all. This is the failure mode worth testing a vendor for, because it is invisible until the campaign runs.
Third, the bounce may not be about the recipient. A 550 arriving because your domain is on a blocklist, or because the receiving gateway rejected your IP, is a message about you. The bounce text says which, and it is the part people skip.
Fourth, greylisting and throttling produce failures on a real send that had nothing to do with the mailbox. Those come back as temporary codes and resolve on retry, so they look like bounces in a dashboard and are not.
Fifth, a full mailbox rejects mail while existing perfectly well. And sixth, content filtering at the gateway can reject a message after accepting the recipient, which is a bounce about your message rather than your data.
Three bounce messages, read closely
Say three verified addresses bounce on the same send. The first message reads 550 5.1.1 The email account that you tried to reach does not exist. That one is about the recipient. The mailbox is gone, most likely because the person left after your check. Suppress it.
The second reads 554 5.7.1 Service unavailable; client host blocked using zen.spamhaus.org. Nothing in it concerns the recipient. It's about the server your mail came from, and every message you send to that company will fail until the listing clears. Don't delete the contact.
The third reads 452 4.2.2 The email account that you tried to reach is over quota. A full mailbox exists and may be read again next week. Leave it alone unless it repeats over several sends.
That's three bounces with three different causes, and only one of them is a list problem.
A triage for the whole bounce report
Export the bounces from the campaign and sort them two ways. Group by code first. If most of them start with 5.7 or mention a blocklist, your list is fine and your sending setup needs the attention.
Group by domain next. When a large share of the bounces sits at one company's domain, there are two likely causes. Either that company's gateway is blocking you, or the domain accepts everything and the addresses were never proven.
Then match each bounced address back to its verdict and the date of the check. You'll usually find three piles. One holds addresses checked months ago. Another holds addresses that carried a catch-all verdict all along. The last holds valid verdicts that were only days old.
The last pile is the one to take to your vendor. If it's large and the codes say the mailbox doesn't exist, ask whether the random-address test ran on those domains.
Related questions
How long is a verification result good for?
Roughly three months for business data before decay makes a re-run worthwhile. Consumer addresses last longer.
Does a bounce mean the verifier was wrong?
Not necessarily. Read the bounce text: a policy rejection aimed at your sender is a different failure from an unknown user.
Why would a valid verdict be unearned?
If the domain accepts every recipient and the verifier did not run a control probe, the 250 it received proved nothing.
What bounce rate remains after verification?
A small one always. People leave jobs between the check and the send, and catch-all addresses were never provable.