Time is the first suspect. Business addresses die when people resign or change roles, and a list verified three months ago has moved on since. Nothing about the original check was wrong. See list decay for how quickly that adds up on an unmailed file.
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 real check took place. This is the failure worth testing a vendor for, because it stays hidden until the campaign runs. Can catch-all emails be verified explains the one probe that exposes it.
Third, the bounce may not be about the recipient at all. A 550 that arrives because your domain sits on a blocklist, or because the receiving gateway refused your IP, is a message about you. The bounce text says which, and it's the part most people skip. Our blacklist checker tells you in seconds whether your server is listed.
Fourth, greylisting and throttling cause failures on a real send that have nothing to do with the mailbox. They come back as temporary 4xx codes and clear on retry, so they look like bounces in a dashboard without being lost contacts.
Fifth, a full mailbox rejects mail while existing perfectly well, and it may be emptied next week. 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
Why did an email marked valid still bounce?
Usually because the mailbox closed after the check, the domain was catch-all and the verifier called it valid, or the receiving server blocked your sending IP. Read the bounce code: 5.1.1 means no such user, while 5.7.1 points at your server.
How long is a verification result good for?
About three months for business data before job changes make a re-run worthwhile. Consumer addresses usually last longer, and new data should be checked the day it arrives.
Does a bounce mean the verifier was wrong?
Not necessarily. Read the bounce text first: a policy rejection aimed at your sending server is a different failure from an unknown user, and only the second is about the address.
What bounce rate remains after verification?
A small one always remains. People leave jobs between the check and the send, and catch-all addresses carry their own risk, so mail them as a separate batch.