ForgeSendDocs

Verification

Every contact has a single verificationStatus field, but it's populated by two entirely separate systems — worth knowing which one you're looking at.

Two sources, one field

Status badges — read only

From Lead Finder

VerifiedHigh probabilityCatch-allEmail not found

From built-in verification

ValidRiskyInvalid
  • Verified / High probability / Catch-all / Email not found — written by Lead Finder when it finds (or fails to find) an email for a contact during enrichment.
  • Valid / Risky / Invalid — written by ForgeSend's own built-in verification, covered below. This one runs entirely on ForgeSend's own server and doesn't touch enrichment credits.

Both sets land in the same field, so a contact can move from one vocabulary to the other over its lifetime — importing a Lead-Finder contact and then running Verify List on it will overwrite high_probability with valid/risky/invalid, for example.

How verification works

ForgeSend's built-in verification runs three tiers per email, each gating the next:

Verification tiers — read only
Tier 1 — SyntaxRegex format check
Tier 2 — DomainDNS MX record lookup
Tier 3 — MailboxLive SMTP RCPT probe to the mail server, 7s timeout

Verdict logic is deliberately conservative about tier 3:

  • Fails tier 1 (bad syntax) or tier 2 (no MX record) → Invalid
  • Tier 3 gets a positive SMTP response (250/251) → Valid
  • Tier 3 gets a 550–559 response, times out, or errors → Risky, not Invalid

That last point is intentional, per the code's own reasoning: unauthenticated port-25 probes commonly get 550-class responses from policy blocks, IP reputation filters, greylisting, or catch-all gateways that would accept the real send anyway — none of those mean the address doesn't exist, so ForgeSend doesn't downgrade it all the way to Invalid on a single probe.

This 3-tier check is the only verification ForgeSend runs today. There's no separate paid or higher-accuracy verification tier layered on top of it — what you see above is the complete verification pipeline, not a free preview of something bigger.

Verify List

Clicking Verify List first loads a preflight count, then asks you to confirm before touching anything:

Verify List — confirm step

Verify existing emails?

This checks deliverability status for contacts that already have an email. Contacts without emails are skipped. No enrichment credits are used.

Will be checked201
No email — skipped12
Already have a status140
CancelVerify 201 contacts

Confirming re-checks and overwrites the status of every contact with an email, including ones that already have a status from a previous run or from Lead Finder — "already have a status" is shown for information, it doesn't exclude them from the re-check. Contacts with no email are always skipped, and this never touches enrichment credits.

Verify a single contact

The edit-contact modal has its own Verify email button, running the exact same tier-1/2/3 check against just that one address — useful after fixing a typo without re-running the whole list.

Where this feeds into sending

Verification status is one of the checks in campaign preflight before launch — invalid leads block launch outright, while risky and unverified leads produce warnings and can be configured to be skipped automatically by a campaign's send policy rather than sent to.

Related docs

Next: Lead Finder overview