DEV Community: Anthony

How to Validate Email Addresses in Python (Beyond Regex)

Anthony — Fri, 19 Jun 2026 09:43:50 +0000

Search "validate email Python" and you'll drown in regexes. Regex has its place, but it only answers "does this look like an email?", not "can this address actually receive mail?" Here are the layers, and how to add the ones regex can't.

Layer 1: syntax (regex)

A simple pattern rejects obvious nonsense. Don't chase the giant RFC 5322 monster regex; it's huge and still tells you nothing about whether the domain exists.

import re

EMAIL_RE = re.compile(r"^[^@\s]+@[^@\s]+\.[^@\s]+$")

def looks_valid(email: str) -> bool:
    return bool(EMAIL_RE.match(email))

Layer 2: domain and MX records

A real address needs a domain that actually accepts mail. Check its MX records with dnspython:

import dns.resolver  # pip install dnspython

def domain_accepts_mail(domain: str) -> bool:
    try:
        return len(dns.resolver.resolve(domain, "MX")) > 0
    except Exception:
        return False

This removes dead domains and a lot of fakes. It's server-side only, though, and it won't tell you whether an address is disposable, a role account, or a likely typo.

Layer 3: disposable, role, and typo detection

These need data you don't really want to maintain yourself (a current list of throwaway domains, a list of common providers for typo suggestions, and so on). In practice most people reach for an email verification API here, which returns the lot in one call. The response shape is similar across providers:

import requests

def verify(email: str) -> dict:
    res = requests.post(
        "https://your-verification-api.example/v1/verify",
        headers={"x-api-key": "YOUR_KEY"},
        json={"email": email},
        timeout=10,
    )
    res.raise_for_status()
    return res.json()

# Typical response:
# {
#   "status": "risky", "score": 75,
#   "checks": {"syntax": True, "mx_found": True, "disposable": False, "role": False},
#   "did_you_mean": "gmail.com"
# }

Putting it together at signup

In a Flask or Django view, verify on the server before creating the account:

@app.post("/signup")
def signup():
    email = request.form["email"]
    result = verify(email)
    if result["status"] == "undeliverable":
        return {"error": "That email can't receive mail."}, 400
    # "risky" -> warn but allow; "deliverable" -> proceed
    create_account(email)
    return {"ok": True}

Show the did_you_mean hint in your form to recover typos, reject undeliverable on submit, and treat risky as a soft warning rather than a hard block.

Summary

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

Disclosure: I build an email verification API, so this is a topic I work on daily.
The approach above is vendor-neutral; any verification API follows the same shape.

How email verification works: syntax, MX, and SMTP explained

Anthony — Fri, 19 Jun 2026 09:40:12 +0000

"Email verification" sounds like one thing, but it's really a stack of checks of increasing depth and cost. Knowing what each layer actually proves helps you pick the right level instead of overpaying for verification you don't need.

Layer 1: syntax

The cheapest check: does the string look like a valid email address? A pragmatic regex catches obvious garbage (asdf, a@@b, trailing spaces). It's instant and free, but weak on its own: nobody@asdf.asdf passes syntax and can't receive a single message.

Layer 2: domain and MX records

Next, does the domain actually accept mail? Every domain that receives email publishes MX (mail exchanger) records in DNS pointing to its mail servers. A quick DNS lookup tells you whether any exist. No MX (and no fallback A record) means the domain can't receive mail, so the address is undeliverable no matter how it's spelled. This single step removes a large class of fakes and dead domains.

Layer 3: SMTP mailbox check

The deepest level connects to the domain's mail server and begins the motions of sending a message to ask whether that specific mailbox exists, without actually delivering anything. It's the only layer that can hint a particular inbox is real, but it comes with real caveats:

It's slow (a live connection per address).
Many servers are "accept-all" and say yes to everything, so the answer is often meaningless.
Lots of providers block or throttle these probes, and outbound port 25 is blocked on most modern hosting, so it's frequently unavailable anyway.

SMTP checks matter most for cleaning old, cold lists, and far less for stopping junk at signup.

The heuristics layer

Alongside those, useful verification adds signal that has nothing to do with deliverability per se:

Disposable detection: is it a throwaway provider?
Role detection: is it info@ or admin@ rather than a person?
Typo suggestions: "did you mean gmail.com?" for gmial.com.
A deliverability score: one 0–100 number that rolls it all up so you can just threshold on it.

Which layers do you actually need?

For the most common job, validating emails at signup, syntax + MX + the heuristics catch the overwhelming majority of bad addresses, instantly and cheaply. Live SMTP probing adds cost and unreliability for little extra benefit in that context, and is mainly worth it for bulk cleaning of stale lists.

So before reaching for the heaviest, slowest option, ask what you're actually trying to prevent. For most signup forms, the first two layers plus a few heuristics are all you need.

Disclosure: I build an email verification API, which is why I spend time thinking about this. The post is vendor-neutral; the layers apply to any tool you choose.

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.

Disclosure: I build an email verification API, so this is a topic I work on daily.
The approach above is vendor-neutral; any verification API follows the same shape.

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.

Disclosure: I build an email verification API, so this is a topic I work on daily.
The approach above is vendor-neutral; any verification API follows the same shape.