What email verification cannot tell you
Every verification vendor has this page. Most of them do not write it. These are the places where the protocol runs out of answers, and where Sortance reports uncertainty instead of hiding it behind a number.
Catch-all domains are a dead end
A catch-all domain accepts mail for every address by design. An SMTP probe against anything@vendor.io returns the same acceptance whether the mailbox exists or not, so there is no signal to read — for anyone. No verifier resolves this, ours included.
What Sortance does instead is report it honestly: a wide confidence_interval, a signals.catch_all flag, and — where more than one provider was asked — a disagreement figure that tells you the pool could not settle it either. A vendor returning a confident valid on a catch-all address is not more accurate than us; it is guessing without saying so.
Where the remaining error actually lives
Same protocol, same providers, two very different outcomes depending on who hosts the mailbox:
| Mailbox host | Verified valid | Not confirmed |
|---|---|---|
| Google Workspace | 90.6% | 9.4% |
| Microsoft 365 | 51.4% | 48.6% |
Microsoft-hosted domains largely stopped answering SMTP probes truthfully. That is why fan-out pays on exactly the addresses one provider cannot settle, and why on Google Workspace mail Sortance will tell you a single cheap check was enough rather than billing you four times for it.
Figures are industry benchmark rates for mailbox host verification, not measurements of Sortance traffic.
Spam traps are invisible to verification
A spam trap is a working mailbox. It accepts mail, it does not bounce, and nothing about an SMTP transaction distinguishes it from a customer who genuinely signed up. Verification answers “will this deliver”, and for a trap the honest answer is yes.
If trap exposure is your problem, the fix is list provenance — knowing where an address came from and how old it is — not a verifier. Sortance will not sell you a trap score.
Deliverable is not the same as appropriate
info@, sales@ and support@ deliver reliably and are usually a poor cold outreach target. An address behind a relay alias delivers to someone whose real address you do not have. An agent_mailbox delivers to software.
This is why actor_class is its own field rather than being folded into a single score. SMTP only ever answers the deliverability question, and collapsing two questions into one number loses the one you actually needed. See agent mailboxes.
When nobody answers
Providers have outages. When every provider in the pool fails, Sortance returns 200 with degraded: true and a probability drawn from the prior rather than from any measurement of that address. It is labelled so you can tell the difference. Do not treat a degraded response as evidence — see the fail-open contract.
A new account is not calibrated to you
On day one, calibration reads "prior": the number comes from a seeded benchmark table, not from your traffic. It only becomes "fitted" once you report real outcomes back. Sortance labels which one you are getting rather than presenting a prior as a measurement.
Enrichment coverage is not 100%
No enrichment vendor knows every company or every person, and Sortance buys from vendors rather than holding data of its own. A small company, a new domain or a personal address often comes back with nothing. When that happens the field is null, never a guess, and enrichment.coverage reports the fraction of the fields you asked for that actually came back. Consumer mailboxes are not enriched at all, so their coverage is 0 by design.
A rule over a missing field evaluates to unknown, and by default (on_unknown: "skip") an unknown rule is skipped rather than matched. That is why a policy that depends on enrichment should send a miss to review rather than deny: otherwise missing data becomes a lost signup. See enrichment.
An ICP score is a rubric, not a prediction
The ICP score is arithmetic over criteria you wrote: each criterion that matches adds its weight, and the total is clamped to 0–100. No model produces the number and nothing is trained on your data. It says how well a signup matches your own description of a good customer, which is not the same as how likely they are to pay.
It is also only as complete as the enrichment under it. Every score carries a coverage figure — the share of the rubric’s weight that could be evaluated — and a 68 at coverage 0.3 is a much weaker statement than a 68 at 0.9. Whether a high score actually converts better is something only your outcome data can tell you. See ICP.
Without the metadata key, the Stripe join is approximate
Connecting Stripe only helps if a payment can be tied back to the signup decision that let the person in. The exact way is to set metadata.sortance_trace_id on the Stripe customer when you create it. Without it, Sortance falls back to the customer’s email: hashed, then matched to your most recent decision for that hash in the 90 days before the event.
That fallback is wrong whenever someone signs up with one address and pays with another, and it cannot tell which. Every event records how it was joined (exact, by_email or none), and segment reports count each method separately so the caveat travels with the numbers. See the Stripe integration.
Questions people actually ask
Can any email verifier resolve a catch-all domain?
No. A catch-all domain is configured to accept mail for every address at that domain, so an SMTP probe returns the same acceptance for a real mailbox and for an address nobody has ever used. There is no signal to read. Sortance reports a wide confidence interval rather than a guess dressed as a verdict.
Why do Microsoft 365 addresses verify so much worse than Google Workspace?
Microsoft-hosted domains largely stopped answering SMTP probes truthfully, so a check that resolves cleanly on Google Workspace comes back unresolvable on Microsoft 365. It is not a provider being bad at its job — the protocol simply stopped carrying the answer.
Does Sortance detect spam traps?
No. A spam trap is a real, deliverable mailbox whose owner never opted in — deliverability checks cannot distinguish it from any other working address, because there is nothing about it to detect. Any vendor claiming trap detection is inferring from list provenance, not verifying the address.
Does a low bounce probability mean the address is safe to cold-email?
No. Deliverability and appropriateness are different questions. A role account like info@ is usually perfectly deliverable and usually a bad idea to cold-mail, which is why actor_class is a separate field from bounce_probability rather than folded into one score.
Why will Sortance not claim 99.9% accuracy?
Because the number would be meaningless. Accuracy depends entirely on the mix of domains in your list — catch-all domains cannot be resolved by anyone, and Microsoft-hosted mail confirms valid about half the time. A single headline figure hides exactly the variance that decides whether the product is useful to you.