Test data: email address requirements

When running automated testing against the Boarding API and Application flows, please use valid, deliverable email addresses and ensure each application uses a unique email address.

This prevents:

  • Message undeliverable and bounce back noise in our email systems

  • Test failures caused by duplicate email reuse when unique emails are expected

  • Confusing support investigations caused by blocked or invalid destination addresses

Requirements and Best Practices

Use a valid, deliverable email address

Use an email address that can receive mail. Avoid obviously invalid domains (for example @example.fake) or malformed addresses.

If your test does not need to receive the email content, you can still use a deliverable address, but route it to a mailbox you control for testing.

Use a unique email per application

Our system expects each application to have its own unique email address. Reusing the same email across many applications can lead to validation failures or unexpected results.

Best practice:

  • One email address per application record

Option A: Plus addressing (+tag)

Most common email providers support plus addressing, which treats everything after + as a tag while still delivering to the same mailbox.

Pattern:

Examples:

This is a good default for small scale testing.

Option B: Plus addressing with timestamp

For automated testing, use a timestamp based tag so every request is unique.

Recommended tag formats:

  • yymmddhhmmss

  • yyyymmddhhmmss

Examples:

Notes:

  • Keep the tag numeric and compact for easier log searching

  • Ensure your generator uses the local time or UTC consistently within your test suite

Option C: Timestamp plus sequence counter

If your test can create multiple applications within the same second, add a short counter to avoid collisions.

Examples:

If you want to keep the tag purely numeric:

What Not To Do

Avoid these patterns:

  • Reusing the same email across many applications (example: always [email protected])

  • Using non deliverable domains (example: @nope, @invalid, @fake)

  • Using mailbox names that will cause large bounce volume (example: random addresses at a corporate domain that rejects unknown users)

Suggested Implementation in Automated Tests

Simple generator rule

  1. Choose a base mailbox that is deliverable and controlled by your team, for example [email protected]

  2. Convert it to a tagged address with a timestamp

  3. Optionally add a sequence when generating multiple emails quickly

Example output set:

Example pseudo logic

If you are only generating one email per second, you can omit the counter.

Troubleshooting

Emails are not being delivered

Common causes:

  • Your mail provider does not support plus addressing

  • Your organization has mail rules that strip or block tagged addresses

  • The address is not deliverable, or the domain rejects unknown recipients

What to do:

  • Confirm plus addressing works for your domain

  • If it does not, use a catch all mailbox, or create a dedicated test mailbox list (for example qa1@, qa2@, qa3@)

  • Keep the uniqueness rule, even if you use a different strategy

Duplicate email validation failures

If you see application failures that look like email uniqueness issues:

  • Confirm your test data generator is producing a unique value per application

  • Add the timestamp and counter strategy above

  • Avoid parallel test workers sharing the same base tag logic without coordination

Last updated