Checking an address never emails it. Not once, and not by accident. Here’s why that holds
Email verification
Check one address, clean up a list you already have, or verify every signup as it happens. Every answer comes back with the evidence behind it and a clear recommendation.
5 free checks, no account neededNo credit card required
A real check against the real service. It talks to the mail server and never delivers anything: there is no DATA stage in the probe.
There is no DATA stage in the probe, so nothing can reach the mailbox.
Four answers, and one that admits when nothing safe can be said.
A fixed vocabulary you can write code against, never text from a stranger’s server.
The free checker returns exactly what the API returns, before you sign up.
Why it matters
Take out the addresses that were never going to arrive, before a mailbox provider notices you sending to them.
Every bounce is a small vote against you. Keep invalid and burner addresses out of campaigns, trials and your user table.
Catch a typo while the person is still on the page. That is the one moment it costs nothing to fix.
Three ways in
Three different jobs and three different interfaces. Underneath, the same checks and the same four answers.
01 / Single
For when somebody in support, sales or ops needs a straight answer about one address. You get the verdict, and every stage that led to it.
Check an emailRecommended action: allow
02 / Bulk
Upload the file you already have, watch it work through, then filter by outcome and export only the rows you need.
Explore bulk verification| Deliverable | 104,852 |
| Risky | 9,112 |
| Undeliverable | 9,804 |
| Unknown | 1,652 |
Made-up figures, for the sake of the example. No two real lists break down alike.
03 / Real-time
One call while the person is still typing. The response tells your signup, lead form or checkout whether to let it through, ask for confirmation, add a step, or turn it away.
Explore real-time verification// request
{ "email": "person@example.com" }
// response
{ "status": "deliverable",
"action": "allow",
"confidence": 0.92,
"reason_codes": ["SMTP_RCPT_ACCEPTED"] }How a check runs
There is no score here to take on faith. Each stage asks one question, and the work stops as soon as the answer is settled.
Is it even a well-formed address? Typos, stray spaces and a missing @ are caught here, without touching the network.
Does the domain exist at all, and does it say anything about receiving mail?
Where does mail for this domain actually go? MX records, null MX, implicit MX.
We start a conversation, name the recipient, then reset and hang up. There is no DATA step.
Everything we found becomes a status, a recommended action, and the codes explaining both.
A mail server saying yes is good news, but it is not proof. That yes can come from a catch-all domain, from a gateway that checks properly later on, or from a provider that simply will not tell you whether a mailbox is there. Which is why one of the four answers is “we couldn’t say”.
What you get back
Colour is only a hint. The label, the icon and the recommended action are what carry the meaning.
The mailbox is there and the server accepted it. Nothing was flagged against it.
Typically: Mail exchangers configured · Recipient accepted · No risk flags
Action: allow
The address may well work. Something about it weakens the evidence, and the reason code says what.
Typically: Catch-all domain · Disposable provider · Role account · Looks like a typo
Action: challenge
A hard failure. The address is malformed, the domain doesn’t exist, or it takes no mail at all.
Typically: Bad syntax · Domain does not exist · Domain accepts no mail · Mailbox not found
Action: reject
The mail server wouldn’t say. That happens more often than you’d expect, and a guess would be worse.
Typically: Timed out · Greylisted · Provider throttled · Mailbox existence hidden
Action: allow_with_email_confirmation
pending means the mailbox check is still running. It arrives with a retry_after_ms, so your polling is bounded instead of blind, and it always settles into one of the four above.The response
One thing you will never find in there: the raw text a mail server sent back. It gives away details of someone else’s infrastructure, it can carry control characters you did not ask for, and it changes the day a provider rewords a message. You get stable codes instead.
Running it at scale
The numbers below are still with the platform team. Until they have been measured and signed off, they stay visibly marked rather than quietly invented.
checks per minute
measured uptime
typical response
processing locations
Marked figures are placeholders waiting on approval. We would rather show you a gap than a number we can’t defend.
The probe opens a session, names the recipient, and resets. There is no code path in it that can send mail.
The slow checks are queued and polled on an explicit interval. No request sits holding a socket open and hoping.
Probe evidence can only produce a rejection where we have measured how accurate it is for that provider. Where we haven’t measured, nobody gets blocked.
Integrations
[CUSTOMER QUOTE — TWO TO THREE SENTENCES, NAMED SOURCE]
No quote goes live until Marketing supplies a real one, from a real person who agreed to it.
Pricing
One product, sold by volume. Buy a thousand or buy a million: you get the same checks, the same answers and the same ways in. Only the unit price moves.
Questions
Four things, in order: whether the address is well formed, whether its domain exists, where that domain sends its mail, and what the receiving server says when we name the recipient. Alongside that we look for what makes an address risky even when it works — burner domains, shared inboxes like info@, and domains that say yes to absolutely everything.
No. The probe opens an SMTP session, names the recipient, then resets and disconnects. There is no DATA stage in the prober at all — not one that gets skipped, not one behind a flag. Whoever owns the mailbox never hears about it.
That we couldn’t get a straight answer, and we’d rather say so than invent one. Providers time out, greylist, throttle, or deliberately hide whether a mailbox exists. When that happens the result stays unknown and the advice becomes: let the person in, behind a confirmation email.
Partly, and we’re straight with you about which part. A catch-all domain accepts every address it’s offered, so acceptance says nothing about that particular mailbox. Instead of promoting a guess to deliverable, those come back as risky with an ACCEPT_ALL_DOMAIN code, and you decide what your flow does with them.
Usually not long. Most answers come from syntax, DNS and routing, where nobody else is involved. When a mailbox probe is needed you’re waiting on someone else’s mail server, and a few of them answer slowly on purpose. Those come back as pending with a retry interval, so nothing spins forever. Median and p95 figures go up here once we’ve measured them properly.
The conclusion is. Keeping it is what lets a repeat check answer at once instead of knocking on a stranger’s mail server a second time. How long it’s kept, and how to have it deleted, are on the security page and in the privacy policy.
Start here
Start free, run your first few checks, and see what the answers look like on your own data.