Verification is not the same as validation
Validation asks whether an address is well formed. A regex can tell you that jane.doe@acme.com looks right and that jane@@acme is broken. It cannot tell you whether acme.com runs a mail server or whether the jane.doe mailbox was deleted two years ago.
Verification asks whether the address can receive mail right now. That requires looking outside your application: resolving DNS, reading MX records, and asking the receiving server about the mailbox. Most bounces come from addresses that pass validation and fail verification.
The checks that make up a verification
A full verification runs several checks in sequence and stops as soon as one fails. Each step is cheap compared to the next, so a bad address is rejected early and a good one gets the full treatment.
- Syntax: the address follows RFC 5322 rules and has a sensible local part and domain.
- Domain and MX: the domain resolves and publishes at least one mail exchanger.
- Mailbox: an SMTP conversation asks the server whether the mailbox exists, then closes without sending a message.
- Risk signals: disposable providers, role accounts like info@ or sales@, and catch-all domains that accept everything.
- Typo detection: gmial.com becomes a suggested correction instead of a silent bounce.
What the results mean
A good verification service returns a small set of statuses with a reason attached. VeriDock returns four: deliverable, undeliverable, risky, and unknown. Deliverable addresses are safe to send to. Undeliverable addresses should be removed. Risky addresses might work, and the reason field tells you why you should decide case by case. Unknown means the mail server did not give a definitive answer, usually because it timed out or greylisted the check.
Treating unknown as invalid is the most common mistake. Those addresses are often fine, and the right move is to retry later or keep them in a separate segment.
{
"email": "jane.doe@acme.com",
"status": "deliverable",
"reason": "accepted_email",
"score": 97,
"checks": { "syntax": true, "domain": true, "mx": true, "smtp": true,
"disposable": false, "role_account": false, "catch_all": false },
"suggestion": null,
"billed": true
}Where verification fits in your product
The two most common places are signup forms and list imports. At signup, verify on the server after the user submits so you can block throwaway addresses and catch typos while the user is still on the page. For imports, run the whole file through bulk verification before it reaches your email tool, and keep the result next to each row so you can audit later.
Verification cannot guarantee delivery. Mail servers change, mailboxes fill up, and spam filters make their own decisions. What it does reliably is remove the addresses that will never work, which protects your sender reputation and your budget.
Rule of thumb: validate in the browser for instant feedback, verify on the server before the address is stored or mailed.
Key takeaways
0/4Try it on a real address
Run syntax, DNS, MX, disposable, and role checks on any address. No signup needed.
Frequently asked questions
Verify addresses with one API call
250 free checks every month, recurring. Unknown results are never billed.