DEV Community: Jonas Hämmerle

The complete guide to disposable email detection

Jonas Hämmerle — Tue, 14 Jul 2026 12:55:24 +0000

Syntax-valid, MX-record-valid, and still worthless for your product: that's a disposable email address from 10minutemail, guerrillamail, mailinator, or one of several hundred similar throwaway-inbox services. If you're not filtering these, a meaningful slice of your "verified" signups are addresses nobody will ever check twice.

Here's why this is a genuinely different problem from syntax or MX validation, and how to actually solve it.

Why there's no algorithmic tell. A disposable-mail domain looks completely normal — valid syntax, real MX records, sometimes even a legitimate-looking domain name. There's no structural pattern that distinguishes mailinator.com from gmail.com at the protocol level. The only reliable signal is a maintained list of known disposable domains, checked against the domain part of the address:

function isDisposable(email, disposableDomainSet) {
  const domain = email.split("@")[1]?.toLowerCase();
  return disposableDomainSet.has(domain);
}

The catch: the list has to stay current. New disposable-mail domains spin up constantly — some services rotate domains specifically to dodge blocklists. A list you snapshot once and never update degrades within weeks. The community-run disposable-email-domains project is a solid free starting point and is actively maintained, but you need a process to re-sync it, not a one-time import.

Where this fits in the validation pipeline. Order matters, because each check is progressively more expensive and should only run if the previous one passed:

Syntax — near-instant, always run
MX record lookup — one DNS call, catches typo'd/dead domains
Disposable-domain check — a set lookup against your list, catches throwaway-but-technically-valid addresses

Running them in that order means you only pay for the disposable-domain check on addresses that already passed the cheaper filters — no wasted work on obviously broken input.

What it doesn't catch: a user who signs up with a real Gmail address they simply never check again. Disposable-domain detection targets services designed for throwaway use, not general inbox abandonment — that's a retention problem, not a validation one.

I run this exact pipeline (syntax → MX → disposable-domain, each opt-in past the first) as an endpoint on Validate with a synced domain list, if you'd rather not own the re-sync process yourself. Sibling APIs on the same account: QR API and Currency API.

The complete guide to disposable email detection

Jonas Hämmerle — Sun, 12 Jul 2026 09:48:12 +0000

Here's why this is a genuinely different problem from syntax or MX validation, and how to actually solve it.

function isDisposable(email, disposableDomainSet) {
  const domain = email.split("@")[1]?.toLowerCase();
  return disposableDomainSet.has(domain);
}

Where this fits in the validation pipeline. Order matters, because each check is progressively more expensive and should only run if the previous one passed:

Syntax — near-instant, always run
MX record lookup — one DNS call, catches typo'd/dead domains
Disposable-domain check — a set lookup against your list, catches throwaway-but-technically-valid addresses

Running them in that order means you only pay for the disposable-domain check on addresses that already passed the cheaper filters — no wasted work on obviously broken input.

Why your regex for IBAN validation is probably wrong

Jonas Hämmerle — Sun, 12 Jul 2026 09:47:29 +0000

A regex like /^[A-Z]{2}\d{2}[A-Z0-9]{11,30}$/ will pass through plenty of IBANs that are complete garbage. It checks the shape — two letters, two digits, then alphanumerics — but shape isn't validity, and this is the mistake nearly every from-scratch IBAN validator makes.

Here's what a shape-only regex misses, in order of how often it bites people:

1. Country-specific length. IBAN length isn't a range, it's a fixed number per country: Germany is always 22 characters, the Netherlands 18, Malta 31. A regex with {11,30} for the BBAN portion accepts a "German" IBAN that's the wrong length for Germany, because it's only checking the global range across all countries, not the specific one this IBAN claims to be from.

2. The checksum. This is the part a regex structurally cannot do — regular expressions can't compute a mod-97 checksum, because that requires arithmetic over the whole string, not pattern matching. Every IBAN has two check digits (positions 3-4) that are the result of ISO 7064's mod-97-10 algorithm applied to the rearranged, letter-to-number-converted account number. A regex will happily accept an IBAN with those two digits set to anything:

function isValidIBAN(iban) {
  const clean = iban.replace(/\s+/g, "").toUpperCase();
  if (!/^[A-Z]{2}\d{2}[A-Z0-9]+$/.test(clean)) return false; // shape check — necessary but nowhere near sufficient

  const rearranged = clean.slice(4) + clean.slice(0, 4);
  const numeric = rearranged.replace(/[A-Z]/g, c => (c.charCodeAt(0) - 55).toString());

  let remainder = numeric;
  while (remainder.length > 2) {
    const chunk = remainder.slice(0, 9);
    remainder = (parseInt(chunk, 10) % 97) + remainder.slice(chunk.length);
  }
  return parseInt(remainder, 10) % 97 === 1;
}

Note the chunked-modulo loop — IBANs convert to numbers with 30+ digits, well past what JS's Number type can hold precisely, so you can't just do bigNumber % 97 in one step without either a BigInt polyfill or this kind of iterative reduction.

3. Per-country BBAN structure. Beyond length, each country also defines which positions must be digits vs letters within the BBAN. A regex checking "alphanumeric" for the whole remainder will accept a UK IBAN with digits where the bank code letters should be.

None of this means "validate against a live bank lookup" — that's a different, heavier problem (does the account exist right now), and format validation deliberately doesn't answer it. It means: regex for shape, then the real mod-97 checksum, then country-specific length/structure — in that order, each one catching what the previous step can't.

I wrapped all three checks into one endpoint on Validate if you'd rather not own the mod-97 edge cases and the per-country BBAN table yourself. Same account also covers QR API and Currency API if useful.

Real-time currency conversion API - no signup required

Jonas Hämmerle — Sun, 12 Jul 2026 09:46:38 +0000

Most currency-conversion APIs make you register for a separate vendor account, verify an email, and sometimes wait for manual approval before you get a key — for something that should be a two-line integration. Here's a route that skips the vendor-specific signup entirely.

RapidAPI's marketplace lets you subscribe with the RapidAPI key you already have (or create once, for free) rather than a new account per data provider. For Currency API, that means:

curl "https://currency-api.p.rapidapi.com/v1/convert?from=EUR&to=USD&amount=100" \
  -H "X-RapidAPI-Key: <your-rapidapi-key>" \
  -H "X-RapidAPI-Host: currency-api.p.rapidapi.com"

{"from":"EUR","to":"USD","amount":100,"rate":1.0821,"result":108.21,"date":"2026-07-11"}

One RapidAPI key, and you're subscribed to every API on the platform you want to try — including this one, Validate for input validation, and QR API for QR generation.

A couple of implementation details worth knowing if you're building this into a checkout or pricing display:

Rates come from the European Central Bank (via Frankfurter, a free keyless proxy over ECB reference rates), updated once per ECB business day — not a live tick-by-tick feed. Fine for pricing pages and invoicing; not a substitute for a trading-grade feed if you're doing FX execution.
Fail loud, not silent. If the upstream rate source is unreachable, the API returns a clean 502 instead of quietly serving a stale cached rate. For anything touching money, knowing the number is wrong beats not knowing it's stale.
/v1/rates vs /v1/convert — pull the whole rate table once per base currency if you're converting to several currencies at once (one call, cache it client-side for the day), and use /v1/convert for one-off single conversions.

Free tier is 500,000 requests/month, no card required to start.

How to generate QR codes for free with an API

Jonas Hämmerle — Sun, 12 Jul 2026 09:41:32 +0000

Generating a QR code server-side usually means pulling in a heavyweight image library, or shelling out to a third-party service that watermarks the output or rate-limits you into a paid plan. Here's the simplest version that actually works in production.

The core idea: a QR code is just a grid of black/white modules encoding your data with Reed-Solomon error correction, then rendered as an image. You don't need to implement the encoding yourself — you need an endpoint that returns either a ready-to-embed SVG or the raw module matrix if you want to render it yourself (canvas, terminal, whatever):

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&ecc=M&cellSize=8" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

That's an SVG you can embed directly with an <img> tag or inline it for crisp scaling at any size — no rasterization artifacts. A few things worth knowing before you ship this:

Error correction level matters more than people think. H (30% recovery) survives a logo overlay or a slightly damaged print; L (7%) is fine for a clean digital display. Don't default to the highest level everywhere — it makes the code visually denser for no benefit if nothing's ever going to obscure it.
Cap your input length. QR codes get exponentially denser as the encoded string grows. If you're encoding a URL, shorten it first; don't just dump JSON payloads into a QR code and expect a scannable result.
SVG over PNG when you can. Vector output means no blurring when someone screenshots and enlarges it, which happens more than you'd expect with QR codes.

I built QR API as a free-to-start, stateless endpoint for exactly this — no data logged, no watermark, SVG or raw matrix output. Same provider also runs Validate (IBAN/email/phone/etc. validation) and Currency API (exchange rates) if you need those too.

Stop using regex for phone validation - use this instead

Jonas Hämmerle — Sat, 11 Jul 2026 10:19:49 +0000

A regex for "valid phone number" is a trap. International phone numbering isn't regular: number length, valid area codes, and mobile-vs-landline prefixes differ per country and change over time as ranges get reassigned. A regex that's correct today starts silently misclassifying numbers months later, and you won't notice until a support ticket comes in.

The actual fix is using the numbering-plan data Google publishes and maintains for Android/Chrome: libphonenumber, or its much smaller JS port libphonenumber-js.

import { parsePhoneNumberFromString } from "libphonenumber-js";

const phone = parsePhoneNumberFromString("+49 30 1234567");
phone?.isValid();              // true - checks length + pattern for that country
phone?.country;                // "DE"
phone?.getType();               // "FIXED_LINE" | "MOBILE" | undefined (not always determinable)
phone?.formatInternational();   // "+49 30 1234567", normalized

Two things regex can't give you that this does for free:

Country-aware validity. "Valid length" isn't one number — it varies by country and sometimes by number type within a country. The library knows the real ranges, and gets updated when they change.
Normalization. Users type phone numbers a dozen different ways (spaces, dashes, parens, with or without country code). formatInternational() gives you one canonical form to store and compare against, instead of writing your own normalization pass.

One gotcha: without a country hint, a local-format number is ambiguous. 030 1234567 is valid in Germany and might also just be a truncated something-else from another country. If your form is scoped to one country, pass it as the default country rather than relying purely on a + prefix being present.

If your backend isn't JS (or you don't want the dependency in a small service), I wrapped libphonenumber-js as a hosted endpoint on Validate — same validation logic, plain JSON in and out.

IBAN validation guide for developers

Jonas Hämmerle — Sat, 11 Jul 2026 10:14:40 +0000

IBAN validation trips people up because it looks like it should be a length check plus a regex, and it's neither. Here's the actual structure, in the order you should check it.

1. Length and country format. Every IBAN starts with a 2-letter ISO country code and 2 check digits, followed by a country-specific BBAN whose length is fixed per country — Germany is always 22 characters, the Netherlands 18, Malta 31. A string can be the right shape (letters-then-digits) and still be the wrong length for the country it claims to be from.

2. The mod-97 checksum (ISO 7064). This is the part people get wrong or skip:

function isValidIBAN(iban) {
  const clean = iban.replace(/\s+/g, "").toUpperCase();
  if (!/^[A-Z]{2}\d{2}[A-Z0-9]+$/.test(clean)) return false;

  const rearranged = clean.slice(4) + clean.slice(0, 4);
  const numeric = rearranged.replace(/[A-Z]/g, c => (c.charCodeAt(0) - 55).toString());

  // IBANs convert to numbers far too large for JS's Number type (30+ digits),
  // so mod 97 has to be computed in chunks rather than in one BigInt/Number op.
  let remainder = numeric;
  while (remainder.length > 2) {
    const chunk = remainder.slice(0, 9);
    remainder = (parseInt(chunk, 10) % 97) + remainder.slice(chunk.length);
  }
  return parseInt(remainder, 10) % 97 === 1;
}

Move the first 4 characters to the end, convert every letter to its numeric value (A=10 ... Z=35), and the resulting number mod 97 must equal 1. The chunked-modulo loop is the detail that trips up most from-scratch implementations — you can't just do BigInt(numeric) % 97n in older runtimes without a BigInt polyfill, and plain Number silently loses precision past 2^53.

3. What this does not tell you. A passing checksum means the IBAN is well-formed — not that the account exists, is open, or belongs to who the payer thinks it does. Confirming that needs a live lookup against the bank (or a service like the account-name-matching checks banks now run for fraud prevention), which is a separate, heavier operation than format validation.

For most apps — checkout forms, payout setup, onboarding — steps 1 and 2 are exactly the right amount of validation: fast, no external calls, no third-party uptime dependency. I wrapped both (plus the per-country BBAN structure check) into an endpoint on Validate if you'd rather not own the mod-97 edge cases yourself.

How to validate email addresses properly in 2026

Jonas Hämmerle — Sat, 11 Jul 2026 10:09:48 +0000

"Just use a regex" is the most common wrong answer to email validation. Here's what actually matters, in the order it actually matters.

1. Syntax — but a permissive one. The RFC 5322 spec technically allows things like quoted strings and comments in the local part, which almost no real mail provider uses. Don't implement the full spec; use a pragmatic check instead:

function looksLikeEmail(input) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(input);
}

This deliberately under-validates. A regex that's too strict will reject real addresses (plus-addressing, unusual-but-valid TLDs) more often than it catches typos — false rejections cost you signups, false acceptances just mean you fall through to the next check.

2. MX record lookup. Syntax passing doesn't mean the domain can receive mail:

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

async function canReceiveMail(domain) {
  try {
    return (await resolveMx(domain)).length > 0;
  } catch {
    return false;
  }
}

Catches typo'd domains (gmial.com) and abandoned/fake domains for basically zero added latency.

3. Disposable/temp-mail detection. Syntax-valid, MX-valid, and still worthless for your product: throwaway addresses from 10minutemail, guerrillamail, mailinator, and hundreds of similar services that spin up new domains constantly. There's no algorithmic tell — you need a maintained domain blocklist (the community-run disposable-email-domains list is a solid free start, just budget time to keep it synced).

4. What you're deliberately not doing: an SMTP handshake to check if the specific mailbox exists. It's slow, unreliable, and most mail servers now treat probing behavior as spam reconnaissance and silently no-op it. Don't build on a foundation that stopped being reliable.

Put together, that's syntax (fast, always run) → MX (cheap, catches typos) → disposable-domain check (catches throwaway signups) — each step only worth running if the previous one passed. I built exactly this pipeline as endpoints on Validate if you'd rather not maintain the MX/disposable-list plumbing yourself.

Validate API changelog: disposable-email detection and postal-code validation

Jonas Hämmerle — Wed, 08 Jul 2026 20:35:43 +0000

We just shipped two new endpoints on Validate, the validation/utility API — both format-only checks, no external services called, same pattern as the existing IBAN/VAT checksum endpoints.

`POST /v1/validate/disposable-email`

Flags throwaway/temp-mail addresses — Mailinator, Guerrilla Mail, 10-minute-mail, YOPmail, and 80+ other known providers, including their subdomains (so abc.mailinator.com still gets caught). Real email providers (Gmail, Outlook, your own domain, etc.) are never flagged.

curl -X POST "https://validate7.p.rapidapi.com/v1/validate/disposable-email"   -H "X-RapidAPI-Key: <your-key>"   -H "X-RapidAPI-Host: validate7.p.rapidapi.com"   -H "Content-Type: application/json"   -d '{"email": "test@mailinator.com"}'
# => {"syntaxValid":true,"domain":"mailinator.com","disposable":true,"errors":[]}

Useful paired with the existing /v1/validate/email endpoint (syntax + MX check) to reject fake signups without blocking real users.

`POST /v1/validate/postal-code`

Format validation for 50+ countries — US, CA, GB, DE, FR, and most of the EU/APAC/LatAm. Same idea as the IBAN mod-97 checksum: structure-only, no claim that the code is currently assigned by the postal service.

curl -X POST "https://validate7.p.rapidapi.com/v1/validate/postal-code"   -H "X-RapidAPI-Key: <your-key>"   -H "X-RapidAPI-Host: validate7.p.rapidapi.com"   -H "Content-Type: application/json"   -d '{"countryCode": "US", "postalCode": "94103"}'
# => {"valid":true,"countryCode":"US","postalCode":"94103","supported":true,"errors":[]}

There's also GET /v1/validate/postal-code/countries if you need the full list of supported country codes.

Both are live now on the same free tier as everything else. If there's a specific validation check you keep re-implementing that isn't covered yet, I'd genuinely like to hear about it — that's exactly how these two got picked.

Entropy-based password strength scoring (and why 'has a symbol' rules are theater)

Jonas Hämmerle — Wed, 08 Jul 2026 13:42:01 +0000

"Must contain one uppercase, one number, one symbol" rules produce passwords like Password1! — technically compliant, trivially guessable. Entropy-based scoring is a better signal.

The idea: estimate the search space an attacker would need to brute-force, based on character variety and length, then flag patterns that reduce real entropy below what the raw math suggests (dictionary words, keyboard walks, repeated characters).

Rough approach:

function estimateEntropyBits(password) {
  let poolSize = 0;
  if (/[a-z]/.test(password)) poolSize += 26;
  if (/[A-Z]/.test(password)) poolSize += 26;
  if (/[0-9]/.test(password)) poolSize += 10;
  if (/[^a-zA-Z0-9]/.test(password)) poolSize += 32;
  return Math.log2(poolSize) * password.length;
}

That's the naive version — it overestimates for anything with patterns. A real implementation should also penalize repeated substrings and common dictionary words before trusting the raw bits figure.

I built a fuller version of this (plus the breach-check endpoint from k-anonymity) as part of Validate if you want the batteries-included version.