What is a disposable email address, and should you block it?

A disposable email address is an inbox on a domain whose whole purpose is to receive mail briefly and then be forgotten: no account, no password, often deleted within hours. You should block it at signup only if a throwaway account costs you something real, such as free compute, a trial, a promo credit or a vote. If an account costs you nothing, flagging is usually better than blocking.

The rest of this article explains how these services work under the hood, who actually uses them, and how to make that block-or-allow call for your own product.

How a disposable inbox service works

Most disposable services run the same trick. They own one or more domains, point the MX records at their own mail servers, and accept mail for every possible local part. Nobody registers anything@mailinator.com. It already exists, because the server accepts whatever arrives and files it under the local part.

Mailinator is the classic example, and its public mailbox documentation is unusually blunt about the design:

• Every address on the public domain exists already. Inboxes are created when mail arrives.
• Public inboxes are readable and deletable by anyone. There is no privacy by design.
• No signup is needed. You type an inbox name and read it.
• Messages auto-delete after a few hours.
• The system is receive-only. Nobody can send from it.

That last point matters more than people expect. A disposable address can click your verification link, but it can never reply to your onboarding email, and it can never receive your password reset next month, because the message will be gone or the domain will have moved on.

Other services vary the details. Some give you a random address with a countdown timer. Some rotate through dozens of domains so a single blocklisted name doesn't hurt them. Many quietly run several domains on the same mail server: sharklasers.com and guerrillamail.com both publish mail.guerrillamail.com as their MX host, and yopmail.fr points at smtp.yopmail.com. That shared infrastructure is useful for detection, which we cover in how to detect disposable email addresses at signup.

What does not count as disposable

The word gets stretched to cover things that behave very differently. Getting this wrong is how you end up blocking paying customers.

Relay services forward to a real, permanent inbox and the user can reply through them. They are a privacy tool, and treating them as disposable punishes exactly the careful users you want. We wrote a whole piece on why Apple Hide My Email and Firefox Relay are not disposable email.

Plus addressing is a duplicate-account problem, not a disposable one. jane+1@gmail.com and jane+2@gmail.com land in the same inbox. If you care about one account per person, see Gmail dots, plus addressing and duplicate accounts.

Who uses disposable addresses

Two groups, and you will see both in your logs.

People protecting their main inbox. Someone wants to read one gated whitepaper, test your product for five minutes, or download a file without joining a newsletter forever. They are not attacking you. They are telling you, fairly clearly, that they don't trust you with their real address yet.

People who need many accounts. Free-tier farming, trial resets, referral and promo abuse, fake reviews, ballot stuffing, scraping behind a login, spam posting. For these users a disposable address is a cost-free identity, and the ability to create one in two seconds is the whole point.

There is a third, smaller group you should not forget: your own QA team and integration tests. Mailinator and similar services market themselves for testing signup flows. If you block disposable domains, make sure your test suite has another way in, or you will find out from a failing CI job.

There is no honest universal percentage split between these groups. It varies wildly by product, and anyone quoting one is guessing.

Should you block disposable email addresses?

Ask one question: what does a throwaway account cost you?

Block at signup when the answer is concrete:

• Each account gets free usage that costs you money (compute, API credits, AI tokens, SMS, storage).
• Each account gets a free trial, a discount code or a referral reward.
• Accounts can vote, review, post publicly or message other users.
• You need to reach the user later for billing, security or legal notices.

Flag instead of blocking when the cost is low:

• A newsletter, a gated PDF or a waitlist. A blocked visitor just leaves; a flagged one at least shows up in your numbers.
• A product where the free tier is cheap to serve and the real value is behind payment.
• B2B lead capture, where you'd rather route the lead to a low-priority queue than lose it.

The detailed trade-offs, including what the error message should say, live in should you block disposable emails or just flag them. The short version: block where abuse is expensive, measure everywhere else.

Two things to keep in mind either way.

Blocking disposable domains does not stop a determined abuser. A free Gmail or Outlook account takes a few minutes to create. Blocking disposable inboxes raises the cost of each fake account from seconds to minutes, which kills casual abuse and scripts that rely on public inboxes. It does nothing against someone patient. If trial abuse is your real problem, you need more signals; see stopping free-trial abuse without punishing real users.

Every list has false positives. The community list on GitHub carried gmal.com, a typo of Gmail rather than a disposable service, from before 2018 until a maintainer removed it in December 2025. Lists also get attacked: in January 2026 the maintainers pulled 33 domains that arrived through an automated source a reporter had flagged as set up to poison the list. A block decision built on a list should come with a way for a real user to contact you.

The list most people use

The de facto open dataset is disposable-email-domains on GitHub, released under CC0. In October 2026 the blocklist file held about 9,900 domains, roughly double what it held a year earlier. PyPI's admins have said publicly that they use it to block throw-away domains from creating accounts.

A few practical notes if you use it directly:

• Entries are registrable domains. You need to reduce mail.something.co.uk to something.co.uk before matching, using the Public Suffix List.
• It changes most days. A copy you vendored six months ago is missing thousands of domains.
• Lowercase and punycode the domain before you look it up.

pingutil syncs from that list weekly and does the normalization for you. A lookup returns category: "disposable" and verdict.is_spam: true with reason: "disposable_domain". You can browse what the category covers on the disposable domains page.

curl -s -X POST https://pingutil.com/v1/lookup \
  -H "Authorization: Bearer $PINGUTIL_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "input": "someone@sharklasers.com", "skip_enrichment": true }'
# "category": "disposable",
# "verdict": { "is_spam": true, "low_trust": false, "reason": "disposable_domain" }

A quick decision checklist

1. Write down what one fake account costs you. If you can't name a cost, don't block; flag and watch.
2. If you do block, block on the domain category, not on a regex of words like "temp" or "trash". Plenty of real companies have those words in their names.
3. Keep relay services and plus addresses out of the block. Normalize plus addresses if you need one account per person.
4. Use a list that updates, and give blocked users a way to reach a human.
5. Exempt your own test domains so QA doesn't break.
6. Treat the block as one signal among several. It stops lazy abuse, not careful abuse.