Email Verification for AI SDR Agents: A Send or Skip Field That Agents Can Use

An AI SDR agent should verify every address right before it sends, and it should decide from a single field. On SimpleVerifier's API that field is action: send, send_with_care, retry_later or do_not_send. Add the likely_invented flag to catch addresses a language model made up, and route catch-all results to a slower path. That is most of the safety an agent needs.

Agents are good at writing emails and bad at knowing whether an address exists. They will happily produce jane.smith@company.com because it fits the pattern, whether or not Jane works there.

Where bad addresses come from in an agent loop

Source	Typical problem
Pattern guessing	Generates first.last@ for a person who uses flast@
Web scraping	Picks up old staff pages, typos or obfuscated addresses
LLM output	Invents a plausible address when it cannot find one
Third-party enrichment	Returns addresses checked weeks or months ago
Placeholders	test@, john.doe@, example.com left in prompts or templates

A human SDR would notice some of these. An agent sending 200 emails a day will not, and the sending domain pays for it in bounces.

The minimum safe loop

1. Agent selects a lead and drafts the email.
2. Agent calls the verification API with the address.
3. Agent reads action and branches.
4. Agent logs reason_code so a person can review later.

Verify at send time, not when the lead was found. A lead found three weeks ago and verified then is a three-week-old result.

The fields an agent should read

A call to https://simpleverifier.com/api/v1/verify?email=... with a Bearer key returns, among other things:

{
  "email": "jane@company.com",
  "status": "valid",
  "action": "send",
  "risk": "low",
  "likely_invented": false,
  "reason_code": "mailbox_exists"
}

Full details are in the API docs. The four fields that matter for an agent:

Field	Values	How to use it
action	send, send_with_care, retry_later, do_not_send	The decision
risk	low, medium, high	A tiebreaker or for sorting
likely_invented	true / false	Hard skip, and a signal the agent is guessing
reason_code	Stable codes, e.g. mailbox_exists	Logs and explanations

action follows strict rules. Only status: valid gives send. invalid always gives do_not_send. Catch-all, role inbox and provider-hides-status results give send_with_care. Refusals, timeouts and DNS failures give retry_later. Reason sentences can be reworded over time; reason_code values do not change, so branch on codes, not text. Treat an unknown code like other and go by action.

Mapping actions to agent behaviour

action	What the agent should do
send	Send
send_with_care	Do not send from the main queue. Move to a slower path, or ask a human
retry_later	Re-queue the check in a few hours
do_not_send	Drop the address. Try to find a different one for the person

For send_with_care, look at why. A catch-all address graded higher likelihood may be worth sending at low volume. A role inbox like info@ usually is not, for cold outreach.

Catching invented addresses

likely_invented is true when the address looks made up. It is never true for a confirmed mailbox. Otherwise it is set only for:

• Placeholder local parts: test@, demo@, user@, john.doe@, firstname.lastname@ (trailing digits ignored).
• Reserved or template domains: example.com, .test, yourdomain.com.
• A domain with no mail server at all, when it is not a typo of a real one.
• Sequential or repeated local parts: 1234@, abcd@, aaaa@.

Role inboxes and real-looking names are never flagged by it. When likely_invented is true, risk is high.

Treat a run of likely_invented results as a bug report. It usually means the agent's prompt is letting it fill gaps with guesses, or a template variable did not resolve.

Catch-all handling for agents

Catch-all domains accept every address at the check stage, so no verifier can confirm the mailbox. SimpleVerifier never marks them valid. It returns catch_all_confidence as higher, medium or lower, with reasons.

A sensible agent policy:

• Higher: allowed into a separate, lower-volume campaign.
• Medium: only for high-value leads, or after a human approves.
• Lower: skip.

The catch-all verification page explains how the grades are made.

Using MCP instead of raw API calls

If your agent runs in a tool that supports the Model Context Protocol, such as Claude or Cursor, you can give it verification as a tool rather than writing HTTP code. The MCP docs list the tools and how to connect. Results carry the same action, risk, likely_invented and reason_code fields.

Give the agent an explicit instruction too: "Never send to an address unless the verify tool returned action send." Agents follow explicit rules better than implied ones.

Rate limits and cost

Each API key allows 120 calls a minute. Pro includes 10,000 API calls a month, then $1.50 per 1,000 on monthly billing. Business includes 100,000 and Agency 300,000, then $1.00 per 1,000. List uploads count separately from API calls. Prices are on the pricing page.

For an agent sending a few hundred emails a day, the included calls on Pro usually cover it.

Checklist for an agent builder

• Verify at send time, every time.
• Branch on action, log reason_code.
• Hard-skip likely_invented: true.
• Keep catch-all sends in their own queue with a lower daily cap.
• Retry retry_later results instead of sending.
• Alert a human if do_not_send or likely_invented passes a set share of checks.

Try a few addresses yourself on the verify page. The first 100 checks are free with a Google sign-in, no card.