Plus Addressing, Gmail Dots and Free-Trial Abuse: The Rules

To stop repeat free trials, store the address exactly as typed and also compute a normalised identity key: lower-case it, strip the +tag where the provider documents plus addressing, and remove dots only for gmail.com and googlemail.com. Check the key, not the address, when granting a trial. Never strip dots on other domains.

Every rule below comes from the provider's own documentation, fetched on 1 October 2026, or is marked as something we could not confirm.

Why one person can have dozens of addresses

Many large providers deliver several spellings of an address to the same inbox, so a naive uniqueness check on the email column lets one person start as many trials as they like.

janedoe@gmail.com, jane.doe@gmail.com, j.a.n.e.doe+trial7@googlemail.com and JaneDoe@gmail.com all reach one inbox. If your trial logic is "one trial per email address" and the email column is unique as typed, each of those is a new customer.

This is not exotic. Plus addressing is a documented, encouraged feature, and the people using it for free trials are usually not attackers. They are individuals who discovered that your trial resets. The fix is cheap if you design for it from the start.

The rules, provider by provider

Only two providers in our list ignore dots, several ignore a +tag, and some create aliases in ways no string rule can undo.

Provider	Dots ignored?	+tag delivered to base address?	Other alias mechanisms	Source
Gmail (gmail.com)	Yes	Yes	None	Google dots, Google plus addressing
googlemail.com	Yes (same accounts as gmail.com)	Yes	None	Google: "Messages sent to @gmail.com and @googlemail.com are the same"
Google Workspace (own domain)	No, dots change the address	Yes	Admin-defined aliases	Same two Google pages
Microsoft 365 / Exchange Online (own domain)	Not documented	Yes, on by default; admins can disable	Admin-defined aliases	Microsoft Learn
Outlook.com / Hotmail (consumer)	Not documented	Could not confirm from a current Microsoft page	Account aliases	None found
Yahoo Mail	Not documented	Not documented	nickname-keyword@yahoo.com disposable addresses	Yahoo Help
Fastmail	Not documented	Yes	anything@user.fastmail.com subdomain addressing	Fastmail Help
Proton Mail	Not documented	Yes	@pm.me for paid plans	Proton plus aliases, pm.me
Apple iCloud+	Not documented	Not documented	Hide My Email random addresses	Apple Support

"Not documented" means we did not find the rule in the provider's own help pages. It does not mean the provider behaves the other way, only that we will not write code that depends on it.

Gmail: dots, but only on gmail.com

Google's help page is explicit: "If someone accidentally adds dots to your address when emailing you, you'll still get that email." The same page then says: "If you use Gmail through work, school, or other organization (like yourdomain.com or yourschool.edu), dots do change your address."

That second sentence is the trap. A Google Workspace domain is still Gmail underneath, but jane.doe@company.com and janedoe@company.com can be two different people. Removing dots from every address hosted on Google would merge them.

Exchange Online: a + is tried literally first

Microsoft's documentation describes the resolution order: "When Exchange receives an email for an address that contains a +, it will try to resolve the full email address (for example, sean+newsletter@contoso.com) to a known mailbox. If the first resolution attempt fails, Exchange does a second attempt to resolve the email address without the plus sign and tag."

So in a Microsoft 365 organisation, sean+newsletter@ could in principle be its own mailbox, and an admin can switch plus addressing off entirely. Stripping the tag is right in nearly every case but not guaranteed, which is one more reason to use the stripped form as a key for comparison, never as the address you send to.

Yahoo, Fastmail and Proton: different shapes of alias

Yahoo disposable addresses take the form nickname-keyword@yahoo.com. According to Yahoo, free users in Yahoo Mail Plus locales can try up to 3, and up to 500 come with Yahoo Mail Plus. The nickname is a base name chosen once ("Once this is set it can't be changed"), and Yahoo's page does not say it has to match the account's own username, so there is no reliable string rule that maps a disposable address back to the account. Do not strip text after a hyphen: hyphens appear in ordinary addresses too.

Fastmail supports plus addressing and also subdomain addressing, where whateveryoulike@alias.domain.tld is delivered like a plus address. For fastmail.com that means shopping@jane.fastmail.com reaches jane@fastmail.com. Fastmail also supports this on custom domains, which you cannot detect from the address alone.

Proton documents plus aliases: "All mail sent to a plus alias arrives in your regular inbox." Its @pm.me page says a user can use both eric.norbert@protonmail.com and eric.norbert@pm.me, but activation of @pm.me is limited to paid plans, so it is a weak vector for trial abuse and we leave it alone.

Apple: two kinds of relay address, which behave differently

Hide My Email, part of iCloud+, generates "unique, random email addresses" that forward to the user's real inbox. They cannot be normalised; each one is genuinely a different string with no shared component.

Sign in with Apple relay addresses are different. Apple's developer documentation says they end in @private.icloud.com, @privaterelay.appleid.com or @icloud.com, and that they are "the same for a user across all apps written by a single development team, and different for the same user across apps written by different development teams." So a user signing in with Apple to your app gets the same relay address every time. That makes it a stable identity, not an abuse vector, and blocking it would mostly lock out privacy-conscious customers.

The code: an identity key, not a rewritten address

Keep the typed address for sending, and store a second column containing the normalised key. Grant trials by key.

This JavaScript function applies only the rules in the table that we could verify. The optional mxHosts argument lets you apply Workspace and Exchange Online plus-addressing rules to custom domains, which you can only identify from their MX records. The MX lookup itself is covered in validating email in JavaScript and Node.js.

const GMAIL = new Set(["gmail.com", "googlemail.com"]);
const PLUS_TAG_DOMAINS = new Set(["gmail.com", "googlemail.com", "proton.me", "protonmail.com", "pm.me", "fastmail.com"]);

export function identityKey(email, { mxHosts = [] } = {}) {
  const at = email.lastIndexOf("@");
  if (at < 1) return null;
  let local = email.slice(0, at).trim().toLowerCase();
  let domain = email.slice(at + 1).trim().toLowerCase();

  const fastmailSub = domain.match(/^([a-z0-9-]+)\.fastmail\.com$/);
  if (fastmailSub) {
    local = fastmailSub[1];
    domain = "fastmail.com";
  }

  const plusOnMx = mxHosts.some((h) => /(^|\.)(google\.com|mail\.protection\.outlook\.com)\.?$/i.test(h));
  if (PLUS_TAG_DOMAINS.has(domain) || plusOnMx) {
    local = local.split("+")[0];
  }
  if (GMAIL.has(domain)) {
    local = local.replaceAll(".", "");
    domain = "gmail.com";
  }
  return `${local}@${domain}`;
}

The Python version behaves identically. It needs Python 3.10 or later for the type hints.

import re

GMAIL = {"gmail.com", "googlemail.com"}
PLUS_TAG_DOMAINS = {"gmail.com", "googlemail.com", "proton.me", "protonmail.com", "pm.me", "fastmail.com"}
PLUS_ON_MX = re.compile(r"(^|\.)(google\.com|mail\.protection\.outlook\.com)\.?$", re.I)
FASTMAIL_SUBDOMAIN = re.compile(r"^([a-z0-9-]+)\.fastmail\.com$")


def identity_key(email: str, mx_hosts: list[str] | None = None) -> str | None:
    local, sep, domain = email.strip().rpartition("@")
    if not sep or not local:
        return None
    local, domain = local.lower(), domain.lower()

    if match := FASTMAIL_SUBDOMAIN.match(domain):
        local, domain = match.group(1), "fastmail.com"

    if domain in PLUS_TAG_DOMAINS or any(PLUS_ON_MX.search(h) for h in mx_hosts or []):
        local = local.split("+", 1)[0]
    if domain in GMAIL:
        local, domain = local.replace(".", ""), "gmail.com"
    return f"{local}@{domain}"

We ran both against the same inputs with Node 22 and Python 3.14. The outputs matched:

Input	MX hosts passed	Identity key
J.Ane.Doe+trial3@Gmail.com	none	janedoe@gmail.com
janedoe@googlemail.com	none	janedoe@gmail.com
jane.doe+x@proton.me	none	jane.doe@proton.me (dots kept)
shopping@jane.fastmail.com	none	jane@fastmail.com
jane.doe+x@company.com	none	jane.doe+x@company.com (unchanged)
jane.doe+x@company.com	aspmx.l.google.com	jane.doe@company.com (tag stripped, dots kept)
sean+news@contoso.com	contoso-com.mail.protection.outlook.com	sean@contoso.com
jane+x@outlook.com	outlook-com.olc.protection.outlook.com	jane+x@outlook.com (unchanged, not confirmed)
jane-promo@yahoo.com	none	jane-promo@yahoo.com (unchanged)
not-an-email	none	null / None

Four decisions in that code are deliberate:

1. Dots are removed only after the domain is confirmed to be gmail.com or googlemail.com. Never because the MX is Google's.
2. The consumer Outlook.com MX does not match the Exchange Online pattern. outlook-com.olc.protection.outlook.com is not under mail.protection.outlook.com, so consumer Outlook addresses are left alone until there is a Microsoft source to rely on.
3. The whole key is lower-cased. RFC 5321 says local parts are case-sensitive, so this is our choice for a comparison key, not a claim about any provider. It is one more reason not to send to the key.
4. Unknown domains pass through unchanged. A key that under-merges lets a determined person through; a key that over-merges denies a trial to a different, legitimate person. The second is worse.

Using the key without punishing real users

Use the key to decide trial eligibility, not whether someone may create an account.

A workable pattern:

• Store email (as typed) and email_key (from the function) on the user record. Index email_key, but do not make it unique.
• When a trial starts, check whether any account with the same email_key has had one. If it has, create the account but start it on the paid or free plan, with a message saying a trial has already been used for that address.
• Keep the message neutral. Someone signing up with jane+work@gmail.com after a personal trial on jane@gmail.com is usually not a fraudster.

The key will not catch everything. Yahoo disposable addresses, Hide My Email addresses, catch-all custom domains and plain new Gmail accounts all produce genuinely different keys. For those, the key is one signal alongside the others in stopping fake signups: payment method fingerprints, device signals and rate limits. Throwaway inboxes from temporary-mail services are a separate problem, covered in blocking disposable emails at signup.

The practical takeaway

• Store the address as typed. Compare by a separate identity key.
• Strip dots only for gmail.com and googlemail.com. Google's own help page says dots matter on Workspace domains.
• Strip +tags for Gmail, Proton and Fastmail, and for custom domains whose MX shows Google Workspace or Exchange Online.
• Leave Yahoo hyphens, consumer Outlook.com, and anything you cannot source unchanged.
• Do not block Apple relay addresses. Sign in with Apple gives each user one stable address per development team.
• Python users can pair this with the checks in validating email in Python.