Email Address Verifications: What Each Result Means
Email Address Verifications: What Each Result Means

Only 62% of the email addresses submitted for checking were valid, according to a 2025 ZeroBounce analysis. At least 23% of an average list became invalid within one year. The same report measured list decay at 28% in 2024, 25% in 2023, 22% in 2022 and 23% in 2021. More than 11 billion addresses were analysed, and typo detection alone prevented over 10 million bounces.
That is why a mailbox tick is a confidence label, not proof the message will land, and not proof the person is ready to buy. Email address verifications tell you whether the string is safe to try. You still need a recent check, a clean sending domain, and a dated buying signal before anyone on your team presses send.
You're after paying customers, not a fatter spreadsheet. Hold anything you can't defend.
Table of Contents
What Each Verification Result Tells You to Do
An email address verification does not prove someone will read you. It sorts the address into a category you can act on before you spend a send. Valid, invalid, catch-all, unknown and risky are operating decisions. Treat them as a send policy, not a glossary you file and forget.
The verdict beside each result
| Result | What the check found | Verified email? | What you do |
|---|---|---|---|
| Valid | Syntax, MX and mailbox check agree | Yes | Queue it and recheck close to the send |
| Invalid | Bad syntax, no MX, or mailbox rejected | No | Suppress it and do not retry the same string |
| Catch-all | Server accepts any recipient at SMTP time | No | Keep it labelled; mail only with a strong reason and a tiny test |
| Unknown | Timeout, block, or no clear SMTP answer | No | Recheck later; never count it as confirmed |
| Risky | Role inbox such as info@ or a disposable domain | No | Prefer a named person; drop disposable domains |
Valid is the only row that counts as a verified email. Syntax, the domain's mail setup and the mailbox probe agree, so you may queue it. Recheck it close to the send. A pass from the week you scraped the list is not a pass on the morning you write.
Invalid is a hard stop. The string is malformed, the domain has no mail exchanger, or the server rejects that mailbox. Suppress it and don't retry the same string with a swapped character. Those rows create hard bounces, and hard bounces are how small domains get treated as careless.
Catch-all is not a quiet yes. The server accepts every local part during the SMTP conversation, so the mailbox is unproven. Keep the label on the record. You mail it only when you have a strong, current reason, and only as a tiny test, not as the bulk of a campaign.
Unknown means the check failed to get a clear answer. A timeout, a block, or a vague response is not confirmation. Recheck later. Never export it in the same column as a confirmed mailbox, or a colleague will send it by mistake.
Risky is a different failure. Role inboxes such as info@ hide the reader. Disposable domains are built to vanish. Prefer a named person. Drop the disposable domain outright.
Send rule: Catch-all and unknown stay labelled. A friendly server response does not promote them to confirmed.
Timing beats a stored pass
People leave jobs, domains lapse, and aliases get retired while the CRM still says "good". An address that worked when you stored it is not automatically safe later. For a founder or a small sales team, that means continuing validation, not a one-time import before a quarter of outbound.
Recheck immediately before outreach. If the fresh result is valid, it can enter a small approved batch. If it is anything else, it stays out of the main send. You're protecting the domain you will still need next month.
How the Checks Build One Result
A mailbox check gives you a confidence label, not proof that a message will land or that its recipient is ready to buy. Treat each result as one part of a send decision, alongside sender authentication and a dated buying signal.

Layer by layer
Syntax comes first. The local part and domain must follow mailbox rules. RFC 5321 sets a 64-octet limit for the local part. Check the full address before sending: a correctly formatted string still says nothing about whether the domain or mailbox can receive mail.
The domain comes next. Its DNS records need to show that it is set up to receive email. If no mail exchanger is listed, hold the address. Do not guess a similar domain.
Then comes the mailbox check. An SMTP conversation may ask whether the recipient is recognised, but servers can disable verification commands or return an unclear response. A positive response is not a promise that a later message will be accepted.
Risk flags affect the verdict. Role accounts, disposable domains, and catch-all servers call for caution even when the syntax and domain look sound. Keep valid, invalid, catch-all and unknown results distinct. A positive check is a confidence signal, not a guarantee.
Names that aren't plain ASCII
Names and domains can contain accents or non-Latin characters. RFC 6531 extends SMTP to support UTF-8 through the SMTPUTF8 extension. A server that does not support it may reject an address that requires SMTPUTF8.
Keep the original address. Do not transliterate the local part: the changed spelling could point to another mailbox. Check whether the sending system supports SMTPUTF8 before using an address that needs it.
SignalVan checks each work email before marking it confirmed, and labels catch-all and unknown results rather than hiding them. Its contact enrichment process gives you a result to weigh alongside the prospect's dated buying signal and your sender authentication.
The verdict: send only when the address check, sender authentication and buying signal give you enough confidence. Otherwise, hold.
Bounce Rates That Force a Recheck
A list check can lower bounce risk, but it cannot guarantee inbox placement. A 2025 deliverability benchmark reports that 83.5% of legitimate marketing emails reached inboxes worldwide in 2024, while 9.8% were blocked or deferred before reaching either the inbox or spam folder. Treat verification as one control, not a verdict on whether a message will land or prompt a reply.

The gap between clean, unchecked and bad
The benchmark reports a 1.21% bounce rate for verified addresses, compared with 2.11% for unverified addresses. Addresses classed as bad had a 10.58% bounce rate. These figures support one practical decision: suppress invalid addresses before a campaign. They do not set a universal target for every sender or prove a verified message will reach the inbox.
| Measure | Figure | What it compares |
|---|---|---|
| Inbox placement, legitimate marketing email, 2024 | 83.5% | Worldwide benchmark |
| Blocked or deferred before inbox or spam | 9.8% | Same 2024 benchmark |
| Verified addresses, bounce rate | 1.21% | Versus 2.11% unverified in the same set |
| Bad addresses, bounce rate | 10.58% | Same benchmark as the 1.21% row |
A routine that stops the bleed
- Send a small first batch using the approved list.
- Check the hard-bounce rate after that batch. Keep it separate from deferrals and spam placement.
- If hard bounces rise, pause the next send and recheck the remaining addresses. Resume only when you have dealt with the invalid rows.
- Keep the result in context: a mailbox check is a confidence label, not proof the message will land or that the person is ready to buy.
Before sending, also confirm your sender authentication and look for a dated buying signal. If either is missing, hold the message. If both are in place and the address is confirmed, send a small batch and monitor hard bounces separately from other delivery problems.
How to Handle Catch-All and Unknown Addresses
A catch-all domain is a building that takes every letter at the front desk and may bin it later. Unknown is a desk that won't say whether the person works there. Neither result is a verified email, even when the company is real and the job title looks perfect.

Every work email should be checked before it is marked confirmed. Catch-all servers and unknown results stay labelled rather than hidden. If your tool, or a CSV from a vendor, flattens those rows into "valid", you have already lost the verdict.
The policy, in order
- Leave the label visible on the record, with the check date. A pass with no date is an invitation to send stale mail.
- Don't export catch-all or unknown rows in the same column as confirmed mailboxes. Split the file before it reaches the sequencer.
- Drop them when you have no current reason to write. A lookalike company is not a reason.
- If a buying signal is dated and specific, a new role, a live tender, or a public request for help, you may test a handful. You don't test the whole domain.
- Send that test from an authenticated domain. Watch bounces and replies for several days, then decide whether any more of that domain is worth the risk.
- If the test bounces, or it draws spam complaints, suppress the domain pattern. One polite accept at SMTP time doesn't earn a second wave.
- Recheck unknown rows later. A timeout is often temporary. A permanent accept-all is not, and another probe won't turn it into a named mailbox.
Edge cases that trick small teams
A corporate catch-all can hide a real decision-maker. The signal and the person's name still matter, but the address stays unconfirmed. You're testing a hypothesis, not loading a sequence.
Greylisting can look like unknown on the first probe and valid on a retry. That is why "recheck later" is a step, not a shrug. Two failures in one hour aren't the same as a failure, a wait, and a second clear pass.
Role addresses on a catch-all domain are the weakest combination. You can't tell who reads info@, and you can't tell whether the mailbox is real. Drop that pair unless a named person has publicly used it, and even then keep the label.
Maximising the count of valid-looking rows is the wrong goal. A short list you can defend beats a long list that makes the next domain warmup harder.
Why a Verified Mailbox Can Still Miss the Inbox
A green mailbox tick does not mean the message will arrive. Inbox placement is a sender problem as much as an address problem. Padding the list with stale, role-based or low-intent "valid" rows can raise complaints even when bounces look fine.

Four outcomes, four limits
Syntax validity proves the string is a proper address. It proves nothing about the company, the person, or your right to write.
Domain and MX availability prove the organisation can receive mail. They don't prove this local part is staffed, or that your message will be wanted.
Mailbox confidence proves, at best, that a server recognised the recipient at that moment. It expires as people move, and it says nothing about whether the note belongs in a sales sequence.
Sender-side deliverability is a different test. It covers your identity, your complaint rate, and your permission practice. A verified work address can still be deferred, rejected, or filed as spam if those checks fail.
What bulk receivers now enforce
Gmail and Yahoo require bulk senders to use SPF and DKIM, publish DMARC, align the sending domain, offer one-click unsubscribe, and stay below a 0.3% spam-complaint rate. Google escalated enforcement in late 2025 from filtering toward temporary and permanent SMTP rejection for non-compliant traffic. The numerical bars stayed largely the same.
Google's sender guidance adds the practical detail. Senders to Gmail need SPF or DKIM. Bulk senders also need DMARC, and a policy of none is allowed at first. Marketing and subscribed messages need a visible unsubscribe, plus the List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers.
Before a batch leaves your stack, run this short list.
- Authenticate the domain. SPF, DKIM and a published DMARC record, with the visible From aligned to the signing domain.
- Keep complaints under 0.3%. If you're near that line, stop adding "valid" strangers and cut volume.
- Honour opt-outs. A working unsubscribe is part of deliverability, not a footer decoration.
- Don't treat mailbox confidence as a licence. Mail the named, recent, relevant rows. Leave the rest labelled.
Aggressive list growth feels like progress in a CRM. It is how a small team teaches Gmail that the domain is a nuisance.
Worked Cases from a B2B Prospect List
Policy is easier to copy from rows than from rules. These four contacts are fictional. None of them is a result you should quote as performance. The deciding fact is the same every time: result category, age of the check, and whether a buying signal has a date.
| Case | Contact | Verification result | Check age | Buying signal | Decision |
|---|---|---|---|---|---|
| Case A | Finance director, work address | Valid | This week | Relevant job posted seven days ago | Small approved send |
| Case B | Same title, lookalike firm | Valid | Not rechecked since the scrape | Scraped list from last year only | Hold |
| Case C | Founder, catch-all company domain | Catch-all | This week | Public request for help this week | One careful note, no other addresses on that domain |
| Case D | info@ address | Unknown after two probes | Two probes, still no clear pass | None | Drop |
Case A can go. The work address returned valid this week, and the firm posted a relevant job seven days ago. That is a verified email plus current timing. Put it in a small approved send, with a first line tied to the job post, and stop there. Don't bolt on five lookalikes to "make the batch worthwhile".
Case B is a hold. Same title, valid address, and the only evidence is a scraped list from last year. Validity isn't timing. The person may have left, and you have no dated reason to interrupt them. Recheck if a fresh signal appears. Until then, the row waits.
Case C is a single test. The founder sits on a catch-all company domain and asked for help in public this week. Keep the catch-all label. Write one careful note. Don't add the rest of that domain, and don't call the address confirmed because the request was public.
Case D is a drop. An info@ address is still unknown after two probes, and there's no signal. You can't tell who reads it, and you can't defend it as a confirmed mailbox. Chasing the role inbox wastes the domain's reputation.
A legal caution, not a full brief. In the UK, the ICO's guidance on direct marketing says PECR requires consent or a soft opt-in for electronic-mail marketing to individuals, sole traders and some partnerships. Marketing email to limited companies and other corporate subscribers isn't covered by that specific consent rule, but UK data-protection duties still apply, including a proper legitimate-interests test. In the US, the CAN-SPAM Act compliance guide requires accurate From, routing and subject lines, a clear opt-out that doesn't demand a fee or extra personal data, and honouring opt-out requests within 10 business days, with the mechanism able to process requests for at least 30 days after the send.
Priority still comes first. Mail the fresh, named, valid row. Leave uncertain rows labelled. Signal-led prospect lists only help if the address verdict survives contact with the send button.
Recheck the Address Then Time the Send
A mailbox check is a confidence label, not a promise of delivery or a buying signal. Send only when the address is confirmed, the recipient is the right person, and a dated signal gives you a reason to contact them.
Check the address first. Use a work email that has passed a mailbox check. Keep catch-all and unknown results labelled, and recheck an old result before sending. Hold any uncertain address out of the main batch.
Then check the person and timing. Choose a named decision-maker, and tie the message to a dated signal such as hiring, a new role, a public request, company news or a tender. A relevant job title alone is not a reason to send.
Pair the signal with the address result. The signal helps you choose who is worth contacting now. The mailbox check helps you judge whether the address is safe to try. Neither guarantees a reply.
SignalVan ranks leads with proof, then reveals verified contact details only for the leads you choose. Its outreach agent drafts a first line from what the person said or did, and every first message waits for you to read, change and approve. Campaign approval and sending approval are separate, and outreach goes only through your own Smartlead account. For a comparison with another signal-led prospecting approach, see SignalVan's Clay alternative. Lead records can be exported to Excel, and sending stays in your own Smartlead account, so the send stays in your hands.
Use the mailbox result to decide whether to try the address, not to predict the inbox or the buyer. Check sender authentication and the dated signal before you send.
Paste your website at signalvan.com to see ranked leads with their public signals. Choose the leads you want, review their contact details, and keep control of every send.
SignalVan finds prospects from public buying signals, checks work emails before marking them confirmed, and drafts outreach for your approval. A verified mailbox is one reason to proceed, not a guarantee of delivery or interest. Visit SignalVan to review leads tied to public signals.
Start with your website.
See your first leads, with the reason each one is there.