Bulk Email Verifier

Clean a list before you send to it. Paste addresses, get back which will deliver, which are risky, and which will bounce — each with a reason you can act on.

You are only charged for addresses that return a verdict. If DNS is temporarily unreachable an address comes back unknown, free, with a note to re-run it. No verifier can be certain in that moment, and pretending otherwise is how good customers get deleted.

---

Why lists bounce even after "verification"

Most cheap verifiers run a regex and check whether an MX record exists. That is wrong in four ways, and each one costs money in a different direction.

1. A null MX record means the domain refuses mail — and naive tools call it valid

Under RFC 7505, a domain can publish a single MX record whose exchange is a lone dot:

example.com.   IN   MX   0 .

That is not a mail server. It is an explicit, standards-defined statement that this domain accepts no email at all. A tool that only asks "is an MX record present?" sees one record and returns valid. Every message you send there bounces. We detect it and mark the address invalid with the reason stated.

2. A domain with no MX record can still receive mail — and naive tools delete it

RFC 5321 defines an implicit MX: if a domain has no MX record but does have an A or AAAA record, mail is delivered to that host. Plenty of small business domains work exactly this way. A verifier that requires an MX record marks these invalid and you quietly remove real, reachable customers from your list. We check A and AAAA as a fallback and report mxKind: "implicit-a" so you can see why it passed.

3. A typo domain resolves, accepts mail, and is not your customer

gmial.com, hotnail.com, yahooo.com — these are registered, they run mail servers, and they accept whatever arrives. That is the entire business model of typosquatting: collecting misdirected email. Check only for an MX record and they come back valid, which is worse than useless — you're told a wrong address is safe. We flag them risky and return the likely correction in didYouMean.

4. A DNS timeout is not evidence of a bad address

If a lookup fails for a moment, that tells you nothing about the address. Tools that return invalid on a lookup error silently destroy list quality over time. We return unknown, don't charge for it, and tell you to re-run.

---

Disposable and role addresses are different problems

Most tools lump them together as "risky", which makes the flag useless because you can't act on it.

Disposable — mailinator.com, 10minutemail.com, guerrillamail.com and similar. The address works right now and will be abandoned. Someone wanted your lead magnet without giving you a real address. These are churn: they inflate your list size and deflate every engagement metric.

Role-based — info@, sales@, support@, billing@, careers@. These are usually real, monitored, and deliverable. They are not a person, so open and click rates look terrible, and some ESPs weigh them negatively. For B2B outreach they may be exactly who you want; for a consumer newsletter they are noise. Different decision, so we report them separately — and +tag addressing (you+newsletter@gmail.com) is correctly read as personal, not as a role account.

---

What each verdict means

status	deliverable	what to do
valid	yes	Send. Domain accepts mail, no risk flags.
risky	yes	Your call — check disposable, roleBased, didYouMean to decide.
invalid	no	Remove. Bad syntax, dead domain, or a null-MX refusal.
unknown	unknown	Re-run. DNS was unreachable. Not charged.

mxKind tells you exactly why: mx, implicit-a, implicit-aaaa, null-mx, no-mx, dns-error.

---

Input

Paste a list — new lines, commas or spaces all work, and duplicates are removed automatically:

{ "emailsText": "hello@acme.com\ninfo@example.com\ntest@mailinator.com" }

Or pass an array:

{ "emails": ["a@b.com", "c@d.com"], "maxEmails": 5000 }

Field	Type	Default	Notes
emailsText	string	—	Pasted list, any common separator
emails	array	—	For API and integration use
email	string	—	Verify a single address
maxEmails	integer	1000	Cap on addresses, and therefore on spend

Output

One record per address, plus a SUMMARY with counts and rates:

{
  "email": "someone@gmial.com",
  "status": "risky",
  "deliverable": true,
  "reason": "Likely typo of gmail.com — this domain resolves and accepts mail, which is how typosquatters collect misdirected email. Confirm before sending.",
  "domain": "gmial.com",
  "mxFound": true,
  "mxKind": "mx",
  "disposable": false,
  "roleBased": false,
  "freeProvider": false,
  "didYouMean": "someone@gmail.com"
}

---

What this does not do

Stated plainly, because a verifier that overclaims is the problem it's meant to solve.

• No SMTP mailbox probing. We do not open a connection to the mail server to ask whether a specific mailbox exists. Tools that do are throttled, blocked, or graylisted by every major provider, and catch-all domains accept everything anyway, so the answer is frequently wrong. We verify the domain can receive mail and report risk signals honestly rather than guessing at the mailbox.
• No spam-trap database. Nobody has a reliable public one; anyone claiming otherwise is selling confidence.
• No engagement history. We see the address, not what your recipients did.

If you need mailbox-level certainty, no DNS-based verifier can give it to you — send a double-opt-in confirmation.

For agents and automation

• Capability: bulk email deliverability verification via DNS
• Required input: one of emailsText, emails, or email
• Returns: one JSON record per address plus a SUMMARY
• Bounded: maxEmails caps the run and the spend
• Side effects: none — DNS lookups only. No mail is sent, nothing is stored externally.
• Determinism: deterministic given stable DNS. The non-deterministic case is marked unknown explicitly rather than guessed.

Pricing

Pay per address that returns a verdict. Duplicates are removed before billing, and unknown results are free. $0.80 per 1,000 addresses on paid plans.