Plus addressing: one mailbox, many labels
RFC 5233 describes subaddresses: a separator, usually +, followed by a detail for the recipient's own sorting. Gmail delivers [email protected] to [email protected], and ignores dots in the local part as well. Every variant lands in the same mailbox.
For tests that means one inbox for all runs. You read it with the Gmail API (OAuth) and filter by the To header. Some sign-up forms reject + outright.
Catch-all on your own domain
Point the MX records of a subdomain such as test.example.com at a mail service and accept every local part. Any address works, and you own the domain. The costs: DNS to manage, a mail service to run or pay for, and you still need something that sorts mail by recipient and gives your tests an API, or you are back to one mailbox.
One subdomain per inbox
Some testing services give each inbox its own domain, with a free local part: [email protected]. The domain picks the inbox; the local part separates tests. Because some platforms reject addresses on subdomains, Mailosaur also documents a form without one.
A prefix in the local part
Zyntra puts the team in the local part: {teamId}.{anytext}@zyntramail.com. The part before the first dot finds the team, the rest is up to the test, and each full address is its own inbox. One fixed domain, nothing to set up, no +.
Keep tags to letters, digits and hyphens, and keep the whole local part to at most 64 characters, the limit RFC 5321 sets.
Which one for tests
- Manual checks now and then: plus addressing is fine.
- Parallel CI runs: use a format where each address is its own inbox (the last two above).
- Strict sign-up validation: avoid
+, and check whether your app accepts subdomains. - You must own the domain: catch-all, with the work it brings.