Where can I find a list of temporary email service domains?
Published 10 Jun 2025
Updated 28 Sep 2026
11 min read
Summarize with
Updated on 28 Sep 2026: We refreshed this guide with current list-validation practices and guidance for domains that static blocklists miss.
The most useful places to find temporary email service domains are maintained public GitHub repositories and provider directories. Prefer a raw, downloadable domain file with an explicit license, recent maintenance, version history, and a correction path. Treat each list as candidate data, then verify whether a domain still has working mail infrastructure, still belongs to a disposable service, and has a documented reason for enforcement.
A temporary email domain list answers a narrow question: "Has this domain been associated with disposable, burner, throwaway, or temporary inbox use?" It does not prove that a signup is fraudulent or that the domain still works. It also does not show whether the address belongs to a privacy-forwarding user who should be allowed. Some lists include dead domains, parked domains, and privacy alias domains that real users depend on.
- Fastest start: Use maintained disposable-domain lists to build an initial candidate set.
- Best next step: Validate mail DNS, provider evidence, recent activity, and list provenance before enforcement.
- Safest policy: Use temporary-domain matches as a risk signal before moving to hard rejection.
- Main caveat: Temporary email providers rotate domains, so a stale list gets noisy quickly.
Where to get temporary email domain lists
Start with a public repository, then compare it with a provider directory and a maintained dataset write-up. The public GitHub list exposes raw domains in a simple blocklist file, documents its validation process, and accepts correction requests. A provider directory helps identify services linked to many domains. A published update process can inform the refresh and allowlist process for a local copy.
|
|
|
|
|---|---|---|---|
Public repo | Raw file, license, recent commits | Seed data and diffs | Needs local review |
Provider index | Domain grouping and evidence | Provider research | May mix service types |
Maintainer notes | Collection and removal method | Process design | Not enforcement policy |
Internal data | Abuse, overrides, and conversions | Final decisions | Needs enough volume |
Practical sources for temporary email service domains.
GitHub repository page showing a disposable email domain blocklist file.
Prefer sources that expose raw data and a clear license over sources that only return a search result. Raw data supports change diffs, source tags, removal reviews, version pinning, and tests against historical signups. Check the latest commit, published maintenance method, correction path, and allowlist before importing a source. The GitHub repository's current verify.py --fix workflow normalizes case, sorts entries, removes duplicates, and checks Public Suffix List rules. Its older maintain.sh script is deprecated.
A list of temporary domains is closer to a blocklist (blacklist) feed than a permanent truth set. Domains age out, providers rotate, and some entries change ownership. Keep the source, source revision, first-seen date, last-validated date, and validation result beside every domain.
Why no list stays clean
Temporary email services change domains to avoid blocklist and blacklist coverage. Some use subdomains, while others point many domains at shared mail infrastructure. Closed services can leave domains with no usable mail records. A large list can therefore have broad coverage and still produce weak production decisions.
The hardest cases are privacy-forwarding services, customer support aliases, domain parking leftovers, and old disposable-service entries. Blocking these without review creates support tickets and lost signups. An explicit allowlist and a documented removal process are part of the blocklist, not optional cleanup.
Confidence levels for temporary-domain decisions
Use several signals before turning a domain match into a user-facing block.
Low confidence
1 signal
List match only, no recent validation.
Review
2 signals
List match plus active DNS or provider evidence.
Block or step up
3+ signals
Repeated abuse, provider match, and active mail records.
Do not block a domain because it appears in one file. Check its current mail-routing DNS, confirm the service type with provider evidence, and compare the result with the risk model. A newsletter signup and an enterprise admin account need different rules.
Separate known disposable providers, privacy-forwarding domains, dead domains, and unknown domains. Known disposable providers can be blocked or stepped up according to account risk. Privacy-forwarding domains stay allowed unless abuse data supports another action. Reject dead domains only when DNS shows that the domain cannot receive mail, such as a valid Null MX.
What static domain lists miss
A static disposable email domain list only catches domains already known to its maintainers. It misses a newly rotated domain until someone finds and adds it. It can also miss a user-controlled custom domain routed through temporary inbox infrastructure because the visible domain has never appeared in a public list.
- Link related infrastructure: Compare MX hosts and other provider evidence with domains already classified as disposable, but do not block on shared infrastructure alone.
- Watch recent rotation: Review domains advertised by a known temporary inbox service and record when that evidence was observed.
- Use product evidence: Repeated trial abuse and verified throwaway activity can justify step-up verification while a new domain is reviewed.
- Protect legitimate users: Keep privacy relays and customer-owned domains out of hard blocks unless independent evidence supports the action.
Infrastructure similarity raises confidence, but shared MX hosting creates false positives. Require provider evidence or repeated internal abuse before adding an unknown domain to a hard blocklist (blacklist).
How to validate a candidate list
Validate temporary email domains in layers. The goal is to decide what the product should do now when someone signs up with that domain, not to label the domain permanently.
- Parse: Extract the domain with an email parser rather than splitting untrusted input by hand.
- Normalize: Lowercase it, remove a final dot, normalize Unicode safely, and identify the registrable domain.
- Resolve: Check MX records and Null MX. If MX is absent, check the implicit MX fallback to the domain's A or AAAA records.
- Classify: Tag the domain as disposable, forwarding, dead, parked, or unknown.
- Compare: Check the allowlist, recent customers, support history, and internal abuse evidence before blocking.
- Monitor: Track rejects, overrides, conversions, and complaints after every rule change.
Simple validation workflowtext
input: candidate_domains.txt parse: extract domain safely normalize: lowercase, trim final dot, convert IDN match: exact and parent domains above public suffix resolve: MX, Null MX, implicit MX via A or AAAA classify: disposable, forwarding, dead, parked, unknown review: allowlist before publish ship: monitor rejects, overrides, and complaints
For a quick authentication and DNS snapshot before deciding how to treat a domain, run a domain health check. It does not label a domain as disposable or prove that a mailbox accepts mail, but its DMARC, SPF, MX, and DNS context helps separate active mail domains from abandoned ones.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Keep the signup lookup fast and the review process slower. The signup form should read a current local decision table. A scheduled job can refresh sources, run DNS checks, flag changes, and route high-impact additions for review before they affect users.
Match domains correctly
Exact-string matching misses addresses hosted on subdomains. If the list contains example.co.uk, an address at inbox.example.co.uk should match it. Compare the full normalized domain and each parent domain, but stop at the public suffix. This prevents a match on co.uk or another suffix shared by unrelated registrants.
Use a current Public Suffix List to find the registrable boundary. Convert internationalized domains to one consistent ASCII form, remove a trailing dot, and reject malformed input before lookup. Do not use a simple ends-with test, because badexample.com must not match example.com.
Public-suffix-aware matchtext
address domain: signup.inbox.example.co.uk public suffix: co.uk registrable domain: example.co.uk candidates checked: signup.inbox.example.co.uk inbox.example.co.uk example.co.uk stop before: co.uk
A blocklist entry should normally contain the registrable domain unless the provider operates only on a specific subdomain. Store the intended match scope with every exception so later code changes do not broaden a block silently.
Blocking without punishing good users
A temporary email domain match is a useful account-risk signal, not always a reason to reject. For low-risk actions, a warning or extra verification is enough. For abuse-prone flows, a hard block makes sense after the domain has been validated and the reason documented.
Hard block
- Best for: Free trials, coupon abuse, fake reviews, and high-risk account creation.
- Requires: Strong evidence, an allowlist path, support visibility, and a removal process.
- Risk: Real users get rejected when a list includes privacy-forwarding domains.
Risk-based handling
- Best for: SaaS signups, communities, lead forms, and mixed-intent traffic.
- Requires: Scoring, verification steps, exception handling, and post-change monitoring.
- Risk: Abuse still gets through when temporary domains are only one signal.
Temporary-domain controls sit beside other blocklists and blacklist checks, but they are not global sender-reputation data. They describe likely account intent. A disposable inbox user is not automatically a spam sender, and a legitimate domain is not automatically safe.
Flowchart showing how to review a temporary email domain before taking action.
After changing a signup rule, send test messages through the affected path and confirm that the receiving experience still works. An email tester helps inspect the message, headers, and authentication outcome before support teams see the fallout.
Where Suped fits
Suped's product is not a disposable-domain list. It is a DMARC and email authentication platform with DMARC, SPF, DKIM, hosted SPF, hosted DMARC, hosted MTA-STS, blocklist monitoring, and deliverability insights. That work becomes relevant when temporary-domain decisions affect the mail a product sends after signup.
After tightening signup rules, the sending side still needs monitoring for authentication failures, spoofing attempts, domain reputation changes, and blocklist (blacklist) appearances. Suped's blocklist monitoring keeps that operational view tied to the domains that send real mail.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Use disposable-domain lists for account risk. Use Suped to keep authentication and sender reputation visible, then connect the workflows where a signup policy changes real mail delivery.
Implementation pattern
Use a local decision table with a clear action for each domain. Do not put every public-list entry straight into a production block rule. Import it into a candidate set, normalize and deduplicate it, validate it, assign a status, then publish only reviewed decisions to the signup path.
Candidate domain decision recordyaml
source: public_disposable_feed source_version: immutable_commit_or_release_id domain: mailinator.com match_scope: registrable_domain status: review signals: - list_match - mx_present - provider_page_seen action: step_up_verification first_seen: 2026-09-29 last_validated: 2026-09-29 review_after_days: 30
That record provides an audit trail and a rollback path. When a customer complains, the team can see whether the decision came from a public feed, internal abuse data, or manual review. When a domain changes ownership, the entry can be expired or removed without guessing why it was added.
Signal strength for a domain match
A list match is useful, but operational evidence should carry more weight.
List match
30 scoreActive MX
45 scoreProvider evidence
70 scoreAbuse history
90 scoreThe enforcement path depends on account value and the observed abuse pattern. A paid enterprise signup should get a manual review path. A free trial hit by repeated throwaway addresses can get step-up verification or rejection. A newsletter form can accept the address, then suppress it if mail bounces or engagement stays at zero.
Views from the trenches
Best practices
Treat public lists as seed data, then verify MX and current provider evidence before blocking.
Keep a local allowlist for privacy-forwarding domains that real customers use in your product.
Store the source, match scope, and review date for every temporary domain decision.
Common pitfalls
Blocking every listed domain creates false positives when lists include forwarding services.
Old GitHub lists include dead, parked, or reassigned domains that no longer support a block.
Exact-only matching misses subdomains, while naive suffix matching blocks unrelated domains.
Expert tips
Run a weekly diff so new entries get reviewed instead of entering production silently.
Separate candidate data, reviewed decisions, and allowlist exceptions in local storage.
Test policy changes against recent signups before changing a domain action to block.
Marketer view
Marketer from Email Geeks says public GitHub repositories are useful first sources, but their completeness and listing criteria differ by maintainer.
2025-03-12 - Email Geeks
Marketer view
Marketer from Email Geeks says the raw blocklist file is often the most useful part of a repository when you need domains for research.
2025-03-18 - Email Geeks
A practical answer
Use public repositories and provider directories to find temporary email service domains, then build a reviewed decision layer. Import and version the raw list, validate its mail DNS, classify each domain, check for privacy-forwarding false positives, and use internal abuse data to choose the action. Start with step-up verification when user value or domain intent is unclear.
- Use lists: They are the fastest way to discover likely disposable domains.
- Match safely: Public-suffix-aware matching handles subdomains without widening a block too far.
- Validate first: A stale or reassigned domain can create bad enforcement and wasted review time.
- Monitor after: Policy changes affect signup quality, support load, conversions, and email delivery.
Frequently asked questions
Start with a maintained public GitHub repository that provides a raw domain file, a clear license, recent commits, version history, and a correction process. Import it as candidate data and validate it before production blocking.
No. Block high-confidence disposable providers in abuse-prone flows. Use step-up verification or review when the domain resembles a privacy-forwarding service or the user value warrants an exception path.
Refresh at least weekly for active abuse controls, and run daily updates when provider rotation causes measurable gaps. Review diffs before publishing new hard blocks.
Normalize the address domain, check it and its parent domains, and stop at the boundary identified by a current Public Suffix List. Avoid simple ends-with matching.
No. SMTP uses an implicit MX fallback to the domain's A or AAAA records when MX is absent. A valid Null MX explicitly states that the domain does not accept email, so handle it separately.
They do not change the sending domain's DMARC record. They affect account quality and downstream mail outcomes, so DMARC, SPF, DKIM, and sender-reputation monitoring still matter.
