Bulk Email Verifier — Real SMTP, Not Guesswork

Verifies email deliverability by actually connecting to the mail server. Returns a confidence score and the evidence behind it, never a misleading binary verdict.

What separates this from the alternatives

The two most-used email verifiers on this platform cannot perform SMTP verification at all. That is not a marketing claim — it is visible in their own output.

The leading paid verifier returns reason: "smtp_unreachable" on 10 of 23 test addresses. Outbound port 25 is blocked in most cloud environments, so tools that cannot reach it fall back to DNS records and heuristics, then present the guess as a verdict.

The leading free verifier answered "Mailbox does not exist" for two mailboxes that accepted mail on a live SMTP connection (postmaster@hetzner.com, abuse@hetzner.com — both returned 250). Deleting real customers from your list is the expensive failure, and it is the one most verifiers make.

This actor runs its SMTP probe on dedicated infrastructure with a clean IP, matching forward and reverse DNS, and per-domain rate limiting.

Test methodology

Both competitors were run on an identical 23-address corpus alongside this actor on 2026-09-11. The corpus covered valid mailboxes, non-existent mailboxes at the same domains, catch-all domains, disposable domains, dead domains, malformed syntax and typo domains. Ground truth was established by live SMTP where possible.

	Correct verdicts	Recall on known-good
This actor	23 / 23	4 / 4
Leading paid verifier	18 / 23	3 / 4
Leading free verifier	11 / 21	1 / 4

Caveat, stated plainly: the corpus is 23 addresses, and its known-good entries are RFC 2142 role accounts (postmaster@, abuse@) rather than ordinary user mailboxes. It is a small sample and should be read as an indication, not a guarantee. The capability difference above — that competitors cannot reach port 25 — is the durable point, and you can verify it yourself by inspecting their output.

Catch-all is measured, not assumed

Whether a mail server accepts unknown recipients is a per-tenant setting and cannot be inferred from the MX record. Verified live:

Domain	Mail provider	Accepts unknown recipients?
gmail.com	Google	No — verifiable
segment.com	Google	Yes — catch-all
bosch.com	Microsoft 365	No — verifiable
outlook.com	Microsoft	Yes — catch-all

Any tool that decides from the MX host gets these backwards. This one probes each domain and caches the result.

What you get per address

{
  "email": "someone@company.com",
  "status": "deliverable",
  "confidence": 95,
  "reason": "smtp_accepted",
  "suggestion": null,
  "checks": {
    "syntax": true, "mx": true, "disposable": false,
    "role": false, "free_provider": false, "catch_all": false
  }
}

Statuses: deliverable · undeliverable · risky · unknown

No false confidence. A catch-all domain returns risky with reason: catch_all_domain, because no verifier can confirm an individual mailbox there. Greylisting returns unknown rather than a guess — re-run later for a definitive answer.

Checks performed

• RFC 5322 syntax, including leading/trailing/consecutive-dot rejection
• Typo detection with correction (gmial.com → gmail.com)
• MX records, with A-record fallback per RFC 5321
• 12,146 disposable / throwaway domains, refreshed from maintained public blocklists
• Role accounts (info@, admin@, postmaster@…)
• Catch-all detection, probed per domain and cached
• SMTP RCPT TO mailbox check — never sends mail; the conversation ends before DATA

Typical uses

• Clean a list before a campaign — bounces damage sender reputation
• Validate signups and block disposable addresses at entry
• Verify scraped or enriched leads, where addresses are guesses
• Ongoing CRM hygiene — lists decay roughly 2% per month