Prevent duplicate Gmail alias signups with verified ownership

Prevent duplicate Gmail alias signups by matching dots and plus tags, verifying ownership, and atomically claiming one mailbox key. Keep delivery addresses intact.

To prevent duplicate Gmail signups, compare supported dot and plus-address variants using a separate mailbox key. Claim that key only after email verification, and keep the submitted address for delivery. Matching aliases helps enforce a mailbox policy; it does not prove ownership.

For a product that gives each account a free allowance, comparing only the submitted strings can turn one mailbox into several trials. These synthetic Gmail addresses reach the same mailbox:

alex.river@gmail.com
alexriver@gmail.com
alex.river+trial@gmail.com

Google documents dot handling for consumer Gmail and plus-address variations. These are useful features for organizing mail. An alias alone is not evidence of abuse.

If an unverified signup can reserve the mailbox key, it can stop the real owner from signing up. The order of matching, verification, and ownership matters as much as the normalization rule.

Normalize Gmail aliases without changing the delivery address

Store the submitted address for verification and delivery. Derive a separate value for matching:

delivery address: alex.river+trial@gmail.com
comparison key:   alexriver@gmail.com

The key is a representation our application uses to compare supported aliases. It is not a replacement destination for mail, a user ID, or proof of ownership.

Keep the rule narrow. Consumer Gmail ignores dots, but Google explicitly says dots matter for work and school addresses on custom domains. Removing dots from every address can combine unrelated mailboxes. The same caution applies to stripping plus tags or lowercasing every local part without knowing the provider's rules.

Use a parser and a reviewed provider policy rather than a regular expression that rewrites every address. Preserve the original even when the policy removes characters from the key. If the policy changes later, the original lets you recompute the proposed keys and inspect collisions before changing enforcement.

Verify the address before claiming the mailbox key

Suppose someone submits alex.river@gmail.com but cannot read that inbox. If the application immediately reserves alexriver@gmail.com, a later signup by the actual mailbox owner may be rejected as a duplicate.

Email normalization did its job. The mistake was granting ownership before verification.

A safer sequence is:

1. Validate and screen the submitted address on the server.
2. Let the authentication provider verify control of that exact address.
3. Read the verified address and stable user ID from trusted provider state.
4. Atomically claim the comparison key for that user within the application tenant.
5. Grant protected access or trial benefits only after the claim succeeds.

A pending authentication record may still exist before step four. It must not receive the benefits reserved for verified owners. A boolean sent by the browser, such as emailVerified: true, is not verification evidence.

The verification result also has to belong to the current address and user. If the address changes while verification is in progress, a result for the old address must not authorize the new one.

Use an atomic claim to stop concurrent duplicate signups

Checking whether a key exists and then inserting it is not enough. Two verification callbacks can both see no owner before either writes.

The ownership store needs an atomic operation that permits one owner for a tenant and key. A relational database can enforce that invariant with a unique constraint on the pair. PostgreSQL's unique constraints support this kind of multi-column uniqueness.

If both Gmail variants arrive together, only one user can acquire the claim. A repeated callback for that same user should be safe to process again. A different user must receive an ownership conflict, not a session for the existing account.

Keep the conflict response neutral. Do not reveal an existing account ID or automatically merge account data because two keys match. The user should go through the normal sign-in or recovery flow, where the auth provider establishes the required credentials and verification.

Tenant scope is a product decision. One mailbox may legitimately need accounts in two independent customer workspaces. A global unique key would prevent that even when the product allows it.

Enforce verified ownership beyond signup

A signup hook protects one moment. It does not automatically cover email changes, imported users, social sign-in, or sessions issued through another route.

Every protected route that depends on verified ownership must check the current user and address against the active claim. Email changes need their own verified transfer flow. Existing users need a reviewed migration before enforcement is enabled; installing a new hook does not establish ownership for old records.

This is the boundary GATES adds around an existing auth system. IronDome screens the original address, Mail Canon derives the matching key, and PostgreSQL records verified ownership within the application tenant. The auth provider continues to handle passwords, sessions, and verification. The email-matching guide documents the supported provider rules and their limits.

For disposable-email screening alone, use the IronDome check API with the original address. The API classifies disposable email; it does not create a mailbox-ownership claim or verify control of the inbox. Keep screening, matching, and ownership as separate operations.

If the actual policy is one trial per mailbox rather than one account per mailbox, enforce uniqueness on the trial entitlement instead. People may need multiple accounts without being entitled to multiple free allowances. Make the entitlement write idempotent too, so a retried callback cannot issue credits twice.

Before rollout, test two aliases verifying concurrently, an unverified signup followed by the real owner's signup, a replayed verification callback, and an address change during verification. Those cases tell you whether the control follows verified ownership rather than whoever submitted an address first.

This still does not enforce one account per person. Someone can own several independent mailboxes, and several people can share one inbox. The rule is about the mailbox equivalences your application can establish, not the identity of every person using it.