A sign-up form that wants to stop one person registering twice will often "normalise" email addresses first: lowercase them, strip the dots, cut off anything after a plus sign. Then it compares. It is a reasonable instinct, and on most of the internet it produces the wrong answer.
We'll look at how the major providers handle address variants, find the one sentence in the mail standards that settles the question, and test the obvious fix to see if it works.
The sentence that decides it
The standard for moving email, RFC 5321, says who gets to interpret the part of an address before the @. It is one sentence, and it is unambiguous: the local part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address.
In other words, only the receiving provider knows what john.smith means. Not the sender, not the network in between, and not a sign-up form. Every normalisation rule is a guess about how some particular host behaves, made by software that is not that host.
The same standard goes further on case, and here the world has quietly disregarded it. It states that the local part MUST BE treated as case sensitive, and that for some hosts the user "smith" is different from the user "Smith". In practice almost no major provider treats the case as significant — but the standard permits one that does.
What each provider does with a variant
The table below is built from each provider's own documentation, with notes where a provider is silent.
| Provider | Dots ignored? | Plus addressing? | Other alias form |
|---|---|---|---|
| Gmail (gmail.com) | Yes | Yes | — |
| Google Workspace (own domain) | No — dots change the address | Yes | Admin-set aliases |
| Outlook.com / Hotmail | Not documented | Yes, receive only | Up to 10 real aliases |
| Microsoft 365 / Exchange | Not documented | Yes, on by default | Proxy addresses |
| Apple iCloud | Not documented | Not documented | 3 aliases; Hide My Email relays |
| Yahoo | Not documented | Not documented | [email protected] |
| Proton | Yes, plus hyphens and underscores | Yes | Hide-my-email aliases |
| Fastmail | Not documented | Yes, on by default | [email protected] |
Only two providers document dots as ignorable: Gmail's consumer domain and Proton's own domains.
Where stripping dots merges two different people
Google's help page on dots draws the line itself. Dots don't matter in a gmail.com address — but if you use Gmail through work, school or another organisation, on that organisation's own domain, dots do change your address.
So on a company that runs its mail through Google Workspace, [email protected] and [email protected] can be two different employees with two different inboxes. A normaliser that strips dots would treat them as one person, and tell the second of them that the address is already registered — or, worse, send one person's password reset to the other.
This isn't an edge case. It's the documented, default behaviour of Google Workspace, a common mail service, and the clearest example of dot-stripping merging two people's accounts.
Can you tell from the address? Trying the obvious fix
The difficulty is that a Workspace domain looks exactly like any other domain. Nothing in company.com says Google hosts it. So the obvious fix is to look it up: every domain publishes, in public DNS, which server accepts its mail — its MX record. Ask the domain, and you should learn who the host is.
Here is what that lookup returns for a handful of domains:
| Domain | Mail is accepted by |
|---|---|
| gmail.com | |
| googlemail.com | Google — the same server as gmail.com |
| outlook.com | Microsoft |
| yahoo.com | Yahoo |
| icloud.com | Apple |
| proton.me | Proton |
| fastmail.com | Fastmail |
| smu.edu.sg | Microsoft |
| nus.edu.sg | a Trend Micro security gateway |
| ntu.edu.sg | a Trend Micro security gateway |
For most of those the lookup works. But look at the last two. The National University of Singapore and Nanyang Technological University both route incoming mail through a security filtering service first. The MX record names the filter, not the mailbox provider behind it. From public DNS alone, there is no way to tell whether a dot in a student's address is significant.
This is a common setup for any organisation large enough to buy mail filtering. The lookup fails for the very institutions most likely to have thousands of users with similar names.
The gmail.com and googlemail.com result is worth a word too. The two domains hand their mail to the same Google server, which is consistent with the long-standing understanding that they reach the same inbox. A shared server is suggestive rather than proof, though, and Google's own help pages do not state the equivalence outright.
What a plus-only normaliser never sees
Cutting everything after a + catches the most common alias form and misses several others entirely.
Yahoo does not use the plus sign. Its documented mechanism is the disposable address, built as a fixed nickname, a hyphen, and a keyword — [email protected]. Here the hyphen is the separator. A normaliser looking for + passes every one of them through untouched.
Fastmail has a second form. Besides user+tag@, it accepts [email protected] — the tag moved into a subdomain. The local part is now the tag, and the real username is in the domain.
Apple's relay addresses cannot be normalised at all. Hide My Email and Sign in with Apple generate a unique address per site on privaterelay.appleid.com. The same person has a different address at every service they use, and none of them reveals the real one. That is the purpose of the feature.
Microsoft's plus handling has a twist. Exchange Online, where plus addressing has been on by default since 2022, first tries to deliver to the full address — plus sign included — and only strips the tag if no such mailbox exists. So an address containing a literal plus can be a genuine, separate mailbox. An administrator can also switch plus addressing off for the whole organisation.
Nothing in the standards requires the plus sign
Plus addressing is so widespread that it is easy to assume it is part of email. It is not. The only RFC that defines sub-addressing is RFC 5233, and it is an extension to Sieve, a language for filtering mail that has already arrived — not a rule for delivering it.
Even there, the plus is offered only as an example of a separator, such as "+", and the logic used to split an address is left implementation-defined. A provider that ignores the plus sign entirely, or uses a different character, is breaking no rule.
What holds up
Store the address exactly as the person typed it, and send mail to that. Compare on a key that is lowercased, because no major provider documents case-sensitive addresses in practice. Strip dots and plus tags only for domains whose provider documents that behaviour — gmail.com, googlemail.com and Proton's own domains for dots — and never for an arbitrary custom domain, however it looks.
If what you actually need is to stop one person holding several accounts, the address is the wrong tool. It was never designed to identify a person, and the standard says so in the sentence that opens this article.
What the documents say, and what they do not
Provider behaviour is taken from each provider's own help or developer documentation: Google's pages on dots and on aliases for both Gmail and Workspace; Microsoft's Exchange Online documentation on plus addressing and its Outlook.com help; Apple's pages on iCloud aliases and Hide My Email; Yahoo's page on disposable addresses; and Proton's and Fastmail's help pages. The RFC quotations were checked against the published text of RFC 5321 and RFC 5233. The MX results were looked up directly on 21 September 2026 and reflect each domain's configuration on that date; organisations change mail providers, so a lookup today may differ.
Several things are unconfirmed and marked as such in the table. No major provider's documentation states whether dots are ignored at Outlook.com, Yahoo, iCloud or Fastmail, or whether iCloud and Yahoo honour a plus tag. Google's help pages do not state that gmail.com and googlemail.com are the same inbox, nor that Gmail addresses are case-insensitive, though both are widely relied upon. And the date Microsoft switched plus addressing on by default comes from an administrator-facing notice that is not public; the year is well attested, the exact announcement is not.
View author profile → · Editorial policy
