DEV Community: Arjun CS

Building a Disposable Email Detector API Endpoint from Scratch

Arjun CS — Tue, 13 Oct 2026 18:18:15 +0000

Disposable email addresses are a recurring headache for anything with a signup form: they pass basic syntax validation, have a real domain, and even receive a one-time code, but the inbox self-destructs shortly after. If you're trying to keep fake signups out of your product, here's how to build a basic detector endpoint yourself, and where the DIY approach actually hits its limits.

The basic approach

A disposable email detector needs at least two layers to be useful:

Domain-list matching — check the address's domain against a known list of disposable providers
MX record validation — confirm the domain can actually receive mail at all

Let's build a simple Node.js/Express endpoint that does both.

Step 1: Set up the endpoint

const express = require('express');
const dns = require('dns').promises;
const app = express();
app.use(express.json());

// A small sample list — in production this needs to be much larger
// and updated regularly, new disposable domains appear constantly
const disposableDomains = new Set([
  'mailinator.com',
  'yopmail.com',
  'guerrillamail.com',
  '10minutemail.com',
  'temp-mail.org',
  'throwawaymail.com',
  'maildrop.cc',
  'emailondeck.com'
]);

app.post('/api/check-email', async (req, res) => {
  const { email } = req.body;
  if (!email || !email.includes('@')) {
    return res.status(400).json({ error: 'Invalid email format' });
  }

  const domain = email.split('@')[1].toLowerCase();
  const result = await checkEmail(domain);
  res.json(result);
});

app.listen(3000, () => console.log('Running on port 3000'));

Step 2: Write the actual check logic

async function checkEmail(domain) {
  const result = {
    domain,
    isDisposable: false,
    hasMxRecord: false,
    risk: 'unknown'
  };

  // Layer 1: domain-list match
  if (disposableDomains.has(domain)) {
    result.isDisposable = true;
    result.risk = 'high';
    return result;
  }

  // Layer 2: MX record check
  try {
    const mxRecords = await dns.resolveMx(domain);
    result.hasMxRecord = mxRecords.length > 0;
    result.risk = result.hasMxRecord ? 'low' : 'high';
  } catch (err) {
    // No MX record found, domain likely can't receive mail
    result.hasMxRecord = false;
    result.risk = 'high';
  }

  return result;
}

This catches the obvious cases: known disposable domains and domains that simply can't receive mail. Good enough for a first pass.

Where this approach breaks down

A few real limitations worth knowing before you ship this:

The domain list goes stale fast. New disposable email services launch regularly, and a static list, even a long one, lags behind. You'd need a process to keep pulling updates, which is its own maintenance burden.

MX records don't confirm a live mailbox. A domain can have valid MX records and still be a disposable service, having mail infrastructure doesn't mean the inbox isn't designed to self-destruct in an hour.

No SMTP-level verification. This endpoint can't tell you whether the specific mailbox actually exists right now, that requires an actual SMTP handshake with the destination mail server, which is more involved to build and maintain reliably (handling timeouts, greylisting, rate limits from mail providers who don't want random servers pinging them repeatedly).

Catch-all domains will slip through. A domain configured to accept mail for any address will pass the MX check every time, even disposable ones, since "accepts mail" and "mailbox genuinely exists" aren't the same thing.

Where I'd actually draw the line

For a hobby project or internal tool, this basic version is a reasonable starting point. For anything production-facing where fake signups cost you real money (lead gen, trial abuse, gated content), I've found it's worth pairing this with a dedicated validation API rather than maintaining the disposable-domain list and SMTP logic yourself. I've used Gamalogic's Fake Email Checker API for this specifically, it runs the domain match, a live SMTP handshake, and catch-all/risk scoring together, with the disposable list kept updated server-side so you're not maintaining it. Tools like ZeroBounce have a similar API available if you're already integrated with them elsewhere.

Either way, the core idea holds: catch this at the point of signup, not after a bounce. By the time you see the bounce, you've already paid for the send and polluted your lead data.

Integrating Real-Time Email Validation into a Next.js Signup Flow

Arjun CS — Sun, 11 Oct 2026 18:29:52 +0000

Server-side validation catches bad emails before they hit your database, but by then the user has already submitted the form and is waiting on a response. If you want to tell someone their email looks undeliverable while they're still typing, that's a different problem — and Next.js's API routes make it pretty clean to solve.

Here's how I wired real-time validation into a signup flow, from the client-side debounce to the API route doing the actual check.

Step 1: The Basic Signup Form

Starting point — a simple form with client-side state:

'use client';
import { useState } from 'react';

export default function SignupForm() {
  const [email, setEmail] = useState('');
  const [emailStatus, setEmailStatus] = useState(null); // 'checking' | 'valid' | 'invalid' | null

  return (
    <form>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="you@company.com"
      />
      {emailStatus === 'checking' && <span>Checking...</span>}
      {emailStatus === 'invalid' && <span>This email doesn't look deliverable</span>}
      {emailStatus === 'valid' && <span>✓ Looks good</span>}
    </form>
  );
}

Right now nothing actually populates emailStatus. That's the part we're adding.

Step 2: Debouncing the Check

You don't want to fire a validation request on every keystroke. A simple debounce hook handles that:

import { useEffect, useState } from 'react';

function useDebounce(value, delay) {
  const [debounced, setDebounced] = useState(value);

  useEffect(() => {
    const timer = setTimeout(() => setDebounced(value), delay);
    return () => clearTimeout(timer);
  }, [value, delay]);

  return debounced;
}

Then hook it into the form:

const debouncedEmail = useDebounce(email, 600);

useEffect(() => {
  if (!debouncedEmail || !debouncedEmail.includes('@')) return;

  setEmailStatus('checking');

  fetch('/api/verify-email', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email: debouncedEmail }),
  })
    .then((res) => res.json())
    .then((data) => setEmailStatus(data.valid ? 'valid' : 'invalid'))
    .catch(() => setEmailStatus(null));
}, [debouncedEmail]);

Now the check fires 600ms after the user stops typing, not on every character.

Step 3: The API Route

This is the Next.js API route the form is calling. Keep the actual validation logic server-side — never expose your validation API key to the client:

// app/api/verify-email/route.js
export async function POST(request) {
  const { email } = await request.json();

  if (!email) {
    return Response.json({ valid: false, reason: 'missing_email' }, { status: 400 });
  }

  try {
    const result = await validateEmail(email);
    return Response.json({ valid: result.status !== 'invalid' });
  } catch (err) {
    console.error('Email validation error:', err.message);
    // fail open — don't block signup over a validation service hiccup
    return Response.json({ valid: true });
  }
}

async function validateEmail(email) {
  const response = await fetch(
    `https://api.gamalogic.com/v1/verify?email=${encodeURIComponent(email)}&api_key=${process.env.GAMALOGIC_API_KEY}`
  );
  return response.json();
}

I'm using Gamalogic's real-time email validation API here since it returns catch-all and disposable-domain detection alongside the basic valid/invalid check, which is more than a plain MX lookup gives you.

Step 4: Handling the Loading and Error States Properly

A few things I got wrong on my first pass, worth calling out:

Don't block form submission on a pending check. If the debounce hasn't resolved yet when the user hits submit, either wait briefly for it or re-validate server-side on submit — don't just let it through silently.
Fail open, not closed. If the validation API times out or errors, treat the email as valid rather than blocking a real signup over an infrastructure blip. Log the failure so you can investigate separately.
Debounce delay matters more than it looks. Too short (under 300ms) and you're firing requests on every pause; too long (over 1s) and it feels laggy. 500-600ms was the sweet spot for me.

Step 5: Putting It Together on Submit

async function handleSubmit(e) {
  e.preventDefault();

  if (emailStatus === 'invalid') {
    return; // don't let obviously bad emails through
  }

  const res = await fetch('/api/signup', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  });

  if (res.ok) {
    // redirect or show success
  }
}

The /api/signup route should still re-run validation server-side rather than trusting the client-side emailStatus — the client check is a UX nicety, not a security boundary.

Takeaway

Real-time validation is mostly a UX problem wrapped around a server-side check you probably already have. Debounce the input, keep the actual validation call server-side, and decide up front how you want to handle a validation-service failure so a slow API doesn't turn into blocked signups.

Handling Catch-All Domains Programmatically: A Developer's Guide

Arjun CS — Sun, 11 Oct 2026 18:28:55 +0000

Catch-all domains are the quiet reason your "validated" email list still has garbage in it. A catch-all domain accepts mail sent to any address at that domain — literally-anything@company.com will get a "delivered" response even if no such mailbox exists. Your MX check passes. Your regex passes. The email still bounces or silently vanishes later.

Here's how to actually detect and handle these programmatically, instead of finding out the hard way — this is the exact gap tools like Gamalogic exist to close.

Step 1: Why Standard Checks Miss This

Recall the basic validation chain most of us start with:

async function basicValidate(email) {
  const domain = email.split('@')[1];
  const mxRecords = await dns.resolveMx(domain);
  return mxRecords.length > 0; // true = "valid"
}

This only confirms the domain can receive mail — not that the specific mailbox exists. Catch-all domains are configured to accept everything, so this check will happily return true for addresses that don't exist at all.

await basicValidate('definitely-not-real-12345@some-catchall-domain.com');
// returns true — but that mailbox doesn't exist

That's the trap.

Step 2: Detecting a Catch-All Domain

The standard technique is to probe the domain with a clearly-fake, randomly generated address and see if the mail server accepts it too. If it accepts a made-up address, the domain is catch-all, and you can't trust individual-address checks on it.

const crypto = require('crypto');

function generateFakeAddress(domain) {
  const randomLocal = crypto.randomBytes(12).toString('hex');
  return `${randomLocal}@${domain}`;
}

async function isCatchAll(domain, smtpCheckFn) {
  const fakeAddress = generateFakeAddress(domain);
  const result = await smtpCheckFn(fakeAddress);
  return result.accepted === true; // if a fake address is "accepted", the domain is catch-all
}

smtpCheckFn here would be an SMTP handshake — connecting to the mail server and issuing a RCPT TO command without actually sending mail, then reading the server's response code.

Step 3: Why Rolling Your Own SMTP Probe Is Painful

In theory this is straightforward. In practice, doing SMTP-level probing yourself runs into a handful of real problems:

Greylisting. Many mail servers deliberately delay or soft-reject the first attempt from an unknown sender, so a single probe often gives a false negative.
Rate limiting and IP reputation. Mail servers actively watch for exactly this kind of probing behavior and will throttle or blacklist your sending IP.
Inconsistent server behavior. Some servers return ambiguous codes, some accept everything then bounce later (a "soft" catch-all), and some outright block SMTP verification attempts entirely.
Connection overhead. SMTP handshakes are slow compared to a DNS lookup, and doing this synchronously in a request path will tank your response times.

I hit all of this pretty quickly — a probe that worked fine against Gmail's test domain behaved completely differently against a mid-size company's mail server with greylisting turned on.

Step 4: Structuring the Check with a Fallback

Given those failure modes, it's worth wrapping the check with clear states rather than a binary true/false:

async function checkDomainType(domain) {
  try {
    const mxRecords = await dns.resolveMx(domain);
    if (mxRecords.length === 0) return { type: 'no_mail_server' };

    const catchAll = await isCatchAll(domain, smtpProbe);
    return { type: catchAll ? 'catch_all' : 'standard' };
  } catch (err) {
    return { type: 'unknown', error: err.message };
  }
}

Then decide what to do with each outcome in your application logic — a catch_all result usually means "accept the signup, but flag this list for a stricter re-verification step later" rather than an outright reject, since you genuinely can't tell valid from invalid at that point.

Step 5: Using a Dedicated Service Instead

Because reliable catch-all detection needs infrastructure most apps don't want to maintain (rotating IPs, greylisting retry logic, a database of known catch-all domains), this is one of the areas where handing it to an API makes sense rather than a maintenance burden. I ended up using Gamalogic's catch-all detection for this instead of maintaining my own SMTP probing setup:

async function checkDomainType(email) {
  const response = await fetch(
    `https://api.gamalogic.com/v1/verify?email=${encodeURIComponent(email)}&api_key=${process.env.GAMALOGIC_API_KEY}`
  );
  const data = await response.json();
  return data.status; // 'valid' | 'invalid' | 'catch-all'
}

Same three-way result, without needing to run your own SMTP infrastructure or manage IP reputation.

Takeaway

Catch-all domains break the assumption that "the mailbox exists" follows from "the domain accepts mail." Detecting them yourself is possible but comes with real infrastructure costs — greylisting, IP reputation, rate limits — that are easy to underestimate until you've hit them. Treat a catch-all result as "uncertain" rather than "valid," and build your signup or list-cleaning logic around that third state instead of forcing a binary decision.

Building an Email Verification Middleware for Express.js Signup Forms

Arjun CS — Mon, 07 Sep 2026 17:59:11 +0000

Signup forms are one of those things that look simple until you actually run one in production. You end up scattering the same email-checking logic across every route that touches user creation — signup, invite-a-friend, admin-adds-a-user — and eventually one of those routes forgets the check entirely.

The fix is boring but effective: pull the validation into middleware, run it once, and let every route that needs it just plug it in.

Here's how I set it up.

Step 1: The Problem with Inline Validation

A typical first pass looks like this, copy-pasted into every route that creates a user:

app.post('/signup', async (req, res) => {
  const { email } = req.body;

  if (!email || !email.includes('@')) {
    return res.status(400).json({ error: 'Invalid email' });
  }

  // create user...
});

This works until you have a second route. Then a third. Then someone adds a new "invite teammate" endpoint six months later and forgets the check entirely, because it's not enforced anywhere central — it's just a convention everyone has to remember.

Step 2: Pulling It Out into Middleware

Express middleware is the natural fix here. Define it once, attach it to any route that needs it:

// middleware/verifyEmail.js
function isValidFormat(email) {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

async function verifyEmailMiddleware(req, res, next) {
  const { email } = req.body;

  if (!email || !isValidFormat(email)) {
    return res.status(400).json({ error: 'Please provide a valid email address' });
  }

  next();
}

module.exports = verifyEmailMiddleware;

Now every route that needs email validation just declares it:

const verifyEmailMiddleware = require('./middleware/verifyEmail');

app.post('/signup', verifyEmailMiddleware, async (req, res) => {
  // by the time we get here, email format is already confirmed
  res.status(200).json({ message: 'Signed up successfully' });
});

app.post('/invite', verifyEmailMiddleware, async (req, res) => {
  // same guarantee, no copy-pasted logic
  res.status(200).json({ message: 'Invite sent' });
});

One place to update the rule, every route inherits it. No route can silently skip the check.

Step 3: Leveling It Up Past Format Checks

Format-only middleware stops garbage input, but it won't stop someone signing up with test@test.com or a domain that doesn't accept mail. To catch that, the middleware needs to do an async lookup before calling next():

const dns = require('dns').promises;

async function verifyEmailMiddleware(req, res, next) {
  const { email } = req.body;

  if (!email || !isValidFormat(email)) {
    return res.status(400).json({ error: 'Please provide a valid email address' });
  }

  const domain = email.split('@')[1];

  try {
    const mxRecords = await dns.resolveMx(domain);
    if (mxRecords.length === 0) {
      return res.status(400).json({ error: 'This domain cannot receive email' });
    }
  } catch {
    return res.status(400).json({ error: 'This domain cannot receive email' });
  }

  next();
}

This is the same MX-lookup approach I covered in my last post on Node.js email validation — it plugs neatly into the middleware pattern here.

Step 4: Handling Timeouts and Failures Gracefully

One thing that bit me early on: DNS lookups can hang or fail for reasons that have nothing to do with the user's email being bad (network blip, DNS server timeout). If your middleware treats every failure as "invalid email," you'll reject real users.

async function verifyEmailMiddleware(req, res, next) {
  const { email } = req.body;

  if (!email || !isValidFormat(email)) {
    return res.status(400).json({ error: 'Please provide a valid email address' });
  }

  const domain = email.split('@')[1];

  try {
    const mxRecords = await dns.resolveMx(domain);
    if (mxRecords.length === 0) {
      return res.status(400).json({ error: 'This domain cannot receive email' });
    }
    req.emailChecked = true;
    next();
  } catch (err) {
    console.error('Email verification lookup failed:', err.message);
    // fail open rather than blocking a legitimate signup on a DNS hiccup
    req.emailChecked = false;
    next();
  }
}

Whether you fail open or closed here is a judgment call — I lean toward failing open for signup forms since blocking a real user over a transient DNS issue is worse than letting one borderline case through.

Step 5: Swapping in a Proper Verification Service

Once you need catch-all detection, disposable-domain filtering, or mailbox-level checks, the DNS-only version above starts running into the same ceiling I hit in my last article. I ended up replacing the MX-lookup block with a call to Gamalogic's verification API, keeping the exact same middleware shape:

async function verifyEmailMiddleware(req, res, next) {
  const { email } = req.body;

  if (!email || !isValidFormat(email)) {
    return res.status(400).json({ error: 'Please provide a valid email address' });
  }

  try {
    const result = await validateWithAPI(email); // returns { status: 'valid' | 'invalid' | 'catch-all' }
    if (result.status === 'invalid') {
      return res.status(400).json({ error: 'This email address doesn\'t look deliverable' });
    }
    next();
  } catch (err) {
    console.error('Verification service error:', err.message);
    next(); // fail open, same reasoning as before
  }
}

Same interface, same routes, no changes anywhere else in the app — just a swapped-out implementation behind the middleware.

Takeaway

Middleware turns "remember to validate the email on every route" into "the route just can't run without it." Start with format + MX checks if you're prototyping, decide deliberately whether to fail open or closed on lookup errors, and swap in a dedicated verification step once DIY checks stop covering your edge cases.

How to Validate Email Addresses in Node.js Before Sending Transactional Emails

Arjun CS — Tue, 01 Sep 2026 19:36:36 +0000

If you've ever shipped a signup form and watched your bounce rate creep up a week later, you already know the problem: not every email address that looks valid is actually deliverable.

I ran into this on a transactional email pipeline — password resets, order confirmations, that kind of thing. Everything passed basic form validation, but a chunk of emails still bounced. Turns out "looks like an email" and "will actually receive an email" are two very different checks.

Here's how I fixed it, step by step.

Step 1: Why Regex Alone Isn't Enough

Most of us start here:

function isValidEmailFormat(email) {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return regex.test(email);
}

console.log(isValidEmailFormat("hello@example.com")); // true
console.log(isValidEmailFormat("hello@fake-domain-xyz123.com")); // also true!

Both of those return true. The problem is regex only checks shape, not existence. fake-domain-xyz123.com might not even resolve to a real mail server. Regex will happily pass it anyway.

Step 2: Checking the Domain Actually Has Mail Servers

The next layer most people add is an MX (Mail Exchange) record lookup — this confirms the domain is actually configured to receive email:

const dns = require('dns').promises;

async function domainHasMailServer(email) {
  const domain = email.split('@')[1];
  try {
    const mxRecords = await dns.resolveMx(domain);
    return mxRecords.length > 0;
  } catch (err) {
    return false; // no MX records = domain can't receive mail
  }
}

(async () => {
  console.log(await domainHasMailServer("hello@gmail.com")); // true
  console.log(await domainHasMailServer("hello@fake-domain-xyz123.com")); // false
})();

This catches a lot more junk than regex alone. Combine both checks and you've got a reasonable first line of defense:

async function basicEmailCheck(email) {
  if (!isValidEmailFormat(email)) return { valid: false, reason: 'bad_format' };
  const hasMx = await domainHasMailServer(email);
  if (!hasMx) return { valid: false, reason: 'no_mail_server' };
  return { valid: true };
}

Step 3: Where This Approach Breaks Down

MX-record checking is a solid start, but it has real limits once you're running this in production:

It doesn't catch full mailboxes or deactivated accounts. The domain can receive mail; that specific inbox might not exist anymore.
Catch-all domains lie to you. Some mail servers accept any address at their domain, even ones that don't exist, then silently drop it. Your MX check says "valid," reality says otherwise.
DNS lookups add latency if you're doing this synchronously on every signup request, and you'll want caching, retries, and rate-limit handling once volume grows.
No disposable-email detection. Temp-mail domains often have valid MX records too.

I hit all four of these within a couple months of shipping the DIY version. At that point, rolling your own becomes a maintenance project instead of a five-line function.

Step 4: Handing the Hard Part to an API

This is where a dedicated email validation API tools like Gamalogic earns its keep — it handles MX checks, catch-all detection, disposable-domain lists, and mailbox-level verification behind one call, so you're not maintaining that logic yourself.

I ended up wiring Gamalogic into this same signup flow, since it covers the catch-all and disposable-domain gaps that MX-only checking misses:

const axios = require('axios');

async function validateWithAPI(email, apiKey) {
  const response = await axios.get('https://api.gamalogic.com/v1/verify', {
    params: { email, api_key: apiKey }
  });
  return response.data; // { status: 'valid' | 'invalid' | 'catch-all', ... }
}

Swap this in wherever your DIY check was, and you get mailbox-level confidence instead of just "the domain exists."

Step 5: Putting It in the Signup Flow

app.post('/signup', async (req, res) => {
  const { email } = req.body;

  const result = await validateWithAPI(email, process.env.EMAIL_API_KEY);

  if (result.status === 'invalid') {
    return res.status(400).json({ error: 'This email address doesn\'t look deliverable.' });
  }

  // proceed with account creation
  res.status(200).json({ message: 'Signed up successfully' });
});

Reject clearly invalid addresses at signup, and you avoid the downstream cost entirely — bounced password resets, wasted sends, and a slowly-tanking sender reputation.

Takeaway

Regex gets you shape. MX lookups get you domain existence. Neither gets you mailbox-level confidence, and that gap is exactly where bounce rates come from. If you're just prototyping, the DIY checks above are fine. If you're sending real transactional volume, it's worth handing that last mile to something built for it rather than re-discovering catch-all domains the hard way, like I did.