How to Tell If an Email Address Is Fake or Disposable

Three things "fake" can mean

The word "fake" covers three different problems, each with a different fix.

The first is a malformed address. The address does not conform to email syntax rules, so it could never be delivered to anyone. A form-level syntax check catches this before you try to send anything.

The second is a non-existent mailbox or domain. The address looks valid but either the domain has no mail records or no server accepts mail for that particular local-part. You can probe this with DNS lookups and, more carefully, with an SMTP-level check.

The third is valid-but-disposable. The address is syntactically correct, the domain does receive mail, but it belongs to a throwaway service. The mail will arrive, but the person who typed it never intended to read it again or be reached there.

Identifying which problem you have tells you which check to run first. Syntax is the fastest and cheapest. Domain reachability is a second pass. Disposable-list comparison handles the third case. Running all three, in sequence, is the complete picture.

Check 1: syntax

A syntactically valid email address has a local-part, an @ symbol, and a domain. RFC 5321, the Internet Standard for SMTP, specifies what the local-part and domain may contain: the local-part may include alphanumeric characters and certain punctuation, but not spaces or consecutive dots; the domain must be a valid hostname with at least one dot separating labels.

Every major programming language includes a library that validates against these rules, so the implementation cost is low. The important caveat is that a pass here proves very little: syntax validation confirms the string is structured correctly, not that a mailbox exists, not that the domain accepts mail, and certainly not that the address is permanent. A well-formed address pointing to a temporary inbox passes a syntax check with no trouble.

Use syntax as a filter to catch obvious garbage, including entries with no domain, missing @, trailing spaces from copy-paste errors, or clearly invalid characters. Do not rely on it alone to confirm a real, reachable address.

Check 2: does the domain receive mail (MX/DNS)

After confirming syntax, the next question is whether the domain can receive mail at all. The answer lives in DNS.

Every domain that can receive email publishes at least one MX (Mail Exchange) record. RFC 5321 defines MX records as the mechanism that directs email delivery: a sending mail server resolves the recipient's domain's MX records to find where to connect. A domain with no MX record has nowhere to send mail, so no address on it can receive anything.

You can run this check with standard command-line tools: "nslookup -type=MX example.com" on Windows or "dig MX example.com" on Linux/macOS. If the result returns no MX records, the address cannot be delivered to, regardless of how well-formed it looks. Reject it.

An A-record fallback exists (some very old configurations fall back to an A record if no MX is present), but modern mail servers do not rely on it. For practical filtering purposes, no MX means no mail.

Some legitimate domains receive mail through a catch-all configuration that accepts everything, including addresses that do not correspond to a real mailbox. This makes a positive MX result less conclusive than a negative one. The absence of an MX record is a reliable reason to reject; the presence of one only tells you the domain is connected to a mail server.

Check 3: is it on a disposable list

If the address has valid syntax and the domain has MX records, the remaining question is whether the domain belongs to a throwaway service.

The most widely used reference is the open-source disposable-email-domains repository. It is a plain list of disposable and temporary email address domains, with more than 5,100 GitHub stars. The project has real production adoption: PyPI, the Python Package Index, uses it to block temporary-email signups. The check is straightforward: look up the submitted domain against the list and reject it if there is a match.

The limitation of a static list is that it only knows about domains that have already been added. New disposable services launch regularly, and a freshly created throwaway domain will not appear on any list until someone adds it. Lists also age in the other direction: a domain listed as disposable years ago might have changed ownership. Neither problem makes the list useless; it reliably catches the large, established disposable providers. It just should not be treated as complete coverage.

Commercial detection services address the gap by scoring infrastructure signals rather than matching against a fixed list. Castle's security team describes MX records as "one of the strongest infrastructure signals," noting that many disposable providers run hundreds of domains through shared mail infrastructure, so unrelated-sounding domains point to the same mail server. Their analysis also identifies missing authentication records (SPF, DKIM, DMARC) and recently registered domains as useful signals. IPQualityScore states it tracks more than 700,000 high-risk disposable domains and adds over 10,000 new ones per day. These figures come from the vendors themselves and are worth reading as directional rather than audited, but they illustrate the scale advantage a continuously updated service has over a static community list.

Both approaches have false-positive risk. A legitimate domain that happens to share an MX host with a disposable provider, or that was recently registered by a real startup, can score as suspicious. Static lists carry similar risk if a previously disposable domain has been repurposed. Layering checks helps: a domain that fails syntax, has no MX, and matches a disposable list is almost certainly throwaway; one that only matches a list should be treated with more caution.

The fast way

If you want to run these checks without building your own toolchain, the TempMailSpot email validator covers syntax, domain, and disposable-list checks in one step.

The goal for most form owners is stopping throwaway signups: catching the disposable addresses that people use when they want a confirmation code but not a relationship with a service. Syntax checking is the floor, MX checking adds meaningful signal, and disposable-list or scored API checking is where the real work happens.

Combining all three layers reduces both misses and false rejections. A rough priority order: reject on syntax errors (fast, no network call); reject if no MX record (one DNS query); reject if domain is on a maintained disposable list or scores as high-risk with a commercial service (adds latency but improves coverage). For the user side of this question, including which disposable services still slip through detection, see how websites detect temporary email.