Email address verification

Sending to bad addresses is not a cosmetic problem. Mailbox providers score senders on bounce rate, and a single campaign to an unverified list can push a domain into the spam folder for months. The fix is cheap: check addresses before you send, and know what the answer means.

This skill covers how to make that decision well. It uses the ClearBounce MCP server (verify_email, find_email, check_credits) for the live checks, but the judgement rules below are what actually matter — most mistakes come from misreading a result, not from missing a tool.

The one rule that matters

Verify with intent, never in bulk-by-reflex.

Every verification costs a credit. Verifying 500 addresses to send to 40 of them wastes 460 credits. Verify what you are about to use, in the order you will use it, and stop as soon as you have what you need.

Finding someone's address

find_email takes a full name and a company domain and is free. It returns:

• status — found_published if the address came from a published source, or pattern_guesses if it was derived from common company address patterns
• best_match — the best address, with confidence (0–100)
• detected_company_pattern — the pattern this company actually uses, when known
• seen_at_company — addresses already published at that domain (up to 5)
• candidates — the ranked alternatives, at most the top 25
• total_candidates — the size of the full pool, which can exceed 25

found_published is a real observation. pattern_guesses is arithmetic on a name — it is not evidence that a mailbox exists. When the status is found_published, best_match is that published address and candidates holds the alternatives, not the match itself.

The workflow:

1. Call find_email. It is free, so always start here.
2. Tell the user how many candidates came back and that each verification costs 1 credit. Quote the worst case from total_candidates, not from the length of candidates — the visible list is capped at 25 and can understate the pool.
3. Get the user's agreement before spending anything.
4. Verify candidates one at a time, highest confidence first.
5. Stop at the first deliverable result. Do not verify the rest of the pool.
6. Report what you spent: how many checked, how many credits, balance remaining (verify_email responses include creditsRemaining).

If detected_company_pattern is present, the pattern-matching candidate is usually the first one worth spending a credit on, regardless of raw ordering. seen_at_company is the evidence behind it — real addresses observed at that domain. Reading the pattern off those by eye often beats trusting the ranking.

Reading a verification result

verify_email returns a status, a subStatus reason, a 0–100 score, and a checks object. Act on the status first:

status	Means	Do
deliverable	Mailbox confirmed to exist	Send
undeliverable	Will bounce	Remove from the list, never send
risky	Real risk of a bounce or a complaint	Judge — see below
unknown	Could not be determined this time	Do not treat as invalid — retry later

unknown is the most commonly misread value. It means the answer is missing, not that the answer is "no". Its sub-statuses — unavailable_smtp (the mailbox check could not be performed) and provider_temporarily_blocked — describe a check that did not complete, not a verdict on the mailbox. Many resolve on a later retry. Deleting unknown addresses throws away good contacts.

The sub-statuses, by the status they belong to:

• undeliverable — invalid_syntax and invalid_domain (malformed, or the domain cannot receive mail at all), rejected_email (the server explicitly refused this mailbox)
• deliverable — accepted_email
• risky — low_quality (a disposable domain, or a likely typo); low_deliverability (a catch-all domain that could not be confirmed); mail_server_did_not_respond
• unknown — unavailable_smtp, provider_temporarily_blocked

mail_server_did_not_respond deserves its own note: it means a secure email gateway (Mimecast and similar corporate filters) intercepted the check. It is deliberately reported as risky rather than unknown, because the mailbox behind the gateway may well exist — but nothing observable confirms it. Treat it like a catch-all: fine for one careful message, not for a bulk send.

The catch-all problem

This is where most verification tools quietly lie, so understand it.

A catch-all (accept-all) domain accepts mail for every address, including addresses that do not exist. sdfgsdfg@theircompany.com gets a green light from a naive SMTP check and bounces two days later.

When checks.isCatchAll is true, an SMTP "accepted" carries no information on its own. Only a provider-specific signal can resolve it — which is why the result may still come back deliverable for a catch-all domain on Google Workspace, Microsoft 365, Yahoo, iCloud or Proton, where the mailbox can be confirmed another way. When no such signal exists, the honest answer is risky, and that is what you get.

How to treat risky on a catch-all domain: it is not a "no". It is "we could not confirm this mailbox". For a low-volume, high-value send (one prospect, a reply to a person) it is usually fine. For a bulk campaign it is not — a list of catch-all guesses is exactly how bounce rates spike.

Other risk signals in checks

• isRoleBased — info@, sales@, support@, admin@. Often deliverable, but they reach a shared inbox, get low engagement, and attract spam complaints. Keep them out of cold outreach; they are fine for transactional or support contexts.
• isDisposable — a throwaway address. Deliverable today, gone next week. Never worth a marketing send; a signup with one is a signal in itself.
• hasTypo — a likely misspelling with a suggested correction (e.g. gmial.com). Do not send to the original. Offer the correction to the user; the corrected address is worth one credit to verify.
• isFreeProvider — gmail.com, outlook.com and similar. Not a problem, just context: in a B2B list it usually means a personal address rather than a work one.

The score and riskFactors

score starts at 100 and is reduced for each risk signal found. It drops straight to 0 on a hard failure — bad syntax, no MX records, or a mailbox the server explicitly rejected. So a 0 means "definitely not", but a mid-range number means "accepted, with caveats", not "probably invalid".

riskFactors is the plain-language list of exactly which signals cost points ("Disposable/ temporary email domain", "Possible typo detected (did you mean …?)"). When a user asks why an address is risky, read them this list rather than guessing from the score.

Use status for the send/don't-send decision and the score for ordering within a status — which of several risky addresses to try first. Do not invent a score threshold and treat it as a rule: a deliverable at 70 is still deliverable.

Credit discipline

• find_email and check_credits are free. verify_email costs 1 credit per call.
• Call check_credits before a run that could cost more than a handful of credits, and tell the user what the run will cost before starting it.
• Never verify the same address twice in one session — reuse the result you already have.
• When a user asks to "clean this list", ask how many addresses first. For anything beyond a few dozen, the bulk upload in the dashboard is cheaper in time and gives a downloadable result; the MCP tools are for interactive, one-at-a-time decisions.

Anti-patterns

• Verifying an entire candidate pool when the second candidate already came back deliverable
• Treating unknown as undeliverable and deleting the contact
• Sending a bulk campaign to risky catch-all addresses
• Spending credits without telling the user first
• Reporting "verified" without saying which status came back

Setup

The tools come from the ClearBounce MCP server:

{
  "mcpServers": {
    "clearbounce": {
      "url": "https://clearbounce.net/mcp"
    }
  }
}

Authenticate with OAuth when the client prompts, or send a ClearBounce API key in an X-API-Key header. New accounts include free credits. Setup details for Claude, ChatGPT, Claude Code, Cursor and VS Code: https://clearbounce.net/mcp-server