EmailGuard

Knowledge base

Disposable detection

How disposable and detection_source identify throwaway inbox providers, live vs precomputed results, and blocking abuse at signup.

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.

How EmailGuard detects disposables

After syntax passes, EmailGuard evaluates the domain against layered intelligence we maintain and refresh continuously:

  1. Curated domain intelligence — millions of known disposable and burner domains, aggregated from public blocklists, community reports, and our own detection pipeline.
  2. Infrastructure fingerprinting — MX and DNS patterns shared by multi-tenant throwaway backends, so new hostnames riding the same mail stack can be classified even before they appear on a published list.
  3. Live DNS when needed — for domains not yet in static data, EmailGuard can resolve MX records in real time (RFC 1035) and match them against known disposable operators. Fresh throwaway sites often expose themselves through mail routing long before they show up in community blocklists.

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.

detection_source values

ValueMeaning
precomputedResult from EmailGuard's maintained domain and infrastructure data
live_dnsLive MX/DNS resolution contributed to this classification

Use detection_source to understand latency and to audit how often your traffic hits day-zero domains.

API examples

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"
  }
}

DNS and mail standards

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.

Signup policy patterns

ApproachImplementation
Hard blockReject signup when disposable is true
Soft challengeRequire CAPTCHA or payment when true
Shadow banAllow signup but exclude from campaigns
AuditLog 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.

What to expect

  • Coverage improves over time — burner domains rotate quickly; live DNS and infrastructure matching are how EmailGuard stays useful against day-zero hosts.
  • Freemail is not disposable — consumer providers flagged by public domain are usually legitimate; disposable targets intentional throwaway products.
  • One API call — combine disposable with syntax, role, and relay flags instead of stitching blocklists yourself.

Related docs