Append a plus sign (+) or insert dots into any Gmail address, and Google delivers it straight to the original inbox:

primary: myemail@gmail.com
aliases: myemail+testing@gmail.com
         myemail+newsletter@gmail.com
         m.y.e.m.a.i.l@gmail.com

To Google, all of these belong to one mailbox. But to many web applications, each string looks like a brand-new user.

Is this a clever productivity lifehack or a security blindspot? The short answer: it is a standard mail routing feature that becomes a vulnerability when systems treat raw email strings as unique human identities.

---

1. The Core Mechanism

1. Subaddressing (RFC 5233): Everything between the + character and the @ symbol is an optional tag meant for client-side sorting and filtering.
2. Dot-Insensitivity: Google ignores periods in the username portion entirely (jasur.haydarov == jasurhaydarov). A 10-character username yields over 500 dot variations, all routing to the same inbox.

---

2. The Feature: Why Users Love It

• Breach Tracking: Sign up for an untrusted site with you+companyname@gmail.com. If you ever get spam sent to that specific alias, you know immediately that their database was breached or sold.
• Instant QA & Multi-Role Testing: Test admin, manager, and viewer roles from a single browser tab without registering dozens of test inboxes.
• Inbox Triage: Automatically route, label, or forward incoming messages via native Gmail filters using the tag.

---

3. The Problem: Where Backends Break Down

When a backend checks uniqueness with a simple equality check:

SELECT id FROM users WHERE email = 'user+trial2@gmail.com';

Because user+trial2@gmail.com != user@gmail.com, naive applications treat them as separate accounts. This enables:

• Trial & Credit Farming (Sybil Abuse): Abusers register dozens or hundreds of accounts (user+1@..., user+2@...) to repeatedly claim free-tier GPU credits, signup promo codes, or welcome discounts.
• Referral Gaming: Self-referring alias accounts to illicitly collect referral rewards.
• Stacking with Temp Mails & Browser Profiles: Combining aliases with disposable email services (like temp-mail.org) and incognito/multi-profile browser sessions easily sidesteps basic cookie and IP blocks.

---

4. The Solution: Canonical Normalization

Never reject the + character—valid RFC addresses use it, and power users rely on it. Instead, separate message delivery from identity verification.

The Normalization Logic

1. Lowercase and trim the address.
2. For Gmail / Google domains, remove all dots from the local-part.
3. Strip everything after + in the local-part.

export function normalizeEmail(email: string): { canonical: string; display: string } {
  const trimmed = email.trim().toLowerCase();
  const [local, domain] = trimmed.split('@');
  if (!local || !domain) throw new Error('Invalid email');

  let cleanLocal = local.split('+')[0];

  if (domain === 'gmail.com' || domain === 'googlemail.com') {
    cleanLocal = cleanLocal.replace(/\./g, '');
  }

  return {
    canonical: `${cleanLocal}@${domain === 'googlemail.com' ? 'gmail.com' : domain}`,
    display: trimmed,
  };
}

Database Strategy: Two Columns, One Unique Key

Store the original address so outgoing emails keep the user’s alias tag, but enforce uniqueness on the canonical version:

CREATE TABLE users (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  display_email   VARCHAR(255) NOT NULL, -- user+tag@gmail.com (for outbound delivery)
  canonical_email VARCHAR(255) NOT NULL, -- user@gmail.com (for identity & uniqueness)
  CONSTRAINT unique_canonical_email UNIQUE (canonical_email)
);

If you also need protection against throwaway mail, check incoming domains against an open-source disposable email blocklist (disposable-email-domains).

---

Summary

• For users: An indispensable tool for testing, privacy tracking, and inbox organization.
• For engineers: A reminder that email addresses are communication channels, not identity keys.

Respect the user’s alias for outgoing delivery, but bind authentication, trials, and quotas to the normalized canonical address.