How to Block Disposable Email Addresses on Your Website

How Disposable Addresses Are Detected

Detection works on the domain part of the address, the bit after the @ sign. A disposable service owns a set of domains, so a list of those domains lets you recognise its addresses. There are four common methods, and most sites combine two.

Notice that only the first two can recognise a disposable address. The last two do not care what kind of address it is, which is often the better design. They deal with the behaviour you actually dislike, such as ten trials from one machine, whoever's inbox is used.

A Minimal Check in JavaScript

The core logic is only a few lines. This example checks the domain against a set and also catches subdomains, such as mail.tempdomain.com when tempdomain.com is on the list. The three domains in it are placeholders for your own maintained list, not a real blocklist.

// Replace these with a maintained list (loaded from a file or database).
const DISPOSABLE = new Set(['tempdomain.example', 'throwaway.example', 'burner.example'])

export function isDisposable(email) {
  const at = email.lastIndexOf('@')
  if (at < 1) return false
  const domain = email.slice(at + 1).trim().toLowerCase()
  const parts = domain.split('.')
  // check "a.b.c", then "b.c", then "c" so subdomains are caught
  for (let i = 0; i < parts.length - 1; i++) {
    if (DISPOSABLE.has(parts.slice(i).join('.'))) return true
  }
  return false
}

Run this on the server, not only in the browser. A check in the front end is easily skipped, so it is a convenience for the user and no defence. Normalise the address first (trim and lower-case it), and keep the list in a file you can update without a deploy.

We use the same idea inside Nexora. Our own marketing emails skip addresses on a disposable list, because mail to those addresses is wasted and can hurt delivery for everyone else. A list like that is only as good as its upkeep, which is the next problem.

How to Test Your Own Signup Form

Test with a real temporary inbox, because a mock only proves that your code ran. A real inbox proves that mail was delivered over the internet to an address you did not control. Use the free Nexora Temp Mail tool for this and use dummy data only.

1. Check that your block works

   Enter a temporary address from a domain you expect to block. Confirm the form shows your message and does not create the account.

2. Check the wording

   Read the error as a customer would. It should say what to do, not just "invalid email".

3. Check the allowed path

   Temporarily allow the domain in a staging copy, sign up, and confirm that the verification email really arrives and the link activates the account.

4. Check delivery time

   Note how long the message took. If it is slow, users will give up, whatever kind of address they used.

5. Check the unhappy paths

   Request a second code, enter a wrong one and let one expire. These flows break in production more than the first one does.

Also note that a block on your side is the reason many visitors see "this email is not valid" on sites that use lists. That is why temp mail for verification cannot work everywhere, and why we say so plainly in our own guides.

Respecting Privacy-Minded Visitors

Many people use a temporary address because they do not trust the form, not because they plan to cheat. They have been burned by spam before. If your signup makes a promise about how you treat their address, such as "no marketing without consent", say it near the field. A clear privacy note converts more of these visitors into real addresses than a block ever will.

Offer value before asking. Let people try something without an email where you can, and ask for one at the point where it clearly helps them, such as saving their work. When the ask feels fair, the right address tends to arrive on its own. For the visitor's side of this, see our guide to disposable email addresses, and for how safe these inboxes are, is temp mail safe.

A Worked Example With Made-Up Numbers

Numbers help decide whether blocking is worth it. The figures below are invented for illustration, so replace them with your own. Imagine a SaaS tool that gives every new account 100 free credits, each worth about 4 cents of compute, which is $4 per trial.

Suppose 1,000 people sign up in a month, and 8 percent of those use a disposable address. That is 80 signups. If a quarter of them are repeat trials from the same people, 20 trials are abuse, costing about $80 in credits. A block that removes most of them saves perhaps $60 a month. If the same block also turns away 15 honest privacy-minded users who would have converted at 5 percent into a $20 plan, you lose around $15 a month. The block wins, but not by much, and a gentler measure such as limiting credits until the address is verified might win by more.

The point is not the numbers. It is that the choice is a calculation about your own signups, and most sites never do it. Run the version for your product before you add a hard block.

Wording That Keeps Good Users

The message you show on a block decides whether the visitor leaves or tries again. Three versions show the range, from worst to best.

The worst is "Invalid email address". It tells a person with a perfectly good address that they have made a mistake, and they will retype it and fail again. A better one is "Temporary email addresses are not allowed", which is accurate but a little cold. The best explains the benefit: "Please use an address you will keep, so we can send you receipts and password resets. If you are worried about spam, we only send what you ask for."

Keep it to two sentences, put it next to the field and leave the form data in place so the visitor does not have to start again.

Five Server-Side Rules of Thumb

If you are implementing this next week, these five habits will keep the work small and the results sane.

1. Check on the server

   Treat the browser check as a courtesy to the visitor and the server check as the real one.

2. Fail open on lookup errors

   If a DNS lookup or a list service is down, let the signup through and flag it, rather than blocking real customers because of your own outage.

3. Log every block with the domain

   You cannot tune what you cannot see. Store the domain, not the full address, to keep personal data out of your logs.

4. Keep the list outside the code

   Load it from a file or table so a stale list is a data update and not a release.

5. Add an allow-list

   Let your support team exempt a domain in minutes when a real customer is caught by mistake.

None of this needs a large system. A single function, a list you refresh weekly and a log line per block will put you ahead of most signup forms.

Keep reading