How to Detect Fake Email Addresses

Why a blocklist alone doesn't work

There's no finite list of "fake" email addresses to check against — an abuser generates a new local part every time, often programmatically. Detection has to work on addresses the system has never seen before, which means it has to reason about the shape of the string itself, not look it up anywhere.

The shape signals that actually work

Vowel ratio and consonant runs

Real names and words have a fairly predictable vowel-to-consonant balance. A segment of meaningful length (long enough that this isn't just chance — very short strings like "jsmith" or "jdoe" are excluded, since real abbreviations legitimately have low vowel ratios) with a vowel ratio under roughly a quarter, or a run of five or more consecutive consonants, is a strong signal the string wasn't typed as a word or name — it reads like xkqbzvmpl rather than anderson.

Where the digits are matters more than how many there are

sarah.johnson1987 has digits, but they're a trailing suffix — a very common, entirely benign pattern (birth year, a disambiguating number added because "sarah.johnson" was taken). x7k2p9m4q1 has digits interleaved throughout the string, which is a materially different and much rarer pattern in real human-chosen addresses. Detection treats these differently: a trailing numeric suffix gets a mild, size-scaled adjustment; digits scattered through the string at a high ratio (three or more digits making up over 30% of the string) is flagged as a genuine excessive-numbers signal.

Keyboard-adjacent sequences

Strings like qwerty, asdfgh, zxcvbn, or qazwsx — literal runs of adjacent keyboard keys — show up disproportionately in placeholder and bot-generated addresses, checked in both forward and reversed form. Nobody's actual name is asdfjkl.

Repeated fragments

A 2–8 character fragment repeating three or more times consecutively anywhere in the string — abcabcabc123, xyxyxyxynoise — is a pattern generation scripts produce and humans essentially never do. The detection isn't limited to the fragment tiling the entire string exactly; it catches the pattern even with unrelated trailing characters after it.

Entropy as a supporting metric

Shannon entropy (bits of information per character, based on the character-frequency distribution) is reported alongside the other metrics as a general randomness indicator. It's descriptive rather than a standalone trigger — a high-entropy string that also fails the shape checks above is a much stronger case than entropy alone.

"Unusual" and "risky" are deliberately kept separate

An address like skennt98@gmail.com has digits and moderate entropy but doesn't trip any of the shape signals above — it looks like a real, if slightly unusual, human-chosen handle. The local-part analysis returned by the API reflects that: descriptive metrics (length, entropy, number ratio, whether it looks name-like) are always returned, but they only affect the risk score when they cross into an actual triggered signal. A mildly unusual local part shows up as lower-scoring in the descriptive local_part_analysis block without ever touching the risk score itself — the API distinguishes "this looks a bit odd" from "this is evidence of automation," which matters a lot for false-positive rates at scale.

Example

{
  "email": "xkq-bzv-xkqbzv847@mailtemp.io",
  "local_part_analysis": {
    "length": 17,
    "contains_numbers": true,
    "number_ratio": 0.18,
    "entropy": 3.92,
    "repeated_character_ratio": 0.0,
    "keyboard_pattern": false,
    "name_like": false,
    "randomness": "high",
    "classification": "suspicious"
  },
  "signals": [
    { "code": "SUSPICIOUS_LOCAL_PART", "severity": "medium", "impact": 15, "description": "The local part is formed by repeating the same fragment, a pattern common in generated addresses." },
    { "code": "DISPOSABLE_DOMAIN", "severity": "critical", "impact": 60, "description": "The email domain is known to provide temporary or disposable mailboxes." }
  ]
}

Note the two signals are independent: the local-part shape triggered one, the domain being a known disposable provider triggered a completely separate one. A generated-looking local part on a legitimate domain, and a normal-looking local part on a disposable domain, both get flagged — for different, specific reasons.

Common mistakes

• Flagging any digits in a local part — trailing digits are extremely common and mostly benign
• Using a single regex for "looks random" instead of separate signals — it makes false positives hard to diagnose and fix
• Treating fake-address detection as a replacement for verification — a generated-looking local part can still sit on a real, deliverable mailbox
• Ignoring short local parts entirely to avoid false positives, instead of applying a minimum-length gate before shape checks run