Why disposable email blocklists go out of date (and how to detect new domains)
The first thing most teams try against throwaway signups is a blocklist: a file of a few thousand disposable domains from GitHub, checked at signup. It works for a week. Then the fake signups start again, from domains that aren't on the list.
This post explains why lists fall behind, and what a domain's DNS records reveal about it even when nobody has listed it yet.
Why lists fall behind
Domains are cheap. Many top-level domains cost a dollar or two for the first year. A temp-mail service can register dozens at once and switch to new ones whenever the old ones get blocked.
Services rotate on purpose. Popular temp-mail sites offer a domain picker or change their default domain regularly, precisely because their users want addresses that sites still accept.
Lists are updated by people. Open-source lists depend on someone noticing a new domain and opening a pull request, then on you updating your copy. Each step adds days or weeks.
Lists can't see private services. Someone running a throwaway setup on their own domains never appears on a public list.
The result: a list stops the domains everyone already knows, and lets through exactly the new ones that people are actively using.
What DNS reveals about a new domain
A domain built only to receive throwaway mail is set up differently from a real company's domain. Its public DNS records show it:
| Signal | A real company domain | A cheap throwaway domain |
|---|---|---|
| Website | company.com or www.company.com resolves | Often nothing: the domain exists only to receive mail |
| SPF record | Authorizes the servers that send its mail | Missing, or a placeholder that authorizes nobody |
| DMARC record | Usually present | Usually missing |
| Reverse DNS on the mail server | Always set: mail servers without it struggle to deliver | Often missing: the server only receives |
| Mail server | Their own, or a mainstream provider | Often shared with dozens of other throwaway domains |
No single signal proves anything. Plenty of small legitimate domains have no DMARC record. But a domain with no website, no real SPF and a mail server without reverse DNS is very unlikely to belong to someone's real inbox. Scoring several signals together gives a useful answer for domains no list has seen.
The strongest signal: shared mail servers
Throwaway services rotate domains, but running mail servers is more work, so many domains point at the same few servers. Once one domain is identified as disposable, its mail server becomes a clue for the next one.
That is how Signitize learns:
[email protected]is detected by its DNS signals. The domain and its mail server are remembered.- The next address at
new-burner.xyzis caught immediately, without a DNS lookup. - A sibling domain on the same mail server starts with a head start in its score, so it needs fewer other signals to be caught.
Two safety rules matter here. A learned server alone is never enough to flag a domain, so one wrong guess can't block a legitimate business. And mail servers of shared providers (Google, Microsoft, Zoho and others) are never learned, so one bad domain hosted there can't affect anyone else.
What still gets through
Being honest about limits:
- A temp-mail service with a real website, proper SPF and reverse DNS looks legitimate to DNS checks until it is listed or one of its domains trips the signals.
- Catch-all custom domains (any address
@someones-domain.comarrives in one inbox) are real domains owned by real people. They can't be detected from the address. - When DNS lookups fail, a careful checker answers "not disposable" rather than guessing, so real users aren't blocked by a network hiccup.
That is why the email check should be one layer: combine it with duplicate detection by canonical email and hold back free perks until the email is verified.
Try it
Detection documents every step, signal and score Signitize uses. The Free plan includes 2,500 checks a month: get a free API key and send it the newest throwaway domain you've seen.