Single check
Know if it will bounce before you hit send.
Syntax, DNS, MX and the mailbox itself, returned as a scored report you can act on.
Try it now
Check any address against the live engine. No account, no card. What comes back is the same verdict the API returns.
- 01
Mailbox-level
We talk to the receiving server, not just the domain.
- 02
Explainable score
Every result includes reason codes, not only a colour.
- 03
Typo suggestions
Obvious domain misspellings are called out before you spend the send.
- 04
Safe for lists
Stricter-than-RFC input so hostile addresses never reach SMTP.
- 05
Provider-aware
Gmail and Microsoft constraints surface as explicit codes.
- 06
API or UI
The same engine as POST /v1/check_email.
Method
What happens in the second after you press Verify.
Four stages, in order, each one able to end the check on its own. Nothing is inferred from a list of known-bad domains.
- 01
Parse and normalise
The address is read against stricter-than-RFC rules and reduced to the form the receiving server will actually see. Hostile syntax is rejected here, before a credit is spent.
- 02
Resolve the domain
DNS, then MX. A domain that publishes no mail exchanger accepts no mail, and that is a finished answer rather than a guess.
- 03
Ask the mail server
We open an SMTP connection to the receiving host and probe the recipient. Catch-all, full, disabled and role mailboxes are each classified, not lumped together.
- 04
Score and explain
The signals become a 0 to 100 score, a verdict, a recommended action, and the reason codes that produced them.
Response
What a single check gives you back.
The fields most integrations branch on. The full object carries the DNS, SMTP and provider detail behind each one.
| Field | Values | What it tells you |
|---|---|---|
| is_reachable | safe | risky | invalid | unknown | The verdict. Four values, and they are exhaustive: every check lands on exactly one of them. |
| score.score | 0-100 | How confident we are that the address will accept mail. Your threshold is a config value on your side, not a decision we make for you. |
| score.reason_codes | string[] | Stable machine values naming each signal that moved the score, so your code branches on codes rather than on English prose. |
| smtp.is_catch_all | boolean | True when the domain accepts mail for every recipient. Nobody can resolve a catch-all to a single mailbox, so we say so instead of calling it valid. |
| misc.is_disposable | boolean | True for throwaway and temporary inbox providers, checked against a list that is maintained rather than snapshotted. |
| bounce_risk.action | send | send_with_caution | do_not_send | verify_manually | The recommendation, if you would rather act on one field than build your own rule from the score. |
FAQ
Questions before you send the list
How is this different from a regex?
A regex cannot tell you the mailbox is full, catch-all, or disabled. We ask the mail server.
Do you store the address?
Guest checks store a keyed hash, not the address. Account checks follow the retention in your plan.
What does risky mean?
The address resolved, but catch-all, role, or reputation signals raise bounce or complaint risk.
Can I check an address at signup?
Yes. One API call at capture stops the typo before it enters the database. The dashboard and the free checker on this page run the same engine.
How long does one check take?
Usually under a second. A receiving server that is slow to answer gets a bounded window, and when it runs out the verdict is unknown rather than an invented one.
Which addresses can nobody verify?
Two kinds. A catch-all domain accepts mail for every recipient, so no provider on earth can resolve one address inside it. And some mail servers refuse recipient probes outright as an anti-harvesting measure. Both come back as risky or unknown, with the reason code that says which.
Run your first 100 on us.
No card. Credits never expire until you use them.