Most email verifiers are black boxes. You submit an address, you get a verdict, you have no idea what happened in between. Here is what happens inside MailoClean from the moment your API call lands to the moment we send the response back.
Step 1: Request validation (5-10ms)
The API receives your request, authenticates your bearer token, applies rate limiting based on your plan, and parses the email address. Basic syntax checks run here: the local-part has valid characters, the domain has at least one dot, the string is shorter than RFC's 254-character limit.
Step 2: Cache check (1-2ms)
If we have verified this exact address in the last 24 hours, the cached result returns immediately. This costs you zero credits and shaves about 1.4 seconds off the response. Cache key is a hash of the lowercased address, so case differences do not split cache entries.
Step 3: Disposable and role-based pattern matching (1ms)
Two fast checks happen in parallel before any network call:
- Domain against the disposable list (~130,000 domains, updated multiple times daily).
- Local-part against the role pattern list (info, admin, sales, support, and 60+ others).
These set flags on the result; the actual deliverability check still runs.
Step 4: DNS resolution (10-100ms)
We resolve the domain's MX records. If no MX exists, the domain cannot receive mail. We mark invalid and return.
If MX exists, we cache the results internally. Common domains like gmail.com, outlook.com, and yahoo.com have static cache entries to avoid repeated lookups.
Step 5: SMTP probe (300-1800ms)
We open a TCP connection to the highest-priority MX server, port 25 (or 587 if 25 is blocked). The conversation:
EHLO mailoclean.com
MAIL FROM: <verify@mailoclean.com>
RCPT TO: <target@target-domain.com>We read the response code on RCPT TO. 250 means accepted; 550 means rejected; 4xx codes indicate temporary problems (greylisting, rate limit, server busy).
Step 6: Catch-all detection
If the RCPT TO response was 250, we run a second probe against a guaranteed-fake address at the same domain: x9z7q3pq8k2m@target-domain.com. If this also returns 250, the domain is catch-all and the original verification is ambiguous. We return catch_all status with confidence score 70.
If the fake address returns 550, the domain is not catch-all and the original 250 was a real positive. We return valid status with confidence score 95.
Step 7: Greylist handling
4xx responses sometimes indicate greylisting. We back off, retry with delay, and re-probe. If the address eventually responds with a definitive 250 or 550, we use that. If it stays in 4xx after the retry window, we mark risky with the greylisted flag set.
Step 8: Reputation signals
Before returning the response, we check the address against several external signals:
- Known spam-trap addresses (we keep a regularly-updated list).
- Free email provider classification (gmail, yahoo, outlook are flagged as free).
- Engagement history (for addresses that have been verified multiple times and show patterns).
Step 9: Scoring
We compute a 0-100 confidence score based on:
- SMTP response (definitive yes/no scores high; catch-all scores middle; ambiguous scores low).
- Reputation flags (disposable subtracts, spam-trap subtracts heavily).
- Domain reputation (well-known providers score higher than obscure domains).
- Engagement history if available.
Step 10: Response and caching
We assemble the response: status, score, individual check booleans, provider response message. Cache the result for 24 hours, charge one credit (only on definitive results), and return JSON.
The total latency budget
| Stage | Time |
|---|---|
| Validation + auth | ~10ms |
| Cache check | ~2ms |
| Pattern matching | ~1ms |
| DNS / MX | ~50ms |
| SMTP probe | 800-1500ms |
| Catch-all probe | +400ms when needed |
| Scoring + response | ~5ms |
| Total p50 | ~1.4s |
FAQ
Why so many steps?
Each step exists to handle a specific failure mode. Skipping any one results in misclassification on a specific class of address.
Can I see the raw SMTP response?
For debugging, the API can return the underlying SMTP response code in the provider_response field. Useful when investigating edge cases.
Run it yourself
Free single check on the homepage shows the same engine. The breakdown panel exposes each check individually.