How to test multiple user accounts without creating separate mailboxes
You do not need a mailbox per test user. Take one receiving address and add a reference after a plus sign — yourprefix+admin@in.demopost.net, yourprefix+member@in.demopost.net — and your application treats each one as a different user while every message arrives in the same private workspace.
Why this works
The part after a plus sign is a sub-address. For the receiving side it is the same mailbox; for your application it is a different string, so registration, uniqueness checks and user records behave as if these were separate people. That is exactly what you want when you are testing five roles in one afternoon.
A role mapping that stays readable
Pick references that describe the scenario, not the date. A workable set:
| Test user | Address | What you check |
|---|---|---|
| Workspace owner | yourapp+owner@in.demopost.net | Onboarding and billing mail |
| Invited member | yourapp+member@in.demopost.net | Invitation and role changes |
| Customer | yourapp+signup@in.demopost.net | Welcome and confirmation mail |
| Billing contact | yourapp+invoice@in.demopost.net | Invoices and PDF documents |
| Dunning case | yourapp+reminder@in.demopost.net | Reminders and escalation |
Keep the mapping in your test plan. Six months later, “+reminder” still tells you what the message was for; “+test3” does not.
Setting it up
- 1Start your DemoPost subscription and choose your receiving prefix. The prefix is yours; the references are free-form.
- 2Write the address of each test user into your application's test records, using one reference per role or scenario.
- 3Trigger the flows you want to check. Your normal sending provider delivers the messages.
- 4In DemoPost, search on the reference to pull up only the messages of that test user.
Where plus addressing falls short
Some applications reject or normalise the plus sign
A number of signup forms refuse addresses containing “+”, and some systems strip the sub-address before storing it, which collapses your five test users back into one. If a form rejects the address, that is a finding about the form, not about DemoPost — and you will need a different reference scheme for that particular system.
References are organisation, not isolation
Every reference lands in the same private workspace. It keeps messages recognisable; it does not create separately secured mailboxes with their own access rules.
What DemoPost does not do
- Plus addressing is not a universal workaround; test whether the system under test accepts it before you build a test plan on it.
- A reference does not authenticate anyone — anybody who can reach your workspace can see all of it.
- DemoPost does not create real user accounts in your application; you still set up the test records yourself.
Quick checklist
- Each test user has a unique, descriptive reference.
- The mapping between reference and role is written down.
- The signup form of the system under test accepts the plus sign.
- Messages for each reference appear in your workspace when you trigger the flow.
- Sensitive production data is nowhere in the test records.
Related reading
Set up your prefix
Start the 7-day trial, pick your receiving prefix and give your first five test users their own address.
Try Email for 7 days. Then €19/month, excluding applicable tax. Cancel before your trial ends to avoid the subscription charge.