Service documentation
How verification is performed and interpreted.
A transparent reference for inputs, checks, outcomes, and the limits of mailbox verification.
Method
Progressive checks
The verifier begins with inexpensive local and DNS checks. Eligible addresses may then receive a limited SMTP dialogue from mx1.nordicmailops.com. The conversation stops before the SMTP DATA command, so verification does not submit message content.
- Normalize the input and identify duplicate addresses.
- Check address syntax and whether the domain advertises a mail route.
- Where appropriate, open an SMTP session and inspect the receiving system's response.
- Map the evidence to a deliberately conservative result and preserve its reason.
Input and output
CSV, JSONL, or plain text
Operators can process a plain-text list, a CSV with a recognized email column, or JSONL. CSV output retains original columns and appends verification metadata.
Appended evidence
Output includes the classification, reason, check timestamp, cache state, syntax state, MX state, and available SMTP evidence. Existing output files are protected against accidental replacement.
Outcomes
Four classifications
| Outcome | Meaning |
|---|---|
| Deliverable | The checks produced a positive recipient signal, with no catch-all or other known ambiguity detected. |
| Risky | Catch-all routing, a role or disposable address, a full inbox, or another ambiguous acceptance was detected. |
| Invalid | The address has bad syntax, its domain does not accept mail, the mailbox is disabled, or SMTP explicitly rejected it. |
| Unknown | A timeout, temporary failure, greylisting, rate limit, policy block, or inconclusive provider response prevented a reliable result. |
Operating limits
Low-volume defaults
- Two concurrent checks.
- Twenty new checks per minute globally.
- Five-second spacing for repeated checks to the same recipient domain.
- A persistent maximum of 5,000 SMTP attempts per UTC day across all batches.
- Seven-day caching for conclusive results and 30-minute caching for unknown results.
- No automatic retry by default.
The quota is reserved before a batch starts, so concurrent developer jobs cannot silently exceed the daily ceiling.
Interpretation
Use the reason, not only the label.
Verification results support data maintenance; they do not create permission to contact a person. Operators must consider source, purpose, applicable privacy requirements, prior opt-outs, and the receiving provider's policies separately.
Unknown results should remain unknown. Repeatedly probing an inconclusive provider can create unnecessary traffic and reduce IP reputation, so default operation does not retry them automatically.