Confirm that your mail service accepts the tagged address, then preserve and test that exact address throughout the website account lifecycle; do not strip tags as a universal identity rule.
A plus email address is useful only if the whole account journey can keep using it. Receiving a welcome message is a promising first result, but it does not establish that next month’s login, password reset or support request will recognize the same identity.
Consider a fictional illustrator registering a portfolio tool with studio+portfolio@example.com. Mail reaches the intended inbox, but the tool later displays studio@example.com in account settings. The owner now needs to discover whether that is merely a display choice or whether the application has changed the identifier it actually uses. Creating another account immediately could make the situation harder to untangle.
Check the mailbox behavior before blaming the website
RFC 5233 describes subaddressing as adding detail to an address’s local part; a plus sign is one common separator. The detail rules belong to the receiving mail system. The document does not promise that every provider treats a tagged address as the untagged mailbox.
Ask your mail administrator or read the current documentation for your service. Establish whether the exact tagged address can receive external messages, whether a setting controls that behavior, and whether replies can use that address. Do this with a mailbox you control and a harmless message, not by repeatedly asking a real customer to retry.
A provider-specific example illustrates why the distinction matters. Exchange Online’s documentation describes plus addresses as receive-only and allows organizations to disable the feature. It first attempts to resolve the full address, then tries without the tag if needed. Do not project that sequence onto another service.
Separate the website’s five compatibility decisions
| Stage | What the owner needs to establish | A useful failure clue |
|---|---|---|
| Entry | The intended tagged address is accepted without silent editing | The form rejects the plus sign before a request is sent |
| Storage | Account settings preserve the intended identity | The saved address differs from the submitted address |
| Verification | The expected mailbox receives a link for the right account | The message arrives but opens a different pending account |
| Login | The documented account identifier works after signing out | Only the untagged form is recognized unexpectedly |
| Recovery | The same owner can regain access through the saved address | The reset request targets an address the owner did not choose |
Use the table as a record of observed behavior, not as permission to bypass restrictions. A site may have an explicit account policy that disallows tagged addresses. That is a different result from a broken form which claims to accept ordinary email addresses but changes one without explanation. In either case, the owner needs a dependable recovery address before putting important work into the account.
Find the layer that rejects or changes the value
MDN’s email-input guidance distinguishes syntactic validation from proving that an address exists or belongs to a person. A browser check is also not a substitute for server validation. Passing the visible field therefore answers only one small part of the account question.
For your own website, reproduce the issue in a controlled environment using an authorized test address. Compare the field value, the request your application sends, the value the server accepts and the resulting account settings. An extra validation pattern, an application rule or an integration mapping can each change the outcome. Fix the earliest demonstrated mismatch instead of broadening unrelated permissions.
If the address changes while traveling through a request, have the developer compare the value on each side of the demonstrated boundary. Record the submitted and interpreted values privately. Do not paste request bodies, verification links or account details into a public forum. The aim is to preserve the chosen value through the supported interface, not to disable all validation.
Do not turn mailbox delivery into a universal identity rule
The illustrator might deliberately want separate accounts for a portfolio and a training course, even when both deliver to one inbox. Another service might have a documented rule that one mailbox owner gets one account. Neither decision should be guessed by deleting everything after a plus sign for every email domain.
If you operate the website, define how account identifiers, uniqueness and address changes work. Review an existing account collision before changing normalization. A hurried migration that collapses two stored addresses can mix records, entitlements or recovery routes. Use an established, authenticated address-change procedure and preserve a rollback plan rather than rewriting production identities in bulk.
For a reader using someone else’s service, keep the exact registered address in a password manager alongside the account. The same care applies to the different compatibility issues covered in our internationalized email and domain guide. Do not assume that a visually similar spelling represents the same stored account.
Review verification, login and recovery as one journey
Before a consequential signup, check the service’s account policy and confirm that you control the mailbox. After registration, inspect the saved address, complete verification and sign out. Sign in again using the documented identifier. If the service supports a safe recovery rehearsal, check that its instructions target the intended address and account; never publish or forward the private recovery link.
If a verification message arrives but its action fails, separate that problem from plus-address acceptance. Our password reset and magic-link guide follows the request, email and final action. Repeating signup with several spellings is a poor substitute for finding which account is already pending.
For the illustrator, a useful support report says: the exact tagged address was accepted, account settings display another value, and the documented login succeeds or fails in a stated way. Ask support which identifier and recovery route are actually recorded. Share private account details only through the service’s authenticated support channel.
Keep a usable exit path when compatibility is incomplete
- Record the original registered address and any account reference before changing it.
- If access still works, use the supported account settings to move to another address you control when necessary.
- Confirm the new address and its recovery route before abandoning the old one.
- Resolve duplicate or pending accounts with the service rather than claiming they are the same person from an address pattern.
- Keep mailbox administrator recovery separate from recovery of each website account.
The business email administrator recovery guide covers the underlying mailbox account. A reliable tagged address should remain understandable at every stage: who receives the message, which website identity it belongs to, and how that owner can return later. If you cannot establish those three answers, use a supported address while the compatibility issue is resolved.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- RFC 5233: Sieve subaddress extensionChecked Subaddressing separates user and detail components according to the receiving mail system.
Limits: Does not require every mailbox or website to support plus addresses. - MDN: email input validationChecked Browser email-format checks differ from mailbox existence and ownership verification.
Limits: HTML validation does not define a website database or account identity policy. - Microsoft Learn: plus addressing in Exchange OnlineChecked A concrete receive-only implementation, including organizational controls.
Limits: Exchange behavior is an example, not a universal rule for other mail services.