A disposable email blocklist goes stale in about a month, because the providers that run the disposable services rotate their domains constantly. The list you built last month blocks the domains that existed last month. The new domains are already in use.
The list that rots
A disposable email blocklist is a list of domains that belong to disposable email services. When a user signs up with an address from one of those domains, the signup is blocked. The list works, and then it stops working, and the reason it stops working is that the domains change.
The providers rotate their domains constantly. When a domain gets blocked, the provider registers a new one and moves the service to it. The old domain stops working, the new domain starts working, and the blocklist that was built on the old domain is useless against the new one. The rotation is the business model. The providers know their domains get blocked, and they plan for it.
The speed of the rotation is what makes the list go stale so fast. An open-source list of disposable domains regenerates every 24 hours, which is fast enough to keep up. A list that is updated monthly is stale within weeks, because the domains it blocks have already been replaced. A list that was built once and never updated is not a blocklist. It is a historical document.
How big the problem is
The scale of disposable email use is large. A 2019 study published in the IEEE Symposium on Security and Privacy found that 2.3 million emails were sent to about 56,000 temporary addresses across 7 services in 3 months. That is the volume of mail going to disposable addresses, and it is only the mail that was measured. The real number is higher, because the study only covered seven services and only three months.
The services themselves are well known. 10 Minute Mail, Guerrilla Mail, Temp-Mail, Mailinator, and YOPmail are the names that come up most often, and they are free, instant, and require no registration. A user who wants a disposable address can have one in seconds, and a bot can have a thousand in a minute.
The addresses are short-lived by design. A 10 Minute Mail address works for ten minutes. A Guerrilla Mail address works for an hour. The address exists long enough to receive a verification code and no longer. By the time you check it, it is gone.
Why the obvious checks do not work
The obvious check is to send a verification email and see if it bounces. That does not work against a catch-all domain, which accepts mail to any address at that domain, so a bounce check cannot tell whether a specific address is real. The check has to look at the domain itself, not at whether the address bounces, and that is harder to do at scale.
The other obvious check is to look at the domain and decide whether it looks disposable. That does not work either, because the new domains are chosen to look legitimate. A domain that was registered last week and looks like a normal email provider is indistinguishable from a normal email provider until someone identifies it as disposable.
The check that works is a list that is updated constantly, from a source that tracks the rotation. The list has to be regenerated daily, and the check has to run on the server at signup, before the account is created. A check that runs in the browser can be bypassed. A check that runs after signup is too late.
Keeping the list fresh
The practical answer is to use a list that regenerates every 24 hours, and to run the check server-side at signup. The open-source disposable domain lists do this, and they are the standard for a reason. They track the new domains as they appear, and they drop the old ones as they disappear.
The second part of the answer is to check more than the domain. Check the age of the domain, check whether it is a catch-all, and check whether the address has been used before. A disposable address that passes the domain check can still be caught by a behavioral check, because the behavior of a disposable address is different from the behavior of a real one.
The list will never be perfect, and it does not have to be. It has to be fresh enough to catch the domains that are in use right now, and that means updating it every day, not every month. A blocklist that is a month old is a blocklist that is blocking last month's domains while this month's fake accounts walk through the door.
Keep reading
Related guides on this site: how email verification trades deliverability against friction how bots pass CAPTCHA and what behavior signals catch them More from Bot Defense For Web3.
Frequently asked questions
What is a disposable email address?
A disposable email service gives you an address that works for a few minutes or a few hours, receives mail, and then disappears. Services like 10 Minute Mail, Guerrilla Mail, Temp-Mail, Mailinator, and YOPmail all work this way, and they are free.
Why do disposable email domains change so fast?
They rotate their domains. When a domain gets blocked, the provider registers a new one and moves the service to it. The old domain stops working, the new domain starts working, and the blocklist that was built on the old domain is useless against the new one.
How many disposable email addresses are in use?
A 2019 study published in the IEEE Symposium on Security and Privacy found that 2.3 million emails were sent to about 56,000 temporary addresses across 7 services in 3 months. The volume is large, and the addresses are short-lived.
How often should a disposable domain blocklist be updated?
It depends on the list. An open-source list of disposable domains regenerates every 24 hours, which is fast enough to keep up with the rotation. A list that is updated monthly is stale within weeks, because the domains it blocks have already been replaced.
What is a catch-all domain and why does it break bounce checks?
A catch-all domain accepts mail to any address at that domain, so a bounce check cannot tell whether a specific address is real. The check has to look at the domain itself, not at whether the address bounces, and that is harder to do at scale.
Where should the disposable email check run?
It has to run on the server, at signup, before the account is created. A check that runs in the browser can be bypassed, and a check that runs after signup is too late. The check has to be part of the signup flow, not an afterthought.