DEV Community: mnotr

IBAN Validation: Complete Developer Guide (2026)

mnotr — Thu, 12 Feb 2026 20:16:22 +0000

If your app handles international payments, money transfers, or banking integrations, you'll need to validate IBANs. The International Bank Account Number is used across 80+ countries to identify bank accounts for cross-border transfers.

Getting IBAN validation wrong means failed transfers, returned payments, and unhappy users. This guide shows you exactly how the validation works, with code you can drop into any project.

What's Inside an IBAN?

Every IBAN follows the same structure:

DE  89  3704 0044  0532 0130 00
──  ──  ─────────  ─────────────
 │   │      │            │
 │   │      │            └── Account number
 │   │      └── Bank code (BLZ)
 │   └── Check digits (MOD-97)
 └── Country code (ISO 3166-1)

Country code (2 letters) — DE = Germany, GB = UK, FR = France
Check digits (2 digits) — computed using MOD-97 to catch typos
BBAN (Basic Bank Account Number) — the rest, format varies by country

The total length depends on the country. Germany is 22 characters, the UK is 22, France is 27, and Norway is just 15.

IBAN Lengths by Country

Country	Code	Length	Example
Germany	DE	22	DE89 3704 0044 0532 0130 00
United Kingdom	GB	22	GB29 NWBK 6016 1331 9268 19
France	FR	27	FR76 3000 6000 0112 3456 7890 189
Spain	ES	24	ES91 2100 0418 4502 0005 1332
Netherlands	NL	18	NL91 ABNA 0417 1643 00
Italy	IT	27	IT60 X054 2811 1010 0000 0123 456
Switzerland	CH	21	CH93 0076 2011 6238 5295 7
Norway	NO	15	NO93 8601 1117 947
Poland	PL	28	PL61 1090 1014 0000 0712 1981 2874
Belgium	BE	16	BE68 5390 0754 7034

The MOD-97 Checksum Algorithm

IBAN validation uses the MOD-97 algorithm defined in ISO 7064:

Move the first 4 characters to the end: DE89... becomes ...DE89
Convert letters to numbers: A=10, B=11, ..., Z=35. So D=13, E=14
Calculate the remainder when divided by 97
If the remainder is 1, the IBAN is valid

Walk-Through: DE89370400440532013000

Step 1: Move first 4 to end
  370400440532013000DE89
  → 370400440532013000131489  (D=13, E=14)

Step 2: MOD-97
  370400440532013000131489 % 97 = 1

Result: 1 → Valid ✓

The challenge: this is a 24+ digit number, which exceeds JavaScript's Number.MAX_SAFE_INTEGER (2^53). You need to process it in chunks.

JavaScript Implementation

function validateIBAN(input) {
  // 1. Clean and uppercase
  const iban = input.replace(/\s/g, '').toUpperCase();

  // 2. Basic format check
  if (!/^[A-Z]{2}\d{2}[A-Z0-9]{4,30}$/.test(iban)) {
    return { valid: false, reason: 'Invalid IBAN format' };
  }

  // 3. Check country-specific length
  const lengths = {
    DE: 22, GB: 22, FR: 27, ES: 24, IT: 27, NL: 18,
    BE: 16, AT: 20, CH: 21, SE: 24, NO: 15, DK: 18,
    FI: 18, PL: 28, PT: 25, IE: 22, LU: 20, CZ: 24,
  };

  const country = iban.substring(0, 2);
  if (lengths[country] && iban.length !== lengths[country]) {
    return { valid: false, reason: `${country} IBAN must be ${lengths[country]} characters` };
  }

  // 4. MOD-97 check
  // Move first 4 chars to end
  const rearranged = iban.substring(4) + iban.substring(0, 4);

  // Convert letters to numbers
  let numeric = '';
  for (const char of rearranged) {
    if (char >= 'A' && char <= 'Z') {
      numeric += (char.charCodeAt(0) - 55).toString();
    } else {
      numeric += char;
    }
  }

  // MOD-97 on large number (process in chunks)
  let remainder = 0;
  for (let i = 0; i < numeric.length; i++) {
    remainder = (remainder * 10 + parseInt(numeric[i])) % 97;
  }

  if (remainder !== 1) {
    return { valid: false, reason: 'Checksum failed (MOD-97)' };
  }

  return {
    valid: true,
    country,
    check_digits: iban.substring(2, 4),
    bban: iban.substring(4),
    formatted: iban.replace(/(.{4})/g, '$1 ').trim(),
  };
}

validateIBAN('DE89 3704 0044 0532 0130 00');
// { valid: true, country: "DE", check_digits: "89",
//   bban: "370400440532013000",
//   formatted: "DE89 3704 0044 0532 0130 00" }

The key trick is the chunk-based MOD-97 on lines 33-36. Instead of converting the entire string to a BigInt, we process digit by digit, taking the modulus at each step. This keeps the number small and works in any JavaScript environment.

Extracting the Bank Code

The BBAN contains the bank code, but its position varies by country:

Country	Bank Code Position	Example
Germany (DE)	Characters 5-12 (8 digits)	37040044
UK (GB)	Characters 5-8 (4 letters)	NWBK
France (FR)	Characters 5-9 (5 digits)	30006
Netherlands (NL)	Characters 5-8 (4 letters)	ABNA
Spain (ES)	Characters 5-8 (4 digits)	2100

function extractBankCode(iban, country) {
  const bankCodeLengths = {
    DE: 8, GB: 4, FR: 5, NL: 4, ES: 4,
    IT: 5, BE: 3, AT: 5, CH: 5, SE: 3,
  };

  const len = bankCodeLengths[country];
  if (!len) return null;

  return iban.substring(4, 4 + len);
}

Common Mistakes

1. Not handling spaces
IBANs are often displayed with spaces (DE89 3704 0044...) but stored without them. Always strip spaces before validation.

2. Case sensitivity
IBANs can be entered in lowercase. Always convert to uppercase before processing — the letter-to-number conversion depends on it.

3. Skipping the length check
An IBAN that passes MOD-97 but has the wrong length for its country is still invalid. A German IBAN must be exactly 22 characters — no more, no less.

4. Using parseInt on the full number
parseInt("370400440532013000131489") loses precision because it exceeds 2^53. Always use the chunk method or BigInt.

Using the DataCheck API

If you'd rather not maintain country-specific length tables and bank code extraction logic:

const res = await fetch(
  'https://datacheck.dev/api/validate?input=DE89370400440532013000&type=iban'
);
const data = await res.json();

// {
//   valid: true,
//   formatted: "DE89 3704 0044 0532 0130 00",
//   country: "DE",
//   details: {
//     country: "Germany",
//     check_digits: "89",
//     bban: "370400440532013000",
//     bank_code: "37040044"
//   }
// }

Or with the npm package:

npm install datacheck-api

import { validateIBAN } from "datacheck-api";
const result = await validateIBAN("DE89370400440532013000");

Test IBANs for Development

Country	Valid Test IBAN
Germany	DE89 3704 0044 0532 0130 00
UK	GB29 NWBK 6016 1331 9268 19
France	FR76 3000 6000 0112 3456 7890 189
Spain	ES91 2100 0418 4502 0005 1332
Netherlands	NL91 ABNA 0417 1643 00
Switzerland	CH93 0076 2011 6238 5295 7
Belgium	BE68 5390 0754 7034
Norway	NO93 8601 1117 947

Wrapping Up

IBAN validation comes down to three checks: format (letters + digits), country-specific length, and MOD-97 checksum. The tricky part is the big-number arithmetic, which the chunk-based approach solves cleanly.

For apps that just need to verify IBANs and extract bank codes, the 40-line implementation above works perfectly. For production use with 45+ countries and always-current formats, consider using an API like DataCheck.

Luhn Algorithm Explained: Credit Card Validation in JavaScript

mnotr — Thu, 12 Feb 2026 20:07:55 +0000

Every credit card number has a built-in error-detection mechanism called the Luhn algorithm (also known as "modulus 10"). It catches accidental typos — swapped digits, single-digit errors, and most transposition mistakes — before a number ever reaches your payment processor.

This article explains how it works step by step, shows you a clean JavaScript implementation, and covers brand detection so you can build a complete card validator.

How the Luhn Algorithm Works

The algorithm operates on the card number's digits from right to left:

Start from the rightmost digit (the check digit) and move left
Double every second digit (starting from the second-to-last)
If doubling produces a number > 9, subtract 9
Sum all digits
If the total is divisible by 10, the number is valid

Walk-Through: 4111 1111 1111 1111

This is Visa's standard test number. Let's trace through it:

Original:   4  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1
Double alt: 8  1  2  1  2  1  2  1  2  1  2  1  2  1  2  1
Sum:        8+ 1+ 2+ 1+ 2+ 1+ 2+ 1+ 2+ 1+ 2+ 1+ 2+ 1+ 2+ 1 = 30
30 % 10 === 0 → Valid

Now change one digit — 4111 1111 1111 1112:

Sum: 31
31 % 10 !== 0 → Invalid

A single typo changes the checksum. That's the point.

JavaScript Implementation

function luhn(cardNumber) {
  const digits = cardNumber.replace(/\D/g, '');
  let sum = 0;
  let alternate = false;

  // Walk from right to left
  for (let i = digits.length - 1; i >= 0; i--) {
    let n = parseInt(digits[i], 10);

    if (alternate) {
      n *= 2;
      if (n > 9) n -= 9;
    }

    sum += n;
    alternate = !alternate;
  }

  return sum % 10 === 0;
}

// Test it
luhn('4111111111111111'); // true  (Visa test)
luhn('4111111111111112'); // false (one digit off)
luhn('5500000000000004'); // true  (Mastercard test)
luhn('378282246310005');  // true  (Amex test)

That's 15 lines. No dependencies, no libraries. It runs in under 1 microsecond.

Detecting the Card Brand

Card brands are identified by their prefix (BIN range) and length:

Brand	Prefix	Length
Visa	4	13, 16, 19
Mastercard	51-55, 2221-2720	16
Amex	34, 37	15
Discover	6011, 644-649, 65	16-19
JCB	3528-3589	16-19
UnionPay	62	16-19
Diners Club	300-305, 36, 38	14-19

function detectBrand(cardNumber) {
  const d = cardNumber.replace(/\D/g, '');

  if (/^4/.test(d)) return 'Visa';
  if (/^5[1-5]/.test(d) || /^2[2-7]/.test(d)) return 'Mastercard';
  if (/^3[47]/.test(d)) return 'Amex';
  if (/^6(?:011|4[4-9]|5)/.test(d)) return 'Discover';
  if (/^35(?:2[89]|[3-8])/.test(d)) return 'JCB';
  if (/^62/.test(d)) return 'UnionPay';

  return 'Unknown';
}

Complete Validator

Combining Luhn check, brand detection, and length validation:

function validateCard(input) {
  const digits = input.replace(/\D/g, '');

  if (digits.length < 13 || digits.length > 19) {
    return { valid: false, reason: 'Card number must be 13-19 digits' };
  }

  if (!luhn(digits)) {
    return { valid: false, reason: 'Invalid checksum (Luhn check failed)' };
  }

  const brand = detectBrand(digits);
  const lastFour = digits.slice(-4);
  const bin = digits.substring(0, 6);

  return {
    valid: true,
    brand,
    last_four: lastFour,
    bin,
    formatted: digits.replace(/(.{4})/g, '$1 ').trim(),
  };
}

validateCard('4111-1111-1111-1111');
// { valid: true, brand: "Visa", last_four: "1111", bin: "411111",
//   formatted: "4111 1111 1111 1111" }

What Luhn Doesn't Catch

The Luhn algorithm only checks for accidental errors. It does not:

Verify the card exists — you need a payment processor for that
Check if the card is expired — validate expiry separately
Detect stolen numbers — that's fraud detection, not validation
Catch all transposition errors — swapping 09 and 90 passes Luhn

Think of Luhn as a fast pre-filter. It rejects obvious mistakes before you make an API call to Stripe or your payment gateway. This saves you money (each processor call costs something) and gives users instant feedback.

Using an API Instead

If you want Luhn validation + brand detection + formatting without writing the code yourself:

const res = await fetch(
  'https://datacheck.dev/api/validate?input=4111111111111111&type=credit_card'
);
const data = await res.json();

// {
//   valid: true,
//   formatted: "4111 1111 1111 1111",
//   details: {
//     brand: "Visa",
//     last_four: "1111",
//     bin: "411111",
//     type: "credit"
//   }
// }

Or with the npm package:

npm install datacheck-api

import { validateCard } from "datacheck-api";
const result = await validateCard("4111111111111111");

Test Card Numbers

Use these for testing. They all pass Luhn but aren't real cards:

Brand	Number
Visa	4111 1111 1111 1111
Mastercard	5500 0000 0000 0004
Amex	3782 822463 10005
Discover	6011 1111 1111 1117
JCB	3530 1113 3330 0000

Wrapping Up

The Luhn algorithm is one of the most useful 15-line functions you'll ever write. It catches typos instantly, works offline, and costs nothing to run. Pair it with brand detection and you've got a complete client-side card validator.

For production apps, use it as a pre-filter before calling your payment processor — or use an API like DataCheck that handles everything in one call.

How to Validate International Phone Numbers in JavaScript (2026)

mnotr — Thu, 12 Feb 2026 20:07:38 +0000

Phone number validation sounds simple until you go international. US numbers have 10 digits, UK mobiles have 11, German numbers range from 7 to 12, and India uses a completely different prefix system. A basic regex that works for one country breaks on all the others.

This guide covers four approaches, from simple to production-grade, with working code for each.

The Problem with Simple Regex

Most developers start here:

// DON'T use this in production
const isPhone = /^\d{10}$/.test(input);
// Misses: +44 7911 123456, 0049 170 1234567, +91 98765 43210

This only matches exactly 10 digits. It rejects every valid international number, numbers with country codes, parentheses, dashes, or spaces. It also accepts invalid 10-digit strings that aren't real phone numbers.

Approach 1: Country-Specific Regex Patterns

Instead of one regex, use a separate pattern per country:

const patterns = {
  US: /^1?([2-9]\d{2}[2-9]\d{6})$/,
  GB: /^(?:44)?0?(7\d{9}|[1-9]\d{8,9})$/,
  DE: /^(?:49)?0?([1-9]\d{4,13})$/,
  FR: /^(?:33)?0?([1-9]\d{8})$/,
  IN: /^(?:91)?0?([6-9]\d{9})$/,
};

function validatePhone(digits, country) {
  const cleaned = digits.replace(/[\s\-\(\)\.\+]/g, '');
  const pattern = patterns[country];
  if (!pattern) return { valid: false, reason: 'Unsupported country' };
  return { valid: pattern.test(cleaned) };
}

Pros: Zero dependencies, fast, works offline.
Cons: You need to maintain regex for every country. You also need the caller to specify the country.

Approach 2: Google's libphonenumber

Google maintains libphonenumber, originally built for Android. The JavaScript port is google-libphonenumber:

npm install google-libphonenumber

const { PhoneNumberUtil, PhoneNumberFormat } = require('google-libphonenumber');
const phoneUtil = PhoneNumberUtil.getInstance();

function validate(input, countryCode) {
  try {
    const number = phoneUtil.parse(input, countryCode);
    return {
      valid: phoneUtil.isValidNumber(number),
      formatted: phoneUtil.format(number, PhoneNumberFormat.E164),
      type: phoneUtil.getNumberType(number),
      country: phoneUtil.getRegionCodeForNumber(number),
    };
  } catch (e) {
    return { valid: false, reason: e.message };
  }
}

Pros: Most accurate. Handles every country, number type, and format.
Cons: The bundle is ~1.2 MB. That's massive for a frontend app and significant for serverless functions where cold start time matters.

Approach 3: API-Based Validation

Offload the work to an API. This keeps your bundle size at zero and gets you extra data like location and line type:

async function validatePhone(input) {
  const res = await fetch(
    `https://datacheck.dev/api/validate?input=${encodeURIComponent(input)}&type=phone`
  );
  return res.json();
}

// Returns:
// {
//   valid: true,
//   formatted: "+1 4155551234",
//   country: "US",
//   details: {
//     type: "mobile",
//     area_code: "415",
//     location: "San Francisco, CA"
//   }
// }

Or use the npm wrapper:

npm install datacheck-api

import { validatePhone } from "datacheck-api";

const result = await validatePhone("+14155551234");
console.log(result.details.location); // "San Francisco, CA"

Pros: Zero bundle size. Returns enriched data (location, line type). Always up to date.
Cons: Requires network call. Depends on external service uptime.

Approach 4: Hybrid (Recommended)

The production sweet spot: validate format client-side for instant feedback, then verify server-side via API before saving:

// Client-side: quick format check
function quickCheck(input) {
  const digits = input.replace(/\D/g, '');
  if (digits.length < 7 || digits.length > 15) {
    return { valid: false, reason: 'Phone must be 7-15 digits' };
  }
  return { valid: true };
}

// Server-side: full validation before saving
async function fullValidation(input) {
  const res = await fetch(
    `https://datacheck.dev/api/validate?input=${encodeURIComponent(input)}&type=phone`
  );
  const data = await res.json();
  if (!data.valid) throw new Error(data.reason);
  return data;
}

This gives users instant feedback on typos while catching all edge cases on the backend.

Comparison Table

Approach	Accuracy	Bundle Size	Countries	Extra Data
Simple regex	Low	0 KB	1	No
Country patterns	Medium	~2 KB	5-30	No
libphonenumber	High	~1.2 MB	250+	Type only
API (DataCheck)	High	0 KB	30+	Type, location, area code
Hybrid	High	~1 KB	30+	Type, location, area code

Common Pitfalls

1. Stripping the + sign too early
The + prefix indicates international format. If you strip it before parsing, +44 becomes 44, which could be confused with a domestic number starting with 4.

2. Assuming all countries have the same length
US numbers are always 10 digits. German numbers range from 7 to 12 digits. Chinese mobile numbers are 11 digits. Never hardcode length.

3. Ignoring leading zeros
In the UK, 07911 123456 is valid locally but the leading 0 is dropped in international format: +44 7911 123456. Your validator needs to handle both.

4. Not returning formatted output
Always store the E.164 formatted version (+14155551234). This is the universal format that SMS gateways, Twilio, and phone APIs expect.

Wrapping Up

For hobby projects, country-specific regex works fine. For production apps with international users, use either libphonenumber (if bundle size isn't a concern) or an API like DataCheck (if you want zero dependencies and enriched data).

The hybrid approach gives you the best of both: instant client-side feedback and accurate server-side validation with location data.

How to Reduce Email Bounce Rate with Validation

mnotr — Thu, 12 Feb 2026 17:30:31 +0000

A high email bounce rate destroys deliverability. Once your bounce rate exceeds 2%, email providers start routing your messages to spam. Above 5%, you risk getting your sending domain blacklisted entirely.

The fix is simple: validate email addresses before they enter your system.

The numbers

60% of form submissions use fake or mistyped emails
2% bounce rate threshold before spam filtering kicks in
~5ms to validate an email via API (faster than a page load)

Why emails bounce

Hard bounces (permanent)

Invalid domain: The domain doesn't exist or has no mail servers (no MX records)
Invalid mailbox: The domain exists but the specific address doesn't
Typos: user@gmial.com, user@hotnail.com — real people with wrong addresses

Soft bounces (temporary)

Full mailbox: The recipient's inbox is full
Server down: The receiving mail server is temporarily unavailable
Message too large: The email exceeds the recipient's size limit

Hard bounces are the ones that hurt your sender reputation. They're also the ones you can prevent with validation.

What email validation catches

Syntax errors: Malformed addresses that aren't valid email format
Non-existent domains: Domains with no DNS records or no MX records
Disposable addresses: Throwaway emails from services like Mailinator that expire in minutes
Typos: Common misspellings of popular domains (gmial.com, yaho.com, outlok.com)
Role accounts: Generic addresses like info@, admin@, noreply@ that often don't accept mail

Where to validate: signup vs. send time

At signup (recommended)

Validate the email the moment a user enters it. If it's invalid, show an error immediately. If it's a typo, suggest the correction.

The user is still on the page and can fix their email
You never store a bad address in the first place
Response time is fast enough for real-time UX (~5ms)

Before sending a campaign

If you have an existing list, validate it in bulk before sending. Run every address through validation and remove hard bounces before they damage your sender score.

Implementation: real-time validation at signup

Frontend (show feedback as they type)

const emailInput = document.getElementById("email");
const feedback = document.getElementById("email-feedback");
let timeout;

emailInput.addEventListener("input", () => {
  clearTimeout(timeout);
  const email = emailInput.value.trim();
  if (!email || !email.includes("@")) return;

  // Debounce: wait 500ms after user stops typing
  timeout = setTimeout(async () => {
    const res = await fetch(
      `https://mxcheck.dev/api/validate?email=${encodeURIComponent(email)}`
    );
    const data = await res.json();

    if (data.suggestion) {
      feedback.textContent = `Did you mean ${data.suggestion}?`;
      feedback.style.color = "#eab308";
    } else if (!data.valid) {
      feedback.textContent = data.reason || "Invalid email";
      feedback.style.color = "#ef4444";
    } else if (data.checks.disposable) {
      feedback.textContent = "Please use a permanent email address";
      feedback.style.color = "#ef4444";
    } else {
      feedback.textContent = "Email looks good";
      feedback.style.color = "#22c55e";
    }
  }, 500);
});

Backend (verify before saving)

import mxcheck from "mxcheck";

app.post("/signup", async (req, res) => {
  const result = await mxcheck(req.body.email);

  if (!result.valid) {
    return res.status(400).json({
      error: "Invalid email",
      reason: result.reason,
      suggestion: result.suggestion
    });
  }

  if (result.checks.disposable) {
    return res.status(400).json({
      error: "Disposable emails are not allowed"
    });
  }

  // Email is validated, proceed with account creation
});

The ROI of email validation

Say you have a SaaS with 1,000 signups per month:

Without validation: ~15% of emails are invalid. That's 150 bad addresses per month.
You send a welcome email, a follow-up, and a weekly digest. That's 600+ bounces per month from new signups alone.
Your bounce rate climbs past 2%. Gmail starts flagging your emails as spam. Open rates drop for ALL users.
Cost of an email validation API: $0-29/month depending on volume.
Cost of a damaged sender reputation: months of remediation, potential domain blacklisting, and lost revenue.

Email validation isn't a cost center. It's insurance for your entire email channel.

Best practices

Validate at the point of entry. Don't wait until send time. Catch bad emails when the user can still fix them.
Show typo suggestions. "Did you mean user@gmail.com?" converts a lost user into a saved one.
Block disposable emails for paid features. Free tier with disposable is fine. Paid features should require a real address.
Don't over-block. A valid email that scores low might still be worth accepting. Use the score, not just the boolean.
Re-validate periodically. Domains expire. Mail servers change. Re-validate your list quarterly.

Summary

Email bounces are preventable. Validate addresses at signup with a syntax check, MX record lookup, and disposable detection. It takes one API call, adds ~5ms of latency, and protects your sender reputation from day one.

MXCheck - Free email validation API. 3,000 requests/month free. npm install mxcheck

The Complete List of Disposable Email Domains (2026)

mnotr — Thu, 12 Feb 2026 17:25:18 +0000

Disposable email services let anyone create a temporary inbox that expires in minutes. They're used to bypass signups, abuse free trials, and create fake accounts.

Here are 500+ disposable email domains you should block, plus code to detect them automatically.

Why block disposable emails?

Free trial abuse: Users create unlimited accounts with throwaway addresses
Fake signups: Inflated user counts with zero engagement
Spam registrations: Bots using disposable addresses to flood your system
Wasted resources: Sending emails to addresses that won't exist tomorrow

Detection code

JavaScript

const disposableDomains = new Set([
  "mailinator.com",
  "guerrillamail.com",
  "tempmail.com",
  "throwaway.email",
  "yopmail.com",
  // ... add the full list below
]);

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

Python

DISPOSABLE_DOMAINS = {
    "mailinator.com",
    "guerrillamail.com",
    "tempmail.com",
    "throwaway.email",
    "yopmail.com",
    # ... add the full list below
}

def is_disposable(email: str) -> bool:
    domain = email.split("@")[1].lower()
    return domain in DISPOSABLE_DOMAINS

Or use an API

import mxcheck from "mxcheck";

const result = await mxcheck("user@mailinator.com");
console.log(result.checks.disposable); // true

The full list (500+ domains)

Here are the most common disposable email domains, sorted alphabetically:

0-mail.com, 0815.ru, 0clickemail.com, 0wnd.net, 0wnd.org,
10mail.org, 10minutemail.com, 10minutemail.net, 123.com, 126.com,
12minutemail.com, 1mail.net, 20minutemail.com, 2prong.com,
30minutemail.com, 33mail.com, 3mail.ga, 4wristbands.com,
5mail.cf, 5mail.ga, 6mail.cf, 6mail.ga, 6mail.ml,
7mail.ga, 7mail.ml, 8mail.cf, 8mail.ga, 8mail.ml,
9mail.cf, 9ox.net, a-bc.net, afrobacon.com, agedmail.com,
ajaxapp.net, alivance.com, amilegit.com, amiri.net,
anappthat.com, ano-mail.net, anonbox.net, anonymbox.com,
antichef.com, antichef.net, antireg.ru, antispam.de,
armyspy.com, baxomale.ht.cx, beddly.com, beefmilk.com,
bigstring.com, binkmail.com, bio-muesli.net, bladesmail.net,
bloatbox.com, bobmail.info, bodhi.lawlita.com, bofthew.com,
bootybay.de, boun.cr, bouncr.com, breakthru.com,
brefmail.com, brennendesreich.de, broadbandninja.com,
bsnow.net, buffemail.com, bugmenot.com, bumpymail.com,
bund.us, bundes-ede.de, burnthespam.info, buyusedlibrarybooks.org,
byom.de, c2.hu, cachedot.net, cashette.com, casualdx.com,
cellurl.com, centermail.com, centermail.net, chammy.info,
cheatmail.de, chogmail.com, choicemail1.com, clixser.com,
cmail.club, cmail.com, cmail.net, cmail.org,
coldemail.info, cool.fr.nf, correo.blogos.net, cosmorph.com,
courriel.fr.nf, courrieltemporaire.com, crazymailing.com,
cubiclink.com, curryworld.de, cust.in, cuvox.de,
d3p.dk, dacoolest.com, dandikmail.com, dayrep.com,
dcemail.com, deadaddress.com, deadspam.com, delikkt.de,
despam.it, despammed.com, devnullmail.com, dfgh.net,
digitalsanctuary.com, dingbone.com, discard.email,
discard.ga, discard.gq, discardmail.com, discardmail.de,
disposable.cf, disposable.ga, disposable.ml, disposableaddress.com,
disposableemailaddresses.emailmiser.com, disposableinbox.com,
dispose.it, dispostable.com, dm.w3internet.co.uk, dodgeit.com,
dodgit.com, dodgit.org, donemail.ru, dontreg.com,
dontsendmespam.de, drdrb.com, dump-email.info, dumpandjunk.com,
dumpmail.de, dumpyemail.com, e-mail.com, e-mail.org,
e4ward.com, easytrashmail.com, ee1.pl, ee2.pl,
einmalmail.de, einrot.com, einrot.de, email-fake.cf,
email-fake.com, email-fake.ga, email-fake.gq, email-fake.ml,
email-fake.tk, email60.com, emaildienst.de, emailgo.de,
emailias.com, emailigo.de, emailinfive.com, emaillime.com,
emailmiser.com, emailproxsy.com, emails.ga, emailsensei.com,
emailspam.cf, emailspam.ga, emailspam.gq, emailspam.ml,
emailspam.tk, emailtemporanea.com, emailtemporanea.net,
emailtemporar.ro, emailtemporario.com.br, emailthe.net,
emailtmp.com, emailto.de, emailwarden.com, emailx.at.hm,
emailxfer.com, emeil.in, emeil.ir, emz.net,
enterto.com, ephemail.net, ero-tube.org, etranquil.com,
etranquil.net, etranquil.org, evopo.com, explodemail.com,
express.net.ua, eyepaste.com, fakeinbox.com, fakeinformation.com,
fakemail.fr, fantasymail.de, fastacura.com, fastchevy.com,
fastchrysler.com, fastkawasaki.com, fastmazda.com, fastmitsubishi.com,
fastnissan.com, fastsubaru.com, fastsuzuki.com, fasttoyota.com,
fastyamaha.com, filzmail.com, fixmail.tk, fizmail.com,
fleckens.hu, flyspam.com, fr33mail.info, frapmail.com,
freundin.ru, friendlymail.co.uk, front14.org, fuckingduh.com,
fudgerub.com, fux0ringduh.com, garliclife.com, get-mail.cf,
get-mail.ga, get-mail.ml, get-mail.tk, get1mail.com,
get2mail.fr, getairmail.cf, getairmail.com, getairmail.ga,
getairmail.gq, getairmail.ml, getairmail.tk, getmails.eu,
getonemail.com, getonemail.net, ghosttexter.de, giantmail.de,
girlsundertheinfluence.com, gishpuppy.com, gmial.com,
goemailgo.com, gorillaswithdirtyarmpits.com, gotmail.com,
gotmail.net, gotmail.org, gotti.otherinbox.com, great-host.in,
greensloth.com, grr.la, gsrv.co.uk, guerillamail.biz,
guerillamail.com, guerillamail.de, guerillamail.info,
guerillamail.net, guerillamail.org, guerrillamail.biz,
guerrillamail.com, guerrillamail.de, guerrillamail.info,
guerrillamail.net, guerrillamail.org, guerrillamailblock.com,
h8s6ohufyrc7.cf, h8s6ohufyrc7.ga, h8s6ohufyrc7.gq,
h8s6ohufyrc7.ml, h8s6ohufyrc7.tk, haltospam.com, harakirimail.com,
hartbot.de, hatespam.org, herp.in, hidemail.de, hidzz.com,
hmamail.com, hopemail.biz, hotpop.com, hulapla.de,
ichimail.com, imails.info, inbax.tk, inbox.si,
inboxalias.com, inboxclean.com, inboxclean.org, inboxproxy.com,
incognitomail.com, incognitomail.net, incognitomail.org,
insorg-mail.info, ipoo.org, irish2me.com, iwi.net,
jetable.com, jetable.fr.nf, jetable.net, jetable.org,
jnxjn.com, jourrapide.com, junk1e.com, junkmail.ga,
junkmail.gq, kasmail.com, kaspop.com, keepmymail.com,
killmail.com, killmail.net, kimsdisk.com, kingsq.ga,
klzlk.com, kook.ml, kurzepost.de, lawlita.com,
letthemeatspam.com, lhsdv.com, lifebyfood.com, link2mail.net,
litedrop.com, llogin.ru, lol.ovpn.to, lookugly.com,
lopl.co.cc, lortemail.dk, lovemeleaveme.com, lr78.com,
lroid.com, lukop.dk, m21.cc, mail-filter.com,
mail-temporaire.fr, mail.by, mail.mezimages.net, mail.zp.ua,
mail1a.de, mail21.cc, mail2rss.org, mail333.com,
mail4trash.com, mailbidon.com, mailbiz.biz, mailblocks.com,
mailbucket.org, mailcat.biz, mailcatch.com, mailde.de,
mailde.info, maildrop.cc, maildrop.cf, maildrop.ga,
maildrop.gq, maildrop.ml, maildx.com, maileater.com,
mailed.in, mailexpire.com, mailfa.tk, mailforspam.com,
mailfree.ga, mailfree.gq, mailfree.ml, mailfreeonline.com,
mailfs.com, mailguard.me, mailimate.com, mailin8r.com,
mailinater.com, mailinator.com, mailinator.net, mailinator.org,
mailinator2.com, mailincubator.com, mailismagic.com, mailmate.com,
mailme.ir, mailme.lv, mailmetrash.com, mailmoat.com,
mailms.com, mailnator.com, mailnesia.com, mailnull.com,
mailorg.org, mailpick.biz, mailproxsy.com, mailquack.com,
mailrock.biz, mailscrap.com, mailshell.com, mailsiphon.com,
mailslapping.com, mailslite.com, mailtemp.info, mailtome.de,
mailtothis.com, mailtrash.net, mailtv.net, mailtv.tv,
mailzilla.com, mailzilla.org, makemetheking.com, manifestgenerator.com,
manybrain.com, mbx.cc, mega.zik.dj, meinspamschutz.de,
meltmail.com, messagebeamer.de, mezimages.net, mfsa.ru,
mierdamail.com, mintemail.com, mjukgansen.com, moakt.com,
mobi.web.id, mobileninja.co.uk, mohmal.com, moncourrier.fr.nf,
moneypipe.net, monmail.fr.nf, monumentmail.com, msa.minsmail.com,
mt2015.com, mx0.wwwnew.eu, my10minutemail.com, mycard.net.ua,
mycleaninbox.net, mymail-in.net, mypacks.net, mypartyclip.de,
myphantom.com, mysamp.de, myspaceinc.com, myspaceinc.net,
myspaceinc.org, myspacepimpedup.com, mytemp.email, mytempemail.com,
mytempmail.com, mytrashmail.com, nabala.com, neomailbox.com,
nepwk.com, nervmich.net, nervtansen.de, netmails.com,
netmails.net, neverbox.com, no-spam.ws, noblepioneer.com,
nobulk.com, noclickemail.com, nogmailspam.info, nomail.xl.cx,
nomail2me.com, nomorespamemails.com, nonspam.eu, nonspammer.de,
noref.in, nospam.ze.tc, nospam4.us, nospamfor.us,
nospammail.net, nospamthanks.info, nothingtoseehere.ca,
nowmymail.com, nurfuerspam.de, nus.edu.sg, nwldx.com,
objectmail.com, obobbo.com, odnorazovoe.ru, oneoffemail.com,
onewaymail.com, oopi.org, opayq.com, ordinaryamerican.net,
otherinbox.com, ourklips.com, outlawspam.com, ovpn.to,
owlpic.com, pancakemail.com, pimpedupmyspace.com, pjjkp.com,
plexolan.de, pookmail.com, privacy.net, proxymail.eu,
prtnx.com, punkass.com, putthisinyouremail.com, pwrby.com,
qisdo.com, qisoa.com, quickinbox.com, rcpt.at,
reallymymail.com, receiveee.com, recode.me, recursor.net,
regbypass.com, regbypass.comsafe-mail.net, rejectmail.com,
reliable-mail.com, rhyta.com, rklips.com, rmqkr.net,
royal.net, rppkn.com, rtrtr.com, s0ny.net,
safe-mail.net, safersignup.de, safetymail.info, safetypost.de,
sandelf.de, saynotospams.com, scatmail.com, schafmail.de,
selfdestructingmail.com, sendspamhere.com, shiftmail.com,
shitmail.me, shortmail.net, sibmail.com, skeefmail.com,
slaskpost.se, slipry.net, slopsbox.com, slowslow.de,
slutty.horse, smashmail.de, smellfear.com, snakemail.com,
sneakemail.com, sneakymail.de, snkmail.com, sofimail.com,
sofort-mail.de, softpls.asia, sogetthis.com, sohu.com,
soisz.com, solvemail.info, soodonims.com, spam.la,
spam.su, spam4.me, spamavert.com, spambob.com,
spambob.net, spambob.org, spambog.com, spambog.de,
spambog.ru, spambox.info, spambox.irishspringrealty.com,
spambox.us, spamcannon.com, spamcannon.net, spamcero.com,
spamcon.org, spamcorptastic.com, spamcowboy.com, spamcowboy.net,
spamcowboy.org, spamday.com, spamex.com, spamfighter.cf,
spamfighter.ga, spamfighter.gq, spamfighter.ml, spamfighter.tk,
spamfree.eu, spamfree24.com, spamfree24.de, spamfree24.eu,
spamfree24.info, spamfree24.net, spamfree24.org, spamgourmet.com,
spamgourmet.net, spamgourmet.org, spamherelots.com,
spamhereplease.com, spamhole.com, spamify.com, spaminator.de,
spamkill.info, spaml.com, spaml.de, spammotel.com,
spamobox.com, spamoff.de, spamslicer.com, spamspot.com,
spamstack.net, spamthis.co.uk, spamtrap.ro, spamtrail.com,
spamwc.de, speedgaus.net, sperma.cf, spikio.com,
spoofmail.de, squizzy.de, sry.li, startkeys.com,
stinkefinger.net, stop-my-spam.cf, stop-my-spam.com,
stop-my-spam.ga, stop-my-spam.ml, stop-my-spam.tk,
streetwisemail.com, stuffmail.de, supergreatmail.com,
supermailer.jp, superrito.com, superstachel.de, suremail.info,
svk.jp, sweetxxx.de, tafmail.com, tagyoureit.com,
talkinator.com, tapchicuoihoi.com, teewars.org, teleworm.com,
teleworm.us, temp-mail.org, temp-mail.ru, tempalias.com,
tempe4mail.com, tempemail.co.za, tempemail.com, tempemail.net,
tempinbox.com, tempinbox.co.uk, tempmail.eu, tempmail.it,
tempmail2.com, tempmaildemo.com, tempmailer.com, tempmailer.de,
tempomail.fr, temporarily.de, temporarioemail.com.br,
temporaryemail.net, temporaryemail.us, temporaryforwarding.com,
temporaryinbox.com, temporarymailaddress.com, tempthe.net,
thanksnospam.info, thankyou2010.com, thc.st, thecriminals.com,
thisisnotmyrealemail.com, thismail.net, throwam.com,
throwawayemailaddress.com, tittbit.in, tizi.com, tmailinator.com,
toiea.com, toomail.biz, topranklist.de, tradermail.info,
trash-amil.com, trash-mail.at, trash-mail.com, trash-mail.de,
trash2009.com, trash2010.com, trash2011.com, trashdevil.com,
trashdevil.de, trashemail.de, trashmail.at, trashmail.com,
trashmail.de, trashmail.me, trashmail.net, trashmail.org,
trashmailer.com, trashymail.com, trashymail.net, trbvm.com,
trbvn.com, trialmail.de, trickmail.net, trillianpro.com,
turual.com, twinmail.de, tyldd.com, uggsrock.com,
umail.net, upliftnow.com, uplipht.com, uroid.com,
us.af, venompen.com, veryreallynicemail.com, vidchart.com,
viditag.com, viewcastmedia.com, viewcastmedia.net,
viewcastmedia.org, vomoto.com, vpn.st, vsimcard.com,
vubby.com, wasteland.rfc822.org, webemail.me, weg-werf-email.de,
wegwerf-emails.de, wegwerfadresse.de, wegwerfemail.com,
wegwerfemail.de, wegwerfmail.de, wegwerfmail.info, wegwerfmail.net,
wegwerfmail.org, wh4f.org, whatiaas.com, whatpaas.com,
whyspam.me, wickmail.net, wilemail.com, willhackforfood.biz,
willselfdestruct.com, winemaven.info, wronghead.com,
wuzup.net, wuzupmail.net, wwwnew.eu, x.ip6.li,
xagloo.com, xemaps.com, xents.com, xjoi.com,
xmaily.com, xoxy.net, yep.it, yogamaven.com,
yopmail.com, yopmail.fr, yopmail.gq, yopmail.net,
yourdomain.com, ypmail.webarnak.fr.eu.org, yuurok.com,
zehnminutenmail.de, zippymail.info, zoaxe.com, zoemail.org

The problem with maintaining your own list

New disposable services launch constantly. Your blocklist goes stale within weeks. An API-based approach stays current automatically.

MXCheck checks against 500+ disposable domains (updated regularly) in a single API call that also validates syntax, MX records, and catches typos. 3,000 free requests/month.

npm install mxcheck

How to Validate Email Addresses in Node.js (2026 Guide)

mnotr — Thu, 12 Feb 2026 17:24:23 +0000

Email validation is one of those problems that looks simple but isn't. A basic regex catches obvious typos, but it won't tell you if the domain has a mail server, if the address is a disposable throwaway, or if the mailbox actually exists.

This guide covers 4 approaches to email validation in Node.js, from basic regex to full API-based verification, with working code for each.

1. Regex Validation (Basic)

The simplest approach. Catches formatting errors but nothing else.

function isValidEmail(email) {
  const regex = /^[a-zA-Z0-9.!#$%&'*+/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;
  return regex.test(email) && email.length <= 254;
}

console.log(isValidEmail("user@gmail.com"));     // true
console.log(isValidEmail("not-an-email"));        // false
console.log(isValidEmail("user@.com"));           // false

Pros: Fast, no dependencies, no network calls.
Cons: user@fakdomain123.com passes validation. So does user@mailinator.com. You're only checking format, not deliverability.

2. MX Record Lookup (Medium)

Check if the domain actually has mail servers configured. This catches fake domains that pass regex.

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

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

async function validateEmail(email) {
  const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!regex.test(email)) return { valid: false, reason: "Invalid format" };

  const domain = email.split("@")[1];
  const hasMx = await hasMxRecords(domain);

  if (!hasMx) return { valid: false, reason: "Domain has no mail server" };

  return { valid: true };
}

// Usage
const result = await validateEmail("user@fakdomain123.com");
// { valid: false, reason: "Domain has no mail server" }

Pros: Catches fake domains. Uses built-in Node.js dns module (no dependencies).
Cons: Doesn't catch disposable emails, role accounts, or typos. DNS lookups add ~10-50ms latency.

3. Disposable Email Detection (Better)

About 60% of fake signups use disposable email services like Mailinator, Guerrilla Mail, or 10MinuteMail. You need a blocklist.

const disposableDomains = new Set([
  "mailinator.com",
  "guerrillamail.com",
  "tempmail.com",
  "throwaway.email",
  "yopmail.com",
  // ... 500+ more domains
]);

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

console.log(isDisposable("user@mailinator.com")); // true
console.log(isDisposable("user@gmail.com"));      // false

Pros: Blocks the majority of throwaway signups.
Cons: You need to maintain the list yourself. New disposable services appear constantly.

4. API-Based Validation (Best)

An API handles all checks in one call: syntax, MX records, disposable detection, typo suggestions, and more.

import mxcheck from "mxcheck";

const result = await mxcheck("admin@mailinator.com");
console.log(result);
// {
//   email: "admin@mailinator.com",
//   valid: true,
//   score: 0.6,
//   checks: {
//     syntax: { valid: true },
//     mx: { valid: true, records: ["mail.mailinator.com"] },
//     disposable: true,
//     role_account: true,
//     free_provider: false
//   },
//   suggestion: null
// }

The API also catches typos:

const result = await mxcheck("user@gmial.com");
console.log(result.suggestion); // "user@gmail.com"

Comparison

Method	Fake format	Fake domains	Disposable	Typos	Latency
Regex	Yes	No	No	No	<1ms
MX Lookup	Yes	Yes	No	No	10-50ms
Blocklist	Yes	No	Yes	No	<1ms
API (MXCheck)	Yes	Yes	Yes	Yes	~5ms

Which approach should you use?

Contact form with low stakes: Regex is fine.
User registration: MX lookup + disposable detection at minimum.
Lead generation or paid signups: API-based validation. Bad emails cost you money.
Enterprise or compliance: API-based, plus SMTP verification.

Quick start: Add to Express.js

import mxcheck from "mxcheck";

app.post("/signup", async (req, res) => {
  const result = await mxcheck(req.body.email);

  if (!result.valid) {
    return res.status(400).json({
      error: "Invalid email address",
      reason: result.reason,
      suggestion: result.suggestion
    });
  }

  if (result.checks.disposable) {
    return res.status(400).json({
      error: "Disposable email addresses are not allowed"
    });
  }

  // Email is valid, proceed with signup
  res.json({ success: true });
});

One API call blocks fake emails, catches typos, and flags disposable addresses.

MXCheck - Free email validation API. 3,000 requests/month free. npm install mxcheck