Choosing a Mode
mode controls how much work happens before a response comes back. This page is a quick reference — for the reasoning behind it, see Real-Time Email Verification API in the blog.
| Mode | What it does | Latency | Use when |
|---|---|---|---|
| fast | Cache-only — never makes a live DNS/RDAP call | Lowest, most consistent | A synchronous pre-check that must never add meaningful latency (see the hybrid pattern in Checking at Signup Without Blocking the Flow) |
| standard | Live DNS/MX/SPF/DMARC + domain age if not cached | Usually fast; bounded by DNS resolver time on a cache miss | The default for most signup, lead, and transaction checks |
| full | Everything standard does, plus a live SMTP handshake | Slowest and least predictable — depends on a third-party mail server | High-value actions where the strongest deliverability signal is worth the latency, or any background/async check where latency doesn't matter |
Rule of thumb
- Never use full mode in a synchronous request the user is waiting on — always run it in a background check instead (see Checking at Signup Without Blocking the Flow)
- standard is the right default for almost everything — it's cached aggressively, so repeat checks against common domains are fast after the first lookup
- fast is for pre-checks and autocomplete-style feedback, not for a decision you're relying on alone
- Bulk jobs can use any mode — full mode on a bulk job just takes longer to process, since it's already async by design
Mode changes confidence, not just speed
The risk score's confidence value reflects how much evidence was actually gathered — a fast-mode result with no cached data carries lower confidence than the same score computed in full mode with a confirmed SMTP result. If you're making an important decision off a fast-mode score, check confidence before trusting it as strongly as a full-mode result.