Where can I find a current list of disposable email domains for email suppression?
Published 14 Aug 2025
Updated 18 Oct 2026
10 min read
Summarize with
Updated on 18 Oct 2026: We clarified disposable-domain matching and how to preserve address-level suppressions when refreshing a list.
There is no single canonical list that stays current by itself. The practical setup is to use a maintained public disposable-domain blocklist (blacklist) as seed data, refresh it automatically, and treat every match as a suppression signal with policy controls around it.
For a free starting point, use the public GitHub list. It provides a plain domain blocklist for application imports and accepts documented additions or removal requests. Its maintainers also state that they cannot guarantee every entry is still disposable, so local review and versioning remain necessary.
- Use a maintained public blocklist to catch known temporary email domains.
- Pull updates on a schedule, store the version, and track every domain added or removed.
- Do not convert list membership into a permanent global block without review rules and allowlists.
A disposable-domain list should be an input to suppression, not the whole suppression process. Temporary email services rotate domains, and ordinary mailbox providers can be used for throwaway accounts without being disposable domains.
Where to download a current disposable email domain list
Use a maintained GitHub dataset and import an approved copy into your application. In the recommended repository, open disposable_email_blocklist.conf on the default branch and select Raw to download the plain-text domain file. It contains one domain per line without an @ sign; convert it to CSV or JSON locally if your application requires another format.
GitHub repository containing the disposable email domain blocklist.
|
|
|
|---|---|---|
Maintained domain file | Local signup checks or bulk imports | Needs scheduled refreshes and review |
Packaged copy | Application builds | Package releases can lag behind the source |
Email verification API | Live classification or mailbox checks | Check disposable coverage, privacy terms and timeout handling |
Internal suppression table | Policy decisions and audit history | Needs an owner and reason codes |
Choose an import method and keep its classification separate from local policy.
A static CSV becomes stale without refreshes, and a raw list cannot tell you whether a signup is fraudulent or a legitimate customer. If you use an email verification API, check that it explicitly detects disposable domains. A valid MX record, an SMTP acceptance response, or a confirmed opt-in does not prove that an inbox will remain available.
The best list for suppression is the one your team can operate. You need to know when it changed, explain why a domain was blocked, and reverse a decision when the data is wrong. Check the latest domain-data changes and the reuse terms before adopting a dataset; a recent README edit alone does not establish list freshness.
What makes a disposable domain list current
A current disposable email domain list is more than a long file. It has recent additions and removals, normalized casing, deduplication, and documented matching rules. Public suffix validation helps catch malformed entries, but wildcard support depends on the dataset and your matcher. A domain that was disposable last year can go offline or change ownership, while a temporary mailbox provider can add fresh domains between refreshes.
Example local refresh targets
Illustrative internal targets measured since the last successful source check. They are not industry standards or proof that the upstream data is complete.
On schedule
0-1 days
Check for source changes at least daily under this example policy.
Refresh overdue
2-30 days
Investigate the missed schedule and compare with the upstream domain-data history.
Review urgently
31+ days
Review the refresh process and coverage. Age alone does not make every existing entry invalid.
Store both the source list and the local decision. The source list records what the outside data said. The local decision records what the business did with that signal. Keeping them separate prevents a public list update from silently changing the customer database.
Static list
- A CSV or text file is easy to import into a signup form or CRM workflow.
- New temporary domains appear between updates to manual files.
- An unversioned file makes it hard to prove which source caused a suppression decision.
Managed suppression logic
- A scheduled refresh retrieves the latest available source data without guaranteeing complete coverage.
- Allowlists, review queues, and risk levels reduce false rejections.
- Each blocked address has a source, timestamp, and business reason.
How to match disposable domains at signup
A reliable suppression process parses the address, normalizes its domain, checks the source's documented domain rules, applies local policy, and logs the decision. Preserve the local part before the @ sign, including plus tags. Enforce checks on the server, because browser-only validation is easy to bypass. Passing this domain check does not authorize a send or clear an existing address-level suppression.
Domain matching only (pseudocode)text
email = parse_email(trim(input)) domain = lower(idna_to_ascii(email.domain)).rstrip(".") registrable = public_suffix_aware_domain(domain) action = "pass_domain_check" rule = null if domain in exact_domain_allowlist: action = "domain_exception" rule = domain elif domain in disposable_exact_list: action = "block_signup" rule = domain elif registrable in disposable_registrable_list: action = "block_signup" rule = registrable elif matches_disposable_wildcard(domain): action = "review" rule = matched_wildcard(domain) log_decision(email, domain, rule, action, source, version, timestamp)
Use Public Suffix List-aware parsing instead of removing labels until only two remain. A registrable domain under co.uk needs different handling than one under com. Match the full domain first, and only use the registrable-domain branch for a source that defines entries at that level. Match subdomains at dot boundaries, so a rule for example.com does not match notexample.com; do not broaden an exact subdomain entry to its parent.
- Trim surrounding whitespace, lowercase only the domain, convert internationalized domains to their IDNA ASCII form, and handle a trailing root dot consistently.
- Check exact entries before applying documented registrable-domain or explicit wildcard rules. Do not assume every list includes wildcards.
- Use block, review, and domain-exception states instead of one permanent suppressed state. Offer a correction or appeal path for false positives.
- Save the matched rule, source, version, and timestamp for every suppression action.
Do not suppress existing engaged subscribers just because a domain appears in a new list update. Mark them for review instead. A list can contain mistakes, and some domains change ownership or behavior over time. Existing unsubscribes, complaints and confirmed invalid-mailbox suppressions still apply.
What to suppress and what to review
Disposable email suppression works best when it separates hard evidence from weak signals. A reviewed exact match identifies a listed temporary mailbox service, but it does not prove fraud or establish an address's expiration time. A free mailbox provider is not a disposable domain. Unusual signup behavior or low engagement needs context; confirmed invalid-recipient bounces and complaints need address-level suppression controls.
|
|
|
|---|---|---|
Reviewed temporary-domain match | Block at signup if policy requires | Known service, subject to local exceptions |
Wildcard hit | Review | Scope needs context |
Free mailbox provider | Pass the domain check | Provider category does not establish user intent |
Privacy forwarding alias | Do not block solely for aliasing | Forwarding does not establish a short mailbox lifetime |
High bounce rate | Inspect SMTP reasons and suppress confirmed invalid addresses | Domain-wide rates have mixed causes |
Existing engaged subscriber | Review a new domain match | Account history matters; other suppressions still apply |
Keep domain filtering separate from address-level sending eligibility.
This distinction matters because suppression changes affect acquisition and deliverability. A broad domain block rejects legitimate users and still misses low-intent accounts at ordinary mailbox providers. Track false-positive reports alongside signup rejection rates rather than assuming that more blocked domains means a better rule.
Poor rule
- Blocks entire free mailbox providers because some users create throwaway accounts there.
- Treats a domain match as proof of fraud without reviewing the source or account history.
- Ignores consent and bounce evidence once an address passes the domain check.
Better rule
- Applies a documented signup policy to reviewed temporary-domain matches.
- Uses confirmed opt-in and product use as additional signals, without treating either as proof of mailbox longevity.
- Routes weak signals into manual or automated review instead of permanent suppression.
Keep address-level suppression rules separate
A disposable-domain list classifies domains. An email suppression list records individual addresses that should not receive particular messages. A domain allowlist or removal from a disposable blacklist must never automatically clear an unsubscribe, complaint, or invalid-recipient record.
- Check applicable address-level suppressions before every send, including campaigns, automated messages and retries. Record the reason and the message scope.
- Keep marketing unsubscribes suppressed for the relevant marketing scope. A domain-list refresh is not renewed permission to send.
- Keep complaints and confirmed invalid-recipient hard bounces suppressed unless a documented review justifies a change. An engaged account history does not override them.
- Investigate temporary DNS failures or a full mailbox separately. Review the SMTP status and confirm recovery before removing a delivery-related suppression.
The reason matters: in an Atlassian support case, support found address-level suppressions after recipient-unknown responses, and the customer later reported a failing DNS nameserver. Inspect the delivery evidence before expanding one address's failure into a domain-wide block.
Keep list suppression separate from deliverability checks
Disposable-domain suppression is a list quality control. Authentication checks examine your sending identity, while sending blocklist (blacklist) monitoring checks reputation signals. Neither a clean recipient list nor a passing authentication test guarantees inbox placement.
After a suppression change, test a real campaign or transactional message with Suped's email tester to inspect the authentication used by your sender. Then check the sending domain's published DNS with the domain health checker so authentication problems are not blamed on suppression rules.
Suped's DMARC reporting and email authentication platform provides DMARC monitoring to group sending sources and inspect SPF and DKIM results. Use those reports to investigate authentication failures, and its blocklist monitoring (blacklist monitoring) to investigate listings affecting the sending IP or domain.
Email tester sample report showing total score, email preview, issue summary, and per-section results
A cleaner signup list can reduce avoidable bounces, but it will not repair a broken SPF record or missing DKIM signature. Recipient eligibility belongs in your application and sending system; Suped's authentication reports help diagnose the separate sending-identity issues.
A practical refresh and audit plan
Daily refresh is a practical baseline, not a universal standard. Higher-risk signup flows can refresh more often when the source publishes more frequently. The refresh job should compare the new list with the previous version, count additions and removals, and flag large changes before they affect production. A successful fetch with no domain changes still needs a recorded check time.
Daily refresh checklisttext
fetch source list and record source revision reject failed downloads, HTML and empty files normalize domains and validate documented format validate public suffix rules remove duplicates compare with previous version write additions and removals flag unexpected changes for review run allowlist and recent-signup checks publish approved version atomically retain previous approved version on failure log source revision, version hash and check timestamp
- Assign one team to approve the suppression policy and review unexpected list changes.
- Store the source name, source revision, local version hash, last successful check time, and approval timestamp.
- Run the rule against recent signups before publishing it into the live form. Track false positives, bounce outcomes and rejection rates after release.
- Keep the previous approved version ready so you can reverse a bad update quickly. A failed fetch should retain that version and trigger an alert.
A strong suppression program has a release process. The list update is the data change. The production decision is the policy change. Define timeout handling for any live verification API so an outage does not silently change signup decisions.
When a disposable list is the wrong fix
If many users choose temporary inboxes, review the acquisition flow. An unclear signup purpose or unwanted marketing can encourage people to protect their primary address. A stricter list does not address that reason for using a throwaway email address.
Do not treat Gmail, Yahoo, Outlook, or Hotmail as disposable domains. Also distinguish temporary inboxes from privacy aliases that forward to an existing mailbox. Plus-addressing does not change the domain and is not evidence that an address is disposable. Catch-all acceptance is also a separate classification, not proof of a temporary mailbox.
Illustrative suppression decisions
Invented percentages compare two rule designs. They are not measured results or recommended targets; set policy using your own false-positive and delivery evidence.
Allow
Review
Suppress
If you are cleaning an existing database rather than filtering new signups, treat list cleaning as a separate project. One-time cleanup changes records that already have history. Keep the original records and suppression reasons, and do not restore marketing eligibility merely because an address passes validation.
