user+anything@gmail.com is one mailbox wearing labels. How subaddressing works, why blocking it backfires, and what plus addresses reveal about your data flows.
Sign up somewhere as user+shopname@gmail.com and the mail still arrives at user@gmail.com, carrying a label the owner chose at signup. That is subaddressing: a convention, standardized in RFC 5233 and implemented by Gmail, Fastmail, Outlook, iCloud, and most modern providers, that lets one mailbox present unlimited task-specific faces. For recipients it is filtering and leak detection. For senders it is a small protocol detail with outsized consequences in validation code, deduplication logic, and what your complaint data can teach you.
How it works, and how it varies
The receiving server splits the local part at a separator character, routes on the base, and exposes the tag to filtering rules. Gmail and most providers use +; Fastmail additionally supports subdomain-style aliases; Yahoo uses a dash-based scheme configured per account; some self-hosted systems use - or make the separator configurable. Two sender-relevant consequences follow. First, only the receiving domain knows its own rules: you cannot reliably compute the base address from outside, because a plus sign in a local part is also simply legal in a plain address. Second, Gmail adds a separate wrinkle, dot-insensitivity, where u.ser@gmail.com equals user@gmail.com, which is a different mechanism with similar deduplication implications.
Why recipients use them, and why that is fine
The two honest uses are filtering (route +newsletters to a folder) and attribution: give every service a unique tag, and when spam arrives addressed to user+yourbrand, the owner knows exactly whose database leaked, was sold, or was breached. That second use makes tagged subscribers a distributed audit of your data practices, and senders with clean practices have nothing to fear from it. The occasionally cited third use, minting endless variants to re-claim single-use trials, is real and marginal, and the defense is verifying at the account layer (payment identity, device, phone) rather than trying to out-parse mailbox providers at their own address semantics.
The sender policy that follows
Handling tagged addresses correctly
- 1
Accept them everywhere
Forms, APIs, imports, and support tooling all treat + as the ordinary character it is. Test your whole intake path with a tagged address, including the confirmation mail round-trip.
- 2
Store what the user gave you
The tagged address is the address. Never silently strip tags to a computed base: it breaks the user's filters, defeats their leak tracing, and edits data they deliberately chose.
- 3
Deduplicate with judgment, not normalization
For marketing frequency capping, flagging probable same-mailbox variants (same base at a subaddressing provider) is reasonable analytics. For consent, suppression, and account identity, each distinct string stands alone: suppressing user+news must not suppress user+receipts, because those are different consents.
- 4
Mine the tags you can see
Aggregate complaint and bounce data by tag pattern where visible. Complaints clustering on addresses tagged with a partner's name is the partner-source audit arriving by itself, and it deserves the acquisition-source investigation from our complaints playbook.
- 5
Never exploit the structure
Mailing the computed base address of someone who only ever gave you a tagged variant is mailing an address you were not given. It is the fastest possible way to convert a privacy-conscious subscriber into a complainer with evidence.
Edge cases worth knowing
VERP collisions: bounce systems that build envelope addresses from recipient addresses must encode the + properly or generate broken return paths; test your bounce round-trip with a tagged recipient. Deliverability is unaffected at the receiving end, since the tag is stripped before mailbox routing, and reputation systems key on your identity rather than recipient address shapes. And the analytics caveat runs both ways: a mailbox owner with twelve tagged subscriptions to your brand is one reader in engagement terms, but twelve consents in compliance terms, and conflating those two framings is how well-meaning deduplication projects create unsubscribe violations.
Subaddressing is a small corner of the spec that works as a character test for senders: systems that handle it correctly tend to be the ones that treat addresses as user data rather than as strings to normalize, and recipients who use tags notice which kind of sender you are. Passing the test costs a regex fix and a policy sentence. Failing it costs the subscribers most likely to report you with receipts.
Frequently Asked Questions
Should we normalize Gmail dots and plus tags for duplicate detection?
Do plus addresses hurt deliverability or engagement metrics?
Someone signed up with our competitor's name as their tag. Meaning?
Can we detect which providers support subaddressing?
Key Takeaways
- Subaddressing routes user+tag to the base mailbox with a user-chosen label, standardized and widely supported
- Rejecting + in forms is a validation bug that filters out exactly the privacy-conscious users worth keeping
- Store the literal address given; stripping tags breaks filters, defeats leak tracing, and edits user data
- Deduplication has two layers: probable-mailbox analytics may group variants, consent and suppression never do
- Complaints clustering on a partner-tagged pattern is your acquisition audit delivering itself; read it
Related articles
Half-Year Review: Email in the AI Inbox Era
Six months that rearranged the reading layer: Gemini in Gmail, Microsoft rejecting outright, DMARC finally a standard. What the first half of 2026 means for senders.
Deliverability Postmortems: Learning From Incidents
The incident is over, placement recovered, and the pressure to move on is enormous. The blameless postmortem practice that converts each incident into prevention.
Writing for AI Readers: Structure When Gemini Summarizes You
Five months of AI Overviews data shows opens up and clicks down: recipients read summaries. How to structure email so the model's version still does your job.