---
title: "Email Verification API: Verify Before You Send | Derrick"
description: "Email verification API returning a status per address over REST, Sheets and MCP. Read every result right, cut bounces, pay 1 credit per email checked."
canonical: "https://derrick-app.com/email-finder/verification-api"
category: "Email Finder"
updated: "2026-07-22"
---

# Email verification API: check every address before you send

> An email verification API is an HTTP endpoint that takes an email address and returns a structured verdict on whether it can actually receive mail, without sending anything to the person. It runs four checks behind one answer: syntax, domain and MX records, a mailbox probe, and risk classification for role accounts, disposables and catch-all domains. Derrick verifies at 1 credit per email, billed per result, over REST from the Standard plan, inside a Google Sheets sidebar from the Mini plan, and from Claude through an MCP server. The point is deliverability: mailbox providers judge senders on failed deliveries, and most teams work to a bounce rate under 2 percent.

*Canonical: https://derrick-app.com/email-finder/verification-api* · *Email Finder*

---

You cannot check a mailing list by eye, and you should never check it by sending to it. An email verification API turns that check into part of your software: one request per address, one structured answer, no person in the loop. This guide covers what the check actually inspects, how to read every status it hands back, when to call it live at a form versus in bulk before a campaign, what it should cost you per address, and how to run the exact same check from a spreadsheet or an AI assistant when writing code is beside the point.

## What is an email verification API?

An email verification API is an HTTP endpoint that takes an email address and returns a structured verdict on whether that address can actually receive mail. You send `jane.doe@acme.com`, and you get back a status, a reason, and the supporting signals your code needs to decide what happens next. Nothing is sent to the person. The check happens against the receiving infrastructure, not through a test message that would land in someone's inbox and burn your reputation to learn a fact you could have looked up.

The reason teams reach for the endpoint rather than a dashboard is that verification is rarely a one-off. A signup form needs the check to run in the second between a user typing an address and the form submitting. A CRM needs it to run on a schedule, because contact data goes stale on its own: people change jobs, companies get acquired, and mailboxes are decommissioned without telling anyone. A campaign needs it to run right before send, not three months earlier. Each of those is a machine calling a function, which is exactly what an endpoint is for. Derrick's [Email Verification](https://derrick-app.com/features/email-verification) feature costs 1 credit per email checked, billed per result, and the same engine is reachable over REST, from Google Sheets, and from an MCP-compatible AI assistant.

The stake is deliverability. Mailbox providers judge a sender largely on how often they try to deliver to addresses that do not exist, and the operational threshold most teams work to is a bounce rate under 2 percent. Cross it repeatedly and inbox placement degrades for every message you send afterwards, including the ones going to perfectly valid contacts. Verification is the cheapest insurance available against that outcome: at 1 credit per address, checking ten thousand contacts costs less than the price of one badly damaged sending domain.

![email verification API four checks](/illustrations/articles/verification-api/ef-v1-four-checks.webp)The four checks behind a single verification result.

## How an email verification API works: the four checks behind one answer

A single call looks instant. Behind it, four distinct checks run in increasing order of cost and certainty, and knowing which one produced your answer is what lets you handle an ambiguous result instead of treating every response as a yes or a no.

### Syntax and formatting

The first pass is structural: is the string a legal address at all? This catches the typos that dominate form submissions, missing at-signs, trailing spaces pasted from a CRM export, double dots, and characters that are not permitted before the domain. It is cheap and it is decisive. An address that fails here can never receive mail, so no further check is needed.

### Domain and MX records

Next, the domain itself is resolved and queried for mail exchange records. A domain with no MX record has nowhere to deliver mail, which is common with parked domains, expired registrations, and the near-miss typos of real companies. This step also flags disposable domains, the throwaway inboxes people use to get past a signup gate, which are technically deliverable but worthless to a sales pipeline.

### The mailbox probe

The third check opens a conversation with the receiving mail server and asks whether that specific mailbox exists, without ever completing a delivery. This is the step that separates a real verification service from a syntax checker, and it is also the step that fails in interesting ways: some servers answer honestly, some accept everything, and some deliberately delay unknown senders. That variability is why a good response carries more than a yes or a no.

### Risk classification

Finally, the address is classified beyond deliverability. Is it a role account like `contact@` or `billing@` that reaches a shared inbox rather than a person? Is it on a domain that accepts all mail regardless of the local part? Is it a known spam trap? These flags do not make an address undeliverable, but they change whether you should include it in an outbound sequence, and no amount of raw SMTP scripting will produce them for you.

![email verification API response status codes](/illustrations/articles/verification-api/ef-v2-status-actions.webp)What each verification status should trigger in your code.

## Reading the response: what each status should trigger

The mistake that wastes most verification budgets is treating the response as a boolean and discarding everything that is not a clean pass. Roughly a fifth to a quarter of a typical B2B list comes back as something other than plainly valid, and how you route those rows decides whether verification made your campaign better or just smaller. Each class of answer, and what it should trigger in your code:

| Status | What it means | What your code should do |
| --- | --- | --- |
| Valid | The mailbox exists and accepts mail | Send. This is the only class that belongs in a cold sequence by default. |
| Invalid | Syntax, domain, or mailbox check failed definitively | Suppress permanently and record why, so the same address never re-enters from another import. |
| Catch-all | The domain accepts every address, so the mailbox cannot be confirmed | Hold in a separate segment. Send only to high-value contacts, and watch bounces closely. |
| Risky | Role account, disposable domain, or trap-like pattern | Exclude from outbound. Role accounts are fine for support replies, not for prospecting. |
| Unknown | The server refused to answer, often greylisting or rate limiting | Re-queue and retry later rather than deleting. A large share resolve on a second pass. |

Catch-all domains deserve their own policy because they are so common in mid-market and enterprise B2B, where a security appliance sits in front of the mail server and accepts everything by design. Deleting them removes a meaningful slice of your best accounts; sending to them blindly inflates your bounce rate. The workable middle is a separate segment with a lower send volume and tighter monitoring, which we break down in our guide to [detecting and managing catch-all addresses](https://derrick-app.com/email-finder/catch-all). The unknown bucket deserves patience for a different reason: it is usually a temporary refusal, not a verdict, and throwing those rows away silently shrinks your reachable market.

## Real time at the form, or bulk before the campaign

There are two moments worth spending a verification call on, and they answer different questions. Real time means the check runs at the point of capture, while the user is still on the page, so a typo gets corrected before it ever enters your database. That is the cheapest possible intervention: one call, one address, and a data quality problem that never happens. The tradeoff is that the call sits inside a user-facing request, so it has to be fast and it has to fail open, letting the signup complete rather than blocking a real customer because a mail server was slow.

Bulk means the check runs across a list you already hold, before you use it. This is the pass that matters for outbound, because an address verified four months ago is not verified today. Data decay is continuous, not an event, and the practical rule most teams land on is to re-verify any list older than about ninety days before a send, plus every list that arrived from outside your own capture flow. Our deep dive on [real-time versus scheduled verification](https://derrick-app.com/email-finder/real-time-verification) covers how to sequence the two so you are not paying twice for the same address.

The two are complements, not alternatives. Real time protects the front door; bulk protects the campaign. Teams that only do the first end up sending to contacts who were valid at signup and have since left the company. Teams that only do the second keep letting bad data in and pay to clean it later, which is strictly more expensive.

![email verification API in your stack](/illustrations/articles/verification-api/ef-v3-stack-fit.webp)Four places an email verification API earns its keep.

## Where an email verification API fits in your stack

An email verification API earns its keep in four specific places. Naming them turns "we should verify our data" into something you can actually put on a sprint board.

**The signup form.** A call on submit stops fake and mistyped addresses at the boundary. It also stops disposable domains from consuming trial capacity, which for a self-serve product is a direct cost line and not just a data hygiene concern.

**The CRM pipeline.** A scheduled job that walks records older than a set age and re-checks their addresses keeps the database honest without anyone remembering to do it. Pair it with a field that stores the verification date, because the useful question is never just whether an address was valid, it is when you last confirmed it.

**The pre-send gate.** A step in your outbound workflow that verifies immediately before dispatch, and routes anything that is not clean to a holding segment. This is the one that pays for itself fastest. It is the last place you can stop a bounce rather than measure one.

**Agent and automation workflows.** When an AI assistant or a no-code automation is building a list as part of a larger task, verification has to happen inside that flow, not as a manual step afterwards. Because Derrick exposes a REST API, it plugs into Zapier, Make, and n8n alongside three thousand other apps, so verification becomes one node in a pipeline you already run. If you also need to discover addresses rather than only check them, the companion [email finder API](https://derrick-app.com/email-finder/api) resolves a name and a domain into a verified address in the same call.

![email verification API cost per address](/illustrations/articles/verification-api/ef-v4-cost-budget.webp)Verification cost per address across Derrick plans.

## What verification should cost, and how to budget it

Verification pricing is easy to reason about once you convert everything to a cost per address, which is the only number that matters when you are sizing a list. Derrick bills verification at 1 credit per email, charged on results, and every plan bundles a credit balance that rolls over when you do not spend it. That makes the arithmetic direct: your cost per verified address is simply the plan's price divided by the credits it carries.

| Plan | Price | Credit balance | Cost per address verified |
| --- | --- | --- | --- |
| Free | 0 EUR | 100 credits per month | Verification is not on this tier. Free credits cover the LinkedIn and data-cleaning features. |
| Mini | 9 EUR | 4,000 credits | About 0.00225 EUR |
| Standard | 20 EUR | 10,000 credits | 0.002 EUR, and the first tier with API access |
| Plus | 47.50 EUR | 25,000 credits | About 0.0019 EUR |
| Pro | 175 EUR | 100,000 credits | About 0.00175 EUR |

Two details change how you should plan. First, verification itself is available from the Mini plan upward, while the REST API and the MCP server unlock at Standard. If you only need bulk checking from a spreadsheet, you do not need to pay for programmatic access; if you are wiring verification into a product, Standard is the entry point. Second, credits roll over on paid plans, which means a list-building month and a quiet month average out rather than forcing you to over-provision for your peak.

Set against that, a single bounce-driven deliverability incident costs weeks of degraded inbox placement across every campaign. At these unit prices, verifying a hundred thousand addresses costs less than most teams spend on a single month of sending tooling, which is why the decision is usually about integration effort rather than budget.

![email verification in Google Sheets](/illustrations/articles/verification-api/ef-v5-sheets-sidebar.webp)Verify a list from the Derrick sidebar in Google Sheets.

## Verify without writing code: the Google Sheets route

Plenty of verification work never justifies an integration. A list came out of an event, a partner sent a spreadsheet, a rep exported a segment and wants to know what is safe to touch. For all of that, Derrick runs as a sidebar inside Google Sheets: you point it at a column of addresses, pick the verification feature, and it writes the status back into the columns beside them, row by row, across the whole sheet. There are no spreadsheet formulas to learn and nothing to deploy.

This matters more than it sounds, because it decouples verification from engineering availability. The person who owns the list can check it themselves, on the same data, with the same engine that the API calls. A row cleaned in a sheet and a row cleaned by a nightly job come out identical, so you are not maintaining two definitions of what "verified" means. And it scales in both directions: a hundred rows and a hundred thousand rows run through the same sidebar, so a quick sanity check and a full database pass are the same workflow at different sizes. Our walkthrough of [finding and confirming valid professional emails](https://derrick-app.com/email-finder/valid) shows the sheet-side flow end to end.

## Verification from an AI agent: the MCP route

The newest place verification needs to live is inside an AI conversation. When an assistant is researching accounts, assembling a contact list, or drafting outreach, it needs to confirm an address mid-task rather than handing the job back to a person. [Derrick MCP](https://derrick-app.com/mcp) exposes the enrichment engine over the Model Context Protocol, so Claude, ChatGPT, or any MCP-compatible tool can call verification as a tool step and act on the result in the same turn. It is available from 20 EUR per month, the same tier that unlocks the REST API.

The practical effect is that verification stops being a stage in a pipeline and becomes something an agent simply knows how to do. Ask for a list of contacts at a set of target accounts and the assistant can return addresses already checked, with the risky ones flagged, instead of a plausible-looking list you then have to clean. For teams building agentic workflows, that is the difference between an assistant that produces work and one that produces work you have to audit.

## Email verification API vs a homemade SMTP script

Any engineer can write a script that opens an SMTP connection and asks whether a mailbox exists. The question is what happens after the first hundred addresses, and this is where a purpose-built email verification API separates from a weekend project.

| Dimension | Homemade SMTP script | Verification API |
| --- | --- | --- |
| IP reputation | Probes come from your own IP, which gets rate limited and blocklisted | Runs on infrastructure built and maintained for probing |
| Catch-all handling | Reads as valid, silently poisoning your list | Flagged as its own status you can route separately |
| Risk signals | None. Role accounts, disposables, and traps look like anyone else | Classified in the same response |
| Greylisting | Reads as a failure, so good contacts get deleted | Returned as unknown and retried |
| Maintenance | Ongoing, and it breaks quietly when providers change behaviour | None on your side |

The failure mode of the homemade version is not that it does not work. It is that it appears to work while quietly producing wrong answers, deleting valid contacts that were merely greylisted and passing through catch-all addresses that will bounce. You discover the damage in the campaign metrics, after the send, which is exactly the moment it stops being fixable.

## Mistakes that make verification useless

Verification is easy to run and easy to run pointlessly. Five patterns account for most of the wasted spend.

**Verifying once and treating it as permanent.** A verification result is a timestamped observation, not a property of the address. Store the date alongside the status and treat anything past ninety days as unconfirmed.

**Deleting the ambiguous rows.** Unknown and catch-all are instructions to handle differently, not to discard. Teams that delete them quietly shrink their addressable market by a double-digit percentage.

**Verifying after the send.** Cleaning a list in response to a bad campaign is measuring the damage, not preventing it. The check belongs before dispatch, as a gate.

**Trusting a guessed address because it looks plausible.** Pattern matching a name against a domain produces strings that read correctly and bounce anyway. If you are generating addresses rather than finding them, verification is not optional, it is the only thing standing between you and your sender reputation. Derrick's [Email Finder](https://derrick-app.com/features/email-finder) verifies as part of the same lookup at 5 credits per email found, so a discovered address arrives already checked.

**Ignoring the classification fields.** Sending outbound to `info@` and `support@` addresses is a reliable way to look like a bulk sender to the people whose job is to spot bulk senders. The risk flags are there so you can act on them.

Get those five right and verification stops being a chore you run before campaigns and becomes a property of your data. The check itself is a single call; the discipline is in when you make it and what you do with the answer. Start with the pre-send gate, add the signup check, then schedule the CRM pass. [Install Derrick free with 100 credits per month](https://derrick-app.com/?utm_source=blog&utm_medium=article&utm_campaign=ef-verification-api), then switch verification on from the Mini plan and clean your first list, in a spreadsheet or over the API, whichever fits how you work.

## Use Derrick in Claude (MCP) or via API

Derrick isn't only a Google Sheets add-on. The same B2B data enrichment runs as an MCP server (use it directly inside Claude and other AI agents) and as a REST API:

- **Claude / AI agents (MCP)**: connect the Derrick MCP server, then enrich from chat. Setup: /mcp
- **REST API**: call the same enrichment endpoints from your own stack (Standard plan and up). Docs: https://app1.derrick-app.com/api/v1/docs/

## FAQ

### What is an email verification API?
An email verification API is an HTTP endpoint that takes an email address and returns a structured verdict on whether it can receive mail. It checks syntax, the domain's mail exchange records, and the mailbox itself, then classifies the address for risk. Nothing is sent to the person, so you learn whether an address is safe without touching your sending reputation.

### Does Derrick have an email verification API?
Yes. Derrick's Email Verification runs over a documented REST API, from a Google Sheets sidebar, and from an MCP server that lets Claude and other AI assistants call it as a tool. API access and MCP unlock on the Standard plan at 20 EUR per month, while verification itself is available from the Mini plan at 9 EUR.

### How much does email verification cost per address?
Derrick bills verification at 1 credit per email, charged per result. That works out to roughly 0.00225 EUR per address on the Mini plan and about 0.00175 EUR on Pro, since each plan carries a credit balance that rolls over. Verification is a paid feature: it starts on the Mini plan, while the Free plan and its 100 credits per month cover the LinkedIn and data-cleaning features instead.

### What should I do with a catch-all result?
Do not delete it and do not treat it as valid. A catch-all domain accepts every address by design, usually because a security appliance sits in front of the mail server, so the mailbox cannot be confirmed either way. Put those rows in their own segment, send only to high-value contacts, and monitor bounces on that segment separately.

### Can an email verification API guarantee zero bounces?
No, and any service promising that is overselling. Greylisting, catch-all domains and mailboxes closed between the check and the send all create residual risk. What verification does reliably is remove the addresses that were never going to work, which is what keeps a bounce rate under the 2 percent range mailbox providers care about.

### How often should I re-verify a list?
Treat a verification result as a dated observation rather than a permanent property. Most teams re-check any list older than about ninety days before a send, plus every list that came from outside their own capture flow. Storing the verification date next to the status is what makes that rule enforceable in code.

### Do I need to write code to verify emails with Derrick?
No. Derrick runs as a sidebar inside Google Sheets, so you can point it at a column of addresses and write the statuses back across thousands of rows without any integration. The REST API, the MCP server for AI assistants, and no-code tools like Zapier, Make and n8n all reach the same verification engine.

## Related

- [Lead Email Finder: The Complete Guide to Finding Your Prospects' Emails](https://derrick-app.com/email-finder/lead)
- [How to Find a Company Website: Complete 2026 Guide](https://derrick-app.com/email-finder/find-from-website)
- [Find Company Name & Website from Email: 4 Methods (2026, Tested)](https://derrick-app.com/email-finder/find-company-from-email)
- [Valid Email Finder: How to Find and Verify Valid Professional Emails](https://derrick-app.com/email-finder/valid)
- [Catch-All Email: How to Detect and Manage Them in B2B Prospecting](https://derrick-app.com/email-finder/catch-all)
- [Email Bounce Checker: Verify Every Address Before You Hit Send](https://derrick-app.com/email-finder/bounce-checker)
- [Real-Time Email Verification: Definition, How It Works, and Why It Matters in 2026](https://derrick-app.com/email-finder/real-time-verification)
- [How to Find a LinkedIn Profile by Email Address](https://derrick-app.com/email-finder/find-linkedin-by-email)
- [Cold Email Benchmarks 2026: What Reply, Open and Bounce Rates Should You Expect?](https://derrick-app.com/email-finder/cold-email-benchmarks-2026)
- [How to Find a Company Founder's or CEO's Email: 5 Methods (2026)](https://derrick-app.com/email-finder/founder-email)
- [How to Find Someone's Email from a LinkedIn Profile](https://derrick-app.com/email-finder/from-linkedin-profile)
- [Email Finder API: find and verify professional emails at scale](https://derrick-app.com/email-finder/api)
- [LinkedIn Email Finder Tools: The Buyer's Guide to Choosing One](https://derrick-app.com/email-finder/linkedin-tools)
- [How to Find CFO Email Addresses for B2B Sales](https://derrick-app.com/email-finder/cfo-email-addresses)
- [Executive Email Addresses](https://derrick-app.com/email-finder/executive-email-addresses)
- [Company Email Address: Generic vs Named](https://derrick-app.com/email-finder/company-email-address)
- [Sales email sequence: how to structure one that gets replies](https://derrick-app.com/email-finder/sales-email-sequence)
- [How to Buy an Email List, and What It Really Costs](https://derrick-app.com/email-finder/buy-email-list)
- [Email Scraper: What It Actually Returns, and Why the List Bounces](https://derrick-app.com/email-finder/email-scraper)