Sign in to the AWS Management Console and open the Amazon SES console. In the navigation pane under Configuration choose Identities. From the Identities table, select a verified email identity by clicking directly on the identity name rather than its checkbox. On that identity's detail page, choose Send test email.
Then the question worth asking before you read the result: where did that message go. If you left the Scenario on a mailbox simulator option, it went to an address inside AWS that never touched a mailbox provider. AWS states the consequence directly: emails you send to the mailbox simulator do not count toward your sending quota or your bounce and complaint rates, nor do they affect Virtual Deliverability Manager metrics.
They are still billed. For billing purposes, emails sent to the Amazon SES mailbox simulator are the same as any other email you send using Amazon SES. A simulator test is a paid message that changes nothing and measures nothing about placement, which is fine as long as you know that is what you bought.
What each mailbox simulator address does
The simulator is genuinely useful, just not for the thing people reach for it to do. Each address at simulator.amazonses.com forces one outcome so you can exercise the handling code behind it:
success@simulator.amazonses.comaccepts the message normally.bounce@simulator.amazonses.comreturns a hard bounce.complaint@simulator.amazonses.comreturns a spam complaint.ooto@simulator.amazonses.comreturns an out-of-office auto response.suppressionlist@simulator.amazonses.comreturns a suppression list rejection.
This is how you test that your bounce processing removes an address, that your complaint webhook fires, and that your suppression logic behaves, without spending real reputation to generate the events. Every other sending platform in this category makes you cause a real bounce to test bounce handling. SES does not, and that is a real advantage.
The simulator also works while your account is sandboxed, which matters more than it sounds.
The sandbox is why your test will not go anywhere
Every new SES account starts in the sandbox, in every Region separately. While sandboxed, you can only send mail to verified email addresses and domains, or to the Amazon SES mailbox simulator. An external seed address you have not verified is unreachable, and the failure reads as a permissions problem rather than a policy one.
The sandbox also caps sending at 200 messages per 24-hour period and one message per second.
To leave it, open Account dashboard in the SES console navigation panel, find the warning box stating that your account is in the sandbox, choose View Get set up page, and request production access. AWS does not publish what your production limits will be, stating only that the number varies based on your specific use case, so treat any figure you see quoted elsewhere as invented.
Formatted or Raw, and why your HTML arrives as plain text
The console test form asks for an Email Format. Choosing Formatted means AWS puts the text into email format for you, which is convenient and drops your HTML. HTML and attachments only survive if you choose Raw and paste complete MIME yourself.
AWS attaches a warning to that path worth repeating, because it produces a confusing failure: a blank line between the two header lines causes the email to be formatted as plain text instead of HTML. If your raw test arrives as a wall of markup, that is usually why, and nothing about the symptom points at the cause.
This is the general shape of SES. It is a raw message relay rather than a campaign tool, so there is no template rendering, no merge tags, no unsubscribe generation and no rendering preview. Nothing is stripped from your message because nothing was ever added to it.
SES scans for viruses, not for spam
There is no SpamAssassin-style scoring anywhere in SES, no spam-word checker and no content grade. The feature people mistake for one is virus scanning: every message sent through SES is scanned for viruses, and you can prove it with an EICAR test file, which produces a Reject event.
That is malware detection. It tells you nothing about whether a mailbox provider will file your message as spam.
For the content half of the question, the check has to happen outside SES. Across messages tested with Unspam this year, 88% land in the safe SpamAssassin range, so content is rarely the whole story, but it is the cheapest part to rule out before looking at reputation.
SES does measure placement, in two places, both paid
The console Send test email button is not the only test SES has, and the other two are easy to miss because neither sits next to it.
Predictive inbox placement tests have been part of the SES deliverability dashboard for years, reached through the CreateDeliverabilityTestReport API. AWS describes them as helping you predict how your messages will be handled by various email providers around the world: you supply a sample message, and Amazon SES then sends that message to special email addresses spread across several major email providers. The test completes in about 24 hours, and you read the outcome with GetDeliverabilityTestReport.
Global deliverability arrived on 29 May 2026 and sits inside Virtual Deliverability Manager. It reports inbox, spam and missing percentages with an ISP breakdown, results land in roughly two to four hours, and it adds blocklist monitoring alongside. It is sold as a subscription package at $1,250 per month, per region, per account, which includes 5 domains, 12 IPs and 25 seed list tests per month.
AWS does not publish which providers its seed accounts sit at, how many seeds there are, or their addresses. That is a meaningful gap if you are trying to reconcile a placement result against a specific provider's behavior.
The cheaper SES feature, SES deliverability in Virtual Deliverability Manager, is a separate paid opt-in at $0.07 per 1,000 emails. It gives you a dashboard and an advisor over your own sending data: open, click, complaint, delivery and bounce rates. Like every engagement dashboard, it reports on mail that already arrived somewhere, which is the one thing a placement question is asking about.
When you need a real send to a seed address
Once you have production access, the honest test is an ordinary message through your normal SES path, to an address that is not inside AWS.
The Amazon SES deliverability guide covers that setup, including the configuration set and event destination wiring that lets you actually observe what happened. For where the message lands, an inbox placement test delivers it to seed mailboxes at Gmail, Outlook, Yahoo and five other providers and reports the result per provider.
Of the campaigns run through Unspam so far this year, 65% of emails reach the primary inbox, and the Unspam deliverability benchmark tracks the split.
When the message is one you would really send, run it through the free Unspam spam test and read the authentication on the live send rather than on a simulated one.
