A disposable email domain belongs to a service that hands out throwaway inboxes: you pick or receive an address, read the one message you were waiting for, and the mailbox expires minutes or hours later. Detection is a list problem with a DNS twist. An open list catches the domains people already know about, and matching a domain's mail servers against the same list catches the new ones, because a fresh burner domain still routes mail through an operator that is already listed.
What is a disposable email domain?
Services such as Mailinator, Guerrilla Mail, 10 Minute Mail and hundreds of smaller clones run thousands of domains whose only purpose is to receive mail nobody intends to keep. Some inboxes are public: anyone who guesses the address can read it. Most expire on a timer. None of them belong to a customer who wants to hear from you.
The same infrastructure also powers legitimate uses: testing a signup flow, avoiding a newsletter you were forced to subscribe to, or protecting privacy from a site you do not trust. The address is real and accepts mail. It is simply not a relationship.
Why do people use them?
Three motives dominate. Fraud and abuse: creating many accounts to farm free trials, coupons or votes. Privacy: not wanting a permanent address in yet another database. Friction: a site demanded an email address for something that did not need one. The third group is the largest, which is why the right response depends on what your form is for.
How does detection work?
Spaw combines three layers, in this order.
The open list. The domain is matched against the disposable/disposable-email-domains project, an open dataset of tens of thousands of burner domains, synced weekly and unioned with a bundled seed so detection works before the first sync. Matching includes parent domains, so a subdomain a burner service hands out is caught by its parent.
Local overrides. Two small files in the repository correct the upstream: an allowlist for false positives, which always wins, and a denylist for burners the upstream has not caught yet. Either beats waiting for the next sync.
MX host matching. New burner domains appear every day, faster than any list can follow. What does not change as fast is the mail infrastructure behind them. Spaw resolves the domain's MX records and matches those hosts against the same list, so a domain registered this morning that routes mail through a listed operator's servers is caught on its first lookup.
| Layer | Catches | Misses |
|---|---|---|
| Open list, with parent-domain matching | Known burner domains and their subdomains | Domains created since the last weekly sync |
| Allow and deny overrides | Corrections either way, effective immediately | Anything nobody has reported yet |
| MX host matching | New domains on known burner infrastructure | Burners on their own, unlisted mail servers |
Why is the list never complete?
Burner operators register domains in bulk precisely to stay ahead of lists, and a domain that is on every list gets rotated out. That is why the third layer exists, and why a disposable check that only looks the domain up in a table will always run a week or more behind. It is also why an address that passed a disposable check at signup can be on the list a month later; a scheduled monitor re-verifies a list on a cadence and reports when its makeup changes.
What does Spaw return for a disposable address?
The verdict is risky with reason: "disposable" and disposable: true. The mailbox is never probed, since spending a handshake on a burner would only confirm what the list already says, so smtp_checked is false. The disposable flag adds 80 to the risk score, the high band on its own.
curl https://spaw.co/api/v1/email \
-H "Authorization: Bearer sk_live_…" \
-H "Content-Type: application/json" \
-d '{"email": "[email protected]"}'
{
"success": true,
"data": {
"email": "[email protected]",
"deliverable": "risky",
"reason": "disposable",
"risk_score": 90,
"risk_level": "high",
"disposable": true,
"smtp_checked": false,
"mailbox_exists": null,
"// 19 more fields": "see the endpoint reference"
},
"meta": { "credits_used": 0, "credits_remaining": 10, "cache_hit": false }
}
That test address is free. A real disposable answer is a risky answer and costs 1 credit, because it is a usable answer: you learned the address should not go on a list. A typo-squat domain that also sits on the disposable list is reported as likely_typo instead, since the correction is the more useful fact.
The domain endpoint answers the same question for a whole domain, with disposable: true or false, alongside its provider, SPF and DMARC records and registration age.
Should you block disposable addresses?
It depends on what the address is for.
| Form | Recommendation |
|---|---|
| Free trial, credits, coupons, anything with value per account | Block, and say why. Ask for a different address. |
| Newsletter or marketing signup | Block, or accept and never send. Nobody reads a burner twice. |
| Purchase receipt or transactional flow | Accept. The customer chose where the receipt goes, and the message must be sent. |
| Contact or support form | Accept. Replying to a burner costs you nothing, and the sender chose the risk. |
| Existing list before a campaign | Remove. Burner domains attract spam-trap conversions and never engage. |
When you block, tell the user what happened and let them correct the address. The form helper that ships with Spaw runs the check on blur and shows the verdict inline without ever blocking the submit; blocking is a decision for your server.
Is my domain wrongly listed?
It happens: an open list occasionally includes a small privacy-focused provider or a company that once hosted mail for a burner service. The domain endpoint shows the current answer and the dataset version that produced it. Spaw's allowlist fixes a confirmed false positive immediately, ahead of any upstream change; send the domain to [email protected] with a line about who runs it.
What to do next
- Check a domain in the free disposable domain checker; each result has a permalink you can share.
- Read the
disposablereason page for the exact contract, including why the mailbox is not probed. - Ask the domain intelligence endpoint for the domain's provider, records and age in one call.
- Schedule a list monitor from the dashboard so burners that appear on the list later are caught before the next send.