What addresses can I use for testing?

MailBlastr provides a mailbox simulator — a set of reserved addresses that always produce a specific outcome. Send to them to test that your delivery, bounce, and complaint handling works end to end, without mailing real people and without affecting your sender reputation.

Simulator addresses

Send to one of these exactly like any other recipient. The from address must still be on one of your verified domains.

Why not @example.com or @test.com?

Reaching for @example.com or @test.com is a common mistake. Those domains are not built to receive mail and routinely reject messages, which shows up as bounces — and a high bounce rate erodes your sender reputation and future deliverability. Use the simulator addresses above instead, which produce the outcome you want without a real-world bounce against your reputation.

Labeling with a + suffix

The simulator addresses support plus-addressing, so you can send to the same outcome address many ways and still tell the resulting events apart. Add a label after a + and before the @:

delivered+user1@mailblastr.dev
bounced+signup@mailblastr.dev
complained+newsletter@mailblastr.dev

Each still triggers the same delivered / bounce / complaint behavior, but the label rides along on the event — handy for matching a webhook or a GET /emails/:id result back to the exact test scenario (signup flow vs. newsletter flow, etc.) that produced it.

import { MailBlastr } from 'mailblastr';

const mb = new MailBlastr('mb_xxxxxxxxx');

const { data, error } = await mb.emails.send({
  "from": "Acme <hello@yourdomain.com>",
  "to": ["delivered@mailblastr.dev"],
  "subject": "Delivery test",
  "html": "<p>This should be delivered.</p>"
});
console.log({ data, error });

Why use the simulator

• Deterministic — bounced@ always bounces, complained@ always complains. No need to find or fake real bouncing mailboxes.
• Reputation-safe — simulator traffic does not count against your bounce or complaint rates, so testing failure paths can never hurt deliverability.
• Real event flow — events are generated the same way they are for real recipients, so your webhook and per-email log handling get a true rehearsal.

For an automated workflow built on these addresses, see Setting up E2E testing.