The Gmail + trick is dead. Here's what works in 2026.

The Gmail subaddress trick — appending +anything to your address before the @ so [email protected] routes to your inbox — stopped working reliably around 2024. By 2026, the list of platforms that silently strip the suffix before checking for duplicate accounts has grown long enough that you can't build a privacy or multi-account pattern around it.

What the + trick was supposed to do

Google has supported subaddressing since Gmail launched. Everything after the + gets ignored for delivery, so any variant of your address still reaches you. The original use case was filtering: sign up for newsletters at [email protected], create a filter on that label, archive automatically.

Some people extended this into a privacy pattern — give a different +tag to each service so you could trace which one sold your address when the spam arrived. That part still works, on platforms that bother to preserve the suffix. The part that broke is using it to create what looks like a separate identity at a service that enforces one account per email.

Why most sites reject it now

The fix is trivial from the service side: strip everything between + and @ before running the "does this email already exist?" check. LinkedIn does it. Reddit does it. Discord does it. Most SaaS tools that grew serious about account uniqueness have added this logic at some point in the last two years.

Some platforms go further and reject the address at form validation entirely, returning "invalid email address" even though [email protected] is a completely valid RFC 5321 address. The result is that the trick has become unpredictable — it works on older platforms that never added the stripping logic, fails silently on the ones that do strip it (you think you created a fresh account; they detect the same underlying address), and fails noisily on the ones that actively block it. You can't know in advance which behavior you'll get.

Other workarounds that also stopped working

The Gmail dot trick has the same problem. Google treats [email protected] and [email protected] as the same inbox. Some platforms used to skip dot canonicalization before their duplicate check — you could create a second account on the dotted version. That loophole closed at most major services around the same time as the + stripping.

Catch-all domains — registering a domain and routing [email protected] to yourself — technically work, but MX-based blocklists have gotten sharper at detecting forwarding-domain patterns. Any domain you register for this purpose is also attached to your real identity via WHOIS (or kept server-side at a privacy-protecting registrar, which is its own kind of record). The operational overhead grows fast for what's supposed to be a throwaway technique.

Forwarding-alias services like SimpleLogin and AnonAddy are showing up on blocklists at some platforms too. They function well for general spam filtering — they're transparent public services and not trying to hide — but their known alias domains are easy to detect and block the same way services block disposable-email domains. Once a domain pattern is fingerprinted, the blocklist problem spreads fast.

What a disposable inbox actually does differently

A purpose-built throwaway address is not a forwarded alias of your real address. It is a separate inbox, on a domain that actually accepts mail, with no structural connection to any account you hold elsewhere. The distinction matters when the platform does an MX lookup to verify the domain (it passes), when they check for subaddressing patterns (there are none), and when they match against a blocklist (domains with active deliverability monitoring rotate before they accumulate enough complaints to land on one).

The inbox exists until it expires or you delete it. Mail arrives in real time. You read it at cybertemp.xyz in the browser without creating an account or installing anything. There is no reply-to that exposes your real address, because the throwaway address has no real address behind it.

The per-service burner pattern

The practical replacement for the + trick — if your goal was tagging which service leaked or sold your email — is a per-service burner inbox. Pick a format that's easy to remember: [email protected], [email protected], [email protected]. Open cybertemp.xyz, type the local part you want into the inbox field, paste the address into the signup form, and read the verification email when it arrives. No account, no install.

Each of those is a genuinely distinct address with its own inbox. There is no shared underlying account the service could trace back to your identity. If one starts pulling spam after months of silence, you know exactly who sent it. You don't need to unsubscribe — when an inbox has served its purpose, you close it and it's gone.

For one-off verifications where you'll read one email and move on, the free tier handles it with no setup at all. For inboxes you plan to check periodically over days or weeks — a trial subscription, a beta program, a site that sends account recovery codes — the ECO and CORE tiers keep addresses active longer and give you a view of which ones are still running.

Who the + trick still works for

If you use Gmail subaddresses purely to organize your own mail — different tags for different mailing lists, all routing to the same inbox — a throwaway address isn't the replacement. That's a mail-organization workflow, not a privacy or multi-account workflow. Gmail filters and labels solve that problem directly and always have.

The + trick as a leak-detection tool still works on platforms that haven't added stripping logic. If you gave [email protected] to Reddit and later get spam to exactly that address, you've confirmed the source. The catch is that you have to test each service to know whether they preserve the suffix, and the majority of major platforms no longer do.

Bottom line

The Gmail + trick isn't universally broken, but it's unreliable enough that you can't build a privacy strategy around it. The services where clean separation actually matters — social platforms, SaaS tools, any service with an "one account per email" rule — have either stripped the suffix or blocked it outright.

For the simple case, open cybertemp.xyz, type whatever local part you want (amazon-2026, trialsite, whatever-fits), paste the address into the form, and read the verification email when it arrives. For anything longer-lived, the per-service burner pattern gives you what the + trick was always trying to give you — traceability and isolation — without depending on the platform being lazy enough to skip the strip. If you want the broader picture on why treating email addresses as disposable has become the cleaner default, that post covers the reasoning end to end.