Should a Website Block Disposable Email?

In short. It depends on what a lost real customer costs you, and in practice most blocking is set far tighter than the actual risk justifies. We run a service that gets blocked, so the arguments for blocking are laid out here in full rather than waved away.

Start with the honest disclosure

This site hands out disposable addresses. If sites stop refusing them we benefit. You should read everything below with that in mind, which is exactly why the case for blocking is stated first and completely, and why nothing here argues that abuse is imaginary. It is not.

Four real reasons to block

Trial abuse. A free trial per account becomes an unlimited free product if accounts are free and infinite. For anything with real per-user cost, this is the strongest argument there is.

Votes, reviews and rankings. Anywhere one account equals one unit of influence, cheap accounts are the attack. Review scores, polls, contests, referral bonuses.

Deliverability metrics. Mail to an expired mailbox eventually bounces or lands in a spam trap, and both damage your sending reputation. A list full of dead addresses makes your real mail arrive less often.

Compliance. Some regulated activities require a contactable customer of record, and an address designed to expire fails that requirement regardless of anyone's opinion.

If one of these describes you, block, and read the rest for how to do it without overshooting.

What blocking does not solve

It stops casual abuse and inconveniences determined abuse for about four minutes.

Anyone running fraud at scale does not use public throwaway domains. They buy addresses on ordinary domains for fractions of a cent, or they register a domain and run a catch-all, which is indistinguishable from a small business. The sophisticated attacker you are worried about walks straight past a blocklist; the person it stops is a shopper who did not want another newsletter.

That is the asymmetry worth sitting with. A blocklist is a filter tuned to catch the least motivated attacker and the most privacy-conscious customer, which is close to the opposite of what you want.

The list you installed is not a list you audit

Almost nobody writes their own. The near universal implementation is a public file of domain names, one per line, pulled from a package or a repository and consulted on every signup.

Consider what that file is. Entries are contributed by whoever noticed a domain and opened a request, from evidence that is rarely recorded and never revisited. Additions are easy and uncontroversial, so they accumulate. Removals require somebody to argue that a domain has changed hands or was never disposable in the first place, which almost nobody does. The file therefore only grows, and it grows in one direction: more refusals.

Then there is the update problem, which cuts both ways and embarrasses both sides of the argument. Most sites vendor the list once and never refresh it, so they are refusing a snapshot of the throwaway landscape from whichever year they last touched their dependencies. That list misses every domain registered since, and keeps refusing domains that stopped being disposable years ago.

The practical summary: you are enforcing a policy you did not write, based on evidence you cannot see, on a schedule you do not control.

Why the list can never catch up

Here is the part we can describe from the inside, because it is our side of it.

Domains used for throwaway mail are consumables. Every public one is eventually added to the lists, and from that point some forms refuse it. That is normal and expected, so a service in this category keeps a set of them in rotation and replaces them as they wear out. We publish our current set on this site, and we deliberately do not hand out the domain of the site itself by default, because a service's own domain is the very first name anyone adds to a list.

Now compare the two sides of the race. Adding a domain to your blocklist takes a report, a merge, a release and a deploy on your side. Replacing a burned domain takes a registration and a DNS record on ours. The costs are not close, and they are not paid by the same people, which is why exhaustive blocking never converges no matter how diligent the list maintainers are.

This is not an argument that blocking is pointless. It is an argument that blocking is a rate limiter and not a wall, and that budgeting for it as a wall is how sites end up with settings that cost more than they save.

The cost nobody measures

A refused signup is invisible. It does not appear as a failed conversion, because from your analytics nothing happened: a form was abandoned. There is no support ticket, because from the user's side the site simply refused them and they went elsewhere.

So the cost of blocking is systematically underestimated in every meeting where it gets discussed. The benefit is visible, countable and reported as fraud prevented. The cost is a slightly lower conversion rate that everyone attributes to something else. If you have never measured how many signups your validator refuses, you do not have the numbers to justify the setting you are running.

Worse, some of those refusals hit people whose addresses are not disposable at all. False positives are common enough that they usually outnumber the genuine catches on ordinary consumer sites.

What the refused person does next

Four things, and it is worth being clear about which of them you were aiming for.

They try a masking alias, which a growing number of lists also refuse, so they hit the same wall wearing a different coat.

They try a plus-tagged version of their real address, which some validators also refuse, and which in any case gives you the permanent address you wanted with a tag attached.

They give a real address they do not read: an old account, a spare, a work mailbox they will leave next year. This is the outcome that flatters your metrics and helps you least, because it looks like a clean signup and behaves like a dead one.

Or they leave.

Only the second of those is the result the block was designed to produce. Two of the four are worse for you than accepting a throwaway address would have been, because a dead permanent address damages the very deliverability score that justified the block.

Alternatives, from gentle to firm

Verify the address. Confirm by clicking a link. This catches nothing about disposability but catches everything about deliverability, which is what most sites actually care about.

Delay the reward. Let anyone sign up, but release the trial credit, the discount or the referral bonus after some period. Throwaway addresses expire before the reward arrives, and legitimate users simply come back. A waitlist does this by accident: the invitation goes out weeks later, and only an address that still exists can accept it.

Bind to something scarcer than email. Device, phone number, payment method. Any of these costs an attacker more than an address does, and none of them punishes a customer for their choice of mailbox.

Review anomalies by hand. Forty signups from one address range in an hour is a pattern worth looking at; one signup from a domain on a list is not.

Block, but only the top offenders. If you do block, use a short list of the largest services rather than an exhaustive one. The long tail of any blocklist is where the false positives live.

Move the check away from the door

The best structural change costs almost nothing: stop deciding at the signup form and start deciding at the moment something of value is handed over.

At the form you know nothing except a string. At the moment you grant trial credit, publish a review or pay a referral bonus, you know the account's age, whether the address confirmed, how the session behaved and whether forty siblings appeared from the same network in the same hour. Deciding there uses all of it instead of one field.

You also keep the record. A refused form leaves you nothing to analyse. An accepted signup that never confirmed leaves you a row you can count, group by domain and argue about with numbers rather than opinions.

Where blocking is not arguable

Anything involving money moving, physical goods shipping, or a regulated service being delivered. Also anything where you are legally required to be able to reach the customer later.

In these cases the address is part of the transaction record, not a contact preference, and an expiring address genuinely cannot do the job. Nobody sensible argues otherwise, including us.

Choosing a threshold with numbers instead of feelings

Two quantities, both estimable in an afternoon.

The cost of one abusive account: what a free trial actually costs you to serve, or what one fake review costs in trust.

The value of one refused customer: your average customer value multiplied by the share of refused signups who were legitimate. That share is higher than most teams assume.

Compare them. If an abusive account costs you two cents of compute and a customer is worth forty dollars, you can tolerate an enormous amount of abuse before blocking pays for itself. If each fraudulent account costs you a physical device, the answer flips immediately.

The point is not that blocking is wrong. It is that most sites have never done this arithmetic and inherited their setting from a library default written by someone who never saw their numbers.

A policy short enough to actually follow

If you want something to write down and hand to whoever builds the form:

Accept any address with valid syntax and working mail servers. Require confirmation by link before anything is granted. Withhold credit, bonuses and public posting until confirmation plus a waiting period. Refuse outright only where regulation requires a contactable customer. Log every refusal with the domain and the reason, and review the grouped list once a quarter.

Five sentences, no list file to maintain, and every one of them defensible with a number when someone asks why signups moved.