Mar 31, 2025·7 min
Plus addressing in email: accept +tags and dedupe safely
Handle plus addressing in signups without blocking real users. Learn safe normalization for deduping, storage rules, and validation checks.
Handle plus addressing in signups without blocking real users. Learn safe normalization for deduping, storage rules, and validation checks.
Yes, many real users rely on plus addressing like [email protected], and many mail providers deliver it to the same inbox as [email protected]. Treat it as a normal formatting choice, not a red flag.
People use tags to filter mail into folders, track where an address was used, and keep different signups separated. Blocking + often rejects careful, legitimate customers.
The safest default is to store and display the email exactly as the user typed it, and send mail to that exact string. Changing it can break inbox filters, confuse users, and create support problems later.
Don’t dedupe by stripping +tag in your main email field. If you need deduping, create a separate internal “comparison key” and keep the original address untouched for delivery and display.
Require the exact email used at signup as the primary login identifier. If someone enters a different variation that only matches via a normalized key, prompt them to verify ownership rather than silently logging them into an account.
Normalize conservatively: trim surrounding spaces, reject control characters, and lowercase the domain. Only apply local-part rules like stripping +tag for domains you explicitly allowlist and understand, and keep that logic in a separate dedupe key.
A too-strict pattern that only allows letters, numbers, and dots before @ is a common cause. Use RFC-aware syntax validation and avoid homemade regex rules that treat + as invalid.
No, support depends on the receiving domain’s configuration, not just the provider brand. Assume it may work, validate deliverability signals, and avoid hardcoding rules like “+ always works” or “+ never works.”
A +tag usually indicates a normal mailbox, but it can be used to create many “unique-looking” addresses for the same inbox. Address that with product rules and behavior checks (verification, rate limits, risk scoring), not by banning +.
Validate for reachability and risk: syntax, domain checks, MX records, and disposable provider detection, while still accepting tagged addresses. Keep validation results (status, reason, timestamp) separate from the stored email string so you don’t rewrite what the user entered.
Plenty of real people use emails like [email protected]. The +tag part is a tag (also called a subaddress). Many providers deliver it to the same inbox as [email protected], but the tag lets someone label where the address was used.
People use tags for practical reasons: filtering (rules that file messages into folders), tracking (spotting which site leaked or sold an address), and keeping signups separate (so each account gets a distinct-looking email). It’s especially common with Gmail and Fastmail users.
Problems start when a signup form treats + as invalid or suspicious. That blocks careful, legitimate customers. Another common mistake is stripping the tag and storing only the base address. That can collapse multiple signups into one account and cause confusing login and recovery issues later.
Common failure modes:
+ emails even though they can receive mail.name+billing@... and name+personal@... into one user.Treat plus addressing as a formatting choice, not proof of fraud. Accept addresses that can receive email, and only dedupe when it’s truly safe. The simplest rule that prevents most pain: keep the original email exactly as the user entered it, and (if you need one) create a separate matching key used only for comparison.
If you run email validation (for example, via a provider like Verimail), validation should focus on deliverability and risk signals, not punishing +tags that many legitimate users rely on.
Plus addressing is a way to add a tag to an email without creating a new mailbox. The usual pattern is [email protected], where the part after + helps the user label where the address was used.
An email address has two main parts: the local part and the domain. In [email protected], name+tag is the local part, and example.com is the domain.
Three ideas often get mixed up:
+.sales@ and hello@), managed by the provider or domain owner.What counts as “the same inbox” depends on the receiving provider and domain configuration. Technically, [email protected] and [email protected] are different strings. Some providers deliver both to the same mailbox, but not all do, and behavior can vary by domain.
That’s why the safest default is to treat the full address the user typed as meaningful. If someone signs up with [email protected], they may expect future messages to keep landing in the filtered folder they set up.
Example: a customer uses [email protected] for newsletters and [email protected] for invoices. If your app removes +news and +billing, you can merge two separate intents into one account and create confusion (and support tickets) later.
Plus addressing is common, but it isn’t universal. Many major inboxes accept addresses like [email protected] and deliver them to the same mailbox as [email protected]. Others treat the + part differently, or don’t support it.
One detail matters more than the brand name: the rule is set by the receiving domain. Even within one company, different domains can have different mail routing settings. Hardcoding “+ always works” or “+ never works” eventually blocks real users.
Some domains support +tags only for certain mailboxes. Some allow different separators. Some setups forward mail through systems that strip or rewrite parts of the local address. Treat subaddressing as a “maybe” feature unless you can verify it.
What not to assume across all domains:
jane.doe vs janedoe) unless you know the domain behaves that way.+tags for delivery decisions (sending email to the user).A safe default is straightforward: accept the email the user typed, validate it, and keep it exactly as entered for messaging. If you need deduping, store a second “normalized for dedupe” value separately.
If someone signs up as [email protected] because they want to filter onboarding emails, rejecting it loses a real customer. Overwriting it with [email protected] can be just as bad, because you’re no longer sending to the address they expect.
A practical approach is to accept the address, then validate syntax and domain setup (including MX records), and finally apply disposable and risk checks. An email validation API such as Verimail can confirm the address is well-formed and that the domain is set up to receive mail, while you still keep the original address untouched for delivery.
Store what the user typed, and send to that exact address. People use tags for real reasons (filtering receipts, separating work and personal signups), and rewriting the address can break delivery or make support harder when a user says, “I signed up with [email protected].”
At the same time, many products want a second value that helps spot duplicates and keep accounts tidy. That’s where normalization belongs: in a separate internal key, not in the email you deliver to.
A practical data model keeps two fields with different jobs:
Keep verification information separate from both. Validation isn’t part of the address itself. It’s a property of the address at a point in time. Store things like status (valid, risky, invalid), a reason (for example, domain missing MX), and a timestamp.
Normalization should be conservative. Lowercasing the domain is usually safe. Lowercasing the local part is often safe in practice, but be consistent and avoid surprises. Most importantly, don’t remove +tag unless it’s only for an internal key and only where you’re confident it won’t merge different people.
Concrete example: store [email protected] as the original email, but keep a key like [email protected] for matching. Messages still go where the user expects, while your system can spot potential duplicates without rewriting the deliver-to address.
Accept real addresses (including plus addressing) while still spotting duplicates by creating a separate dedupe key, not by rewriting what the user typed.
A practical approach:
Trim and sanitize input. Remove leading and trailing spaces. Reject control characters (tabs, newlines, nulls) that can hide a different address or break logs and emails.
Run basic syntax checks, but don’t ban +. A valid local part can include + and other characters. Focus on obvious issues like missing @, empty parts, or illegal whitespace.
Normalize the domain carefully. Lowercase the domain and normalize it consistently. If you support internationalized domains, convert them using a standard process so exämple.com and its ASCII form map to the same domain.
Apply local-part rules only when you control the risk. Don’t remove +tag globally. If you want to dedupe [email protected] with [email protected], do it only for domains you explicitly allowlist and can verify behave that way.
Create a stable dedupe key, keep the original untouched. Store both values: the original for sending and display, and the normalized key for matching.
Example: if someone signs up as [email protected], store [email protected] as the contact email. Build a dedupe key like [email protected] only if example.com is on an allowlist for stripping +tags. Otherwise, keep the key closer to the original, like [email protected].
If you use an email validation API like Verimail, validate first, then normalize. That order helps you avoid “fixing” a bad address into something that looks valid but still won’t deliver.
Treat the email a person types as their identity label, not something you can freely rewrite. With plus addressing, two strings can route to the same inbox, but they’re not always the same “account” from the user’s point of view.
At signup, accept +tags and show the address back exactly as entered (including the +part). That reassures people you didn’t “fix” their email.
For login, a simple rule prevents surprises: let users sign in with the exact email they used when they created the account. If someone tries a different variation (like removing the tag) and you only find a match via a normalized key, don’t silently log them in. Ask them to confirm ownership, for example by signing in the usual way or completing an email verification step.
Merging should require proof, not just “these normalize to the same string.” Common safe options:
Example: Alex signs up as [email protected] for a newsletter trial. Months later, a coworker types [email protected] on a shared device. Auto-merging based only on normalization can hand over access to the wrong person.
Decide upfront whether +tags should count as unique identities. Some teams treat each invited address as distinct for tracking, but still prevent multiple accounts unless the invite is claimed through a confirmed email.
If you validate emails during signup, keep the boundary clear: validation helps with deliverability and risk, while identity decisions (login, merge, invites) should follow explicit product rules.
The fastest way to lose good signups is to treat a valid address as “weird.” Plus addressing is normal for people who filter mail, track where they shared an email, or keep signups separate.
A common bug is an email regex that only allows letters, numbers, dots, and hyphens before the @. That blocks [email protected] even though it’s valid for many providers. If your validation rules were written years ago, this is often the culprit.
Another mistake is stripping the +tag and then using the stripped version for delivery. If the user typed [email protected], you should store and send to exactly what they entered. Stripping can also break inbox rules that rely on the tag.
Dot handling is especially risky. Some services ignore dots in the local part (sam.smith@... vs samsmith@...), but many do not. Assuming dot-insensitivity everywhere can merge two different inboxes.
A subtler issue is inconsistent rules across systems. If your signup flow accepts [email protected], but your billing tool strips the tag while your marketing tool keeps it, the same person can show up as multiple contacts or get merged incorrectly.
Quick “don’t do this” checks:
+ in the local part.Normalization isn’t verification. Use normalization only for careful deduping. Use a real validator (for example, Verimail) to catch typos, invalid domains, and disposable addresses without blocking legitimate +tag users.
A +tag is usually a sign of a careful user, not an attacker. People use tags to filter mail or to see which site leaked their address.
Attackers can still abuse aliases to create many accounts, because some providers treat [email protected] as the same inbox. That can bypass “one account per email” rules if your system treats every +tag as a new identity.
The fix isn’t banning +tags. That blocks real users and doesn’t stop abuse on providers that support other alias styles (dots, domain aliases, catch-alls). Decide what you’re protecting: account creation volume, promotions, or identity.
Focus friction on behavior, not formatting. For example: rate limit suspicious signup bursts, require email verification for higher-risk signups, and watch for many signups mapping to one inbox in a short window.
If you need to separate “identity” from “contact method,” don’t make email your only key. Treat the account as its own record, and treat email addresses as contact points that can be added, verified, and removed. That makes shared inboxes, role addresses, and legitimate email changes easier to support.
Disposable email detection matters more than banning +tags. A disposable inbox is designed for throwaway signups; a +tag is usually a normal mailbox. Tools like Verimail can help by catching known disposable providers, spam traps, and invalid addresses while still accepting legitimate tagged addresses.
Most real-world issues with plus addressing are self-inflicted: a too-strict regex or a dedupe rule that quietly merges accounts that should stay separate.
Start with acceptance. Your validator should allow + in the local part (before @). Avoid regex shortcuts that assume only letters, numbers, dots, and underscores. If you use a library, confirm it follows RFC rules instead of a homegrown pattern.
Next, separate delivery from deduping. Always store the original email exactly as the user typed it for display and sending. If you create a normalized key for dedupe, keep it separate and document the rules so support and engineering make the same decisions.
A short pre-ship checklist:
+ in the local part.For domain and mailbox reachability signals, validate before you lock users into steps like “verify your email to continue.” A validator can help you avoid blocking real users because of typos or dead domains.
Finally, run a simple test set: [email protected], [email protected], and [email protected]. Confirm they can sign up, log in, reset passwords, and receive messages without surprises.
A common case: a B2B app offers free trials. One admin at Acme tries the product for different clients and uses tags like [email protected], [email protected], and [email protected] to keep inbox rules tidy. That’s normal plus addressing behavior, and messages still deliver to the same mailbox.
Trouble starts when dedupe is too aggressive. If you strip everything after + and treat all of those signups as the same user, you can lock people out. The admin tries to create a second trial, but your app thinks the account already exists and blocks signup. Then password reset sends them to the first trial’s account, not the one they’re looking at.
A safer approach is to separate “delivery identity” from “account identity.” Store the original email exactly as entered. Store a normalized form only as a helper for matching, review, or analytics. Then:
[email protected], but require email confirmation before the trial is active.For support, it helps to show both fields in the user profile and logs: “Email entered” and “Normalized for dedupe.” That makes it easier to explain what happened and fix it quickly.
If you accept +tags but handle them differently across signup, login, and internal tools, you’ll keep creating duplicates and confusing users. The fastest fix is to write down your rules and apply them everywhere your email field shows up.
A simple policy works well for most teams: store the email exactly as the user typed it, and only use a separate normalized value for matching and reporting. That lets you dedupe without breaking delivery or surprising someone who relies on tags.
Rollout checklist:
If you want an implementation that focuses on reachability and risk signals (without rejecting legitimate +tags), Verimail (verimail.co) provides a single email validation API that combines syntax checks, domain and MX verification, and disposable and blocklist matching.
Once changes are live, measure outcomes to catch regressions and tune rules. Track signup rejection rate and reasons, confirmation bounce rate, duplicate-account rate by your normalized key, and support tickets mentioning duplicate accounts or failed signups. Keep a small sample of rejected addresses (redacted) and review them. If you see lots of real domains getting blocked, your validation or normalization rules are too aggressive.