How it works

Six passes, cheapest first, stop at the first certain answer.

Barometer is a pipeline, not a single lookup. Each stage adds reasons with weights. The score is 50 plus the sum of the weights, and the verdict follows from the score and the kind of evidence behind it.

Cheapest first

String rules run in microseconds, DNS in milliseconds and cached per domain, the SMTP probe in seconds. Paid evidence and the model only run when you ask for the deep tier.

Short-circuit on certainty

A fatal finding ends the check. A disposable domain never reaches DNS, a domain with no MX never reaches a mail server, and a reported bounce never gets probed again.

Unknown is free

If the server greylists us, times out, or says nothing useful, the verdict is unknown and costs 0 credits. Batches retry those leads after 5, 15, and 45 minutes.

The pipeline

A fast check (1 credit) runs stages one to four plus the name and company-domain match. The deep tier (5 credits) adds GitHub and web evidence and the reviewer model.

1
Static rules
Pure string checks against the address: RFC syntax, common domain typos with a suggested fix, more than 120,000 disposable and relay domains, placeholder patterns like you@company.com, noreply and mailer-daemon addresses, and role inboxes such as info@ or sales@.
Microseconds · no network
2
DNS
We resolve MX records (and honor null MX), fingerprint the mail provider and any security gateway in front of it, and read SPF and DMARC. A domain that cannot receive mail stops here. Results are cached per domain, so a list of 10,000 leads at one company costs one lookup.
Milliseconds · cached per domain
3
Outcome history
When you report what happened after a send, it becomes evidence. A hard bounce makes the address undeliverable on every future check; deliveries and replies raise confidence. History is keyed by a salted hash of the address, never the address itself.
Milliseconds · indexed lookup
4
SMTP probe
The probe opens a session with the recipient's own mail server, says HELO, sets a sender, asks RCPT TO for the address, and disconnects. It also asks about a random address on the same domain: if that is accepted too, the domain is catch-all and acceptance alone proves nothing.
1–4 seconds · never sends mail
5
Deep evidence
Deep checks look for proof that this address belongs to this person: whether the local part matches the lead's name, whether the domain matches their company, whether the address appears on a GitHub profile or in public commits, and whether it is published verbatim on the web.
Deep tier · 2–10 seconds
6
Reviewer model
For results that are still ambiguous, typically catch-all domains, a reviewer model reads every fact and reason collected so far and moves the score by at most 20 points in either direction, with a one-line rationale in the reasons list. It never overrides a fatal finding.
Deep tier · bounded ±20

An SMTP probe that never sends mail

The probe talks to the recipient's own mail server the way a sending server would, up to the point where it would hand over a message. Then it stops. There is no DATA command, ever, so nothing reaches anyone's inbox.

The second RCPT TO asks about a random address on the same domain. If the server rejects it, acceptance of the real address means something. If it accepts both, the domain is catch-all and Barometer looks for other evidence instead of guessing.

Probes run from a dedicated host with its own IP and a published HELO name, separate from any infrastructure that sends email, so probing never touches sending reputation.

A probe, end to end

→ connect mx1.acme.io:25
← 220 mx1.acme.io ESMTP
→ EHLO probe.stormgtm.com
← 250-mx1.acme.io
→ MAIL FROM:<verify@probe.stormgtm.com>
← 250 2.1.0 OK
→ RCPT TO:<jane.doe@acme.io>
← 250 2.1.5 OK
→ RCPT TO:<q7x2k9-random@acme.io>
← 550 5.1.1 No such user
→ QUIT

Outcomes close the loop

A check is a prediction. What happens after you send is the truth. Report bounces, deliveries, replies, opens, and complaints to POST /v1/outcomes and they feed every future check of that address.

A hard bounce makes the address undeliverable from then on, without another probe.
A reply adds +50 and a delivery +35, which can settle a catch-all domain for good.
Agents can report outcomes themselves with the MCP report_outcome tool.

Report a bounce

curl https://stormgtm.com/v1/outcomes \
  -H "authorization: Bearer $STORMGTM_API_KEY" \
  -H "content-type: application/json" \
  -d '{ "email": "jane.doe@acme.io", "kind": "bounced",
        "detail": "550 5.1.1" }'

What we keep, and how

Outcomes are hashed

Reported outcomes are stored under a salted SHA-256 hash of the normalized address, next to the domain name. The address itself is not kept with the outcome.

Keys and sessions are hashed

API keys, sign-in links, and session IDs are stored only as hashes. We show a key once, when you create it.

Your checks stay yours

Check results and the context you send are visible only to your account. See the privacy policy for retention and subprocessors.

See the reasons on your own leads

Every account starts with 100 free credits.

Get an API key Explore Barometer