The disposable email domain list 2026: how to maintain your own — SignupDoggy Blog
Every public disposable email list is stale within 48 hours. Here is the exact process to maintain your own blocklist: the 5 GitHub repos to monitor, the per-provider crawls that catch the long tail, and how to deduplicate without losing entries.
The disposable email domain list 2026: how to maintain your own
Every public disposable email blocklist is stale within 48 hours. New disposable email providers launch daily. Existing ones rotate domains. If you maintain your own blocklist, you have to do it actively — fetch the public lists, run your own crawls, deduplicate, and ship updates on a regular cadence.
This post is the exact process: the 5 GitHub repos to monitor, the per-provider crawls that catch the long tail, and how to deduplicate without losing entries. The cost is a 1-2 hour sync per day, fully automatable.
Short answer
The right list to maintain in 2026 has three layers:
A weekly fetch from the top 3 public GitHub repos
A daily fetch from one bulk-API source
A daily crawl of 175 disposable-email provider websites
The 5 GitHub repos + the bulk API give you ~125,000 domains. The per-provider crawl adds another ~75,000 domains (the long tail). The full list is ~200,000 domains, deduplicated, refreshed daily.
The hard part is not the fetching — it is the deduplication and the per-provider crawl. Skip either and your list misses 30%+ of disposable emails.
The 5 public GitHub repos
The disposable-email community maintains several blocklists. The top 5 by quality and update frequency:
disposable-email-domains/disposable-email-domains — 125,000 domains, weekly updates, MIT-licensed, the canonical source
ivolo/disposable-email-domains — 125,000 domains, monthly updates, the historical 'primary' list
GeroldSetserver/fake-mail-server-list — 12,000 domains, daily updates, focused on new launches
wesbos/burner-email-domains — 8,000 domains, manual curation, lower volume but higher signal
stopforumspam/spam-domains — not disposable-email-specific, but contains many disposable-email domains
The first two are the bulk of the list. The third catches new launches within 24-48 hours. The fourth is a manually curated set of 'high signal' disposable providers. The fifth is a bonus source for spam-related domains.
The bulk API source
The bulk API at `deviceandbrowserinfo.com/api/emails/disposable` returns ~49,000 domains in a JSON array. Updated daily. The right cadence is to fetch this once per day and diff against your existing list.
The per-provider crawl
This is the long-tail layer. There are 175 disposable-email providers that operate their own domain (e.g. `tempmail.com`, `guerrillamail.com`, `mailinator.com`). Each has a public-facing website that lists their current active domains. A daily crawl of all 175 sites catches:
• Domains that the bulk lists miss (smaller providers)
• Domains that have been added since the last bulk list update
• Domains that are about to be deprecated (a 1-day warning before the bulk list catches it)
The crawl is the only way to catch the long tail. The GitHub repos and the bulk API give you the top 90% of disposable emails. The crawl gives you the remaining 10% — and the 10% is where the most active fraudsters hide, because the public lists are the first thing they check.
The full sync process
sync.py
import asyncio
import aiohttp
import json
from datetime import datetime
PUBLICREPOS = [
'https://raw.githubusercontent.com/disposable-email-domains/disposable-email-domains/master/disposableemailblocklist.conf',
'https://raw.githubusercontent.com/ivolo/disposable-email-domains/master/index.json',
# ... etc
]
BULKAPI = 'https://deviceandbrowserinfo.com/api/emails/disposable'
PROVIDERINDEX = 'https://example.com/data/emails/providers' # your own index
async def fetchall():
async with aiohttp.ClientSession() as session:
# Fetch the 5 GitHub repos
githubdomains = set()
for url in PUBLICREPOS:
async with session.get(url) as resp:
text = await resp.text()
for line in text.split('
'):
line = line.strip()
if line and not line.startswith('#'):
githubdomains.add(line.lower())
# Fetch the bulk API
async with session.get(BULKAPI) as resp:
bulkdata = await resp.json()
bulkdomains = set(d.lower() for d in bulkdata)
# Fetch the provider index
async with session.get(PROVIDERINDEX) as resp:
providerlist = await resp.json()
# Crawl each provider
providerdomains = set()
for provider in providerlist:
try:
async with session.get(provider['url'], timeout=10) as resp:
html = await resp.text()
# Parse the provider's domain list
for domain in parseproviderdomains(html):
providerdomains.add(domain.lower())
except:
pass # log and continue
# Combine and deduplicate
alldomains = githubdomains | bulkdomains | providerdomains
print(f'Total domains: {len(alldomains)}')
return alldomains
The full sync runs in 5-10 minutes. Run it once per day, on a cron.
The deduplication gotcha
The GitHub repos and the bulk API overlap significantly. The deduplication is straightforward (use a `set`), but the order matters: deduplicate the raw text, not the parsed values. A line like `# this is a comment` in one repo and `this-is-a-comment` in another should not collide.
def parsedisposableconf(text):
"""Parse the .conf format used by the main repo."""
domains = set()
for line in text.split('
'):
line = line.strip()
if not line or line.startswith('#'):
continue
domains.add(line.lower())
return domains
The storage layer
For 200,000 domains, the right storage is a sorted set in a database. Postgres works, Redis works, a flat file works.
If you are serving the list from an API (SignupDoggy does this), the right pattern is:
• Store the full list as a sorted set in KV (Cloudflare KV, Redis, etc.)
• Cache the parsed set in memory for 5 minutes
• Re-fetch from KV on cache miss
The full list is ~5MB as a JSON file. Reading it from KV takes ~50ms. Parsing it takes ~200ms. Caching the parsed set in memory brings the per-request cost to near-zero.
The cost of NOT maintaining your own list
The cost is in the false negatives — disposable emails that pass through your blocklist.
If your list is 30% stale (a 6-month-old snapshot), you are missing 30% of disposable-email signups. For a SaaS getting 10,000 signups per month, that's 3,000 bot signups per month making it into your database. At a $0.50 per-row storage and processing cost, that's $1,500/month in wasted infrastructure. Plus the support tickets from real users complaining about bot accounts in the product.
The cost of maintaining your own list is 1-2 hours of engineering per month to maintain the sync code. The payback period is 1-2 weeks at any reasonable signup volume.
The bottom line
Maintaining your own disposable-email blocklist is a solved problem. The 5 public GitHub repos + 1 bulk API + a per-provider crawl give you a 200,000-domain list, refreshed daily, in 5-10 minutes of compute per day. The cost is engineering time, not compute cost.
If you don't want to maintain your own list, use a managed service. SignupDoggy does this for $0.01 per call. The pricing is the same as the cost of running your own list at a small signup volume (under 100k signups/month) and cheaper at larger volumes.
FAQ
Q: Can I just use one of the public GitHub repos?
A: Yes, but you will miss 30%+ of disposable emails. The public repos are updated weekly; new disposable providers launch daily.
Q: How do I know if my list is stale?
A: Sign up for a new disposable email provider (e.g. `tempmail.com`) and check if your list catches it. If it doesn't, your list is stale.
Q: What's the per-provider crawl's false-positive rate?
A: The crawl is targeted — you only crawl known disposable providers, so the false-positive rate is near zero. The risk is false negatives (missed domains), not false positives.
Q: Can I use the SignupDoggy list without calling the API?
A: Not directly. The list is the data behind the API. If you want to use it standalone, contact us.
Q: How often does the SignupDoggy list update?
A: Daily. The full sync runs on a 24-hour cron. The founder-only `/v1/admin/sync` endpoint can trigger a manual sync on demand.
---
About the author
Jeffrin James is the founder of SignupDoggy, a serverless fraud-detection API for indie hackers and small SaaS teams. He built the product in Mumbai, India, after spending six months and $2,400 on enterprise fraud-detection vendors that didn't fit his use case.
Tags: Disposable email, Tutorial, Engineering