Where the lists come from
A disposable-domain blocklist is a text file: one domain per line, tens of thousands of lines. Several are public and maintained on GitHub, commercial validation APIs keep their own, and most application frameworks have a package that ships one. A domain gets onto them in three ways:
- It appears on a temp-mail website. The maintainers crawl the front pages of disposable services and add every domain they offer.
grabmail.iois on the lists for exactly this reason, and so is every public domain here — it is printed on this site’s own front page. - It behaves like one. A domain whose MX points at a known disposable service, or which accepts any random address, gets added by the probes described below.
- Somebody reported it. A site that saw a burst of sign-ups from one domain submits it, and the next release carries it.
The lists are large, public and slow to change in both directions: a domain added by mistake stays for months, and a genuinely disposable domain can take weeks to appear. The only reliable property is that a domain printed on a temp-mail site is on them, and a domain that never appears anywhere public is not.
The four checks a form can run
“Please enter a valid email” is one message for four different checks, and which one refused you decides what will work instead:
| Check | How it works | What it catches | What gets past it |
|---|---|---|---|
| Domain list | The domain of the address is looked up in a blocklist, usually before the form is even submitted. | Every public disposable domain, on the day it was listed. | Any domain not on the list: your own, or one that is never published. |
| MX lookup | DNS is asked where the domain’s mail goes. If the MX names a known disposable provider, the address is refused. | Domains pointed at a listed provider’s mail server — including, sometimes, your own domain pointed here. | A domain whose MX is not on the provider list. Rarer than the domain check, because it costs a DNS query per sign-up. |
| Catch-all probe | The site’s server opens an SMTP conversation and asks the MX whether a random address on the domain would be accepted. | Every catch-all domain, disposable or not — including a company’s own catch-all. | A domain that refuses unknown addresses, which a catch-all inbox by definition does not. |
| Provider risk score | The address is sent to a validation API that combines all of the above with its own history and returns a score. | Whatever that provider has seen before, which is a lot. | Addresses the provider has no history of — which is most addresses on a domain nobody has used before. |
The first check is by far the most common, because it is free and runs in the browser. The third is the one that matters for the rest of this guide: it is the only check that refuses a domain of your own, and it is the reason the paid pool exists.
Why sites do it, and what it costs them
It is easy to read a refusal as hostility. Usually it is arithmetic, and the arithmetic is worth understanding because it says which sites will never budge:
- Free-trial and credit abuse
- A service that gives away credits, minutes or a free month per account is signed up to a thousand times an hour by scripts. Blocking disposable domains removes the cheapest way to do that. These sites will not stop blocking, and should not.
- Bounces and deliverability
- Mail sent to addresses that expire bounces, and a bounce rate above a percent or two gets a sender’s domain throttled by every major mailbox provider. A site that sends a lot of mail protects its own reputation by not sending to addresses that will not exist next week.
- Fraud and chargebacks
- Anything that touches payment is scored, and an unrecognised or disposable domain is one input among many. Here the block is often the score rather than a list.
What it costs them is real too: every list carries false positives — small mail providers, university domains, a company’s own catch-all — and every refused sign-up is a person who typed a real address and was told it was invalid. A site that blocks without saying why loses those people silently. The last section is for the people running such forms.
Why changing the name before the @ never helps
The instinct after a refusal is to try john.smith instead of js. It does nothing. None of the four checks looks at the local part — the list is a list of domains, the MX lookup is per domain, the probe is per domain, and the score treats the domain as the strongest signal. Every address on grabmail.io is refused together, and so is every address on mixozia.com and linqmail.com.
It is worth saying plainly because the opposite is also true: what does work is changing the domain, and only that. Everything in the next section is a different domain.
Three honest ways round it
Each of these is a different domain, and each answers a different check. Pick by which check refused you and by what the account is for:
| Way round | Gets past | Costs | Right when |
|---|---|---|---|
| A domain of your own, pointed here with one MX record | The domain list and the provider score. Not the MX lookup on a strict site, and not the catch-all probe. | A domain you already own, or a cheap one. No account, no fee. | Testing your own application, or a personal address for sign-ups you would like to keep working. |
| A domain from the pool kept off the lists | All four checks: the domains are ordinary-looking .coms, never published, with plain MX records, and checked against the public lists every day. | A monthly plan, from the pricing page. API access to the pool, read with a key. | Automation that has to sign up on sites that block hard, and the domain of your own was refused too. |
| An alias that forwards to your real inbox | Everything, usually — alias domains are on some lists, but most forms accept them. | An alias service, or your provider’s own feature. | An account you actually want to keep: one that may need a password reset, or that sends you something worth reading. |
Your own domain, in one record
Add this MX record at your DNS provider and every address on the domain becomes a mailbox here, readable exactly like the public ones. The first message that arrives connects it; there is no account and no form to fill in. The setup guide walks through the common DNS providers, and unlimited test accounts on one domain shows what it looks like in a test suite.
MX record for your domain10 smtp.grabmail.io
The pool that stays off the lists
The pool exists for one reason: the catch-all probe. A domain of your own pointed here accepts every address, which is what makes it useful and what a probe detects. The pool domains are plain .coms that no temp-mail page has ever printed, and the service checks each one against the public lists daily; one that turns up is retired. It is the only paid thing on this site, and everything else stays free whether you take it or not.
An alias, when the account matters
If the site is refusing hard and the account is one you would mind losing, the answer is not a better disposable address; it is an address that reaches you. An alias delivers into your real inbox and can be switched off later. Burner, alias or temp mail is the longer comparison, and signing up without your real address covers the habits that make any of them work.
If you run the form: how to block well
Blocking disposable domains is a reasonable thing to do. Blocking badly costs real sign-ups, and the difference is five decisions:
- Check a list, not a heuristic. A maintained list is wrong less often than a rule like “refuse any domain younger than a year”. Update it on a schedule rather than at deploy time.
- Do not probe for catch-all. It refuses every company that runs one, and it makes your server open SMTP conversations with strangers on every sign-up. Let the verification mail do the work instead.
- Verify by sending. An address that receives your confirmation mail and clicks it has proved more than any list can. Most abuse fails at this step on its own, because it never reads the mail.
- Say why. “We don’t accept temporary email addresses — use one you can check later” loses fewer people than “please enter a valid email” on a valid email, and it tells the legitimate ones what to do.
- Rate-limit the thing being abused, not the address. If the problem is free credits, cap credits per payment method or per device; the domain check is a proxy for that, and proxies are what people route around.
None of this stops a determined abuser with a paid pool of domains. It stops the cheap abuse, which is most of it, without refusing the customers who happen to run their own mail.
The short version
- A refusal is about the domain. The local part is irrelevant — do not keep trying names.
- For your own application: a domain of your own, one MX record, free.
- For automation on strict sites: a domain from the pool kept off the lists.
- For an account you want to keep: an alias that reaches your real inbox, not a disposable address at all.
And if the confirmation mail was accepted but never turned up, that is a different problem with its own guide: verification email not arriving.
Questions
Is using a disposable address against the site’s rules?
Sometimes. A site that blocks them usually also forbids them in its terms, and an account made that way can be closed. Nothing here helps you break a site’s rules — the honest ways round a refusal are all addresses you are entitled to use, and the alias option exists precisely for the accounts that matter.
Will my own domain end up on the lists?
Only if it is published somewhere the list maintainers crawl, or reported. A domain that only ever appears in your own test suite or your own sign-ups has no way onto them. The MX lookup can still recognise it on a strict site, and the catch-all probe will — for those, the pool is the answer.
How are the pool domains kept off the lists?
They are never printed on any page, they are ordinary .coms with their own plain MX records, and each is checked against the public blocklists every day. One that appears anyway is retired from the pool. The pool is read through the API with a key, which is what the paid plans provide.
Why does the site accept my address and then never send the mail?
Some sites refuse silently: the form says “check your inbox” and nothing is sent. It looks like a delivery problem and is a block. Verification email not arriving has the sixty-second check that tells the two apart.
Does GrabMail publish a list of its own domains?
The public ones are on the front page, which is the same as publishing them. The pool domains and customers’ own domains are never listed anywhere, and there is no endpoint that enumerates them.
Can a form tell that my own domain points at GrabMail?
An MX lookup can, if the site keeps a list of disposable providers’ mail servers and checks against it. Few do, because it costs a DNS query per sign-up, but strict sites exist. A catch-all probe can too. The domain-list check, which is the common one, cannot.
What is the difference between all of this and a “fake email generator”?
Nothing but the name. A generator gives you a random address on a public disposable domain — on the lists, refused by the same forms. What temp mail is sorts out the vocabulary.
