Just discovered something pretty cool while working on email workflows for BookSea that doesn’t seem to be widely documented anywhere. You can use “+” signs in test emails !

(Updated 2025 July 30 – Now they use the + signs as normal)

I was working on “bounce” handling to catch delivery issues early and notify when quote emails weren’t getting through. You know how it is – you think hard before commiting to test your webhooks properly without accidentally damaging your domain reputation by sending to fake addresses…

The undocumented feature

Resend’s test email documentation mentions the standard test addresses like [email protected], [email protected], and [email protected]. But what it doesn’t mention is that these actually support plus sign aliases in a non-standard way standard way !

You can actually use the plus sign in test email address:

delivered+bookingABCD@resend.dev

I stumbled onto this when I asked Resend support if I could use traditional plus aliases (like delivered+admin@resend.dev) to test different user scenarios. “Jp” from their team clarified that while that format doesn’t work, this reversed approach does.

Why This Matters for Real Testing ?

When you’re building something like Booksea where email reliability actually matters, you need to test scenarios with multiple different recipients hitting the same delivery outcome.

The traditional approach would force you to either:

  • Keep reusing the same test email (boring and unrealistic)
  • Set up actual test inboxes (messy and potentially risky for bounces … and complaints)
  • Mock everything (missing real integration testing)

With plus aliases, you get the best of both worlds – realistic email addresses that behave exactly like the base test addresses, but with unique identifiers that let you trace different test scenarios.

Quick Example

Testing user notification flows? Try:

[email protected]
[email protected]
[email protected]

Your webhook will receive distinct events for each “user” while still getting the predictable delivery outcomes you need for testing.

It’s a little quality-of-life feature that makes integration testing just a bit smoother. Sometimes the best features are the ones that quietly solve annoying edge cases.

By Romain

Leave a Reply

Your email address will not be published. Required fields are marked *