Disposable Email Domains List: How to Block Them

When a product offers a free plan, fake signups follow. Most teams only notice the problem when email bounce rates rise, trial-to-paid conversion drops without explanation, or referral credits are abused. By then, the damage is already done.

We worked with a B2B SaaS company running a freemium product. They had a well-built onboarding flow, good activation emails, and a structured drip sequence. None of it performed as expected. When we looked at the signup data together, nearly one in eight new accounts had been created with a disposable email address. After adding disposable email detection at registration using the Veille API, fake signups dropped by more than 10% in the first month. Conversion metrics became meaningful again. Email performance data finally reflected reality.

This guide explains how to build that detection layer: which open-source blocklists are useful, where they fall short, and how to combine them with real-time API checks to keep your registration flow clean.

What is a disposable email domain?

A disposable email domain belongs to a service that creates email inboxes on demand. No account creation is required. No identity is verified. Users get a working address in seconds. The inbox disappears after a few minutes or hours, sometimes without any time limit. The address is gone or abandoned long before your welcome email is sent.

The most well-known services include Mailinator, Guerrilla Mail, YOPmail, 10MinuteMail, and Temp-Mail. But these are only the most visible. There are hundreds of smaller, lesser-known providers, including domains created specifically to avoid blocklists that target the obvious ones.

Not everyone using a disposable email is trying to abuse your platform. Privacy-conscious users, developers testing integrations, and people avoiding marketing emails all have valid reasons to use temporary addresses. The problem is that bad actors — people who create multiple fake accounts, repeatedly claim free trials, or abuse referral programs — also use them. And they are much harder to filter out after the fact.

The key point: disposable emails are a registration problem, not a deliverability problem. Bounces, sender score damage, and reduced inbox placement are consequences, not causes. It is better to stop the problem at the registration form than to diagnose it from your email analytics weeks later.

Which blocklists are worth using

Several community-maintained lists are available on GitHub. They differ in the number of domains covered, how often they are updated, and how accurate they are.

disposable-email-domains/disposable-email-domains

About 4,000 domains, updated through community contributions that require supporting evidence. This is the cautious choice: fewer false positives, but not complete coverage. A good starting point if you are setting this up for the first time.

disposable/disposable-email-domains

About 100,000 domains, updated automatically every day. Wider coverage, but less accurate. Some entries include privacy services that are not truly disposable. Useful for high-risk platforms where you prefer to block too much rather than too little — for example, gaming platforms, coupon sites, or crypto services.

7c/fakefilter

About 5,000 domains, updated daily, and each entry links back to its source. The ability to trace why a domain is listed is useful when investigating a case where a real user was blocked.

FGRibreau/mailchecker

Available as ready-to-use libraries for Node.js, PHP, Ruby, and other languages. A good option if you prefer an integrated library over a raw text file.

None of these lists is complete. They cover the most common providers and stay reasonably current, but they are always behind the newest services.

Common disposable domains to block

If you need a quick starting point while you set up a proper detection system, these domains appear frequently in fake signup activity:

mailinator.com
guerrillamail.com
temp-mail.org
yopmail.com
10minutemail.com
trashmail.com
emailondeck.com
maildrop.cc
sharklasers.com
guerrillamailblock.com
grr.la
mailnesia.com
getnada.com
mohmal.com
throwam.com
dispostable.com
tempail.com
fakeinbox.com
throwaway.email
tempinbox.com

This list is a temporary measure, not a long-term solution. New disposable domains appear every week. Some disappear quickly, others stay active for months. A list that is never updated will miss everything created after it was last edited.

Why static lists become outdated

Disposable email services are changing. Many now offer REST or GraphQL APIs, which means a person can create a new email address automatically, without opening a browser. A new disposable domain can be set up and ready to receive email within an hour — well before it appears in any public list.

Some attackers do not use existing services at all. Instead, they register low-cost domains, configure basic mail server settings, use the address once, and move on. These domains look legitimate to any static list check. The only way to detect them is by analyzing signals such as DNS configuration, how recently the domain was registered, and whether the mail server actually responds correctly.

This is where static lists reach their limit. They work well for blocking known providers with no added delay, since the check is just a lookup in a set of known values. But they cannot cover custom one-time domains or newly created services.

Real-time detection with the Veille API

The Veille Email Validation API (GET /v1/intelligence/email) checks email addresses against a continuously updated database of 100,000+ known disposable domains, combined with live DNS and mail server analysis. It returns:

• disposable — true if the domain is a known disposable provider
• risk_score — a score from 0 (safe) to 100 (high risk), combining all available signals
• role_account / role_type — detects shared inboxes such as info@, noreply@, or admin@
• dns.mx — whether the domain has a valid, configured mail server
• smtp_valid — whether the specific inbox can receive email (available with qualification_check=true)

The risk_score field is the most useful for making nuanced decisions. Instead of a binary block or allow, you can define thresholds: pass low scores, require extra verification for medium scores, and reject high scores directly at the form.

How to implement disposable email blocking

Python — checking a static blocklist

Download the list from GitHub and store it in memory. Do this once when the application starts, or on a scheduled basis, not on every request.

import requests

BLOCKLIST_URL = (
    "https://raw.githubusercontent.com/"
    "disposable-email-domains/disposable-email-domains/"
    "refs/heads/main/disposable_email_blocklist.conf"
)

def load_blocklist() -> set[str]:
    response = requests.get(BLOCKLIST_URL, timeout=10)
    return set(response.text.strip().splitlines())

DISPOSABLE_DOMAINS = load_blocklist()

def is_known_disposable(email: str) -> bool:
    domain = email.rsplit("@", 1)[-1].lower()
    return domain in DISPOSABLE_DOMAINS

Refresh the list once a week using a scheduled task. The list changes often enough that an old version will miss real abuse, but not so often that you need to update it continuously.

Python — using the Veille API for real-time detection

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://api.veille.io/v1"

def validate_email(email: str) -> dict:
    response = requests.get(
        f"{BASE_URL}/intelligence/email",
        params={"query": email},
        headers={"x-api-key": API_KEY},
        timeout=3,
    )
    response.raise_for_status()
    return response.json()

def signup_gate(email: str) -> tuple[bool, str]:
    data = validate_email(email)

    if data["disposable"]:
        return False, "Please use a permanent email address to sign up."

    if data["risk_score"] >= 75:
        return False, "We could not verify this email address. Please try a different one."

    return True, ""

TypeScript — validation middleware for Express

import express, { Request, Response, NextFunction } from "express";

const API_KEY = "YOUR_API_KEY";
const BASE_URL = "https://api.veille.io/v1";

interface EmailValidation {
  disposable: boolean;
  risk_score: number;
  smtp_valid: boolean;
}

async function validateEmailMiddleware(
  req: Request,
  res: Response,
  next: NextFunction
): Promise<void> {
  const { email } = req.body as { email: string };

  try {
    const response = await fetch(
      `${BASE_URL}/intelligence/email?query=${encodeURIComponent(email)}`,
      { headers: { "x-api-key": API_KEY }, signal: AbortSignal.timeout(3000) }
    );

    const data = (await response.json()) as EmailValidation;

    if (data.disposable || data.risk_score >= 75) {
      res.status(422).json({ error: "This email address cannot be used for registration." });
      return;
    }

    next();
  } catch {
    // If the API is unreachable, allow the request through and log the failure
    console.warn(`[veille] email validation failed for ${email}, allowing through`);
    next();
  }
}

const app = express();
app.use(express.json());
app.post("/auth/signup", validateEmailMiddleware, (req, res) => {
  res.json({ status: "ok" });
});

One important implementation note: if the validation API is unreachable or returns an error, allow the request through. Do not block users because of a network issue. Log the failure and review those signups separately.

Where to add validation

The registration form is the most important place, but not the only one:

• Email change flows — an existing user switching to a disposable address is a warning sign
• Waitlist and early-access sign-up forms
• Coupon and promotional code forms
• Referral program registration

The earlier you detect a disposable address, the less work you have to do later to clean up your data.

Avoiding false positives

Some legitimate services generate email addresses that look similar to disposable ones. Apple Hide My Email, Firefox Relay, Proton Mail aliases, SimpleLogin, and addy.io all create forwarding addresses with unusual patterns. An overly strict blocklist may block these by mistake.

The important difference: these addresses forward to a real inbox belonging to a real person who chose to protect their privacy. Blocking these users means losing real customers, not preventing fraud.

Two steps help avoid this problem. First, maintain a list of known privacy relay services and skip all checks for those domains:

PRIVACY_RELAY_DOMAINS = {
    "privaterelay.appleid.com",
    "relay.firefox.com",
    "simplelogin.co",
    "addy.io",
    "anonaddy.com",
}

def should_skip_check(email: str) -> bool:
    domain = email.rsplit("@", 1)[-1].lower()
    return domain in PRIVACY_RELAY_DOMAINS

Second, use risk_score thresholds instead of simple domain matching. A forwarding address from a known privacy service will typically have a low score. An unknown disposable domain created last week will have a high score. This is where the Veille API provides the most value.

Before enabling any blocking logic in production, run it in test mode for one week: record what would have been blocked without actually rejecting any requests. Review the results manually. If real users appear in the records, adjust your thresholds.

A layered approach

No single check is sufficient on its own. A reliable setup combines several layers:

1. Privacy relay allowlist — checked first; addresses from these domains skip all other checks
2. Static blocklist — fast lookup, blocks the most well-known disposable providers immediately
3. Veille API — real-time check for everything that passed the static list, using disposable, dns.mx, and risk_score
4. Post-registration behavior — accounts that never open an email, never complete onboarding, and show no activity after 7 days should be reviewed, regardless of how they passed the initial checks

Decision logic:

Signal	Action
Domain on privacy relay allowlist	Allow
Domain on static blocklist	Reject at registration form
disposable: true from API	Reject at registration form
risk_score ≥ 75	Reject at registration form
risk_score 50–74	Allow and flag for manual review
No activity after 7 days	Archive and remove from active lists

FAQ

How often should I refresh the blocklist?

Once a week is enough for most teams. Set up an automated task to download the latest version and reload it into memory. Updating more often gives little benefit; updating less often means missing newly identified providers.

Should I block role-based addresses like info@company.com?

It depends on your product. For consumer signups, shared addresses like info@ or admin@ are often a sign of a low-quality lead or a shared inbox. For business products, these may be the only address publicly available for a company. Use the role_account field from the Veille API to flag them separately rather than blocking outright, then handle them with a different onboarding flow.

What about catch-all domains?

Some domains accept email sent to any address, even if no real inbox exists for that address. A static blocklist cannot detect this. Use smtp_valid with qualification_check=true in the Veille API to verify that a specific inbox can actually receive email, not just that the domain is configured.

Can I block all free email providers?

No. Most legitimate users sign up with free providers such as Gmail, Outlook, or Yahoo. Blocking free providers would remove the majority of your real users. The right distinction is between disposable and permanent, not between free and paid.

Is there one list that covers every disposable domain?

No. New disposable email services are created regularly, often with the specific goal of avoiding existing blocklists. The most effective approach is to combine a static list for known providers with a real-time API for everything else.

Veille resources

Veille tracks 953+ disposable email providers, organized into 9 categories: 10-minute inboxes, temporary services, burner addresses, trash inboxes, fake email generators, anonymous forwarding services, alias and relay services, privacy tools, and others. The database is updated every week.

Two free tools to use alongside this guide:

• Disposable email providers directory — browse all 953+ tracked providers, with a category label and description for each one
• Blocklist comparison tool — enter any domain and check whether it is listed across 12 open-source blocklists at the same time, including disposable-email-domains/disposable-email-domains, disposable/disposable-email-domains, 7c/fakefilter, FGRibreau/mailchecker, and more

For real-time detection at registration — where you need disposable, risk_score, and smtp_valid returned immediately — the Veille Email Validation API handles what no static list can.