A customer enters jane.doe+receipts@gmail.com into your signup form. Your validator rejects the plus sign. They remove it, finish signing up, and now your messages miss the filter they created for receipts.
Another implementation accepts the address but removes the tag before saving it. The form works, yet the customer’s preference is still lost. If the same cleanup rule also drives account matching, it can have consequences beyond email delivery.
For teams building signup flows, a useful starting policy is to accept supported address formats, preserve the delivery address, and keep duplicate detection separate from account access. Aliases need provider context before they can tell you anything reliable about identity.
Why people use plus addressing
Plus addressing adds a tag before the @, as in jane+receipts@example.com. Where the mail provider supports it, the tag lets someone organize incoming messages without creating another mailbox. Google documents this as a way to filter newsletters, customer questions, and other mail into the same inbox. See Google’s guide to address variations.
That gives a signup form a straightforward reason to accept a plus sign: the person may be using a supported feature of their inbox. Its presence alone does not establish that an address is temporary or that the signup is abusive.
Plus tags are also only one form of address variation. Separately configured aliases and forwarding addresses can look unrelated to the mailbox receiving their messages. An address string cannot reveal every relationship between inboxes.
Apply alias rules only where they are documented
Mail providers do not all interpret addresses in the same way. Three distinctions matter when designing normalization rules.
Dots depend on the domain. For personal @gmail.com accounts, Google says dotted versions of the same username reach the same inbox. Its documentation explicitly distinguishes work, school, and organizational addresses, where dots change the address. A company using Gmail does not automatically inherit the personal Gmail rule. See Google’s explanation of dotted addresses.
Plus handling depends on configuration. Exchange Online enables plus addressing by default, but administrators can turn it off. Exchange also tries to resolve the full address before trying it without the tag. A blanket instruction to remove everything after + loses that distinction. See Microsoft’s plus addressing documentation.
Case has a standards caveat. The SMTP specification makes domains case insensitive while requiring preservation of case in the local part, the portion before @. It discourages providers from relying on local-part case differences, but that is not a universal guarantee that lowercasing preserves the destination. See RFC 5321, section 2.4.
The practical consequence is to make each comparison rule explicit about the domains it covers. If you have no documented rule for a domain, preserve the distinction between its addresses.
Store the delivery address separately from comparison data
Consider keeping these pieces of information separate in your application:
| Information | Purpose |
|---|---|
| Submitted address | Preserve what the person entered before a library or API transforms it. |
| Delivery address | Send to the address the person chose and confirmed, including its tag. |
| Comparison value | Find possible duplicates using rules whose provider scope you have checked. |
| Confirmation state | Record whether the person completed your confirmation flow for that address. |
These are proposed application fields, not a required UnwrapEmail storage schema. Their value is in separating decisions: a comparison value can help identify records for review without silently changing where messages go.
Send confirmation to the submitted destination after syntax validation and any clearly defined input cleanup. Avoid removing dots or tags from that destination. When a customer changes their delivery address, confirm the new destination through your account’s email-change flow.
Treat duplicate matches as a reason to check
Two address variants reaching one inbox can be relevant to a trial or referral policy. They do not settle whether two product accounts should be combined. Someone may intentionally maintain separate projects, and a shared mailbox may serve several people.
For signup, consider allowing an otherwise acceptable tagged address through the normal confirmation process. For a repeated trial benefit, evaluate a possible duplicate alongside your eligibility rules and account history. For account linking, require an explicit authenticated flow that proves control of the accounts involved.
Do not let a normalized match alone authorize a login, merge customer records, or move workspace permissions. Those actions need their own identity checks. Our guide to decisions after email verification explains how to attach different actions to different signals.
Read UnwrapEmail alias signals in context
For a Gmail input such as jane.doe+receipts@gmail.com, the relevant UnwrapEmail fields can look like this. This is an excerpt of the validation response:
{
"inbound": "jane.doe+receipts@gmail.com",
"normalized": "janedoe@gmail.com",
"validations": {
"has_label": true
},
"metadata": {
"username": {
"label": "receipts"
}
}
}The label describes a detected address tag. It does not prove abuse, ownership, or permission to receive marketing messages. Label extraction covers supported domains; has_label: false is not proof that an address has no alias or forwarding relationship.
Keep the original input in your application if you need an exact record: UnwrapEmail lowercases its input during validation, so inbound is not an untouched copy. Treat normalized as comparison data to evaluate against your domain rules, rather than automatically replacing a delivery address or account identifier.
Check the full signup flow
Before changing your alias policy, try a small set of addresses you control through signup, confirmation, login, and recovery. Include a tagged address on a supported provider, personal Gmail dot variants, and a custom-domain address with meaningful punctuation.
Check that the form accepts the intended formats, confirmation reaches the chosen destination, and a possible duplicate cannot inherit another account’s access. You can inspect UnwrapEmail’s response in the dashboard’s Playground → Email Verification using the first request guide. Then decide which signals should affect signup and which should only prompt further review.