Email verification is uncertain by nature. This document says where the uncertainty is, so that a result you receive means what you think it means. We do not claim guaranteed deliverability, and no honest verifier can.
1. Which checks are deterministic
These produce a fact. Run twice against an unchanged world, they give the same answer, and we will stand behind it:
- Syntax. Whether the address is well-formed under the relevant RFCs, after normalisation.
- Domain resolution. Whether the domain exists in DNS.
- Mail exchange. Whether the domain publishes MX records and which hosts they name.
- Disposable provider. Whether the domain is on our disposable-provider dataset at the time of the check.
- Role address. Whether the local part matches a known role pattern (
info@,sales@,postmaster@). - SMTP acceptance at RCPT. Where the destination completes the conversation, whether it accepted or rejected the recipient.
2. Which results are probabilistic
These are inferences. They are reported as inferences, in their own fields, and never promoted into a deterministic-looking verdict:
- Mailbox existence behind a catch-all domain. See section 3.
- Confidence score. A number derived from the stored check results, reported separately from status. Status says what happened; confidence says how much weight to put on it.
- Risk signals. Provider-behaviour profiles, domain reputation and trap-likelihood indicators, which describe a population rather than an individual mailbox.
Every score is reproducible from the checks we stored alongside it, and every result records the version of the scoring model that produced it. We publish the score bands and what they mean; we do not publish the weights, because a published weight table is a scoring model that can be gamed by anyone selling a list.
3. How catch-all domains are handled
A catch-all domain accepts mail for every local part, including ones that do not exist. On such a domain, an SMTP acceptance tells you nothing about the specific mailbox.
We therefore report the status catch_all, not valid. This is the single most
common place a verification vendor inflates its numbers, and we do not do it. What you get instead:
- An explicit
catch_allstatus, so your own segmentation can decide what risk it will take. - The evidence that led there, including the provider profile of the destination.
- A confidence score that reflects the uncertainty rather than hiding it.
A catch-all result is billed as a completed verification, because the work was done and the answer — "this domain cannot tell you" — is a real, useful and correct answer.
4. Retries, unknowns and timeouts — and what each costs
A temporary failure is not a result. Temporary SMTP failures are retried under a backoff policy, and a retry never bills a second time: one address, one charge.
When retries are exhausted we return unknown rather than guessing. The billing rule is
narrow and published:
| Outcome | Billed? | Why |
|---|---|---|
| Valid, invalid, catch-all, disposable, role | Charged | A completed verification with a usable answer. |
| Unknown, where the destination's own published policy blocked the check and we hold evidence of it | Charged | The work was performed and the obstacle is the destination's, not ours. The evidence reference is stored on the row. |
| Unknown, where the destination provider caused it and the SMTP conversation reached RCPT | Charged | The conversation completed; the provider declined to answer. |
| Every other unknown, including our own timeouts and infrastructure faults | Free | If we could not do the work, you do not pay for it. |
| Unknown because you have not consented to third-party failover | Free | Your privacy setting is not a service you should be charged for. |
| Duplicate rows in your upload | Free | You are billed per unique mailbox, not per uploaded row. |
A cancelled job returns its unspent reservation; you keep and pay for the rows already verified. See the Refund Policy for the money side of this.
5. How often the detection datasets are updated
| Dataset | Refresh | What happens if it goes stale |
|---|---|---|
| Disposable-provider domains | Daily | Staleness is measured and alerted internally; the check keeps running on the last good snapshot. |
| Role-address patterns | Monthly | Patterns change slowly; a stale set under-detects rather than mis-detects. |
| Domain reputation and provider-behaviour profiles | Continuously, from our own observations | Confidence contribution decays with the age of the observation. |
| Trap and burn-domain registries | Daily | Protection escalates rather than relaxes when the data is old. |
Every result carries the version of the detection logic that produced it, so a result you received six months ago can still be explained by the rules in force at the time rather than by today's.
6. What a result is, and is not
- It is evidence about an address at the moment we checked it. Mailboxes are closed and created every day.
- It is not a promise that a message will be delivered, or that it will reach an inbox rather than a spam folder. Deliverability depends on your sending reputation, your content and the recipient's filters — none of which we can see.
- It is not a substitute for consent. A valid address you have no right to email is still an address you have no right to email.
7. If you think a result is wrong
Tell us at support@verifypro.example with the request id or the job id. Every result stores the checks it was derived from and the logic version that produced it, so a dispute is answered by re-reading the evidence rather than by re-running the check and hoping for a different answer.