DEV Community: kevinc0319-prog

Detecting disposable email domains without manual review

kevinc0319-prog — Fri, 11 Sep 2026 07:34:41 +0000

A throwaway address shows up in your signup form. Someone wants the free tier, the download, or the trial, and they have no intention of reading a single email you send. You only find out later, when your open rates sink and your bounce complaints climb. The fix most teams reach for first is manual review. A human scans the address, guesses whether it looks temporary, and decides. That approach does not survive contact with real traffic.

This is the disposable email domain problem. A disposable (or temporary) provider runs a domain whose only purpose is to hand out inboxes that delete themselves after a few minutes. Guessing these by eye does not scale, and it is inconsistent from one reviewer to the next.

What list-based detection actually does

The reliable approach is a list. You maintain a set of known disposable domains and check every address against it. MailProbe ships with a curated set of roughly 1,400 of these domains and matches the domain part of each address on every request. The check is a local lookup, which means it is fast and it costs no network round trip.

The numbers matter here. A human reviewer can hold maybe a few dozen suspicious domains in their head. A list of 1,400 covers the providers that account for the overwhelming majority of throwaway signups. When a new popular temp-mail site appears, you update the list once, and every caller benefits. Manual review would mean retraining every reviewer, every time.

The response makes the result plain:

curl "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=test@mailinator.com"

{
  "email": "test@mailinator.com",
  "valid": false,
  "deliverable": false,
  "reason": "disposable",
  "score": 75,
  "checks": { "syntax": true, "disposable": true, "free": false, "role": false },
  "suggestion": null,
  "provider": "self-hosted"
}

The disposable flag is true and reason is disposable. You can reject the signup or route it to a slower verification path without a second thought.

Where the check belongs in the pipeline

A verification call does several things: it checks syntax, looks up MX records over DNS, flags disposable and role addresses, and detects free providers. The disposable check is special because it needs no network. It is a dictionary lookup against a fixed set. That makes it cheap to run first.

The practical ordering is to clear the cheap, local checks (syntax, disposable, role, free) before spending a DNS query on the MX lookup. If the domain is on the disposable list, there is no reason to resolve its mail servers. You already know the answer. MailProbe returns the disposable flag in the same response as the MX data, so the caller gets the full picture in one call, but the local check is the one that should short-circuit the work.

A small wrapper keeps this readable in application code:

async function isDisposable(email) {
  const res = await fetch(
    "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=" +
      encodeURIComponent(email)
  );
  const data = await res.json();
  return data.checks?.disposable === true;
}

Keeping the list current is the real work

The code is the easy part. The set of disposable providers churns constantly. A site that is the popular choice this month is gone next month, and two new ones appear to take its place. A list of 1,400 domains is only useful if it is refreshed on a schedule, not committed once and forgotten.

The maintenance cost is low. Pull a diff against a maintained source once a week, and have a human review it so a legitimate domain is never added by mistake. The payoff is that the cheap check stays cheap. You are not spending a DNS query or an API call to catch an address the list would have flagged in microseconds. A stale list, by contrast, lets the newest temp-mail provider straight through until someone notices the signups piling up.

What list-based detection cannot catch

The honest part is that a list is only as good as its coverage, and there are three holes worth naming.

First, subaddressing defeats nothing here but is worth separating in your mind. user+tag@gmail.com is a real Gmail inbox, not a throwaway. The disposable list will not flag it, and it should not. It is a legitimate address that happens to use a plus tag.

Second, self-hosted throwaways are invisible to any static list. A determined user can register a fresh domain, point it at a tiny mail server that auto-expires inboxes, and your list will not contain it until someone adds it. This is rare and takes effort, so the volume is low, but it is a real gap.

Third, catch-all domains accept every recipient at the domain. A catch-all is not disposable, but it behaves oddly under verification, and conflating the two leads to mistakes. Catch-all handling is its own subject.

The point is not that list detection is perfect. It is that it removes the bulk of the problem for near-zero cost, and it does so consistently. Anything the list misses is either rare, or it is a different category of address that needs a different check. Combine the list with MX and syntax validation and you cover most of what matters.

I used MailProbe for the examples above because it returns the disposable flag, the MX records, and the provider fingerprint in one response. The endpoint is at https://mailprobe.kevin-c0319.workers.dev/. If you run your own verifier, the same principle applies: keep the disposable list local, check it early, and treat a miss as unknown rather than safe.

MX record lookup vs SMTP verification: what each one actually proves

kevinc0319-prog — Fri, 11 Sep 2026 07:34:36 +0000

Two terms get used as if they mean the same thing: MX lookup and SMTP verification. They do not. Picking the wrong one, or expecting one to do the job of the other, is how teams end up rejecting good customers or trusting bad addresses. The distinction is narrower than the marketing copy suggests.

What an MX lookup proves

An MX (mail exchanger) record tells the world which mail servers accept mail for a domain. Looking it up is a DNS query. If a domain has MX records, mail can, in principle, be delivered to it. If it has none, there is nowhere to send the message, and the address cannot receive mail.

That is the full extent of what MX proves. It answers one question: does this domain have a mailbox infrastructure at all? It says nothing about whether a specific local part, the part before the @, is a real inbox.

curl "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=foo@nonexistentdomainzzz123.com"

{
  "email": "foo@nonexistentdomainzzz123.com",
  "valid": false,
  "deliverable": null,
  "reason": "no_mx",
  "score": 0,
  "checks": {
    "syntax": true,
    "mx": { "ok": false, "records": [], "error": "no_mx", "source": null }
  }
}

Notice deliverable is null, not false. The domain does not resolve, so the verifier cannot claim the address is definitely undeliverable in every sense. The safer claim is that it is unproven. MailProbe uses null deliberately for these cases, and that choice is worth understanding before we get to SMTP.

A domain that does have MX records looks different:

{
  "email": "test@gmail.com",
  "valid": true,
  "deliverable": true,
  "reason": "ok",
  "score": 90,
  "checks": {
    "mx": {
      "ok": true,
      "records": [
        { "exchange": "gmail-smtp-in.l.google.com", "priority": 5 },
        { "exchange": "alt1.gmail-smtp-in.l.google.com", "priority": 10 }
      ],
      "source": "dns"
    }
  },
  "provider": "google-workspace"
}

What SMTP verification adds, and what it costs

SMTP verification goes one step further. After finding the MX server, it opens a connection on port 25, says "I want to send mail to this address," and reads the server's reply. A 250 means the mailbox exists. A 550 means it does not. In theory this tells you whether the specific inbox is real.

In theory. In practice, port 25 is blocked for most cloud hosts and residential networks. Major providers reject connections that do not come from a reputable, warmed-up sending IP. Many mail servers answer a probe with 250 for every address because they are catch-all. Others lie and report success to avoid confirming which accounts exist, which is exactly the information attackers want. So even when SMTP works, its answer is often a polite fiction.

By 2026 the reliable SMTP probe is a self-hosted concern. It needs a server with deliverability reputation and a fixed IP that port 25 will accept. MailProbe's hosted endpoint runs on Cloudflare Workers, which has no raw TCP, so SMTP probing is not available there. The self-hosted Node build can do it because it controls the runtime. If you need SMTP-level checks, run the verifier where you control the network, not on a Worker.

Getting SMTP to work is a reputation project

The reason SMTP verification moved from a default feature to a specialist, self-hosted one is the sending reputation. Providers like Gmail and Microsoft read the probing IP's history before they answer, and a cold IP with no sending track record is throttled or refused outright. Warming an IP for deliverability is a weeks-long project involving real volume and real engagement, not a flag you flip. Most teams do not have that, and renting it is its own cost.

So the practical picture in 2026 is: MX lookup is something any host can do for free, and it answers the domain question cleanly. SMTP answers the inbox question only when you have invested in the infrastructure to be trusted, and even then it lies on catch-all domains. Spend your effort on the check you can actually run well, and treat the rest as unknown.

Why inconclusive is the right answer

The trap is treating "I could not prove it" as "it is invalid." A network timeout during an MX lookup is not evidence that an address is dead. It is evidence that your DNS query did not come back. Marking a good address as undeliverable on that basis loses a real signup over a transient hiccup.

MailProbe returns deliverable: null with reason: mx_timeout when the lookup fails for network reasons, instead of false. The calling code should treat null as "ask again later" or "let the user through with a confirmation email," never as a hard reject. This is the part of the design that ages well. A verifier that conflates "unknown" with "bad" will, over time, quietly refuse valid users whenever the network blips.

A short wrapper that respects the three states:

async function assess(email) {
  const res = await fetch(
    "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=" +
      encodeURIComponent(email)
  );
  const data = await res.json();
  if (data.deliverable === true) return "accept";
  if (data.deliverable === false) return "reject";
  return "confirm"; // null: send a verification link, do not block
}

MX lookup answers "can this domain receive mail." SMTP answers "does this specific inbox exist," badly and unreliably in 2026. Use MX as your always-on filter, treat null as unknown, and only reach for SMTP when you run the infrastructure to make it trustworthy. I used MailProbe for the request shapes here; the hosted endpoint is at https://mailprobe.kevin-c0319.workers.dev/ and does MX plus syntax, disposable, role, and free checks. SMTP remains a self-hosted option.

Catch-all email domains and the false positives they cause

kevinc0319-prog — Fri, 11 Sep 2026 07:34:31 +0000

A catch-all domain is one whose mail server accepts messages for every address at the domain, whether or not the local part was ever created. Send to ceo@bigco.com, asdfgh@bigco.com, or this-does-not-exist@bigco.com, and the server takes the mail. The mailbox may or may not be read by anyone. The server does not say.

This is a legitimate configuration. Small companies turn it on so they never miss a typo'd address, and it is common among firms that route everything to one inbox or to a ticketing system. The trouble starts when a verification service meets a catch-all domain and has to decide what to report.

Why catch-all breaks the usual checks

The two checks people lean on are syntax validation and MX lookup. Syntax confirms the address is well formed. MX confirms the domain runs a mail server. Neither can see inside the domain to learn whether a specific local part is a real inbox.

A catch-all domain passes both. Its MX records are present and valid, so a verifier that stops at "domain can receive mail" reports the address as deliverable. It is, in the weak sense that the server will accept the connection. But that tells you nothing about whether a human reads randomstring@bigco.com.

The false positive appears here. A service reports deliverable: true for an address that is, for all practical purposes, garbage, because the domain is configured to swallow everything. The report is not lying about the domain. It is overclaiming about the inbox.

curl "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=info@stripe.com"

{
  "email": "info@stripe.com",
  "valid": true,
  "deliverable": true,
  "reason": "ok",
  "score": 85,
  "checks": {
    "syntax": true,
    "mx": {
      "ok": true,
      "records": [{ "exchange": "aspmx.l.google.com", "priority": 10 }],
      "source": "dns"
    },
    "role": true
  },
  "provider": "google-workspace"
}

That response confirms the domain is real and accepts mail. What it cannot do, with an MX-only check, is confirm that info is the only valid local part, or that some other local part would bounce. On a catch-all domain, the same shape of response would come back for an address no one monitors.

The deeper problem with SMTP here

You might think SMTP probing settles it. Connect, ask the server if the inbox exists, read the code. On a catch-all domain the server answers "yes" to every probe, because accepting everything is the whole point. So SMTP does not rescue you. It returns the same misleading 250 for real and fake local parts alike.

Some verification vendors react by tagging catch-all domains as "risky" and lowering the score. That is a reasonable signal, but it is easy to overuse. A catch-all domain is not a disposable domain. The people using info@ and sales@ on a catch-all are often exactly the business leads you want. Flagging the whole domain as low quality throws those out with the noise.

The signal you do have is the score

When a verifier knows a domain is catch-all, the useful move is to lower confidence without binning the address. MailProbe does not expose a catch-all flag, but it reports role and free, and both overlap with catch-all use in practice. sales@ and info@ on a catch-all domain are exactly the business leads you most want to keep. Treating the domain as risky because of its catch-all configuration, rather than because of the specific address, is the error that costs you those leads.

The honest framing is that a catch-all domain is a confidence problem, not a validity problem. The domain is real and it accepts mail. What you lack is proof about the local part. Lower the score if you must, but route the address to confirmation rather than rejection. The confirmation step resolves the uncertainty for free, and it does so without ever guessing.

Handling catch-all without rejecting real customers

The fix is not a stricter check. It is a different decision at the signup boundary.

Do not hard-block on a domain you cannot fully resolve to a single inbox. Treat "domain accepts mail, specific inbox unconfirmed" as unknown, the same null state you would use for a network timeout. Then move the burden to a channel you control: send a confirmation email. If the user clicks the link, the inbox is real and monitored, catch-all or not. If they do not, you have lost nothing you would have kept.

A practical flow looks like this:

async function gateSignup(email) {
  const res = await fetch(
    "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=" +
      encodeURIComponent(email)
  );
  const data = await res.json();

  // Hard rejects are cheap and safe: bad syntax, disposable, no MX at all.
  if (data.reason === "disposable" || data.reason === "invalid_format") return "reject";
  if (data.reason === "no_mx") return "reject";

  // Everything else, including catch-all domains, goes through confirmation.
  return "send_confirmation";
}

This keeps the false-positive rate on catch-all domains near zero, because you never silently accept an unconfirmed inbox, and you never silently reject a real business lead. The cost is one extra email, which you wanted to send anyway.

The wider lesson is that verification has two jobs. One is removing addresses that are definitely wrong. The other is sorting the rest into "confirmed" and "needs a confirmation step." Catch-all domains live entirely in that second bucket. Treat them as a reason to confirm, not as a reason to refuse.

I used MailProbe for the request shape above. Its hosted endpoint does MX, syntax, disposable, role, and free checks and is at https://mailprobe.kevin-c0319.workers.dev/. It does not claim to confirm individual inboxes on catch-all domains, which is the honest position. Pair it with a confirmation email and the catch-all problem stops being a problem.

Email typo correction at signup: the cheap fix that saves real users

kevinc0319-prog — Fri, 11 Sep 2026 07:34:27 +0000

The user types their address, hits submit, and walks away. They meant zhang@gmail.com. What they submitted was zhang@gmail.co. The form accepts it, because gmail.co is a syntactically valid domain. The confirmation email sails off to an address no one owns. The user never arrives, never complains, and you never learn why.

This is the quiet leak in most signup flows. It is not a bounce you can measure later. It is a silence you never see.

What a typo correction actually does

The useful case is narrow. The local part, the bit before the @, is almost always typed correctly. The damage is in the domain. People write gmail.co instead of gmail.com, gmial.com instead of gmail.com, hotmial.com instead of hotmail.com. The fix is to compare the typed domain against a list of known-good domains and offer the closest match.

The comparison is edit distance. You count the insertions, deletions, and substitutions needed to turn the typed domain into a candidate. One edit, co to com, is a strong signal. The verifier then returns a suggestion instead of a rejection, and the UI asks "did you mean gmail.com?"

curl "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=zhang@gmail.co"

{
  "email": "zhang@gmail.co",
  "valid": false,
  "deliverable": null,
  "reason": "typo_suspect",
  "score": 0,
  "suggestion": "zhang@gmail.com",
  "checks": {
    "syntax": true,
    "mx": { "ok": false, "records": [], "error": "no_mx", "source": null }
  }
}

The domain gmail.co has no MX records, which is the tell that trips the check. The API returns suggestion with the corrected address and reason set to typo_suspect. Note deliverable is null rather than false: the verifier is not certain the typed address is dead, it is certain a better candidate exists.

A small client handler turns that into a prompt:

async function checkEmail(email) {
  const res = await fetch(
    "https://mailprobe.kevin-c0319.workers.dev/v1/verify?email=" +
      encodeURIComponent(email)
  );
  const data = await res.json();
  if (data.suggestion) {
    showHint(`Did you mean ${data.suggestion}?`);
    return data.suggestion;
  }
  return email;
}

The leak leaves no trace in your dashboards

A hard bounce shows up in your email logs. A mistyped domain shows up as nothing: no signup event worth keeping, no bounce, no complaint. The only signal is a slow, unexplained gap between form submissions and confirmed accounts. If that gap is larger than your open-rate math predicts, a share of it is almost certainly typo loss, and the fix is a one-line hint at the form boundary rather than a rework of the whole funnel.

The mistake teams make is hunting for the leak in the wrong place. They audit their sending reputation and their subject lines, because those are where the metrics live. The typo loss is upstream of all of that, in the half second a user spent typing an address they will never check. You cannot A/B test your way out of an address no one owns.

Why the suggestion must not be automatic

The risk is over-correction. Edit distance has no sense of meaning. If you are too eager, you start "fixing" addresses that were right.

Imagine a user at a small company gmail.com.au who fat-fingers gmail.con.au. One edit away sits gmail.com.au, a real domain they may not own. Or a user on a regional provider whose domain is genuinely one letter off from Gmail. Correcting silently would ship their mail to a stranger. That is worse than the original typo, because it looks like success.

The safe rule is to suggest, never to substitute. Show the hint, pre-fill the corrected value in a confirm step, but require the user to accept it. When the edit distance is more than one, or the candidate domain is not in your known set, stay quiet. A correction offered for a two-letter mistake is a correction that will often be wrong, and a wrong correction erodes trust faster than a missed one.

There is also a cost side. Running edit distance against a domain list is cheap, but it should sit behind the cheaper checks. If the syntax is invalid or the domain is on the disposable list, there is no point computing suggestions. Spend the comparison only on addresses that are well formed and have a plausibly real, if wrong, domain.

Testing the hint is cheap

Show the suggestion to half of your signups and compare confirmation rates to the control group. The lift, when the address was genuinely mistyped, is immediate, and the downside in the control group is zero. If the lift is small, your users are not mistyping domains often, and you have spent an afternoon confirming it. If it is large, you have found a leak you did not know you had, and the repair is a few lines of client code.

The one thing to watch while testing is the false-correct rate. If the treatment group starts showing confirmation rates below the control, your suggestion is firing on addresses that were right, and you are sending users to confirm mail that was already correct. Pull the threshold back to a single edit and a known domain, and the false-correct rate drops to near nothing.

The payoff

The win is not correctness for its own sake. It is the users you keep. A mistyped domain is a user who wanted in and got nothing. One hint at the form boundary recovers them with zero friction, and it costs you one DNS lookup you were going to make anyway.

Pair the suggestion with a confirmation email and the loop closes. The hint catches the obvious typo on the spot. The confirmation email catches the rest, including the catch-all and unknown cases. Between them they remove the silent leak without ever silently rewriting a user's address.

I used MailProbe for the request and response shapes here. Its hosted endpoint returns the suggestion field and the typo_suspect reason, and it is at https://mailprobe.kevin-c0319.workers.dev/. The suggestion is a hint, not an edit, which is the part that matters in production.

Build a zero-dependency email verification service in Node

kevinc0319-prog — Fri, 11 Sep 2026 07:34:22 +0000

Hosted email verification APIs are convenient, but there are reasons to run your own. You might need SMTP probing, which a Cloudflare Worker cannot do because it has no raw TCP. You might have volume that makes per-call pricing awkward, or data rules that keep address checking on your side of the network. The good news is that a basic verifier needs nothing but Node and its standard library.

This walkthrough builds one. It checks syntax, flags disposable and free and role addresses, and resolves MX records over DNS. It runs on zero third-party packages.

The pipeline order matters

The order of checks is not cosmetic. Cheap checks that need no network go first. The one network call, the MX lookup, goes last, and it is wrapped so it can never stall the request.

import dns from 'node:dns';
import { promisify } from 'node:util';

const resolveMx = promisify(dns.resolveMx);

const DISPOSABLE = new Set([
  'mailinator.com', 'tempmail.com', '10minutemail.com', 'guerrillamail.com',
]);
const FREE = new Set([
  'gmail.com', 'qq.com', '163.com', 'outlook.com', 'yahoo.com', 'icloud.com',
]);
const ROLE = new Set(['info', 'support', 'noreply', 'sales', 'admin', 'help']);

// A practical subset of RFC 5322. Not the full grammar, and that is fine.
const SYNTAX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;

function domainOf(email) {
  return email.slice(email.indexOf('@') + 1).toLowerCase();
}

function localOf(email) {
  return email.slice(0, email.indexOf('@')).toLowerCase();
}

function withTimeout(promise, ms) {
  // Resolve (not reject) on timeout so the slow DNS query is abandoned quietly.
  return Promise.race([
    promise,
    new Promise((resolve) => setTimeout(() => resolve({ ok: false, error: 'mx_timeout' }), ms)),
  ]);
}

async function mxRecords(domain) {
  try {
    const records = await resolveMx(domain);
    return { ok: true, records };
  } catch (err) {
    // ENOTFOUND / ENODATA both mean the domain has no MX records.
    return { ok: false, error: err.code || 'mx_error' };
  }
}

async function verify(email) {
  if (!SYNTAX.test(email)) {
    return { valid: false, deliverable: null, reason: 'invalid_format', score: 0 };
  }

  const domain = domainOf(email);
  const local = localOf(email);

  // Local checks first. No network, so no reason to wait.
  if (DISPOSABLE.has(domain)) {
    return { valid: false, deliverable: false, reason: 'disposable', score: 75 };
  }

  const free = FREE.has(domain);
  const role = ROLE.has(local);

  // The only network call, and the only place a hang can happen.
  const mx = await withTimeout(mxRecords(domain), 1500);

  if (!mx.ok) {
    const reason = mx.error === 'mx_timeout' ? 'mx_timeout' : 'no_mx';
    return { valid: false, deliverable: null, reason, score: 0, free, role };
  }

  const score = 100 - (role ? 10 : 0) - (free ? 10 : 0);
  return { valid: true, deliverable: true, reason: 'ok', score, free, role, mx };
}

for (const e of ['test@gmail.com', 'foo@mailinator.com', 'info@bigco.com']) {
  console.log(e, '=>', JSON.stringify(await verify(e)));
}

Why the timeout resolves instead of rejects

The withTimeout helper resolves with { ok: false, error: 'mx_timeout' } rather than throwing. That is the whole point of the design. A DNS query that stalls or a network that blips is a reason to return inconclusive, not a reason to crash the request or, worse, to mark a good address as dead.

This is the mistake most homegrown verifiers make. They treat "the lookup failed" as "the address is invalid" and reject the signup. Over a long enough run, every flaky network moment becomes a lost user. Returning deliverable: null with reason: mx_timeout keeps the door open: the caller can send a confirmation email and let the user prove the inbox works.

Where SMTP would plug in

If you self-host on a machine with port 25 reach and a reputable IP, you can extend verify with an SMTP probe after the MX step. Open a socket to the lowest-priority exchange, issue MAIL FROM and RCPT TO, and read the reply code. Keep the same shape: any ambiguity becomes null, never false. On a Worker or any TCP-less runtime, leave it out. The MX check alone already removes the bulk of bad addresses.

Running it

Save the file as verify.mjs and run it with Node 18 or newer:

node verify.mjs

On a normal host with working DNS you will see MX records for gmail.com and a disposable reason for the temp-mail domain. The catch-all domain bigco.com returns deliverable: true on the strength of its MX records alone, which is the honest limit of an MX-only check. If you need to confirm the specific inbox, that is the confirmation-email step, not something this script should claim.

The script is a starting point, not a product. The disposable and free lists are tiny on purpose. A production build pulls a few hundred or a few thousand domains from a maintained source and refreshes them on a schedule. The shape of the result, and the discipline of returning null for the unknown, is what keeps it safe as the lists grow.

I built this example against the response contract of MailProbe, whose hosted endpoint returns the same fields (valid, deliverable, reason, score, checks, suggestion) and is at https://mailprobe.kevin-c0319.workers.dev/. The hosted version adds typo suggestions and provider fingerprinting that the script above leaves out, but the pipeline order and the inconclusive-on-failure rule are the same. Run the script locally for control and volume, reach for the API when you want the larger lists and the suggestion logic without maintaining them.