How to Reduce Your Signup Bounce Rate (a Practical Playbook)

Anthony — Thu, 18 Jun 2026 08:23:24 +0000

A high email bounce rate isn't just annoying; it actively damages your sender
reputation, which means even your good emails start landing in spam. Most bounces
trace back to bad addresses captured at signup. Fix the front door and the bounce
rate fixes itself.

Here's the playbook, roughly in order of impact-per-effort.

1. Understand why addresses go bad

Four culprits cover almost all of it:

Typos: jane@gmial.com, bob@hotmial.com. The user meant a real address.
Fakes: asdf@asdf.com, entered to skip your form.
Disposable: x@mailinator.com, used once then abandoned.
Role/dead: info@, or addresses at domains with no mail server at all.

Each needs a slightly different defence.

2. Catch typos in the form (recover real users)

Typos are the highest-value fix because the person wants to sign up; you just need
to nudge them. Verify on blur and surface a suggestion:

emailInput.addEventListener("blur", async () => {
  const res = await fetch("https://mailguard-api.atek.workers.dev/v1/verify", {
    method: "POST",
    headers: { "x-api-key": KEY, "Content-Type": "application/json" },
    body: JSON.stringify({ email: emailInput.value }),
  });
  const { did_you_mean } = await res.json();
  if (did_you_mean) showHint(`Did you mean ${localPart}@${did_you_mean}?`);
});

A single "did you mean gmail.com?" prompt recovers signups you'd otherwise lose to a
slipped finger.

3. Block clearly undeliverable addresses on submit

On submit, reject addresses with no mail server (no MX record) and flag disposable
ones. A verification API returns this in one call:

const { status, checks } = await verify(email);
if (status === "undeliverable") return showError("That email can't receive mail.");
if (checks.disposable) return showError("Please use a permanent email address.");

Don't be too aggressive: treat "risky" as a soft warning, not a hard block, so you
don't lose legitimate users on edge cases.

4. Use double opt-in for anything marketing-related

For newsletters and marketing lists, a confirmation email (double opt-in) guarantees
the address is real and that the person wants your mail. It's the single biggest
long-term protector of your sender reputation.

5. Monitor and prune

Watch your bounce rate per send; investigate spikes.
Periodically clean your existing list (a batch/CSV verification endpoint makes this easy) and suppress hard bounces.
Never email purchased lists; it's the fastest way to get blocklisted.

Putting it together

The 80/20 is steps 2 and 3: a verification call on your email field that powers a
typo hint and blocks undeliverable addresses. That alone removes most of the bad
emails before they ever reach your database.

How to Validate Email Addresses in JavaScript / Node.js (Beyond Regex)

Anthony — Thu, 18 Jun 2026 08:22:36 +0000

Search "validate email JavaScript" and you'll get a hundred regexes. Regex has its
place, but it only answers "does this look like an email?", not "can this address
actually receive mail?" This post covers the layers of email validation and how to
add the ones regex can't.

Layer 1: syntax (regex), necessary but weak

A pragmatic pattern catches obvious garbage:

const looksValid = (email) =>
  /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);

Don't chase the "perfect" RFC 5322 regex: it's enormous and still won't tell you the
domain exists. Use a simple pattern to reject nonsense, then move on.

What regex can't tell you:

Does the domain have a mail server? (@asdf.asdf passes regex, accepts no mail.)
Is it disposable? (@mailinator.com is perfectly valid syntactically.)
Did the user mean gmail.com instead of gmial.com?

Layer 2: domain / MX records

A real address needs a domain with an MX (mail exchanger) record. In Node you can
check DNS yourself:

import { resolveMx } from "node:dns/promises";

async function domainAcceptsMail(domain) {
  try {
    const records = await resolveMx(domain);
    return records.length > 0;
  } catch {
    return false;
  }
}

This already removes a big class of fakes. But it runs only server-side, doesn't
cover disposable detection or typo suggestions, and you'll end up maintaining
disposable-domain lists yourself.

Layer 3: disposable, role, and typo detection

This is where a verification API saves you a lot of list-maintenance and DNS plumbing.
Rather than rolling it all yourself, one call returns the full picture:

npm install mailguard

import { MailGuard } from "mailguard";

const mg = new MailGuard(process.env.MAILGUARD_KEY);

const result = await mg.verify("jane@gmial.com");
// {
//   status: "risky",
//   score: 75,
//   checks: { syntax: true, mx_found: true, disposable: false, role: false },
//   did_you_mean: "gmail.com"
// }

if (await mg.isDeliverable(email)) {
  // safe to accept
}

The SDK is dependency-free and works in Node 18+, Bun, Deno, Cloudflare Workers, and
the browser, so the same code runs on your API or your frontend.

Putting the layers together at signup

On blur: call the API, show a "did you mean…?" hint if did_you_mean is set.
On submit: reject status === "undeliverable"; warn (don't hard-block) on "risky".
Server-side: re-check on the backend too; never trust the client alone.

app.post("/signup", async (req, res) => {
  const r = await mg.verify(req.body.email);
  if (r.status === "undeliverable") return res.status(400).json({ error: "Invalid email" });
  // proceed to create the account
});

Summary

Regex = "looks like an email." Keep it simple.
MX lookup = "the domain can receive mail." Worth doing.
Disposable/role/typo detection + a single deliverability score = the part that actually cleans your signups, and the part not worth building from scratch.

DEV Community: Anthony