Email Verifier — Bulk Email Validation, Catch-All & Bounce Removal

The email verifier that admits what it cannot know.

Here is the thing the industry doesn't advertise. Microsoft 365, Outlook.com, Proton, Yahoo and the security gateways in front of corporate mail — Proofpoint, Mimecast, Barracuda — accept mail for every address at a domain and decide afterwards whether it bounces. There is no way to ask them "does this mailbox exist" and get a true answer. Not with a better algorithm, not with more IPs, not at any price.

Roughly a third of a typical B2B list sits behind exactly those providers. Every other verifier marks them valid, because "valid" is what people want to buy. Then you send, and the bounces arrive.

This Actor returns unknown or risky for those addresses, with a reason code and a sentence explaining who the provider is and why nobody can confirm the mailbox. Then it gives you every other signal that can be established — MX provider, catch-all behaviour, SPF, DMARC, DKIM, role and disposable flags, typo corrections, a 0-100 score — so you can make the call yourself instead of trusting a green tick that was a guess.

You are charged per email checked. Duplicates are removed before anything is checked or billed.

---

Try it in 30 seconds

Leave the defaults on, paste a few addresses, hit Start:

sarah.chen@shopify.com
info@stripe.com
j.martinez@gmial.com

You get one row per address, plus a summary row at the end telling you what percentage of the list you should probably drop.

---

The five verdicts, and what to do with each

verdict	What it means	What to do
valid	The mail server accepted this specific address, and the domain is not catch-all. As close to confirmed as email gets.	Send.
invalid	Broken syntax, no mail server, dead domain, or the server explicitly rejected the mailbox.	Remove. These are your bounces.
catch_all	The domain accepts every address, proven by probing one that certainly doesn't exist. The mailbox may or may not be real.	Send carefully — separate campaign, watch the bounce rate. Small agencies and one-person domains are often catch-all and perfectly good.
risky	Deliverable-looking, but a poor bet: disposable domain, role inbox, or a personal address on a B2B list.	Segment. Don't put these in a cold sequence with the rest.
unknown	The mailbox genuinely cannot be checked — the provider accepts everything, or mailbox-level checking was unavailable. The domain signals still come back.	Judge on the score and the signals. A 75-scoring address at a Microsoft 365 domain with strict SPF and a DMARC policy is a very different bet from a 45 with neither.

The honest way to read this: valid and invalid are facts. catch_all, risky and unknown are the situations where a fact is not available, labelled as such rather than rounded up.

---

Reason codes

Every row carries a machine-readable reasons[] array, so you can filter in a sheet or a script without parsing prose.

Code	Meaning
SYNTAX_INVALID	Not a usable address. syntaxError says what's wrong.
LIKELY_TYPO	A near-miss of a common domain. didYouMean has the fix.
DISPOSABLE	Burner domain, checked against a list of 8,870 of them.
NO_MX	The domain publishes no mail server. Nothing can arrive here.
M365_UNVERIFIABLE	Microsoft 365 or Outlook. Accepts all, bounces later. Not checkable by anyone.
PROVIDER_ACCEPTS_ALL	Proton, Yahoo, or a security gateway doing the same thing.
CATCH_ALL	Proven catch-all: a random address at this domain was accepted too.
MAILBOX_ACCEPTED	The mail server accepted this exact address.
MAILBOX_REJECTED	The mail server refused this exact address.
GREYLISTED	Temporarily deferred. Re-run this one later.
ROLE_ACCOUNT	info@, sales@, support@ — reaches a team, not a person.
FREE_PROVIDER	Gmail, Yahoo, iCloud and similar. Only counts against the score in B2B mode.
SMTP_UNAVAILABLE	Mailbox-level checking wasn't possible on this run; domain signals only.
SMTP_NO_ANSWER	The mail server didn't respond to the probe.

---

What a row looks like

{
  "email": "sarah.chen@shopify.com",
  "normalizedEmail": "sarah.chen@shopify.com",
  "domain": "shopify.com",

  "verdict": "unknown",            // honest: this provider cannot be checked
  "score": 73,                     // 0-100, built from everything below
  "bounceRisk": "medium",          // low | medium | high
  "isDeliverable": null,           // true / false / null — null means unknowable

  "reasons": ["M365_UNVERIFIABLE"],
  "providerNote": "Microsoft 365 accepts mail for every address at this domain and rejects bad ones later, so no tool can confirm this mailbox exists without sending to it.",

  "syntaxValid": true,
  "isRole": false,
  "isFreeProvider": false,
  "isDisposable": false,
  "isCatchAll": false,
  "didYouMean": null,

  "domainResolves": true,
  "mxFound": true,
  "mxProvider": "Microsoft 365",
  "mxRecords": ["shopify-com.mail.protection.outlook.com"],

  "spfRecord": "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all",
  "spfPolicy": "strict",           // strict | soft | neutral | any | none
  "dmarcPolicy": "reject",         // none | quarantine | reject
  "dkimFound": true,

  "smtpVerifiable": false,         // could this provider be asked at all?
  "smtpAttempted": false,

  "durationMs": 412,
  "checkedAt": "2026-09-17T19:12:04Z"
}

And the last row of every run is the summary you actually want before you press send:

{
  "summary": true,
  "totalChecked": 10000,
  "byVerdict": { "valid": 4120, "invalid": 812, "catch_all": 690,
                 "risky": 431, "unknown": 3947 },
  "estimatedBounceRatePercent": 8.1,   // if you sent the list as-is
  "wouldRemovePercent": 12.4,          // invalid + risky
  "unverifiablePercent": 46.4,         // honestly unknowable, catch-all included
  "mailboxCheckingAvailable": true,
  "domainsCached": 8571,
  "checkedAt": "2026-09-17T19:14:52Z"
}

Export as JSON, CSV, Excel, XML or HTML, or pull it from the API.

---

What makes it different

It says "I don't know" when it doesn't know. This is the whole product. Nothing else on the Store will tell you that 40% of your list is behind providers that cannot be verified by anyone — because saying so sounds worse than saying "valid". It isn't worse. It's the number you needed.

It names the provider. mxProvider tells you whether an address sits at Google Workspace, Microsoft 365, Proton, Zoho, a Proofpoint gateway or a shared host. That one field explains most of your bounce pattern, and nobody else returns it.

Real catch-all detection, not a guess. Where the mail server can be trusted, this Actor asks it about an address that definitely does not exist. If that gets accepted, the domain is catch-all and every "valid" you've ever been sold for it was meaningless.

Domain reputation signals, free with every row. SPF record and its policy, DMARC policy, DKIM presence. A domain with -all SPF and p=reject DMARC is a real, managed mail setup. A domain with none of it, on a shared host, is a very different prospect — and that's a lead-quality signal, not just a deliverability one.

Typos get fixed, not deleted. j.martinez@gmial.com comes back with didYouMean: "j.martinez@gmail.com". That's a recovered lead, not a removed one.

A summary row that estimates your bounce rate. Before the send, not after it.

Explains itself when a check isn't possible. Cloud networks generally block the outbound port that mailbox-level checking needs. This Actor detects that once at the start of a run rather than failing quietly ten thousand times, logs it in plain English, falls back to domain and provider signals, and flags every affected row with SMTP_UNAVAILABLE and mailboxCheckingAvailable: false in the summary. You are never told a result is stronger than it is.

---

Who uses this

Cold-email senders — clean the list before it touches your sending domain. One bad send costs you more in reputation than a year of verification.

CRM and database hygiene — run your contact table quarterly, drop the dead ones, flag the role inboxes, and see which accounts moved mail providers.

Signup and lead forms — catch disposable domains and typos at the point of capture, so the lead is reachable instead of theoretical.

Agencies and lead sellers — hand clients a list with a defensible quality report attached, including what genuinely couldn't be verified. It's a better conversation than a bounce report a week later.

Deliverability consultants — SPF, DMARC, DKIM and MX provider per domain, in one pass, alongside the addresses themselves.

---

Settings

Setting	What it does
Email addresses	One per line. Duplicates removed before checking and before billing
Treat free-provider addresses as lower quality	B2B mode: personal addresses score lower and are marked risky. Leave off for B2C
Full check, including mailbox-level verification	On: every signal available, including catch-all detection and mailbox-level checks where meaningful. Off: fast domain-level only

Concurrency, retries, caching, pacing and network handling are managed for you. There is nothing to tune and no proxy to configure. Per-domain results are cached within a run, so a 10,000-row list from 1,400 companies does the work once per company.

---

Automate it

curl -X POST "https://api.apify.com/v2/acts/YOUR_USERNAME~email-verifier/runs?token=YOUR_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
        "emails": [
          "sarah.chen@shopify.com",
          "info@stripe.com",
          "j.martinez@gmial.com"
        ],
        "businessMode": true,
        "deepCheck": true
      }'

Works with Make, Zapier, n8n, Google Sheets and the Apify API, and as an MCP tool for AI agents. Schedule it to re-check a list on any cadence — mailboxes die quietly, and a list verified a year ago is not a verified list.

---

How accurate is this, honestly

We are not going to claim 99%. Nobody can, and the tools that do are counting unverifiable addresses as correct guesses.

What this Actor actually does, on a typical B2B list:

• Removes 90%+ of the bounces you would otherwise have taken, mostly by catching dead domains, absent mail servers, broken syntax, disposable domains and mailboxes the server explicitly rejects.
• Labels the rest accurately. Where a mailbox can be confirmed, valid means confirmed. Where it can't, you get unknown or catch_all and the evidence, not a coin flip dressed as a fact.
• Recovers leads through typo correction that other tools discard as invalid.

The residual bounce rate after cleaning comes almost entirely from the unverifiable population — Microsoft 365 and friends. No tool reduces that further; the difference is that this Actor tells you the size of it in advance so you can plan the send around it. Warm up properly, send that segment separately, and watch the first batch.

Where mailbox-level checking is unavailable on a run (common on cloud networks, which block the port it needs), confirmed valid verdicts are fewer and more addresses land in unknown. The summary row tells you which kind of run you got.

---

FAQ

My other verifier says this address is valid and you say unknown. Who's right? Both of us, technically — but they're not telling you the whole story. Their check asked the mail server "will you take mail for this address", and a Microsoft 365 server, a Proton server, or a Proofpoint gateway says yes to that question for every address at the domain, including ones made of random characters. They took that yes and printed "valid". We ask the same question, get the same yes, recognise that the yes is meaningless for that provider, and say so. If you want to test it: put a nonsense address at one of your customers' corporate domains through the other tool and see what it returns.

Then why bother verifying at all, if a third of the list is unknowable? Because the other two thirds isn't. Dead domains, missing mail servers, typos, disposable burners and explicitly-rejected mailboxes are the bulk of what actually bounces, and all of it is catchable. The unverifiable slice is the part you manage with sending strategy instead of a filter.

Do I need an API key or an account anywhere? No.

Am I charged for invalid addresses? Yes — the check is the product, and finding out an address is dead is the most valuable result in the run. Duplicates are removed before billing, so you pay once per unique address.

Why is isDeliverable null on so many rows? null means unknowable, deliberately. true and false are only used when there's an actual answer behind them.

Does this send email to anyone? No. Verification stops before any message is transmitted, and nothing arrives in anybody's inbox.

What does deepCheck off actually skip? DKIM lookups, catch-all probing, and any mailbox-level conversation. You still get syntax, typos, disposable detection, MX and provider identification, SPF and DMARC. It's faster and still catches most bounces; the full check is the default for a reason.

Can I verify addresses at a catch-all domain properly? Not by verifying — that's what catch-all means. Use the score and the domain signals, send to that segment separately, and treat the first campaign as the test.

How big a list can I run? Large ones are fine. Per-domain caching means the cost scales with the number of distinct domains, not rows, so corporate lists run far faster than the row count suggests.

---

Terms of Use

This Actor performs technical checks against public DNS records and, where possible and permitted, mail servers. It does not deliver mail to anyone.

Your responsibility. You are responsible for using the results lawfully, including compliance with GDPR, CAN-SPAM, PECR, CASL and any other marketing, privacy and data-protection law that applies to you and to the people on your list. Verifying an address is not consent to email it, and this Actor does not establish a lawful basis for contact.

No warranty. Results are technical signals, not guarantees. A valid verdict does not guarantee delivery; an unknown verdict does not mean an address is bad. Mailboxes change between the check and your send. The Actor is provided "as is", without warranties of any kind, and to the maximum extent permitted by law the developer is not liable for any loss arising from your use of the results.

No affiliation. This Actor is not affiliated with, endorsed by or sponsored by Microsoft, Google, Proton, Yahoo, Proofpoint, Mimecast, Barracuda or any other mailbox or security provider. Those names appear only to identify which provider handles a domain's mail.

---

Found a provider this Actor mislabels, or need volume pricing? Open an issue on the Actor's Issues tab — a wrong provider match is the fastest thing to fix and the most useful thing to report.