If you are trying to personalize an email address for sign-ups, verification codes, or agent-driven workflows, you usually mean one of two things:
- “I want a unique looking address per run/customer so I can correlate emails.”
- “I want a unique inbox per run/customer so I can reliably receive the right email.”
Those are not the same, and confusing them is a common source of flaky tests, mailbox collisions in CI, and unsafe LLM integrations.
This guide compares plus tags (subaddressing like [email protected]) with inbox IDs (an inbox-first API model where you receive from a specific, isolated inbox). You will leave with a clear decision rule and a few implementation patterns that work in 2026 pipelines.
For Mailhook-specific integration semantics (endpoints, webhook verification, payload shape), use the canonical reference: Mailhook llms.txt.
What “personalize email address” means in automation
In product UX, personalization is cosmetic. In QA automation and agent workflows, “personalize” is usually doing one or more of the following:
-
Correlation: tie a message to a run, test, tenant, or user journey (example:
run_81c2). - Isolation: prevent unrelated messages from being visible to the consumer.
- Deterministic retrieval: reliably “wait for the email” without guessing which message is correct.
- Programmability: retrieve the message as data (JSON), not a human mailbox session.
Plus tags are mostly a correlation trick. Inbox IDs are an isolation and programmability primitive.
Plus tags (plus-addressing): what they are and where they break
Plus-addressing (also called subaddressing) is the pattern:
Many mailbox providers route [email protected] to the same underlying mailbox as [email protected]. Gmail documents this behavior directly (search for “plus signs” in Gmail filters): Gmail Help on plus signs.
From an email syntax perspective, + is allowed in the local-part, but plenty of apps still reject it due to incorrect validation. If you want the canonical rules, see the message format spec: RFC 5322.
What plus tags are good at
Plus tags are genuinely useful when you control the receiving mailbox and you only need lightweight correlation:
- Tagging and filtering inside one human mailbox.
- Low-concurrency automation where a single shared mailbox is acceptable.
- Debugging: the tag tells you which run generated the email.
The reliability problem: plus tags do not create inboxes
Plus tags “personalize the address” but they do not create a new inbox. That has consequences:
- No isolation: all tagged emails land in the same mailbox.
- Mailbox collisions: parallel CI runs compete to find “their” email.
- Retry ambiguity: on retries, the “latest email” may belong to a previous attempt.
- Agent safety issues: if an LLM agent can see the mailbox, it may see unrelated emails (including secrets, internal notifications, or prompt injection payloads).
You can mitigate with careful matching rules, but you are still building on a shared container.
Compatibility pitfalls you should assume in 2026
Even though plus tags are common, you should assume at least some of these will happen across products and integrations:
-
Sign-up forms reject
+(bad validators). - Normalization differences: some systems store the address with the tag, some strip it, some compare case-insensitively.
- Fraud and abuse filters: some services treat plus tags as “throwaway” behavior.
- Analytics and identity drift: if your system uses email as a unique user key, plus tags can create accidental duplicates.
If your goal is end-to-end verification in CI, these edge cases can turn “personalized address” into “non-deterministic address.”
Inbox IDs: personalization as an isolated, programmable resource
An inbox ID approach treats “inbox” as the primary resource:
- You create an inbox via API.
- The provider returns an email address plus an inbox identifier.
- You retrieve messages from that specific inbox (often with webhooks for real-time arrival and polling as a fallback).
Conceptually, the personalization is not the string after +. The personalization is the inbox handle that scopes delivery and retrieval.
This is the key shift:
- Plus tags personalize the recipient string.
- Inbox IDs personalize the message container.
Mailhook is built around this inbox-first model: you create disposable inboxes via API, receive emails as structured JSON, and can consume messages via real-time webhooks or a polling API (details in llms.txt).
Why inbox IDs are the default for CI and agents
Inbox IDs map directly to the invariants you typically need in automation:
- Isolation: inbox-per-run or inbox-per-attempt prevents collisions.
- Deterministic waiting: you wait for a message in a specific inbox, not “somewhere in the mailbox.”
- Machine-readable output: emails arrive as JSON, which is more stable than scraping HTML.
- Event-driven delivery: webhooks reduce latency and flakiness.
- Security boundaries: you can provide agents a minimized, scoped view rather than an entire mailbox.
If you want a deeper take on the “email + inbox_id” contract, see: Disposable Email With Inbox: The Deterministic Pattern.
Plus tags vs inbox IDs: decision matrix
Use this table as the quick answer.
| Requirement | Plus tags (user+tag@...) |
Inbox IDs (inbox-first API) |
|---|---|---|
| Looks like a personalized address | Yes | Yes (address can still embed correlation, but it is optional) |
| Creates a separate inbox | No | Yes |
| Parallel-safe in CI | Usually no (shared mailbox) | Yes (inbox-per-run/attempt) |
| Deterministic “wait for email” | Hard (must match within shared mailbox) | Straightforward (wait on one inbox) |
Works with broken validators that reject +
|
Sometimes no | Often yes (depends on address format and domain strategy) |
| Retrieval as structured JSON | Not inherent | Core capability in inbox APIs (Mailhook does this) |
| LLM agent safety (least privilege) | Weak (agent sees too much) | Stronger (scope by inbox, minimize payload) |
| Ops: cleanup and retention | You manage mailbox hygiene | Inbox lifecycle is explicit (expiry/cleanup patterns) |
When plus tags are enough (and how to do them safely)
Plus tags are fine when the mailbox is not a bottleneck and you are not trying to make the system fully deterministic.
Good-fit scenarios
- Manual QA where a human is reading the mailbox.
- Low-volume smoke tests that run sequentially.
- Internal tools where you fully control both the sender and receiver.
Guardrails if you use plus tags in automation
If you still want to use plus tags for correlation, add these constraints:
- Treat the tag as a correlation hint, not a selector. Still match on additional signals (template ID, subject prefix, a run header you control).
- Do not rely on “latest email wins.” Retries and delayed deliveries will burn you.
- Prefer provider APIs over IMAP scraping. IMAP plus HTML parsing is a reliability trap.
-
Keep tags short and structured (for example
run_81c2_attempt_2) and log them. -
Expect rejection: if you are testing third-party signups, assume some will block
+and have a fallback addressing scheme.
If your pipeline is already flaky, these guardrails usually become a lot of work for limited upside.
When inbox IDs are the right tool
If any of these are true, inbox IDs are the better default:
- Your CI runs tests in parallel.
- Your harness supports retries.
- You need an agent or job to receive verification codes/magic links deterministically.
- You want emails as structured JSON for robust assertions.
- You care about webhook authenticity and replay protection.
Two posts that pair well with this model:
- Temp Email API: Receive and Parse Emails as JSON
- Temp Email Receive: Webhook-First, Polling Fallback
Practical patterns: using both without confusing their roles
You can combine the two ideas, as long as you keep the responsibilities separate.
Pattern: use plus tags for human debugging, inbox ID for correctness
- Use an inbox-first API to create an isolated inbox.
- Optionally embed a readable correlation string in the local-part (or tag) if your domain strategy supports it.
- Treat the inbox ID as the only correctness boundary.
This gives you readable logs and deterministic inbox scoping.
Pattern: custom domain with deterministic routing, still inbox-first
If you need allowlisting compatibility or deliverability control, use a custom domain (or subdomain) and route recipients to inboxes deterministically. In this setup, plus tags can become just another routing hint, not the core mechanism.
Mailhook supports both shared domains and custom domain setups (see llms.txt).
Implementation sketch (agent-friendly)
The cleanest agent contract is to avoid “search the mailbox.” Instead, make the tool return an EmailWithInbox descriptor and require downstream tools to use the inbox ID.
A minimal workflow looks like this:
- Create inbox (get
emailandinbox_id). - Trigger the app to send the email.
- Wait for arrival (webhook-first, polling fallback).
- Extract only the needed artifact (OTP or verification URL).
- Expire/cleanup inbox.
Mailhook’s design supports these primitives (disposable inbox creation, webhook notifications, polling API, JSON output, and signed payloads for webhook authenticity). For exact request/response formats, rely on the canonical spec: https://mailhook.co/llms.txt.
Choosing fast
If you want a one-sentence rule:
- Use plus tags when you only need a personalized-looking address inside a single mailbox.
- Use inbox IDs when you need personalized email handling that is deterministic, parallel-safe, and agent-friendly.
If your real goal is reliable email receipt in CI or for LLM tools, the inbox ID model is the one that scales without turning your test harness into a mailbox search engine.
To explore an inbox-first approach with structured JSON emails, webhooks, polling, and disposable inbox lifecycles, see Mailhook and the machine-readable integration contract in llms.txt.
