How AI Agents Verify Email Addresses Before Sending

By Aria Pramesi, founder of InboxPolicy · Updated July 4, 2026

AI agents verify email by calling InboxPolicy's decide_send over MCP, POST /v1/decide over REST, or paying $0.01 in USDC via x402 with no account. Each call runs syntax, MX, and live SMTP checks, then returns one action (send, review, avoid, and others) with a confidence score to branch on.

How does an agent call InboxPolicy to verify an email?

An agent has three ways to reach InboxPolicy: the MCP server's decide_send tool, a REST POST /v1/decide call, or a keyless x402 request. The MCP server also exposes verify_email, batch tools, and a usage tool, so an agent framework calls it the same way it calls any other tool.

With x402, an agent makes a request with no account and no API key. InboxPolicy returns an HTTP 402 with machine-readable payment requirements. The agent attaches an X-PAYMENT header, pays $0.01 in USDC on Base, and gets back its decision plus an on-chain settlement receipt in the same response cycle.

Every call runs the same checks regardless of entry point: syntax, MX record lookup, and a live SMTP conversation against InboxPolicy's own verification engine. A deliverability policy then turns that evidence into one action.

Why does an agent need a decision instead of a raw status?

A raw SMTP status field (valid, invalid, unknown, catch-all) still requires the calling code to encode business logic: which statuses are safe to send to, which need a fallback, which should be retried. That logic gets duplicated across every agent and pipeline that touches email.

InboxPolicy instead returns one of five actions: send, send_with_caution, review, retry_later, or avoid, along with a confidence score and the SMTP evidence behind it. An agent branches directly on the action field, no status-mapping table required.

This matters more for autonomous agents than for a human on a dashboard. A person can eyeball a status column and decide; an agent needs a field it can switch on without a human in the loop.

What happens with unknown or catch-all addresses?

Roughly 30-40% of B2B addresses sit on catch-all domains, where the mail server accepts all recipients and SMTP cannot confirm a specific mailbox exists. InboxPolicy never guesses these as safe.

Unknown or catch-all results map to the review action, not send. That keeps an autonomous agent from firing a send campaign at addresses that only look valid because the receiving server did not reject them.

On the prior verification engine, InboxPolicy's valid-verdict agreement with MillionVerifier ran about 90% typical across 2M+ verifications, though this varies by vertical and drops as low as 60% in some. Treat that as a directional figure, not a formal recent benchmark.

How much does agent-driven verification cost?

Pay-per-call pricing is $0.01 per fresh verification via x402 (USDC on Base), with no account and no API key required. This is also the trial: InboxPolicy has no free tier and no free plan, a deliberate choice, since free tiers attract list-cleaning abuse.

For workloads that do not fit pay-per-call, prepaid credit packs are billed by card with a key emailed: Starter is $5 for 1,000 credits ($5.00/1k), Builder is $19 for 5,000 ($3.80/1k), and Growth is $79 for 25,000 ($3.16/1k). Volume pricing is available on request.

Three things stay free regardless of tier: re-verifying a cached result within 72 hours (returns from_cache, 0 credits), rejecting a malformed email before it reaches SMTP (0 credits), and retrying with the same idempotency key (never billed twice).

How do batches and retries work for agents?

The REST API accepts idempotency keys on every call, so an agent that retries a request after a timeout or a dropped connection never gets billed twice for the same idempotency key.

For bulk work, async batches accept up to 50,000 emails and return per-item results rather than one aggregate status, so an agent can act on each address individually. A signed completion webhook fires when the batch finishes, instead of the agent having to poll for a result.

When should an agent use something else instead?

InboxPolicy is built for send-time decisions inside an agent's workflow, not for every verification job. Three cases point elsewhere:

• Cleaning a huge scraped list in one shot at the lowest cost: MillionVerifier's entry price runs about $0.59-2.50/1k and it resolves unknowns aggressively, which fits one-time bulk cleaning better than a per-send decision API.
• Spam-trap and abuse-address detection: ZeroBounce maintains a spam-trap and abuse database alongside status fields, which InboxPolicy does not build.
• A dashboard-first workflow with CSV uploads: Kickbox and Emailable are built around a marketing dashboard for manual list management, not an API or MCP server an agent calls directly.

Comparison

Frequently asked questions