Plus Addressing: Handle Email Aliases Without Merging Contacts

Plus addressing adds a detail to an email address, often after a plus sign, on mail systems that support it. An address such as alex+receipts@example.com may route according to that system's subaddressing rules. A signup form should preserve the supplied address and evaluate it as entered. It should not automatically remove the tag, reject the address as disposable, or merge it with another contact.

The practical question is how to accept useful address variations without turning an assumption about mail routing into an account or marketing decision. Keep syntax, technical verification, inbox confirmation, and contact identity separate.

Plus addressing and email aliases are related, but different

An email alias is another address configured to receive or route mail. Plus addressing is a particular way some systems encode extra detail in the local part, the portion before @. Not every alias uses a plus sign, and not every domain interprets tagged addresses the same way.

RFC 5233 describes subaddressing and notes that its encoding depends on the receiving system. That is a reason to avoid applying a familiar provider's rewriting rule to every address. The examples here use reserved example domains; they are illustrations, not real mailboxes to test.

Preserve the exact destination the person supplied

Store the submitted address as the contact destination, alongside any narrowly defined comparison value your application needs. Do not overwrite the original with a guessed base address. If a person entered alex+receipts@example.com, sending to alex@example.com changes the destination they chose.

A user may rely on the detail to sort messages or recognize the source of an email. Removing it can break that workflow even when both strings eventually reach the same inbox. Case handling is a separate issue; use the email case-sensitivity guide for normalization boundaries.

Validate the address without inventing a provider rule

1. Accept supported syntax. Check that your form and backend agree on which address forms they accept. Do not reject a plus sign solely because it looks unusual.
2. Verify the submitted address. Send the full address to the technical verification workflow rather than checking a modified base address and transferring the result.
3. Handle uncertain results explicitly. A timeout, Unknown result, or catch-all signal is not evidence that removing the tag will fix the address.
4. Use an inbox action when confirmation is needed. Associate that action with the exact address and account step being confirmed.

Technical verification and inbox confirmation answer different questions. Neither alone proves a unique human identity, permission for every future message, or guaranteed delivery. The confirmation-versus-verification guide explains the wider signup flow.

Do not merge contacts just because the base looks similar

Consider two imported records, one tagged and one untagged. Similar text is a possible review signal, not sufficient evidence to combine their purchase history, account access, permissions, or support records. A receiving domain may use routing rules your application does not know.

Keep a possible-duplicate relationship separate from a completed merge. Require the evidence appropriate to your system, preserve the source records, and make approved merges traceable. For account linking, use the application's authenticated ownership process rather than a string transformation.

Even when two destinations are known to reach the same inbox, their purposes can differ. A receipt address and a newsletter address do not automatically share the same subscription choices.

Keep exclusions attached to their actual scope

Retain opt-outs and other exclusions according to the policy and relationship they cover. Do not re-enable an excluded contact because a later import uses a different tag. Conversely, do not silently expand an address-specific instruction into an unverified rule about every possible alias.

Record the source and intended scope of the exclusion, then apply the relevant account or contact policy. Where the scope is unclear, hold the record for review. Suppression lists remain separate from technical verification results.

Test the complete path through your tools

Use addresses you control to test the form, backend, verification step, CRM export, and confirmation message. Check that the plus sign survives each transition and that the displayed destination matches the stored one. Include an unchanged address, a changed tag, and an uncertain verification outcome.

For asynchronous checks, confirm that a result for the previous address cannot overwrite the current one. Keep the full checked address and request identity with the response. This is the same association problem covered in verification race conditions, applied to an address detail that a user can edit.

Where EmailAwesome fits

EmailAwesome verification evaluates address and domain signals. Your application remains responsible for alias interpretation, account linking, permissions, and duplicate decisions. Check the address supplied, preserve its result, and let the separate identity process decide whether records should be connected.