DEV Community: Arjun CS

Detecting Catch-All and Role-Based Addresses Programmatically in Go

Arjun CS — Tue, 03 Nov 2026 20:16:51 +0000

Two kinds of email address cause trouble precisely because they look fine. A catch-all domain accepts mail for any address, so a mailbox check can't prove a specific inbox exists. A role-based address (info@, support@, sales@) belongs to a team, not a person, so it rarely engages.

Neither should be a hard reject. Both should be flagged so your application can decide what to do. Here's a small Go program that does that, with bounded concurrency, timeouts, and a three-way decision instead of a yes/no.

The design

Instead of returning valid or invalid, classify every address as one of three outcomes:

Accept: looks fine
Review: deliverable but uncertain or low-value (catch-all, role-based, high risk)
Reject: invalid or disposable

That third state is the important design choice. Catch-all and role-based addresses aren't errors, they're judgment calls, and your product or campaign decides how to treat them.

Step 1: The result type

The real-time validation API returns a JSON object with fields such as valid, disposable, role_based, catch_all, and risk_score. Map them to a struct:

package main

import (
    "context"
    "encoding/json"
    "fmt"
    "net/http"
    "net/url"
    "os"
    "strings"
    "sync"
    "time"
)

type ValidationResult struct {
    Email       string `json:"email"`
    Valid       bool   `json:"valid"`
    SyntaxValid bool   `json:"syntax_valid"`
    SMTPCheck   string `json:"smtp_check"`
    Disposable  bool   `json:"disposable"`
    RoleBased   bool   `json:"role_based"`
    CatchAll    bool   `json:"catch_all"`
    SEGDetected bool   `json:"seg_detected"`
    RiskScore   int    `json:"risk_score"`
    Status      string `json:"status"`
}

I'm using Gamalogic's validation API for this. Confirm the exact field types against the API documentation before relying on them, since a type mismatch will make decoding fail.

Step 2: The API call, with a context

func validate(ctx context.Context, client *http.Client, email, apiKey string) (*ValidationResult, error) {
    q := url.Values{}
    q.Set("email", email)
    q.Set("api_key", apiKey)

    endpoint := "https://api.gamalogic.com/v1/validate?" + q.Encode()
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
    if err != nil {
        return nil, err
    }

    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    if resp.StatusCode != http.StatusOK {
        return nil, fmt.Errorf("validation API returned %d", resp.StatusCode)
    }

    var result ValidationResult
    if err := json.NewDecoder(resp.Body).Decode(&result); err != nil {
        return nil, err
    }
    return &result, nil
}

Using NewRequestWithContext means a slow request can be cancelled, and reusing one http.Client lets Go reuse connections.

Step 3: Classify

type Decision string

const (
    Accept Decision = "accept"
    Review Decision = "review"
    Reject Decision = "reject"
)

func classify(r *ValidationResult) (Decision, string) {
    switch {
    case !r.Valid || r.Disposable:
        return Reject, "invalid or disposable"
    case r.CatchAll:
        return Review, "catch-all domain, deliverability uncertain"
    case r.RoleBased:
        return Review, "role-based address"
    case r.RiskScore >= 70:
        return Review, "high risk score"
    default:
        return Accept, "ok"
    }
}

The order matters. Hard failures come first, then the uncertain cases. The risk score threshold of 70 is an arbitrary example, so tune it against how the score behaves on your own data.

A catch-all domain is the clearest reason for a Review state. The server accepts mail for any address, so even a clean SMTP check can't confirm the mailbox is real. Sending to these in smaller batches and watching bounces is a sensible approach.

Step 4: A local fallback for role addresses

If the API is unavailable, a small local check can still catch obvious role-based names:

var roleLocalParts = map[string]struct{}{
    "info": {}, "support": {}, "sales": {}, "admin": {}, "contact": {},
    "hello": {}, "help": {}, "billing": {}, "noreply": {}, "no-reply": {},
    "postmaster": {}, "webmaster": {}, "office": {}, "team": {},
}

func isRoleBasedLocal(email string) bool {
    at := strings.LastIndex(email, "@")
    if at <= 0 {
        return false
    }
    local := strings.ToLower(email[:at])
    if i := strings.Index(local, "+"); i >= 0 {
        local = local[:i] // strip +tag
    }
    _, ok := roleLocalParts[local]
    return ok
}

A list like this is only a rough guide. Teams use all sorts of names, so treat the API result as the source of truth and the local list as a fallback. Role-based addresses behave differently from named contacts, which is why they're worth flagging.

Step 5: Run it concurrently, with a limit

func check(client *http.Client, email, apiKey string) string {
    ctx, cancel := context.WithTimeout(context.Background(), 6*time.Second)
    defer cancel()

    res, err := validate(ctx, client, email, apiKey)
    if err != nil {
        if isRoleBasedLocal(email) {
            return fmt.Sprintf("%-28s review (role-based, API unavailable)", email)
        }
        return fmt.Sprintf("%-28s retry (API error: %v)", email, err)
    }

    decision, reason := classify(res)
    return fmt.Sprintf("%-28s %s (%s)", email, decision, reason)
}

func main() {
    apiKey := os.Getenv("GAMALOGIC_API_KEY")
    emails := []string{"jane@example.com", "info@example.com", "test@mailinator.com"}

    client := &http.Client{Timeout: 5 * time.Second}
    sem := make(chan struct{}, 5) // at most 5 requests in flight
    var wg sync.WaitGroup
    results := make([]string, len(emails))

    for i, e := range emails {
        wg.Add(1)
        go func(i int, e string) {
            defer wg.Done()
            sem <- struct{}{}
            defer func() { <-sem }()
            results[i] = check(client, e, apiKey)
        }(i, e)
    }

    wg.Wait()
    for _, r := range results {
        fmt.Println(r)
    }
}

Each goroutine writes to its own slice index, so there's no shared-write race, and the channel acts as a semaphore to cap concurrency. Failures return "retry" rather than silently accepting an unchecked address, which is safer for a list-cleaning job than for a live signup form.

Things to watch for

Rate limits and credits. Each call is a validation, so check your plan's limits and keep the concurrency cap modest.
Large lists. For many thousands of addresses, a bulk upload or bulk API is usually better than one request per address.
Don't auto-reject Review cases. A small company's info@ may be the real contact. Decide per use case.
Retries. Add retry with backoff for transient errors, and avoid hammering the API during an outage.

Where this fits

This program covers the classification logic, but the detection itself (SMTP checks, catch-all identification, risk scoring) is the work the API does for you. Email Validation platforms like Gamalogic, ZeroBounce and Kickbox expose comparable APIs, so the same three-way structure applies if you use any of them.

How to Rate-Limit and Validate Email Domains in a Django Signup View

Arjun CS — Fri, 30 Oct 2026 20:18:40 +0000

A signup form is one of the cheapest things for an attacker or a bot to hammer, and every request can trigger work on your side: DNS lookups, third-party API calls, database writes. If you validate email domains without limiting how often the form can be hit, you're paying for the abuse.

This walkthrough puts both protections in one Django signup view: rate limiting so the form can't be spammed, and layered email checks so fake or undeliverable addresses are rejected before an account is created.

The order matters

Run the cheap checks first and the expensive ones last:

Rate limit (almost free, blocks abuse before any real work happens)
Local checks (disposable-domain list, then a cached MX lookup)
External API check (costs money and adds latency, so only reached by requests that passed everything else)

Putting the rate limit first means a bot hammering your form never gets as far as your paid API calls.

Setup

pip install django-ratelimit dnspython requests

You also need a cache backend shared across workers (Redis or Memcached). Rate limits stored in a per-process local-memory cache won't work correctly when you run several workers.

Step 1: Cached MX lookup

# validators.py
import dns.resolver
import dns.exception
from django.core.cache import cache


def domain_has_mx(domain: str) -> bool:
    cache_key = f"mx:{domain}"
    cached = cache.get(cache_key)
    if cached is not None:
        return cached

    try:
        answers = dns.resolver.resolve(domain, "MX", lifetime=3.0)
        result = len(answers) > 0
    except (dns.resolver.NXDOMAIN, dns.resolver.NoAnswer, dns.resolver.NoNameservers):
        result = False
    except dns.exception.Timeout:
        # DNS hiccup: fail open and don't cache the result
        return True

    cache.set(cache_key, result, 60 * 60)  # cache for an hour
    return result

Caching matters because many signups share the same domains (gmail.com, outlook.com), so you don't need a DNS lookup for every request.

One caveat: under the mail standards, a domain with no MX record can still receive mail at its A record. Treating "no MX" as invalid is a reasonable simplification for signup forms, but it's worth knowing it's a simplification.

Step 2: A local disposable-domain list

DISPOSABLE_DOMAINS = {
    "mailinator.com",
    "yopmail.com",
    "guerrillamail.com",
    "10minutemail.com",
    "temp-mail.org",
}

This list will go stale quickly, which we'll come back to. It's still a useful free first filter.

Step 3: An external validation check

# validators.py (continued)
import requests
from django.conf import settings


def api_says_acceptable(email: str) -> bool:
    try:
        resp = requests.get(
            "https://api.gamalogic.com/v1/validate",
            params={"email": email, "api_key": settings.GAMALOGIC_API_KEY},
            timeout=4,
        )
        resp.raise_for_status()
        data = resp.json()
    except (requests.RequestException, ValueError):
        return True  # fail open: don't block real users on an API outage

    # Placeholder mapping: check the API docs for the real response fields
    if data.get("disposable"):
        return False
    if data.get("valid") is False:
        return False
    return True

I'm calling Gamalogic's real-time validation API here. The field names in the last few lines are placeholders, so map them to the response schema in the API documentation. Note the short timeout and the fail-open behaviour: a slow or unavailable third-party service shouldn't stop legitimate signups.

Step 4: The form

# forms.py
from django import forms
from django.core.exceptions import ValidationError
from .validators import DISPOSABLE_DOMAINS, domain_has_mx, api_says_acceptable


class SignupForm(forms.Form):
    email = forms.EmailField()

    def clean_email(self):
        email = self.cleaned_data["email"].lower()
        domain = email.split("@", 1)[1]

        if domain in DISPOSABLE_DOMAINS:
            raise ValidationError("Please use a permanent email address.")
        if not domain_has_mx(domain):
            raise ValidationError("That email domain can't receive mail.")
        if not api_says_acceptable(email):
            raise ValidationError("That email address doesn't look valid.")

        return email

Step 5: The rate-limited view

# views.py
from django.shortcuts import render, redirect
from django_ratelimit.decorators import ratelimit
from .forms import SignupForm


@ratelimit(key="ip", rate="10/h", method="POST", block=False)
@ratelimit(key="post:email", rate="3/h", method="POST", block=False)
def signup(request):
    if getattr(request, "limited", False):
        return render(
            request,
            "signup.html",
            {"form": SignupForm(), "error": "Too many attempts. Try again later."},
            status=429,
        )

    if request.method == "POST":
        form = SignupForm(request.POST)
        if form.is_valid():
            # create the account here
            return redirect("welcome")
    else:
        form = SignupForm()

    return render(request, "signup.html", {"form": form})

Two limits are stacked on purpose. The IP limit slows one source hammering the form, and the per-email limit stops the same address being retried repeatedly. With block=False, the decorator sets request.limited and lets you return a friendly 429 page instead of a bare error. Because the limit runs before the form is validated, limited requests never reach your DNS lookups or paid API calls.

Pitfalls to watch for

Proxies and load balancers. key="ip" uses the connecting address. Behind a proxy that can be the proxy's own IP, so configure which header to trust carefully, since forwarded headers can be spoofed.
Shared IPs. Offices and mobile networks can share one IP, so don't set the IP limit so low that real users get blocked.
Cache backend. Use a shared cache such as Redis in production, as mentioned above.
False positives. No check is perfect, so keep error messages polite and let users correct themselves.

Where the DIY version stops

A hand-kept disposable list and an MX check will catch the obvious cases. They won't tell you whether the specific mailbox exists, and they miss newly launched disposable services and catch-all domains, which accept mail for any address. That gap is why I use a validation API for the last step. Gamalogic email validation API runs the mailbox and risk checks together. ZeroBounce and Kickbox have comparable APIs if you're already integrated with one of them.

How are you protecting your signup endpoints: rate limits, validation, CAPTCHAs, or a mix? I'd like to hear what's worked.

Blocking Temp-Mail Signups in a React Form with Real-Time Validation

Arjun CS — Wed, 21 Oct 2026 12:02:28 +0000

Throwaway addresses from services like Mailinator or 10 Minute Mail pass every basic regex check. They have a valid format, a real domain, and a working inbox, just one that disappears in an hour. If your signup form feeds a trial, a gated download, or a lead list, those signups add noise and sometimes abuse.

Here's a practical way to catch them in a React form: a debounced check while the user types, a small backend proxy so your API key never reaches the browser, and a server-side re-check on submit.

The architecture

Three pieces, and the order matters:

React form that checks the email shortly after the user stops typing
Your own backend route that calls the validation API, so the key stays secret
A final check on submit on the server, because anything running in the browser can be bypassed

Skip piece 2 and you'll end up shipping an API key in your frontend bundle. Skip piece 3 and anyone can post straight to your signup endpoint and avoid the check entirely.

Step 1: A small debounce hook

Without debouncing, you'd fire a request on every keystroke.

import { useState, useEffect } 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;
}

Step 2: The form component

export default function SignupForm() {
  const [email, setEmail] = useState('');
  const [status, setStatus] = useState('idle'); // idle | checking | ok | blocked
  const debouncedEmail = useDebounce(email, 600);

  useEffect(() => {
    // Skip empty or obviously malformed input
    if (!debouncedEmail || !/^\S+@\S+\.\S+$/.test(debouncedEmail)) {
      setStatus('idle');
      return;
    }

    const controller = new AbortController();
    setStatus('checking');

    fetch('/api/check-email', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ email: debouncedEmail }),
      signal: controller.signal,
    })
      .then((res) => res.json())
      .then((data) => setStatus(data.allowed ? 'ok' : 'blocked'))
      .catch((err) => {
        // Ignore cancelled requests; fail open on real errors
        if (err.name !== 'AbortError') setStatus('ok');
      });

    // Cancel the in-flight request if the email changes again
    return () => controller.abort();
  }, [debouncedEmail]);

  return (
    <form>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="you@company.com"
      />
      {status === 'checking' && <p>Checking...</p>}
      {status === 'blocked' && (
        <p>Please use a permanent email address, temporary inboxes aren't accepted.</p>
      )}
      <button type="submit" disabled={status === 'blocked' || status === 'checking'}>
        Sign up
      </button>
    </form>
  );
}

Two details worth noticing. The AbortController cancels stale requests so a slow response for an old value can't overwrite the result for the current one. And errors fail open: if the validation service has a hiccup, you let the signup through rather than blocking a real user.

Step 3: The backend proxy

A minimal Express route that keeps the key on the server:

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

app.post('/api/check-email', async (req, res) => {
  const { email } = req.body;
  if (!email) return res.status(400).json({ allowed: false });

  try {
    const url =
      `https://api.gamalogic.com/v1/validate` +
      `?email=${encodeURIComponent(email)}` +
      `&api_key=${process.env.GAMALOGIC_API_KEY}`;

    const response = await fetch(url);
    const result = await response.json();

    res.json({ allowed: isAcceptable(result) });
  } catch (err) {
    console.error('Validation error:', err.message);
    res.json({ allowed: true }); // fail open
  }
});

// Placeholder logic: check the API docs for the actual response fields
// and map them here (disposable flag, validity, risk level, etc.)
function isAcceptable(result) {
  if (result.disposable) return false;
  if (result.valid === false) return false;
  return true;
}

app.listen(3000);

I'm calling Gamalogic's real-time validation API here, which runs syntax, domain, SMTP and risk checks in one request. The field names in isAcceptable are placeholders, so check the response schema in the API documentation and adjust the mapping to match.

Step 4: Re-check on submit, server-side

The client-side check is for user experience only. Your actual signup handler should validate again:

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

  const allowed = await checkEmailServerSide(email); // same logic as above
  if (!allowed) {
    return res.status(422).json({ error: 'Please use a permanent email address.' });
  }

  // ...create the account
  res.json({ ok: true });
});

Without this, a bot or a curious user can skip your React form and post directly to the endpoint.

Things to watch out for

False positives. No detection is perfect. Keep the error message polite and let users fix their input, rather than silently rejecting them.
Latency. Real-time checks add a delay. The debounce and the "Checking..." state keep the form feeling responsive, and you should test latency against your own traffic and region.
Rate limits and cost. Every keystroke pause is a billable call on most services. The debounce helps, and you can add a simple cache for addresses you've already checked.
Don't over-block. Some people use privacy aliases from legitimate services (like Apple's hide-my-email) that aren't throwaway inboxes. Decide what your policy is before you ship it.

Why use an API instead of a blocklist

A hand-maintained list of disposable domains goes stale quickly, since new services appear all the time, and it can't confirm whether a mailbox actually exists. A validation API handles the domain matching, the live SMTP check, and the risk scoring together. I work with Gamalogic on this side of things, and its fake and disposable email checker covers this use case. ZeroBounce and Kickbox have comparable APIs if you're already integrated with one of them.

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.