Bulk Email Verifier API - Deliverability and Toxicity

Clean a mailing list before you send to it. Verify up to ten thousand addresses in a single request, get the verdict and the reason behind it, and score the whole list for the addresses that quietly damage a sender reputation. One flat row per address or domain.

What this actor does

• Verifies in real bulk, not a loop dressed up as one. Addresses go to a synchronous bulk endpoint that verifies the entire batch before it answers, up to ten thousand in one request. A hundred thousand address list is a hundred requests rather than a hundred thousand. Results are matched back to your input by address, not by position, so an address the provider drops never shifts the rest of the list onto the wrong rows.
• Returns the reason, not just the verdict. Every row carries one of four verdicts and the reason code underneath it, across eleven documented codes. That is what separates a receiving server that timed out and will verify on a retry from a mailbox that genuinely does not exist. Both are offered as filters.
• Scores deliverability from zero to one hundred. The verdict alone is blunt. The score lets you keep the stronger risky addresses and drop the weak ones instead of throwing away a whole verdict class.
• Scores toxicity from zero to five. Toxicity is the reputation question rather than the delivery question: spam traps, known complainers and addresses that have burned senders before. An address can be perfectly deliverable and still be the one that gets your domain blocklisted.
• Flags catch-all, disposable, free, role, disabled and full mailboxes. These arrive nested under domain and account objects and are lifted onto the row, because a spreadsheet filter cannot reach into a nested object and every one of these is something people filter on.
• Checks a domain without touching a mailbox. The domain route answers whether a domain is catch-all, disposable or free webmail, which provider runs it, its mail exchanger record and whether it is toxic, at one credit per domain rather than per address. Checking one domain is far cheaper than checking the two hundred addresses on it.
• Waits out an asynchronous job properly. The toxicity list is created, polled and downloaded. The download answers HTTP 400 while the job is still running, which reads like an error and is not one, so the actor treats it as a wait and keeps polling, with the whole wait bounded so a stuck job ends the run rather than hanging it.
• Never charges for a miss. Only rows carrying a resolved result are billed.

Input

Field	What it does
mode	Verify, domain check or toxicity.
emails	Addresses to verify or score.
domains	Domains to check.
statuses	Keep only these verdicts.
reasons	Keep only these reason codes.
excludeFreeEmail	Drop free consumer mailboxes.
excludeRoleAccounts	Drop shared inboxes such as info and support.
excludeDisposable	Drop throwaway addresses.
excludeAcceptAll	Drop addresses on catch-all domains.
minScore	Keep only addresses at or above this deliverability score.
maxToxicity	Keep only addresses at or below this toxicity score.
batchSize	Addresses per bulk request, up to ten thousand.
timeout	Seconds allowed per address on the single address route.
requestsPerMinute	Pace the run under your plan's rate limit.
skipNotFound	Leave unresolved inputs out of the dataset.
maxResults	Hard cap on rows, and therefore on spend and run time.
apiKey	Your own API key. Stored as a secret.

Example output

{
  "found": true,
  "mode": "verify",
  "query": "jane.doe@example.com",
  "email": "jane.doe@example.com",
  "status": "deliverable",
  "reason": "accepted_email",
  "domain": "example.com",
  "acceptAll": "no",
  "disposable": "no",
  "free": "no",
  "role": "no",
  "disabled": "no",
  "fullMailbox": "no",
  "provider": "google.com",
  "dnsType": "MX",
  "dnsRecord": "aspmx.l.google.com",
  "score": 100,
  "toxic": "unknown",
  "toxicity": 0,
  "retryAfter": null,
  "error": null,
  "raw": { }
}

Frequently asked questions

How does bulk email verification actually work?

It runs in layers. The address is checked for syntax, the domain is looked up for mail exchanger records, and then the receiving mail server is contacted over SMTP and asked whether that specific mailbox exists. On top of that the provider applies its own intelligence about disposable providers, role addresses, catch-all configurations and mailboxes that are disabled or full. Each row returns the verdict of that whole process, the reason code that decided it, a zero to one hundred score and the individual flags.

What is the difference between the verdict and the reason code?

The verdict is one of deliverable, risky, undeliverable or unknown. The reason code is the detail underneath it, across eleven documented values, and it is where the useful decisions live. Two addresses can both come back as unknown when one hit a receiving server that timed out and will verify perfectly on a retry, while the other sits behind a DNS error that will never resolve. Filtering on the reason code lets you retry the first group and drop the second.

What does the toxicity score mean, and how is it different from the verdict?

The verdict answers whether mail will arrive. Toxicity answers whether sending it is a good idea. The scale runs zero to five and covers spam traps, known complainers and addresses with a history of damaging senders. A spam trap is a live, perfectly deliverable mailbox whose only purpose is to catch people mailing lists they should not have; it will verify as deliverable and it will still get your sending domain blocklisted. Score a list for toxicity before a first send to a list you did not build yourself.

Should I use the domain check or verify every address?

Use the domain check when the question is about the domain rather than the person. It tells you whether a domain is catch-all, disposable or free webmail, which mailbox provider runs it and whether it is toxic, at one credit per domain instead of one per address. If you hold two hundred addresses at one company, checking that domain once is two hundred times cheaper than verifying them all, and it will often tell you immediately that verifying them individually is pointless because the domain accepts everything.

What is a catch-all domain and why does it matter?

A catch-all domain is configured to accept mail for every possible mailbox, whether or not it exists. That means an SMTP check on any address there comes back positive and tells you nothing about the individual mailbox. The provider marks these, and the verdict comes back as risky rather than deliverable. Decide per domain rather than per address: some catch-all domains belong to well run companies and mail fine, while others are parked and will silently discard everything.

How large can one request be?

Ten thousand addresses, which is the provider's own ceiling on the synchronous bulk route. The actor defaults to a thousand per request, which keeps each response arriving reasonably quickly while still cutting a large list down to a manageable number of requests. Raise it toward ten thousand for very large lists, and remember that each request then takes correspondingly longer to answer because the whole batch is verified before it returns.

Do I need my own API key?

Yes. This actor does not include data access. You use your own API key from Bouncer, which is the provider whose email verification API this actor calls, created on their dashboard. Your own plan, credit balance and terms apply. Paste the key into the apiKey field, where it is stored as an Apify secret. The key travels in a request header rather than on the URL.

How does this handle rate limits and spent credits?

Requests are spaced evenly across the minute so a long list does not bunch up against the limiter, and the pace is yours to set. A rate limit or server error is retried with backoff, because it clears on its own. An empty credit balance is treated differently: the provider reports it with its own status code, the actor recognises it and stops with what it has rather than burning retries on a balance that waiting will not refill.

What happens when an address returns nothing?

The row is written with found: false and an error explaining that no verdict came back, and the run continues to the next input. Misses are not charged for. Set skipNotFound to true to leave them out of the dataset entirely. Note that a greylisting response is different: the provider returns a retry time on the row rather than a miss, so you can re-run just those addresses later.

How much does a run cost?

Pricing is pay per result: you are charged for each address or domain resolved into the dataset, and never for misses, for rows dropped by the filters, or for duplicates. Apify platform usage is included in the per-result price. Your own API provider's credit balance is separate and billed by them.

Keyword map

bulk email verifier API, email verification API, email validation API, email list cleaning, SMTP verification, MX record check, DNS check, catch-all detection, disposable email detection, role account detection, spam trap detection, email toxicity score, deliverability score, bounce rate reduction, sender reputation, list hygiene, domain verification API, mailbox provider lookup, full mailbox detection, greylisting retry, B2B email cleaning, cold outreach list cleaning