Disposable detection
How disposable and detection_source identify throwaway inbox providers, live vs precomputed results, and blocking abuse at signup.
Loading article…
The disposable field is true when the domain is classified as a throwaway inbox provider: temporary mail hosts, burner domains, and shared infrastructure built for one-time signups.
Optional disposable_provider names the source or infrastructure label when we know it. detection_source tells you whether the result came from EmailGuard's precomputed intelligence (precomputed) or included a live DNS lookup (live_dns) for that request.
This is EmailGuard's primary abuse-prevention signal alongside syntax validation.
After syntax passes, EmailGuard evaluates the domain against layered intelligence we maintain and refresh continuously:
Most API calls resolve from precomputed data for sub-millisecond latency. Live DNS fills the gap for newly registered burner domains—the trade-off detection_source exposes in your logs and metrics.
| Value | Meaning |
|---|---|
precomputed | Result from EmailGuard's maintained domain and infrastructure data |
live_dns | Live MX/DNS resolution contributed to this classification |
Use detection_source to understand latency and to audit how often your traffic hits day-zero domains.
Classified disposable domain:
curl -sS \
-H "Authorization: Bearer YOUR_KEY" \
"https://emailguard.co/api/v1/emails/detect?email=user%40throwaway.example"{
"data": {
"email": "[email protected]",
"syntax_validation": true,
"disposable": true,
"disposable_provider": null,
"detection_source": "precomputed"
}
}Legitimate corporate domain:
{
"data": {
"email": "[email protected]",
"disposable": false,
"detection_source": "precomputed"
}
}When live DNS runs, EmailGuard reads MX records per RFC 1035. Domains publishing Null MX (RFC 7505) signal that they do not receive mail; that can factor into classification alongside routing fingerprints.
Disposable detection does not SMTP-verify the address (RFC 5321 RCPT TO). We classify the domain, not whether a specific mailbox exists.
| Approach | Implementation |
|---|---|
| Hard block | Reject signup when disposable is true |
| Soft challenge | Require CAPTCHA or payment when true |
| Shadow ban | Allow signup but exclude from campaigns |
| Audit | Log disposable_provider and detection_source for SOC review |
Pair with normalization so users cannot bypass a domain block with +tag aliases on non-disposable hosts.
For a full server-side walkthrough, see How to block disposable emails at signup.
disposable targets intentional throwaway products.disposable with syntax, role, and relay flags instead of stitching blocklists yourself.