Detecting Gmail-based fake accounts: what Emailnator teaches us

Most disposable email services are easy to detect. They use obvious domains like tempmail.xyz or tmxttvmail.com, which are widely known and routinely flagged by basic anti-abuse filters. Emailnator is different.

While it still provides access to standard temporary inboxes, its most concerning feature is the ability to generate and use real Gmail addresses. These Gmail-based inboxes can receive account confirmation links and other transactional emails, making them highly effective for automating fake signups. Combined with support for temporary phone numbers, Emailnator gives attackers a full disposable identity toolkit, email, phone, and an API to scale it using bots.

In this article, we take a closer look at how Emailnator works, how it generates Gmail addresses, and why these addresses are harder to detect than classical disposable domains.

What Emailnator offers: From disposable mail to scalable Gmail aliases

Emailnator is a web service that offers access to disposable email addresses, temporary phone numbers, and more notably, throwaway Gmail addresses. These are commonly used to bypass registration requirements, automate fake account creation, or hide a user's real contact information.

Disposable emails: The core feature of Emailnator is access to classic temporary inboxes. These use custom domains like psnator.com, as shown in the screenshot below with a generated address dhq8tf9[@]psnator.com.

Disposable emails are short-lived inboxes that don’t require authentication and are publicly accessible. As we detailed in this post, they are commonly used to access gated content, avoid spam, or bypass signup limits. These addresses are easy to generate, often work for a few minutes or hours, and are frequently seen in automated abuse campaigns. Because they rely on non-standard domains, they are routinely blocklisted by defenses like this GitHub project.

Temporary phone numbers: In addition to disposable emails, Emailnator offers temporary phone numbers. These behave in a similar way to disposable emails: the user is assigned a shared number, which can receive SMS messages including verification codes. They're often used to register accounts that require phone validation without disclosing a real phone number.

Bulk generation of Gmail addresses: The most critical feature for attackers is Emailnator’s support for generating Gmail-based throwaway addresses at scale. The UI lets users create high volumes of Gmail addresses using two legitimate Gmail features:

  • Dot variations
  • Plus (alias) addressing

To verify that these addresses actually work, we sent an email from our own Gmail account to tinytmp+zsh8q[@]gmail.com, one of the addresses generated by the platform. The message was successfully received, confirming that the service operates on top of real Gmail infrastructure.

Gmail alias and dot abuse: how Emailnator derives thousands of variants

In this section, we explain the mechanisms used by Emailnator to offer disposable Gmail-based email addresses. These are not fake inboxes. They rely on legitimate Gmail infrastructure, and the disposable behavior comes from how Gmail handles variations of the same address.

Although it’s unclear how Emailnator obtains Gmail accounts in the first place, whether manually or using bots, the core idea is straightforward: with a few hundred valid Gmail addresses, the platform can generate hundreds of thousands of functional variants by applying Gmail’s own address-handling rules.

Emailnator leverages two Gmail features:

  1. Email aliasing, also known as plus addressing: Gmail allows users to add a +tag after the username. For example, user+alias@gmail.com delivers to user@gmail.com. This is officially documented by Google here.
  2. Dot normalization — Gmail ignores dots in the local part of the address, treating my.email@gmail.com and myemail@gmail.com as equivalent. This behavior is confirmed in this Google support page.

These mechanisms are designed for filtering and organization, but Emailnator uses them to create high volumes of unique-looking Gmail addresses derived from a single real account.

Gmail address variants: A single Gmail account can be expanded into many syntactic variants:

  • my.email.test@gmail.com, m.y.e.m.a.i.l.t.e.s.t@gmail.com, and similar variations all route to the same inbox
  • myemailtest+promo1@gmail.com, myemailtest+signup123@gmail.com, and other alias forms are also accepted by Gmail

To an external system, these look like separate email addresses. But Gmail treats them as one.

Account generation and derivation: Emailnator likely starts by registering a base set of real Gmail accounts, for example, 100 such accounts. From there, it generates a large volume of syntactic variations using both dot injection and aliasing. A single account like account1generated@gmail.com might yield:

  • Dot-variant: ac.co.unt1.gen.erated@gmail.com
  • Alias-variant: account1generated+zsh8q@gmail.com

These derived emails all route to the same Gmail inbox. However, Emailnator does not expose the full mailbox. It only shows the messages sent to a specific variant. So when a user visits https://www.emailnator.com/inbox#tinytmp+zsh8q@gmail.com, they only see emails addressed to that alias, not the entire tinytmp@gmail.com inbox.

Why Emailnator’s Gmail variants make abuse hard to stop

Emailnator’s model enables the simulation of nearly unlimited Gmail addresses using a small set of base accounts. Since these addresses use the @gmail.com domain, they appear clean and legitimate. As a result, they bypass most basic filters designed to catch disposable or temporary domains.

Why it’s hard to block: Gmail’s alias and dot-handling behavior is well-documented and commonly used by legitimate users. Blocking + aliases entirely would create false positives, especially among users who rely on them for email organization. Dot variations are even more subtle. there’s no reliable way to distinguish between a real user with a dotted address and someone abusing Gmail’s flexibility.

Without normalization (removing dots and stripping aliases), it’s difficult to correlate these variants.

Abuse scenarios: These Gmail-based disposable addresses can be used for the same types of abuse as classic disposable email services. They’re especially useful in contexts where regular disposable domains are blocked. Common use cases include:

  • Creating multiple fake accounts to bypass free-tier limits, particularly on SaaS platforms offering credit-based access.
  • Sending spam or bulk messages without tying the activity to a persistent identity.
  • Participating in reputation or manipulation campaigns on platforms that use email uniqueness as a proxy for user uniqueness.

Manual and automated usage: Like many abuse vectors, this model supports both manual and automated fraud. Attackers can manually create a few dozen fake accounts using address variations, or use automation frameworks to create thousands.

Emailnator’s paid API, available via RapidAPI, allows programmatic access to its Gmail pool. It supports generating addresses, polling inboxes, deleting messages, and more. This enables attackers to fully automate fake account creation flows, from signup to email verification, using Gmail addresses that appear normal from the outside.

Defending against Gmail-based throwaway emails

Traditional disposable email services are relatively easy to detect. You can use public domain blocklists, such as this one on GitHub, to reject signups using known tempmail providers. These lists are widely used, updated regularly, and simple to integrate into most signup validation pipelines.

Things get more complex when dealing with throwaway Gmail addresses. Because they originate from legitimate Gmail infrastructure and use valid address variations, domain-based filtering is ineffective. To handle this case, email normalization becomes critical.

One effective approach is to normalize user-submitted Gmail addresses during ingestion. This involves removing all dots from the local part and stripping out any + alias. For instance, tinytmp+zsh8q@gmail.com should normalize to tinytmp@gmail.com. By storing both the original and normalized forms, you can detect reuse of the same base address across multiple accounts.

Although it may be tempting to reject addresses with too many dots or + aliases, that strategy doesn’t scale well. Gmail officially encourages the use of aliases for filtering (source), and many users naturally include dots in their Gmail usernames. There’s no clean threshold to distinguish abuse from normal usage. Over-filtering here leads to false positives and unnecessary user friction.

Leverages Google’s detection: Gmail accounts used for malicious automation are often short-lived. Google actively monitors for abuse and regularly bans accounts tied to bot activity, spam campaigns, or mass registration. This means that while attackers may retain access to these accounts shortly after creation, they often lose access over time once the accounts are flagged or suspended by Google.

You can use this to your advantage. Beyond verifying email ownership at signup, it’s useful to periodically re-verify that a user still has access to their registered email address. This simple check can surface abandoned or banned Gmail accounts, especially in scenarios where fake users are trying to maintain long-lived access.

Re-authenticating email ownership also serves as an effective form of soft friction, particularly in environments where multi-account abuse is a concern. While it may introduce minor interruption, this type of challenge is increasingly common in risk-based authentication flows and is generally accepted by users when deployed selectively.

Focus on the intent instead of the email: Instead of focusing solely on syntax, it’s more effective to look at behavioral signals. For example, multiple accounts created from the same device fingerprint or IP address, or flows that show signs of high entropy or automation. Frameworks like Puppeteer Stealth and NoDriver, discussed in this blog post, often leave detectable traces, even when paired with seemingly clean Gmail addresses.

Email filtering should be treated as one signal among many, not a standalone solution. Disposable email detection becomes much more powerful when combined with fingerprinting, rate limiting, IP intelligence, and dynamic friction.

How Castle handles disposable emails

Castle doesn’t just block disposable or Gmail alias-based addresses. These emails are treated as part of a broader real-time risk model. Our detection engine identifies disposable usage and correlates it with other factors like device fingerprint reuse, IP reputation, signup velocity, and behavior entropy.

Some customers choose to block these signups entirely. Others use them to trigger additional verification steps, isolate flows, or introduce friction when risk is high. This allows for adaptive protection without breaking the experience for legitimate users.

For more implementation details, refer to our docs: Block signups with spam emails

Indicators of compromise (IoCs) from Emailnator-generated Gmail variants

To understand how attackers leverage Emailnator in practice, we analyzed its backend and scraped the API to extract a large dataset of Gmail addresses generated using dot injection and plus aliasing. These addresses are functionally equivalent to a smaller set of real Gmail accounts, but are designed to look unique to external systems.

The goal of sharing this data is to help security and fraud teams identify whether similar Gmail variants are being used to abuse their own platforms.

Raw dataset, 46,000 Gmail variants: We collected a total of 46,000 Gmail addresses from Emailnator’s Gmail generation endpoints. These addresses rely on Gmail’s two normalization features, dots and plus tags, to create many syntactic variants from a single base account.

Normalized dataset, 291 unique Gmail roots: After applying Gmail-style normalization (removing all dots and everything after any +), we reduced the 46K addresses down to just 291 unique base Gmail accounts.

This confirms that Emailnator doesn’t generate an infinite supply of real Gmail inboxes. It just amplifies a small set of base accounts into thousands of valid-looking variants that are hard to detect without normalization. Note that this conclusion only holds for the free gmail accounts they provide. Their pool of Gmail accounts is probably larger for users on the paid plan.

How to use this list: If you want to assess whether your platform has been targeted by this technique, we recommend the following:

  1. Normalize Gmail addresses in your user database by stripping dots and + suffixes.
  2. Compare the normalized addresses against our deduplicated list.
  3. Investigate clusters of accounts that share the same normalized Gmail root. High concentrations may indicate automated abuse or attempts to bypass account limits.

This technique is especially useful if you’ve seen a sudden increase in @gmail.com signups that don’t match your historical patterns.

Evidence of real-world abuse: We’ve observed accounts from this dataset actively used on a Castle customer platform, specifically, a SaaS product with a free-tier offering. While we can’t fully determine the attackers' objectives, Gmail variants like these are commonly used to:

  • Register multiple free accounts without hitting limits
  • Bypass per-user quotas on usage or credits
  • Exploit SaaS signup flows and simulate legitimate onboarding

These patterns align with what we’ve previously documented in our deep dive on SaaS free-tier exploitation.

Conclusion

Emailnator illustrates how a small number of legitimate Gmail accounts can be repurposed to generate tens of thousands of syntactically unique, but functionally identical, email addresses. By leveraging Gmail’s plus addressing and dot normalization features, attackers can evade basic filtering and create fake accounts that look clean and valid from the outside.

Traditional disposable domains are relatively easy to block using domain-based filters. But Gmail-based throwaway addresses require deeper defenses. Normalizing emails during ingestion, tracking behavior across sessions, and looking for signs of scripted automation are far more effective than relying on hardcoded patterns like excessive dots or alias usage.

As always, email alone should not be your only signal. Treat these address variants as weak indicators that become meaningful when correlated with device fingerprinting, behavioral analysis, IP reputation, velocity anomalies, or known automation behavior.

Attackers will keep evolving. But with layered detection logic and the right telemetry, defenses can adapt faster, and without penalizing real users in the process.