In this article
To test email safely in staging, capture messages locally by default and allow live delivery only to explicitly approved recipients. Separate template checks, failure simulations, and controlled inbox tests so each test proves one part of the workflow.
A developer testing an invoice reminder against a staging database can still email a real customer if the transport uses production credentials. The template may be correct while the boundary around the test is not.
Mailgun’s May 2026 discussion of test email and sender reputation highlights an important constraint: mailbox providers process live test traffic as real mail. A useful testing strategy therefore starts by deciding which tests need permission to leave your application.
Define what each test proves
“Email works” is too broad to be a test assertion. Split the workflow into observable responsibilities.
| Layer | Question | Suitable evidence |
|---|---|---|
| Business rules | Should this event create a message? | An expected notification intent |
| Composition | Are recipient, subject, and content correct? | A captured message and rendered preview |
| Submission | Does the integration handle responses? | A controlled transport result |
| Event handling | Does a delivery outcome update our records? | A simulated event and state assertion |
| Live delivery | Can a controlled inbox receive this message? | One traced message in an inbox you own |
This separation changes how failures are investigated. A missing receipt in a composition test points to application logic. A receiving-server rejection in a live check points to a different boundary. Neither requires running every test against an external mailbox.
Put the transport behind one application boundary
Have application code create a message through a shared adapter. The adapter selects a capture transport or an explicitly enabled live transport. Keep this choice outside templates and individual notification handlers.
An SMTP capture tool can support an existing SMTP application; Mailpit documents its SMTP server, message interface, and API. An HTTP integration can use a fake transport that implements your own application’s interface. A capture transport should return a clearly local receipt, never a fabricated production delivery event.
The following is provider-independent pseudocode, not a SendMero API example:
submit_message(message, environment):
envelope = collect_all_envelope_recipients(message)
if environment.mode == "capture":
return capture_store.save(message)
require environment.live_send_enabled
require every_address_allowed(envelope, environment.allowlist)
require shared_send_budget.reserve_one_atomically()
return live_transport.submit(message)An allowlist check must cover the actual delivery envelope, including copied and blind-copied recipients. Checking only the visible To field leaves another path to an unintended recipient. Recheck the envelope after any code that rewrites recipients or expands a group.
Make capture mode the default. A missing configuration value should stop delivery or capture the message. It should never quietly select production credentials.
Make fixtures independent of customer data
Create a small set of fictional users covering the variations your templates need: long names, missing optional fields, different currencies, and an address awaiting verification. There is rarely a reason to copy a customer’s full profile just to test a line break.
Use documentation domains for visible examples. IANA reserves domains such as example.com for that purpose. That reservation is not a mail-capture service: the transport boundary must still prevent outbound delivery.
Include a fixture containing several recipients so your tests exercise the envelope guard. Also include an unexpected address and assert that a live-mode submission is rejected before reaching the network. A guard that has only passed permitted examples has not demonstrated that it can block anything.
Test a user who has changed addresses, too. The email address-change workflow should preserve account preferences and keep a late event for the old contact from changing the new contact’s status.
Treat captured messages as application data. Restrict access, set retention, and avoid putting real credentials or active recovery tokens in fixtures. Review screenshots before attaching them to an issue.
Simulate failure at the right layer
A staging suite needs to prove more than successful composition. Give your fake transport a small library of outcomes:
- Submission rejected immediately.
- Submission times out with an unknown outcome.
- A later delivery event reports a permanent failure.
- The same event arrives twice.
- An older event arrives after a newer event.
Keep transport outcomes separate from business outcomes. A submission timeout should not automatically produce a second invoice reminder with a new identity. A duplicate event should not send the user another notification.
For each case, assert the application’s next state and the number of notification intents created. This makes the suite useful even when you change providers or replace SMTP with an HTTP integration.
Give live checks a small, explicit budget
Reserve live delivery checks for the properties local tests cannot establish: current credentials, actual sending configuration, and reception by a controlled mailbox.
For example, a release check might permit one message per chosen template to a short list of team-owned inboxes. Record the release identifier, application message identifier, recipient, and submission time. Follow that specific message instead of repeatedly pressing send.
Enforce the budget in shared storage if several workers or CI jobs can run concurrently. A per-process counter allows each process to spend the full allowance. Keep a separate stop control so an operator can disable live checks without waiting for a deployment.
Restrict outbound network access from capture-only environments where practical. An application guard protects the intended path; an egress rule can also catch a newly introduced library that sends directly.
Make the release decision repeatable
Before promoting a change, confirm that capture tests cover business rules, previews cover the changed templates, and one controlled live check has an identifiable result. A successful live check does not establish inbox placement for every recipient, but it closes a specific integration gap.
Add the transport mode and owner to your email infrastructure inventory. If background jobs can generate large bursts, apply the separate controls in our guide to notification storms.
When connecting the live transport, use the current SendMero documentation for the supported integration details. Your tests should make that final connection a deliberate step in a workflow you can explain.
