Compared
Email domain check vs full verification
A domain check tests the address and its mail route without asking about the recipient. Full verification may add recipient-level SMTP evidence when the destination permits it.
| What you want to know | Full check | Domain check |
|---|---|---|
| Evidence gathered | Domain and risk evidence, plus a recipient-level SMTP answer when available | Syntax, domain existence, mail routing and risk signals; no new recipient-level answer |
| SMTP contact | May contact a mail server; any probe stops before DATA and sends no message | Never opens an SMTP session |
| Maximum credit charge | 10 credits | 2 credits |
| Possible result | deliverable, undeliverable, risky or unknown, depending on the evidence | undeliverable, risky or unknown; no positive mailbox verdict |
| API variant | full, the default when variant is omitted | domain, requested explicitly |
| Choose it for | Evidence about a particular address when recipient acceptance matters | Mail-routing questions or a first pass over addresses before deeper checks |
Choose the depth by the decision you need to make. A domain check answers whether the address is well formed and what DNS and known risk signals say about its domain. It can reject a non-existent domain or one with an explicit no-mail declaration. It cannot establish that a particular mailbox exists, so a routable domain alone does not become deliverable.
What full verification adds
A full check starts with the same address and domain evidence. Where useful and permitted, it may open an SMTP session to ask the receiving server about the recipient. It stops before DATA and sends no message. A full request can also finish without a probe: a decisive domain result needs none, and provider policy or technical limits can prevent one. A server may accept every recipient, defer the request or decline to reveal mailbox validity, so even full depth can return risky or unknown.
The reason codes make that boundary visible. A domain check may include SMTP_PROBE_NOT_REQUESTED; a full check can include SMTP_RCPT_ACCEPTED when a recipient probe succeeds. Both depths can report DNS_NXDOMAIN or DISPOSABLE_DOMAIN where the evidence supports them. Read status, action, checks and reason_codes together rather than treating the chosen depth as a verdict.
What it costs and how to request it
A domain check can charge at most 2 credits; a full check can charge at most 10. These are maximums, not a charge on every request. The final charge depends on the result: a verdict uses the depth's maximum, partial routing evidence costs 2 credits, and invalid input, technical failure or unresolved routing costs 0.
The authenticated email verification API defaults to full. To stop before SMTP, send {"email":"person@example.com","variant":"domain"}. The free public domain checker is a separate routing lookup; for recipient-level evidence, use the full email verifier. Neither depth proves inbox placement, future delivery or that a person controls the mailbox. Use an email confirmation when ownership matters.
Where this shows up in a result
Reason codes from the closed vocabulary in the API response. These are the exact strings an integration writes an if against.
SMTP_PROBE_NOT_REQUESTED | Domain depth requested; no recipient-level SMTP probe is performed. |
SMTP_RCPT_ACCEPTED | Recipient accepted |
DNS_NXDOMAIN | Domain does not exist |
DISPOSABLE_DOMAIN | Disposable address provider |
Related terms
MX record
An MX record is a DNS record that names a domain’s incoming mail server and its preference; it does not establish a mailbox.
Catch-all domain
A domain that accepts arbitrary recipient names, so an accepted address may have no individual mailbox.
Role account
An address named for a function, such as support or billing, which may be read by one person or several.
Read a verification result.
See an example of status, recommended action and check evidence. Sign in to check your own address.