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 two interfaces: the hosted MCP server, which requires an x-api-key, or the REST API. REST accepts either an API key or a keyless x402 payment. 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 a PAYMENT-SIGNATURE 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.

If you're wiring InboxPolicy into a LangChain agent, there's no official adapter — wrap POST /v1/decide as a StructuredTool, or expose the MCP server as a tool provider. See the LangChain email verification integration guide for a source-grounded Python example.

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 normalized signals 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 results map to review. Catch-all results map to review by default or send_with_caution under aggressive strictness. 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?

For API-key calls, the REST API replays the same route, key, and payload while the idempotency record remains valid (24 hours by default). Keyless x402 calls do not use that wrapper; after an indeterminate settlement, do not submit a second payment.

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 at high volume: MillionVerifier's entry price runs $3.90/1k (down to $0.45/1k at 1M volume) and it resolves unknowns aggressively, which fits one-time bulk cleaning at scale better than a per-send decision API. (For comparison, InboxPolicy's 25,000-credit Growth pack is $3.16/1k, while MillionVerifier's 10,000-credit entry purchase costs $39 at $3.90/1k.)
• 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