How to block disposable email addresses on a signup form

Compare the domain after the @ against a list of known throwaway providers, and reject a match before you send anything. That is the whole technique, and it catches the large majority of temporary addresses for the cost of one lookup. The two things people reach for instead — a cleverer regex, and email verification — do not do this job: the regex can't tell mailinator.com from mailchimp.com, and a code sent to a disposable inbox arrives perfectly well. Use the list for throwaways and verification for everything else.

What a disposable address actually is

A disposable address comes from a public service that hands out a working mailbox with no signup. You open the site, you get something like [email protected], you read the incoming message in a browser tab, and the mailbox is gone in ten minutes or ten days. It is a real, functioning address for as long as the visitor needs it to be. That's the part people underestimate.

Three things get lumped in with disposables that aren't:

• Subaddressing. [email protected] is a real mailbox belonging to a real person who is organising their inbox.
• Role addresses. info@ and sales@ are shared, not fake, and in B2B they are often where the buyer actually reads.
• Free providers. Plenty of working businesses run on Gmail. A free domain tells you nothing about intent.

Why they spike on gated downloads specifically

A signup for an account someone will log back into has a built-in reason to use a real address — losing the mailbox means losing the account. A gated download has no such reason. It's a single transaction: pay once with an address, take the file, never need that mailbox again. The visitor isn't being hostile; they're correctly reading the deal on offer.

There's a second, less obvious effect. Adding a confirmation code shifts the fakes rather than removing them. Before the code, someone who didn't want to hand over their address typed [email protected]. After it, that no longer works — but a temporary inbox does, because it genuinely receives. Verification converts nonsense addresses into disposable ones. It is still an improvement, and it is exactly why the blocklist and the code have to run together.

The three approaches, and what each one costs

Pattern matching

Almost useless for this. Disposable domains are chosen to look ordinary, and they succeed — there is no character pattern that separates them from the domain of a small consultancy. Meanwhile the cost of an over-eager pattern is real: hand-rolled email regexes routinely reject plus signs, apostrophes in surnames, and anything on a long TLD like .marketing. Keep the regex for a rough syntax check and let it be generous. It is not a filter.

A domain blocklist

Split the address at the @, lowercase the domain, look it up in a set. Microseconds, no network call, nothing the visitor can perceive. This is the approach that actually removes throwaway traffic, and it removes it before you spend a send on it.

Its cost is staleness. A blocklist is only as good as its last update, and a domain that was registered this morning works until the list learns about it. Which is the whole argument for not maintaining your own.

Verification

Email a code, require it before access. This catches a different category entirely: typos, addresses belonging to someone else, and mailboxes that simply don't exist. Pair it with a DNS check — a domain with no MX record cannot receive mail at all, so there's no point sending — and you've removed everything that was never going to be reachable.

What it does not do is care whether the mailbox is temporary. A code delivered to a ten-minute inbox is entered and works. Anyone selling verification as disposable-blocking is describing two features and shipping one.

Why a mirrored public list beats one you maintain

A hand-kept blocklist has an obvious failure mode: you add a domain the day after it costs you something. Every entry is a scar. Throwaway services, by contrast, add domains constantly and on purpose — rotating them is how they stay usable — so a list built from your own incidents is permanently one step behind a system designed to outrun it.

The public lists are maintained by everyone getting hit at once. Someone else's Tuesday morning becomes your Tuesday morning's defence, and the list grows without anyone at your end owning a chore that will quietly stop being done in March. Mirror it rather than calling a third party live on the signup path: you keep the lookup local, so there's no latency added to the form and no outage in someone else's service that can take your gate down. Replilo checks submitted domains against exactly this kind of mirrored list, then checks the domain's DNS for MX and SPF records, and only then sends a code.

Where blocking is the wrong answer

The most common self-inflicted wound here is subaddressing. [email protected] is not a trick; it's someone routing your mail into a folder, and often it's a sign they intend to keep reading it. Blocking the plus sign rejects your best subscribers. Stripping the tag before you store the address is worse — you've silently rewritten their address, their filters stop matching, and they conclude you're broken.

The same restraint applies to role addresses, to unfamiliar TLDs, and to any rule shaped like "block the whole provider". Blocking info@ at a fifty-person company blocks the company.

The order to run the checks in

Cheapest and least destructive first, so nothing expensive runs on input that was never going to survive:

1. Loose syntax check. Confirm there's one @ and a domain that could exist. Don't get clever.
2. Lowercase the domain and look it up in the mirrored disposable list. Reject on a hit, on the page, with a message that says what happened.
3. Resolve DNS for the domain — MX, and SPF as a signal. No MX means no mail is ever arriving there.
4. Send the six-digit code. Whatever is left after the first three steps is a real domain, and now the person has to show they're holding the mailbox.

That's the sequence behind every Replilo share link, and it's the same reason the delivery step is worth rethinking too — the file itself never leaves by email, so a bad address costs you a row in a table rather than a leaked PDF. If you haven't settled that half yet, it's covered in how to deliver a lead magnet without a full email platform. There's also the broader case for gating a download in the first place.

The short version

Blocklists and codes solve different halves of the problem, and neither one covers for the other. The list keeps out mailboxes that work but won't exist next week; the code keeps out addresses that were never real. Run both, mirror the list instead of writing it, and stay suspicious of any rule that rejects an address for how it looks rather than for where it goes.