Every bounced email tells the receiving server something about you: that you send to addresses that do not exist. A few bounces are normal. A pattern of them, especially from a new mailbox, is one of the clearest signals a spam filter has. Mailbox providers judge every sender on signals like these; Google's sender guidelines list the requirements and the spam-rate limits all senders are measured against. Verifying addresses before you send is the cheapest deliverability protection there is.
This guide explains what verification can and cannot tell you, how to handle the awkward cases (catch-all domains, role addresses, guessed addresses) and a workflow that keeps bounce rates low without throwing away good leads.
What "verified" actually means
An email verifier runs a series of checks, each one stricter than the last. Understanding them helps you judge a verifier's output instead of trusting a green tick.
- Syntax. Is the address well-formed under the email address rules (RFC 5322)? This catches typos like a missing @, double dots or spaces. It says nothing about whether the address exists.
- Domain. Does the domain exist in DNS at all? A domain that does not resolve cannot receive mail.
- MX record. Does the domain publish a mail exchanger (MX) record, and does that server answer? Under RFC 5321 a domain with no MX record can fall back to its address record, but in practice a business domain without MX usually does not receive mail.
- Mailbox (SMTP) check. The verifier opens a connection to the mail server and starts a delivery (
MAIL FROM, thenRCPT TOwith the address) without sending a message. If the server answers that the recipient is unknown (a 550-type response), the address does not exist. If it accepts the recipient, the address probably does. - Risk checks. Is it a disposable-address provider, a role account, a known spam trap, or a catch-all domain?
Only step 4 talks to the recipient's server, and it is the step that gives an honest "exists" or "does not exist". It is also the step most likely to be inconclusive, for reasons below.
The catch-all problem
Many company mail servers, including a lot of Microsoft 365 and Google Workspace setups, accept mail for any address at the domain during the SMTP conversation and only decide later what to do with it. This is called a catch-all (or accept-all) domain.
For a catch-all domain, the SMTP check returns "accepted" for anna.svensson@company.com and equally for zzz-not-a-person@company.com. The verifier cannot tell a real mailbox from a fake one, so a good verifier marks the result as unknown or catch-all, never as valid.
How to treat catch-all results:
- Do not send to them in bulk from a new mailbox. They bounce later (as a non-delivery report after acceptance) more often than verified addresses, and those bounces still count.
- Raise confidence another way. An address you found published on the company's own website, in an email signature or in a reply is far more reliable than a pattern guess.
- Send in small numbers from warmed mailboxes and watch the bounce rate for that batch separately.
Guessed addresses
Prospecting tools often generate addresses from a pattern: first.last@, f.last@, first@. On a non-catch-all domain the SMTP check can confirm or reject the guess, which is fine. On a catch-all domain a guess cannot be confirmed at all; it is still just a guess. Treat pattern guesses on catch-all domains as unverified, whatever the tool's label says.
Role addresses and personal addresses
Role addresses such as info@, sales@ and office@ reach a shared inbox. They are often valid and deliverable, and the GDPR concerns are smaller because they rarely identify a person. But they are read by whoever happens to triage the inbox, so replies are less likely, and in some countries they are not exempt from marketing law: Denmark's spam ban, for instance, explicitly applies to general mailboxes too (see B2B cold email rules by country).
A named work address (anna.svensson@company.com) is personal data. Verifying it is processing under the GDPR, so the same lawful basis and transparency apply as for the outreach itself. The accuracy principle in GDPR Article 5(1)(d) is actually an argument for verification: you are expected to keep personal data accurate and not to act on stale data.
Results to expect, and what to do with each
| Verifier result | Meaning | What to do |
|---|---|---|
| Valid / deliverable | The server accepted this specific address and rejects unknown ones | Send |
| Invalid / undeliverable | Server rejected the recipient, or the domain has no mail server | Remove permanently |
| Catch-all / accept-all | Server accepts every address; this one cannot be confirmed | Hold, or send in small batches from warmed mailboxes |
| Unknown / timeout | Server did not answer or used greylisting | Retry later; do not treat as valid |
| Role address | A shared inbox such as info@ | Send only if no named contact exists and the country allows it |
| Disposable | Temporary address service | Remove |
Greylisting deserves a note: some servers deliberately reject the first attempt from an unknown sender with a temporary error and accept a retry minutes later. A verifier that gives up on the first temporary error reports "unknown", not "invalid". Retrying after 15 to 30 minutes usually resolves it.
Verification is not a one-off
People change jobs, companies change domains, mailboxes are closed. An address that verified three months ago may not exist today. Two habits keep your list honest:
- Verify close to sending. Re-check any address that has not been verified within the last few weeks before it goes into a campaign.
- Treat a hard bounce as final. When a real send bounces with a permanent error, suppress the address in every campaign, not just the one that bounced, and never re-import it from an old list.
Do not verify by sending
Some people "verify" by sending a real first email and seeing what bounces. That is exactly the behaviour verification is meant to prevent: the bounces land on your sending domain's reputation. Equally, avoid sending test messages to an address only to check it exists; the server logs it as a delivery attempt from you.
A practical workflow
- Start from a clean account list. Active companies from an official register, with the right industry code and country (see finding leads in EU company registers).
- Find one named person per company in the role you sell to, from the company's own website where possible.
- Run the full check (syntax, domain, MX, SMTP) and record the result and the date with the contact.
- Send only to "valid". Park catch-all and unknown results; retry unknowns later.
- Keep a global suppression list of hard bounces, unsubscribes and objections, and check every new import against it.
- Watch the bounce rate per batch. If a batch bounces noticeably more than usual, stop and look at where those addresses came from.
- Pace the sending. Verified addresses and a careful daily volume per mailbox together are what protect a new domain.
How Outvori does it
Outvori checks contacts before they are emailed: syntax, domain and mail server, then a mailbox check, with results cached for 90 days. Invalid, catch-all and unknown results are marked as such and do not send by default, hard bounces and unsubscribes go on a workspace-wide suppression list, and every contact keeps the source it came from. Verified contacts are included in every plan; see find customers and pricing.
