You cleaned your list, every address came back valid, and the campaign still produced bounces. It is a frustrating moment, and it makes people wonder whether verification works at all.

It does, but it answers one precise question: would this mail server accept a message for this address, right now? Several things can change that answer between the check and the send, and some bounces have nothing to do with the address at all. Here are the seven usual causes, how to recognise each one, and what to do about it.

First, read the bounce code

Every bounce comes with a code, and it tells you which kind of problem you have (our guide to SMTP bounce codes covers them in detail):

Code What it means Was it the address?
5.1.1, 5.1.10 The mailbox does not exist Yes
5.2.1 The mailbox is disabled Yes
5.2.2, 4.2.2 The mailbox is full Partly: it may be abandoned
5.7.x Rejected by policy: reputation, authentication, content No, it is about the sender
4.x.x Temporary problem, usually retried by your server Not yet decided

If most of your bounces are 5.7.x, verifying the list again will not help: the problem is on the sending side (see reason 5).

1. The domain accepts every address (catch-all)

Some domains are set up to accept mail for any address, real or not. A verifier asks the server about the mailbox and gets "yes", but the server says yes to everything. The real decision comes later: the message is accepted and then bounced, or silently dropped.

A good verifier detects this by also asking about a random address that cannot exist. MailQuell does this in every check and marks those addresses catch-all rather than safe. If you send to catch-all addresses, expect some bounces. Our guide to catch-all emails explains how to send to them carefully.

2. Time passed between the check and the send

Verification is a snapshot. People leave companies, mailboxes are closed, small domains expire. A list checked in January and sent in April is partly a different list.

What to do: verify shortly before a big send. If a list sat unused for a few months, check it again. In MailQuell, re-checking an address you verified in the last 20 days is free, so re-verifying right before sending costs little.

3. The server said yes, then changed its mind

Some mail servers accept the recipient at the start of the conversation and decide only after they have received the whole message. A spam filter, a size limit or a rule on the content can then reject it. No verifier can see this, because the check stops before any message is sent, which is the whole point of verifying without emailing people.

What to do: if bounces come from a few domains only, look at the bounce text. It usually says why. Content and attachments are the usual suspects.

4. The mailbox was full or about to be disabled

A full mailbox can accept a check one day and refuse mail the next, and an inbox that stays full for months is usually abandoned. MailQuell reports inbox full and disabled as separate results, so you can leave them out.

What to do: leave "inbox full" addresses out of this send and try again in a later one. If an address stays full for weeks, it is probably abandoned: remove it.

5. The bounce is about you, not the address

5.7.x bounces mean the receiving server refused your message: your domain or sending IP has a poor reputation, SPF, DKIM or DMARC failed, your IP has no reverse DNS, or a filter disliked the content. The address is fine; the same message from a well-configured sender would arrive.

What to do: check your domain's records (our SPF and DMARC checker shows them), read the 2026 sender requirements, and lower your volume while you fix it.

6. You sent to "unknown" or "risky" addresses

Some servers do not give a clear answer during the check: they are slow, delay unknown senders on purpose (greylisting), or block verification. Those addresses come back unknown. Others answer, but show warning signs such as a brand-new or parked domain, and come back risky. If they were sent with the safe ones, they explain part of the bounces.

What to do: send to safe addresses first. Retry unknown addresses later instead of sending to them blindly. (In MailQuell, unknown results are free, so checking them again costs nothing extra.)

7. The list you sent was not the list you verified

It happens more often than you would think: new contacts added after the check, two exports merged, a typo fixed by hand in the CRM, or the original file sent instead of the cleaned one.

What to do: verify the exact export you are about to upload to your sending tool, and keep a suppression list of every hard bounce so old addresses cannot come back through a new import.

How many bounces are normal after verification?

Not zero, but few. With a list sent soon after verification, and only to safe addresses, hard bounces should stay well under 1%. Adding catch-all and role addresses raises that number. Our article on what a good bounce rate is goes into the numbers.

MailQuell shows a send forecast for each verified list: the bounce rate to expect for each part of it (safe only, with role addresses, with catch-all addresses), next to the 2% line where many sending services start to warn or pause accounts.

When a "safe" address bounces anyway

Report it. On the list's page in MailQuell, paste the addresses or upload the bounce report from your sending tool. We check each one again right away, and when the mailbox really no longer exists, you get the credit back as a credit that never expires.

Frequently asked questions

Is a verifier that reports some bounces inaccurate?

Not necessarily. Check the bounce codes first. Bounces caused by your sending setup (5.7.x), by catch-all domains, or by addresses that changed after the check are not verification errors. A verifier is wrong when it says "safe" about a mailbox that did not exist at the time of the check.

Should I verify right before every campaign?

For lists older than a few weeks, or contacts you have not emailed in a while, yes. For an engaged newsletter list that you send to every week, removing hard bounces after each send is usually enough, with a full check a few times a year.

Can a verifier detect every catch-all domain?

It can detect that a domain accepts every address. It cannot tell which addresses on that domain are real, because the server gives the same answer for all of them.

Check your list