Email plus addressing: preserve tags without making assumptions
Plus addressing adds a tag to an email local part, like alex+receipts@example.com. It is often used to organize incoming mail or distinguish signups. Whether it is supported depends on the receiving system, so it should not be treated as universally invalid or universally interchangeable.
Open the relevant free tool →Keep the tag until the provider rules are known
Accept supported syntax
A plus sign is not inherently a formatting mistake. If your form strips it or rejects it without a reason, legitimate users may be unable to use their preferred address. Keep your supported syntax policy explicit and test tagged addresses. A syntax pass still does not prove that the destination provider accepts the tag.
Do not silently remove the tag
The user may rely on the tag for sorting or tracking where an address was supplied. Rewriting it changes the identifier they entered. Preserve the original address for correspondence and audit. If you maintain a provider-specific normalised identifier for duplicate analysis, keep it separate from the actual destination rather than overwriting the contact field.
Provider rules differ
Exchange Online has documented plus-addressing behaviour and configuration. Other receiving systems can apply different rules. Custom-domain mail should not automatically inherit consumer Gmail assumptions. When you control the recipient domain, inspect its configuration. When you do not, avoid claiming equivalence unless the provider’s behaviour is known and relevant to your use case.
Think carefully about account identity
If tagged variants can reach one inbox, a product may want to detect duplicate registrations. That is an account-policy decision, not a reason to destructively edit all email data. Explain the rule, handle false positives and keep ownership confirmation independent. Do not apply a blanket rule that collapses different users at providers with different local-part semantics.
Use tags in list cleanup
For an existing list, distinguish exact duplicates from possible related aliases. Exact deduplication can be automatic under a documented normalization policy. Alias merging needs more context. Keep consent and suppression records linked correctly: a new tag should not automatically bypass an existing opt-out, but an overbroad merge should not erase a legitimate separate contact either.
Worked example
alex+receipts@example.com and alex+events@example.com are illustrative tagged addresses. Whether either delivers, or whether both reach one inbox, depends on example.com’s mail system.