Email Verifier & Validator — Bulk Email Verification

Clean any email list before you send, whether it comes from Apollo, LinkedIn, a scraper or your CRM. Each address gets a mailbox-level check plus catch-all, disposable, role and free-provider detection. You get one clear verdict per address (good, risky or bad) and a 0–100 score. No email is ever sent, and you don't need an API key.

Why use it

• Protect your sender reputation. Remove addresses that would bounce before they hurt your domain.
• Know what's actually deliverable. Each mailbox is checked against the recipient's mail server, not just its format.
• Catch the tricky cases. Catch-all domains, disposable inboxes, role addresses such as info@ or sales@, and full or disabled mailboxes are each labelled clearly.
• Bulk-ready and cheap. Paste thousands of addresses or call it from your own tools. You pay only per address verified.

What each address gets

Check	What it tells you
Syntax	Whether the address is well-formed.
Mail domain	Whether the domain can receive email (MX records, with the standard A-record fallback).
Mailbox	Whether the specific mailbox exists and can receive mail.
Catch-all	Whether the domain accepts any address, which makes individual mailboxes unconfirmable.
Disposable	Whether it uses a temporary-inbox service.
Role address	Whether it is a shared inbox such as info@, sales@ or support@.
Free provider	Whether it is Gmail, Outlook, Yahoo or a similar service.
Domain health (optional)	SPF, DKIM and DMARC records for the domain.

Results: what the statuses mean

Status	Meaning	What to do
good	The mailbox exists and can receive mail.	Safe to send.
risky	The domain is catch-all, it's a role address, the mailbox is full, or the mail server gave no definite answer.	Send with care or review manually.
bad	Invalid address, no mail domain, disposable inbox, or the mailbox doesn't exist.	Remove it.
unverifiable	The mailbox couldn't be checked during this run, for example because the provider didn't respond. It is not a negative signal.	Re-check later, or treat it as untested.

Every row also has a technical_status (valid, invalid, unknown, catch_all, disposable or error), a 0–100 score and a machine-readable reason. Reasons include:

• ok
• invalid_syntax
• no_mail_infrastructure
• smtp_rejected
• mailbox_disabled
• mailbox_full
• spamtrap
• catch_all_domain
• disposable_email
• role_address
• smtp_unverifiable
• smtp_inconclusive
• smtp_not_checked

How to use

1. Paste your addresses into Emails to verify, one per line or comma-separated.
2. Keep Check mailbox and Detect catch-all domains on (the defaults).
3. Run the Actor. Download the results as CSV, JSON or Excel, or connect them to your CRM.

Input example

{
  "emails": ["jane.doe@company.com", "info@company.com", "test@mailinator.com", "not-an-email"],
  "smtpCheck": true,
  "detectCatchAll": true,
  "checkDomainHealth": false
}

Output example

{
  "email": "jane.doe@company.com",
  "domain": "company.com",
  "status": "good",
  "technical_status": "valid",
  "score": 98,
  "reason": "ok",
  "free": false,
  "role": false,
  "disposable": false,
  "catch_all": false,
  "mailInfrastructureFound": true
}

Each row also includes a verification_details object with the full evidence behind the verdict: mail servers, catch-all result, classification flags and optional domain-health results.

Common workflows

• Clean lead lists from Apollo, Clay, LinkedIn or your CRM before an outreach campaign.
• Block disposable and malformed addresses at sign-up.
• Send catch-all and role addresses to a separate, lower-volume sequence.
• Re-check stored contacts periodically to remove dead mailboxes.
• Audit SPF, DKIM and DMARC across a list of partner or vendor domains.
• Run it from Make, Zapier, n8n, Google Sheets, the Apify API or an AI agent through MCP.

Need the email address first? LinkedIn Email Finder finds and verifies work emails from a name and company.

Limitations

• Catch-all domains can't be confirmed per address. These domains accept mail for every address, so their mailboxes come back risky / catch_all rather than good.
• Some providers don't reveal whether a mailbox exists. Those addresses come back risky with reason smtp_inconclusive, or unverifiable if the provider didn't respond. They are not marked bad.
• Results are a point-in-time check. A mailbox can be closed or fill up after verification, and a provider can still filter a message based on its content or your sender reputation.
• DKIM detection is best-effort. A missing DKIM result doesn't prove that DKIM isn't configured.

FAQ

Does this send an email to the address? No. Verification stops before any message is sent. Recipients see nothing.

Why are some addresses "risky" instead of "good"? Some domains accept mail for every address (catch-all), so an individual mailbox can't be confirmed. Shared inboxes like info@ and full mailboxes are also flagged risky, because sending to them is less reliable.

How accurate is it? A good result means the recipient's mail server confirmed the mailbox. Delivery can still fail later if the mailbox is closed after the check, or if a provider filters your message based on its content or your sender reputation. No verifier can rule that out.

Do I need my own verification API key? No. Everything is included in the per-address price.

Can I verify very large lists? Yes. Addresses are processed in parallel, and results for the same domain are reused within a run to keep it fast and inexpensive.

Input reference

Field	Default	Description
emails	—	The addresses to verify (required).
smtpCheck	true	Check whether each mailbox exists. Turn it off for syntax, domain and classification checks only.
detectCatchAll	true	Detect domains that accept any address.
checkDomainHealth	false	Add SPF, DKIM and DMARC checks for each domain.
maxConcurrency	10	How many addresses to process at once (1–50).

Advanced and legacy fields (smtpTimeoutSecs, useApifyProxy, deep) are kept for existing integrations. Leave them at their defaults.

Upgrading from version 1

Version 2 replaced the old valid / invalid / risky / unknown statuses with good / risky / bad / unverifiable. The technical result lives in technical_status.

The v1 field names are still included: syntaxValid, mxFound, mxHost, isDisposable, isRole, isFreeProvider, domainHealth, smtpCheck, mailboxExists and confidence.

Responsible use

Only verify addresses you're allowed to process, and follow applicable privacy and anti-spam laws. A good result is not consent to send.

Support

Questions or an edge case? Open an issue on this Actor's page or contact Thirdwatch at thirdwatch.dev.