Email alias detection is the set of checks a website uses to identify whether a signup address is a forwarding address rather than a direct inbox address. Some websites can detect an alias, usually from its domain, but detection and rejection are separate outcomes. Many detected aliases are accepted, and the distinction between the two outcomes explains most of the variation in how sites treat alias addresses. Email alias detection is therefore best understood as a classification step that informs a separate policy decision.
Detection methods
Domain lists are the most common detection method. A signup form takes the part of the address after the @ sign and compares it with a list of domains known to belong to alias services or single-use inbox services. A match flags the address. The method is cheap and fast, and it is also coarse, because it judges every user of a shared domain by the reputation of that domain as a whole rather than by the behaviour of the individual address.
Address shape is a second method. A plus tag, such as user+shop@example.com, is visible in the address itself, and some platforms remove the tag and treat the address as the base address. A subdomain address, such as shop@user.example.com, is likewise visible in its shape, as is a local part made of a random string with no recognisable name. No single shape signal proves that an address is an alias, but shape signals combined with a domain check increase the probability of classification as an alias.
Mail infrastructure and reputation form a third method. A checker can examine the domain mail records, the age of the domain, its sending history, and whether the domain accepts mail for any local part. A shared alias domain handling mail for thousands of users presents a different profile in these checks from a personal domain handling mail for one person. Forwarding is a property of the mail system behind the domain, not of the address string, so infrastructure checks can only infer it indirectly.
Findings of the NDSS 2026 study
The main research source is One Email, Many Faces: A Deep Dive into Identity Confusion in Email Aliases, by researchers at Fudan University, Tsinghua University and Zhongguancun Laboratory, presented at NDSS Symposium 2026 in San Diego on 23 to 27 February 2026. Its place in the programme is confirmed by the accepted papers listing for NDSS 2026. The study evaluated the alias mechanisms of 28 email providers and 18 online platforms.
The published abstract states that only Gmail fully documents its aliasing rules, while 11 providers silently support undocumented alias behaviours. The abstract also states the central platform finding: platforms either failed to distinguish alias addresses or over-aggressively excluded all emails containing a specific symbol. The first failure means that many platforms cannot tell an alias from an ordinary address at all. The second means that some platforms block a whole class of addresses, including legitimate addresses, because of one character or pattern. The paper identifies a lack of standardisation and documentation for aliasing as the root cause of both failures.
Two further figures are stated in the abstract. Attackers exploited aliases to create up to 139 accounts from a single base email on npm for spam campaigns. In the study user survey, 31.65% of participants with alias knowledge mistook phishing emails for legitimate alias mail, because provider implementations differ. These figures concern abuse and confusion rather than ordinary alias users being rejected, but they explain why platforms invest in detection at all. The published abstract does not name individual platforms, so no platform-by-platform detection result is stated here, and the full paper text was not available for this article.
Detection and rejection
Detection is information, and rejection is a policy decision built on top of it. Different sites decide differently, and many sites accept aliases without comment because the address is valid and verifiable by a confirmation message. Rejection occurs when a site requires one address per person, when it guards against abuse, or when it requires long-term contactability. The same detection result can therefore lead to acceptance on one site and rejection on another.
Provider documentation illustrates the distinction. SimpleLogin states that most websites allow registration with a SimpleLogin alias, but some do not accept a SimpleLogin domain. The error can be a clear message such as "This email address is not accepted", a generic error, or no error at all, as documented on the SimpleLogin blocking report page. SimpleLogin describes its aliases as permanent unless the user deletes them, in contrast to temporary addresses, as stated on the SimpleLogin homepage.
Firefox Relay documents the same pattern from a different angle. Its FAQ states that some sites do not accept an address that includes a subdomain, and others accept only addresses from Gmail, Hotmail or Yahoo. Those are two specific filters, a subdomain filter and a known-provider filter, rather than a general statement about aliases. Both filters are documented at the Firefox Relay FAQ, and both explain rejections that are sometimes attributed to aliasing as a whole.
Addresses most often flagged
Shared alias domains are flagged most often, because they are the easiest to list. Once a domain used by thousands of alias users is listed, every new signup from it is flagged regardless of the individual user. That listing is the main cost of a shared domain, and it is the reason providers offer custom domains.
Random-looking local parts are flagged next. An address such as x481n904 on a shared domain carries two signals at once, a listed domain and a random string. The addy.io features page uses that kind of example, x481n904@anonaddy.me, for a random alias, and it also describes username aliases such as anything@username.anonaddy.com, which look far more ordinary. Both formats are described on the addy.io features page.
Subdomain addresses sit between the two cases. Some sites reject them on shape alone, as Firefox Relay documents, while others accept them without issue. The Firefox Relay FAQ is the clearest provider source on this point, because it names the subdomain case directly rather than folding it into a general statement about aliases.
Plus-tagged addresses are the most transparent of all. A plus tag is visible and easy to strip, so platforms that normalise addresses treat user+shop@example.com as user@example.com. That transparency assists inbox filtering, but it exposes the base address, unlike a forwarding alias on a separate domain.
Addresses that pass more often
Plain-looking aliases on clean domains pass more often. A name-based local part, such as shop or newsletters, on a domain that is not on a shared list, gives a checker very little to work with. The domain is not listed, the local part looks ordinary, and the mail records belong to an ordinary domain.
A custom domain is the strongest version of this pattern. addy.io custom-domain documentation describes verifying ownership with a TXT record and adding MX, SPF, DKIM and DMARC records, the same setup any ordinary domain uses for mail. SimpleLogin gives the same advice: its blocking documentation states that a subdomain or a custom domain is the way to resolve a block, as described on the SimpleLogin blocking page.
A managed subdomain is a middle step. It avoids the shared-domain list while keeping the provider infrastructure, and it still looks like an ordinary address to most checkers. Apple takes a different route with Hide My Email, which generates unique random addresses that forward to a personal inbox, as described in Apple Hide My Email guide for Sign in with Apple. Those addresses use Apple's own domains, @private.icloud.com or @privaterelay.appleid.com, so they carry the shared-domain trade-off in exchange for generation inside Safari, Mail and Apple Pay, as described in Apple iCloud+ Hide My Email setup guide.
Accounts that must stay reachable
The banking rule does not depend on detection. The bank gets a permanent real dedicated address used only for financial accounts, never an alias. Recovery, statements and fraud alerts depend on that address staying reachable for years, and an alias adds a forwarding step and a provider dependency between the bank and the reader. Firefox Relay makes the same point: it recommends sharing the true address with a bank, a doctor and a lawyer, and it does not recommend masks where identity must be verified or where very important mail must arrive, as stated in the Firefox Relay FAQ.
The bank gets a permanent real dedicated address used only for financial accounts, never an alias. The same logic applies to government accounts and primary work accounts, where long-term reachability matters more than isolation from any single site.
AliasFleet and email alias detection
AliasFleet provides managed, persistent email aliases that forward to a verified destination inbox. Each alias is a separate address for a site or a purpose, so a leak of one alias does not expose the real inbox address or the aliases used elsewhere. Aliases can be paused or deleted when they start receiving unwanted mail.
AliasFleet also provides managed subdomains and custom-domain options in the same pattern described by other providers: a shared platform domain is convenient and is the most likely to appear on a list, while a managed subdomain or a custom domain gives the address its own reputation. AliasFleet does not provide single-use inbox addresses.
Detection does not change the value of an alias: it keeps the real inbox address out of a site database, isolates that site mail, and can be turned off. What detection changes is the choice of domain and local part for sites that filter strictly, from a plain local part to a managed subdomain to a custom domain, keeping the banking address separate throughout.
Top comments (0)