AWS documents a mailbox simulator for triggering specific sending outcomes, while its sandbox documentation limits ordinary recipients to verified identities and simulator addresses (simulator documentation, sandbox access rules). That makes the boundary clear: the Amazon SES email simulator is useful for testing supported events and your event-handling logic, but it cannot replace a readable test inbox for inspecting message content or confirming an external inbox experience.
This guide is for developers testing their own product’s email flow in the SES sandbox, QA engineers checking bounce and complaint handling, and independent developers validating message text, verification codes, or links before launch.
The simulator's proof boundary
The Amazon SES mailbox simulator gives a controlled way to exercise specific outcomes without using a real recipient as the test case. That is valuable when the product needs to respond to a bounce or complaint, or when a test needs a predictable delivery-related event.
It does not provide a mailbox where a tester can open the message. A simulator result is not evidence that a real user received a particular subject line, saw the intended template, clicked a working link, or found the message in the inbox rather than spam. Those are separate assertions and require a readable test recipient or an external mailbox.
There is another boundary worth keeping explicit: SES accepting a send request, SES producing an event, the event notification reaching your application, and a message appearing in an external inbox are four different observations. A test that checks only the first one should not be marked as a complete email acceptance test.
| Acceptance goal | SES mailbox simulator | Readable test inbox | External mailbox |
|---|---|---|---|
| Exercise a supported send outcome | Yes, for the documented simulator scenarios | Not its main purpose | Possible, but outcomes are less controlled |
| Check your event-processing logic | Yes, if the event destination and consumer are also observed | No, unless paired with event capture | No, unless paired with event capture |
| Read the subject and message body | No | Yes | Yes |
| Assert a code or link in the message | No | Yes | Yes |
| Check how a real provider handles the message | No | Not necessarily; depends on the receiving service | Yes, for the specific external account tested |
| Confirm inbox placement rather than spam placement | No | Only if the inbox is hosted by the provider being evaluated | Yes, for that tested account and provider |
The table separates event simulation from message inspection and external delivery evidence. No single row or tool covers every acceptance goal. Even a real external mailbox gives evidence about the tested recipient and provider, not a guarantee about every recipient’s filtering behavior.
Supported simulator events and application handling
AWS documents simulator addresses for sending scenarios such as success, bounce, complaint, out-of-office, and suppression-list behavior in its Amazon SES simulator instructions. Use the exact addresses and current instructions in the AWS documentation; don’t substitute a made-up recipient or assume that every event type can be forced by changing an address.
The useful test is not merely “did SES return something?” It is whether the product behaves correctly when the expected event reaches the part of the system that handles it. For example:
- A simulated bounce should exercise the application’s bounce-handling path. Check that the relevant address or subscription state changes as intended and that the event is recorded.
- A simulated complaint should exercise your complaint-handling path. Verify that suppression or contact-preference logic runs according to your product’s policy.
- A successful simulator outcome can help test the success-related event path. It does not prove that an ordinary recipient’s mailbox accepted or displayed the message.
- An out-of-office or suppression-list scenario is useful only if the application has a specific expected response to that outcome. If it has none, treat it as an observability test rather than a user-facing feature test.
SES event data contains fields that help distinguish event types and message details. Use the AWS event data reference to build assertions against the actual structure rather than matching a loose text string. That matters when a handler branches on the event type, recipient, or message identifier. A test should fail if the required field is missing or the handler updates the wrong record.
Also test the event delivery path independently. SES may generate the expected event while your configured notification destination, queue consumer, or application handler is misconfigured or unavailable. AWS describes the configuration and delivery of SES event notifications. In your own test, record at least two observations: the SES-side outcome and whether your application received and processed the notification. Don’t treat an event visible in one system as proof that the entire downstream path worked.
A practical example: a QA test sends a password-reset email to a simulator address that produces a bounce. The test can verify the bounce event is ingested and that the application marks the address as undeliverable. It cannot verify that the password-reset email had the right wording or that its reset link opened the intended page. Those require a separate message-reading test.
Message content requires a readable inbox
The simulator does not provide a readable mailbox. It cannot provide the message body for an assertion such as “the verification code is present,” “the reset URL uses the correct host,” or “the template includes the right account name.”
For those checks, use a test recipient that exposes the delivered message to your test process or tester. Depending on the test setup, that might be a dedicated test mailbox, a controlled external inbox, or a temporary inbox used for a short-lived test. The chosen method should let the test read the message and extract the relevant content without involving an employee’s personal mailbox.
| What needs inspection | Evidence to collect | Suitable method |
|---|---|---|
| Subject, sender, and body text | Read the received message and assert the expected fields | Readable test inbox |
| Verification code | Extract the code from the received message and compare it with the application’s expected state | Readable test inbox plus application-side test data |
| Link destination | Parse the URL, check its scheme and host, and confirm the expected route or token structure | Readable test inbox and a link assertion |
| Rendered layout | Open the message in a target email client or use an approved rendering workflow | Client-level rendering check |
| SES event behavior | Capture the event and verify the handler’s state changes | Simulator plus event-destination observation |
Do not infer content correctness from a send or delivery event. A Send event indicates that SES accepted the message for processing; a delivery-related event reports an outcome in the delivery path. Neither is an assertion against the rendered message body. A message can be accepted while containing a broken link, the wrong localization, an empty template variable, or an incorrect verification code.
Content checks should also avoid overfitting to incidental formatting. If the product sends both plain-text and HTML parts, assert the required meaning and links in the appropriate parts. For a code, check that the message contains the code expected by the test fixture, not merely any string of digits. For a link, verify the intended destination and relevant token or route behavior without exposing production secrets in test logs.
A test inbox does not automatically prove that every recipient service will render the message identically. It proves that the test message was readable through that receiving method. If the acceptance requirement is a specific provider’s layout or filtering behavior, use an account on that provider for the corresponding check.
External delivery evidence requires a real recipient
A simulator outcome is controlled test evidence for the simulator scenario. It is not a receipt from a real person’s mailbox, and it does not establish inbox placement.
Even a delivery event should be read precisely. It is evidence about the receiving mail server’s response in that delivery path. It does not by itself prove that the message landed in the primary inbox, appeared as expected in a particular client, or avoided a provider’s spam classification. AWS’s delivery troubleshooting guidance treats delivery problems as a separate area to investigate; a simulator success should not be used to bypass that investigation.
This is where authentication and reputation checks matter. SPF, DKIM, and DMARC affect how receiving systems evaluate sending identity and policy alignment. The mailbox simulator does not establish that your production domain’s authentication records are correct, that alignment passes at an external provider, or that a provider classifies the message as wanted mail. Those checks need evidence from the relevant DNS configuration and a real receiving path.
For an external-receipt test, send a controlled message from the environment and domain that matter to a mailbox you can inspect. Record what the receiving service shows: whether the message arrived, where it was categorized, and whether the content and links are intact. Keep that evidence tied to the tested domain, configuration, and recipient. It is a useful release check, not a universal guarantee for all recipients.
Sandbox constraints shape the test plan
The sandbox is useful for controlled testing, but it changes which recipients are available. AWS states that sandbox accounts can send to verified email addresses or domains, as well as the mailbox simulator; check the current sandbox access documentation for the rules that apply to the account and Region.
AWS also documents default sandbox sending limits of 200 messages per 24-hour period and one message per second in its SES sending quotas. These are sourced service limits, not performance promises. Confirm the current account’s quota and Region before designing a test run around them.
That limitation does not make the simulator a full substitute for a test inbox. It means the two tools serve different parts of a sandbox plan:
- Use simulator scenarios to test supported outcomes and the application’s event-handling logic.
- Use a verified, readable test recipient when the test must inspect content.
- Use an external mailbox when the acceptance criterion requires evidence from a real receiving provider.
- If sandbox recipient restrictions prevent a particular external test, keep the simulator checks and content checks separate. Don’t label the untested external-delivery requirement as passed.
A useful test record captures the environment as well as the outcome: SES Region, sending identity, recipient type, scenario used, event observed, notification received, and message-readable evidence where applicable. This makes a failure easier to classify. A missing event points toward the event path; an incorrect body points toward template generation; a message absent from an external account requires investigation of the actual delivery path.
A decision checklist for choosing the test combination
Step 1: Define the acceptance claim
Write the claim in observable terms. “SES works” is too broad. “The bounce event updates the test contact state” is testable. “The verification email contains the expected code and a link to the staging host” is also testable, but needs a readable message.
Step 2: Match the claim to its evidence
For event processing, select a documented simulator outcome and observe both the resulting event and your application’s handling of it. For message content, use a test inbox that exposes the message. For external receipt, send to an account at the service you need to evaluate and inspect the result there.
Step 3: Keep the test data isolated
Use test identities and test records created for your own product. Keep test credentials, codes, tokens, and personal information out of production accounts and logs. A dedicated test recipient is easier to maintain than repeatedly involving coworkers’ inboxes. For a broader comparison of temporary addresses and secondary accounts, see the temporary email versus secondary account guide.
Step 4: Assert each boundary separately
A robust regression test can have separate assertions for request acceptance, event generation, event notification delivery, application state change, and message content. Mark only the assertion actually observed as passed. If the application receives an event but the test never reads the message, the content assertion remains unverified.
Step 5: Add an external mailbox check only when needed
Use a real external mailbox for a release check that requires provider-specific receipt or presentation. Keep that test distinct from routine event tests, which benefit from simulator outcomes because they are controlled and repeatable. Do not treat one successful mailbox check as proof for every provider or user.
| If the release question is… | Choose… | Do not claim… |
|---|---|---|
| Does the application handle a supported bounce or complaint outcome? | Simulator scenario plus event and handler assertions | That a real recipient reported a bounce or complaint |
| Is the code, template, or URL correct? | A readable test inbox plus content assertions | That a send event verified the message body |
| Did the message reach an external mailbox, and how was it classified? | A controlled send to an inspectable external account | That one account proves universal inbox placement |
| Are all three requirements in scope? | Combine the simulator, readable inbox, and external check | That any one method covers the other two |
The practical answer
Use the Amazon SES simulator when the test is about a documented sending outcome or the application’s response to an event. Add a readable test inbox when a person or automated test must inspect the subject, body, code, or link. Add an external mailbox when the requirement is to observe a real receiving service. That combination preserves the distinction between simulated events and actual recipient experience.
For a short-lived registration, template, or verification-code check, a temporary inbox can be a convenient way to keep test mail out of a primary work inbox. MXTemp is one option to consider for that readable-inbox part of the workflow; it complements SES event simulation rather than replacing it. The MXTemp temporary inbox can be considered when the remaining task is to receive and inspect a test message, while the simulator continues to cover the event scenarios it is designed to exercise.