Someone signed up for your free tier with an address at a domain you have never heard of, used the product for eleven minutes, and now there are forty more like it. The first thing most founders reach for is a list of disposable email domains, and the first thing they discover is that the list stops the forty and not the person running them.
This post is about what those lists are, what they catch, what routes around them for under a dollar, and where the email check belongs in a signup defense once you stop treating it as a door.
How disposable email services and the blocklists work
A disposable email service is a mail server that accepts mail for any local part on its domains and shows the inbox to whoever asks. Mailinator, Guerrilla Mail, 10minutemail and their hundreds of clones work the same way: no account, no password, type a name, read the verification email, leave. Most rotate domains, because being on a blocklist is the main thing that limits their usefulness.
The blocklists are the other side of that rotation. The most widely used is the disposable-email-domains repository on GitHub, a single text file that GitHub reports at 8,714 lines as of this writing, one domain per line. The README describes the contents as domains "often used to register dummy users in order to spam or abuse some services" and is honest about drift: "We cannot guarantee all of these can still be considered disposable but we do basic checking so chances are they were disposable at one point in time." To add a domain you have to attach a screenshot of a page where anyone can generate an address on it.
The other common choice is mailchecker, which ships bindings for nine languages and a list GitHub shows at 56,356 lines. The bigger number is not straightforwardly better. It includes far more dead and rotated domains, and the more aggressively a list is grown, the more likely it is to contain somebody's real mail host.
Mechanically the check is trivial. Split on @, lowercase the domain, look it up in a set. That is why every framework has a package for it and why it is the first thing people add.
What a blocklist catches, and the four ways around it
The list catches the lazy tier: someone who opens a temp-mail site in another tab, pastes the address, and moves on. That is a real population. It includes tire kickers who do not want your onboarding drip, students, competitors, and the lowest-effort abusers.
It does not catch anyone who has thought about it for thirty seconds. There are four routes around it, and each is cheaper than the last time you looked.
A catch-all on a $1 domain. A .xyz registration currently starts at $0.80 for the first year. Point its DNS at Cloudflare, enable the catch-all rule in Email Routing, and every address at that domain forwards to one inbox; the docs describe the rule as forwarding "every email sent to your domain, including misspelled local parts, to a single destination" (Cloudflare). That is an unlimited supply of addresses on a domain that appears on no list, because it has never appeared anywhere. An abuser who wants a hundred accounts buys one domain, not a hundred.
Plus-addressing. Gmail lets you "add a plus sign (+) and any word before the @ sign in your current address" and it all lands in the same inbox (Google). Gmail also ignores dots, so j.smith and jsmith are the same account (Google). A domain list sees gmail.com and waves it through. The fix is normalization: strip the +tag, drop the dots for Gmail, then look for duplicates. Abusers know this too. As KMnO4 put it in the Hacker News thread on this subject, "Any illegitimate email collection service already knows to strip out email subaddresses" (HN).
Real Gmail accounts. Nothing in the address distinguishes a Gmail account created this morning for your product from one that is fifteen years old. Aged Gmail accounts are a commodity, and an address on the largest consumer mail provider in the world is the least suspicious string an attacker can type into your form.
Privacy relays. Apple's Hide My Email hands out addresses at privaterelay.appleid.com for Sign in with Apple (Apple). Firefox Relay uses mozmail.com (Mozilla). Fastmail, Proton, DuckDuckGo and SimpleLogin all offer the same thing. These are technically disposable: one address per site, deletable at will. They are also used by exactly the people you want as customers.
The honest scorecard is that a domain list stops the population that was least likely to hurt you and does nothing to the population that was.
The cost of blocking disposable emails
The Hacker News thread was titled "My burner email blocklist blocked me". The author had shipped a blocklist and then been rejected by it as a user. The comments are a catalogue of who else gets rejected.
T0Bi: "My domain at Hetzner including mail costs less than 20€/year and all emails to [email protected] which are not part of predefined mailboxes land in my [email protected] mailbox" (HN). eloisius does the same on Fastmail for $50 a year, with "a different email for every company or website I interact with" (HN). xyst has a custom domain on a non-.com TLD and says "the number of services that reject sign ups for this purpose are way too high" (HN). rz2k has started having to use a personal domain because some banks and B2B vendors "don't treat fastmail.com as a large email provider" (HN).
Notice what these people have in common. They own a domain. They pay for email. They care enough about their inbox to route it deliberately. That is a description of a senior engineer or a founder, which is a description of your buyer.
Mozilla's own FAQ warns Relay users that "some sites may not accept an email address that includes a subdomain (@subdomain.mozmail.com) and others have stopped accepting all addresses except those from Gmail, Hotmail, or Yahoo accounts" (Mozilla). When a mail provider is documenting how to work around your signup form, your signup form is the problem.
The r/SaaS thread that prompted this post makes the same point from the seller's side. A founder asked whether to allow users with disposable emails after finding that some of those users were genuinely using the product, and the top reply argued that email blocking is the wrong layer (Reddit). On the Indie Hackers thread advising the opposite, csotherden, who runs an email privacy service, replied that "disposable doesn't necessarily mean temporary and it certainly doesn't mean that the user will never receive the email you send to it" (Indie Hackers).
The standard advice, "block disposable emails at signup", is wrong for most software businesses for a simple reason. The cost of a false positive is a lost customer who never tells you why. The cost of a false negative is one free-tier account that you can revoke later. Those are not symmetric, and a hard block at the door treats them as if they were.
Email quality as one signal, not a gate
The right way to think about a disposable email hit is as evidence with a known error rate. On its own it is a weak signal. It tells you the person did not want to give you a durable address, and there are a dozen innocent reasons for that.
Combined with other evidence, it gets sharp fast. A temp-mail domain plus a datacenter IP plus a device fingerprint that already has six accounts on it is not ambiguous. A temp-mail domain plus a residential IP plus a device you have never seen plus a two-minute session reading your pricing page is a person deciding whether to trust you.
christina97's framing in the HN thread is the correct one: "It comes down to what the cost of spam/fake accounts is, the level of sophistication of your adversaries, and the cost of loss of use to legitimate users blocked by your signup gates" (HN). Those three costs are different for every product, and a boolean list lookup cannot weigh them. A score can.
What that looks like in practice is three verdicts instead of two. Clean signals proceed. High-confidence abuse, meaning several independent signals agreeing, is declined. Everything in between proceeds too, but flagged, so that a human or a later automated check can revoke before anything expensive happens. The email check contributes to that middle band and almost never to the block band by itself.
This is the approach Portreeve takes. It runs disposable-domain and email-quality checks as one input alongside device fingerprint, IP intelligence, and velocity counters per device and per cluster, reports what it found in reason codes, and returns review rather than block when a low-quality email is the only thing wrong. The flow continues for the user, the event lands in a queue, and a later deny arrives at your server as a signed webhook so you can revoke on your own terms.
You can build the same shape yourself. The shape is what matters.
A recipe that works: list, score, verify before expensive work
Here is the version of this I would ship at a small software company, in order.
Keep the list, lose the block. Look the domain up. Record the result on the user as a flag. Do not change the signup response based on it. A rejected signup teaches the abuser which domain to rotate off and teaches the real customer nothing, since you cannot tell them why.
Normalize before you count. Lowercase the whole address. For gmail.com and googlemail.com, strip dots from the local part. For every provider, strip the +tag. Now count accounts per normalized address, and count accounts per domain per day. The second one is what jambalaya8 recommended in that thread, rate limiting "the number of signups from a domain per day" (HN), and it catches the $1 catch-all domain the list never will: forty signups at a domain registered last week is a signal even if every individual address is unique.
Add the signals that cannot be typed. An email address costs nothing to change. A device fingerprint and a card fingerprint cost something. Collect a device token in the browser at signup and key your velocity counters on that, so that one laptop opening fifty accounts on fifty domains still looks like one laptop. Do not key them on IP alone. Office NAT, carrier-grade NAT, and campus Wi-Fi put hundreds of real users behind one address, and a per-IP count will block a whole building to stop one person.
Treat relays as neutral. Put privaterelay.appleid.com, mozmail.com, duck.com and the rest on an explicit allow list that overrides the disposable flag. A user who arrived through Sign in with Apple has already been verified by Apple.
Verify before expensive work, not before signup. The email flag matters at the point where a fake account starts costing you money: the first API call against your paid model, the first outbound email sent on the user's behalf, the trial-to-paid conversion, the checkout. Gate those. A flagged account that never touches an expensive action costs you a row in a database. Requiring a confirmed email, a second factor, or a card at that boundary is a small ask from someone who has already found value and an impossible ask from someone running a script.
Close the loop. When you revoke an account, record why. When a flagged account converts to paid and stays, record that too. Those two outcomes are the only ground truth you have, and a score that is never corrected against them drifts toward whichever mistake you noticed last.
The one piece of standard advice I would push back on hardest is "just require a card". For a free tier it kills conversion, and it does not stop the people who worry you. Card testers show up specifically because you accept cards, and a SetupIntent validates a stolen card without moving money, so a card requirement hands them a free oracle.
Where this fits in a signup defense
Signup is the cheapest place for an abuser to be and the most expensive place for you to be wrong. Every signal you have there is weak on its own: the email can be changed for free, the IP is shared, the device is new because every device is new the first time. The defense that holds is a middle verdict at the door, a device-keyed count that survives domain rotation, and a hard check at the first action that costs you something.
If you decide to wire the three-verdict approach in, the pattern is one call at signup, a branch on the verdict, and a webhook handler for the deny that might arrive later. The handling verdicts reference walks through what to do with each of the three responses, and the device fingerprinting guide covers the browser snippet that makes the device-keyed counts possible. The free tier covers 1,000 screened events a month with no card required, so you can create an account and see what your last week of signups would have scored before changing anything in production.