Email Verification API - Deliverability and Spam Traps

Does this mailbox actually exist, and should you send to it. Verified at the receiving server rather than guessed from the syntax, with the risk picture attached. One flat row per address.

What this actor does

• Verifies at the mailbox, not at the regex. The check connects to the receiving mail server and asks whether the address exists. That is a different question from whether it is well formed and whether the domain has an MX record, and it is the only one that predicts a bounce.
• Tells you why, not just what. A failure comes back with a specific reason: the mailbox does not exist, the domain is inexistent, the mailbox is full, the server is catch-all, the server grey-listed the check, the address is a known disposable domain, or a possible spam trap was detected. Sixteen distinct reasons, each its own value.
• Distinguishes a bad address from an uncooperative server. Grey-listing is a spam defence that refuses a first contact from an unfamiliar sender and accepts the retry. Treating that as a bad address throws away good subscribers, so it comes back as retry later rather than bad, and the run tells you how many to check again in an hour.
• Flags spam traps. A spam trap is an address that exists only to catch senders who do not verify, and hitting one damages your sending reputation far out of proportion to the single message. It gets its own column and its own filter.
• Separates role, free mail and catch-all. These are three different reasons to be careful and they need three different decisions, so they are three columns rather than one lumped quality flag.
• Gives you a verdict as well as the evidence. A trust score, an inbox quality score, an overall risk score with the domain, format and profanity components broken out, and a plain send recommendation of safe, risky or do not send. Route on the recommendation, or build your own rule from the parts.
• Checks block lists by name. Which lists the address or its domain appears on, and the reason each one gives, rather than a single yes or no.
• Looks up the domain behind the address. A separate WHOIS mode returns registration date, domain age, time to expiry, registrar, name servers and DNSSEC status. Domain age is one of the strongest single signals that a sending domain was created last week for one campaign.
• Normalises the provider's enumerations. These fields arrive sometimes as a name and sometimes as a number, and a column that is sometimes 1 and sometimes "Ok" cannot be filtered. Every one is resolved to its name here, with the numeric code kept alongside for sorting.
• Uses only your own key. This provider also serves a keyless endpoint on its free tier. It is deliberately not used here, because reselling a free tier through a paid actor is exactly what its terms forbid. Every mode uses the credential you supply.
• Never puts your key in a log. The credential travels in the URL path with this provider, which makes every request URL a secret. Nothing here logs one.
• Never charges for a miss. Only rows carrying a resolved result are billed.

Input

Field	What it does
mode	Verify, assess, block lists, or WHOIS.
queries	Addresses to check, one per line. Domains in WHOIS mode.
assessIpAddress	The IP the signup came from, in assess mode.
assessFirstName	A first name to check the address against.
assessLastName	A last name to check the address against.
results	Keep only Ok, Bad, RetryLater or Unverifiable rows.
deliverableOnly	Keep only addresses confirmed to exist.
sendRecommendations	Keep only these send recommendations.
minTrustScore	Keep only rows at or above this trust score.
maxRiskScore	Keep only rows at or below this risk score.
excludeRole	Drop shared mailboxes such as info and sales.
excludeFreeMail	Drop free consumer mail providers.
excludeDisposable	Drop throwaway domains.
excludeCatchAll	Drop domains that accept everything.
excludeSpamTraps	Drop identified spam traps.
excludeDarkWeb	Drop addresses seen in breached data.
excludeGibberish	Drop machine-looking addresses.
excludeBlockListed	Drop addresses on a block list.
reportQuota	Log your remaining provider allowance first.
requestsPerMinute	Pace the run under your plan's rate limit.
skipNotFound	Leave misses and refusals out of the dataset.
maxResults	Hard cap on rows, and therefore on spend and run time.
apiKey	Your own license key. Stored as a secret.

Example output

{
  "found": true,
  "mode": "verify",
  "query": "user@example.com",
  "email": "user@example.com",
  "result": "Ok",
  "resultCode": 1,
  "reason": "Success",
  "reasonCode": 11,
  "isDeliverable": true,
  "trustScore": 8.4,
  "trustLevel": "High",
  "sendRecommendation": "SafeToSend",
  "inboxQualityScore": 9.1,
  "isSyntaxValid": true,
  "syntaxReason": "Success",
  "hasDnsRecord": true,
  "hasMxRecords": true,
  "mxRecords": ["mx1.example.com", "mx2.example.com"],
  "isRole": false,
  "isFreeMail": false,
  "isCatchAll": false,
  "isDisposable": false,
  "isDarkWebListed": false,
  "isGibberishUser": false,
  "isGibberishDomain": false,
  "spamRecommendation": "Allow",
  "overallRiskScore": 0.8,
  "domainRiskScore": 0.4,
  "formatRiskScore": 0.2,
  "profanityRiskScore": 0,
  "blockLists": [],
  "isSpamTrap": false,
  "spamTrapDescriptor": null,
  "mailServerLocation": "US",
  "smtpBanner": "220 mx1.example.com ESMTP",
  "domain": "example.com",
  "tld": "com",
  "user": "user",
  "emailHashMd5": "b58996c504c5638798eb6b511e6f49af",
  "error": null,
  "raw": { }
}

Frequently asked questions

How is this different from a syntax and MX check?

A syntax check tells you the address is well formed. An MX check tells you the domain can receive mail at all. Neither tells you whether that particular mailbox exists, which is the thing that decides whether your message bounces. This verification connects to the receiving server and asks about the specific address, which is why it is slower than a syntax check and why it is the only one worth running before a send.

What does each verification result mean?

Ok means the mailbox exists. Bad means it does not, and the reason column says why: no such mailbox, the domain does not exist, no MX servers, a mailbox that is full. RetryLater means the receiving server declined to answer right now, almost always grey-listing, and those are usually good addresses. Unverifiable means the answer cannot be obtained at all, most often because the server is catch-all and will accept anything. Four results, and a separate reason column carrying sixteen possible explanations.

Why do I get RetryLater and what should I do about it?

Grey-listing is a spam defence: the receiving server refuses the first contact from any sender it does not recognise and accepts the same contact on a retry a few minutes later. It is a statement about your verification attempt, not about the address. Treating those as bad addresses is one of the most common ways to throw away good subscribers. Run them again an hour or two later and most resolve. The run log tells you how many came back that way.

What is a spam trap and why does it matter so much?

A spam trap is an address that exists for the sole purpose of catching senders who mail without permission or without verifying. Some are addresses that were abandoned and later recycled as traps; others were never real. Sending to one can affect your domain's sending reputation with the major mailbox providers out of all proportion to the single message, which is why it gets its own column here rather than being folded into a general risk score.

Should I drop catch-all domains?

It depends on how much bounce risk you can carry. A catch-all domain accepts mail addressed to every possible mailbox, so the server cannot tell you whether a particular address is real. That makes the result neither a pass nor a fail. Many business domains are configured this way, so dropping them all removes real people; keeping them means accepting that some will bounce. The flag is there so you can decide rather than have the decision made for you.

What is the difference between a role address and a free mail address?

A role address belongs to a function rather than a person: info, sales, support, postmaster. It is real and deliverable, but marketing sent to it tends to be seen by several people and is a common source of complaints. A free mail address is on a consumer provider such as a webmail service. It is a person, just not one at a company domain. They need different decisions, so they are two columns.

What does the assess mode add?

A trust score for the address, and the ability to check it against context you already hold: the IP address the signup came from, checked for data centre and Tor exit node origin, and a first and last name to test against the address. Be aware that those three are positional path segments with this provider, so leaving the IP empty means the names are ignored too. The input descriptions say so at each field.

Why would I run a WHOIS lookup on a domain?

Domain age is one of the strongest single signals in email risk. A domain registered eleven days ago that is sending marketing is a very different proposition from one registered in 2003, and no amount of mailbox verification will tell you that. The WHOIS mode returns registration date, age, time to expiry, registrar, name servers and DNSSEC status for a domain, and it accepts whole email addresses and reduces them to the domain, so you can run it over the same list.

Does this actor use the provider's free endpoint?

No, deliberately. This provider does serve a keyless endpoint as its free tier, and it would be technically easy to call it. Reselling a free tier through a paid actor is exactly what those terms forbid, so every mode here uses the licence key you supply and nothing else.

Do I need my own API key?

Yes. This actor does not include data access. You use your own license key from Email Hippo, which is the provider whose email verification API this actor calls, taken from your provider account and pasted into the apiKey field, where it is stored as an Apify secret. Your own plan, allowance and terms apply. Turn on the balance report if you want the run to log how much of your allowance is left before it starts.

What happens when an address returns nothing?

A negative verdict is a result, not a miss: the provider telling you a mailbox does not exist is exactly the question you asked, so that row is written and billed like any other. A miss is a value the provider would not answer for at all, and a refusal is an input that never left this actor. Both are written with found: false and never billed. Set skipNotFound to true to leave them out entirely.

How much does a run cost?

Pricing is pay per result: you are charged for each value resolved into the dataset, and never for misses, for locally refused inputs, for rows dropped by the filters, or for duplicates. Apify platform usage is included in the per-result price. Your own provider allowance is separate and billed by them.

Keyword map

email verification API, email validation API, bulk email verifier, email list cleaning, mailbox verification, SMTP verification, deliverability check, bounce rate reduction, spam trap detection, disposable email detection, throwaway email check, catch all domain detection, role account detection, free mail detection, gibberish email detection, dark web email check, email block list check, DNSBL check, email risk score, email trust score, send recommendation, domain WHOIS API, domain age lookup, domain expiry check, signup fraud prevention, email hygiene API