# What addresses can I use for testing?

> Use the mailbox simulator addresses to deterministically trigger delivered, bounce, and complaint events without harming your reputation.

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

| Address | Result |
| --- | --- |
| `delivered@mailblastr.dev` | Accepted and **delivered** — produces a delivery event. |
| `bounced@mailblastr.dev` | A **hard bounce** — the recipient is added to your suppression list. |
| `complained@mailblastr.dev` | A **complaint** (marked as spam) — the recipient is suppressed. |
| `suppressed@mailblastr.dev` | A **suppression** outcome — simulates sending to an already-suppressed address (the send is treated as a hard bounce against the suppression list). |

Send to one of these exactly like any other recipient. The `from` address must still be on one of your [verified domains](https://www.mailblastr.com/docs/domains/managing).

## 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 `@`:

```text
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](https://www.mailblastr.com/docs/webhooks/overview) or a `GET /emails/:id` result back to the exact test scenario (signup flow vs. newsletter flow, etc.) that produced it.

**Node.js**

```js
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 });
```

**Ruby**

```ruby
require "mailblastr"

Mailblastr.api_key = "mb_xxxxxxxxx"

Mailblastr::Emails.send({
  "from": "Acme <hello@yourdomain.com>",
  "to": [
    "delivered@mailblastr.dev"
  ],
  "subject": "Delivery test",
  "html": "<p>This should be delivered.</p>"
})
```

**PHP**

```php
$mailblastr = Mailblastr::client('mb_xxxxxxxxx');

$mailblastr->emails->send([
  'from' => "Acme <hello@yourdomain.com>",
  'to' => [
    "delivered@mailblastr.dev"
  ],
  'subject' => "Delivery test",
  'html' => "<p>This should be delivered.</p>"
]);
```

**Python**

```python
import mailblastr

mailblastr.api_key = "mb_xxxxxxxxx"

mailblastr.Emails.send({
  "from": "Acme <hello@yourdomain.com>",
  "to": [
    "delivered@mailblastr.dev"
  ],
  "subject": "Delivery test",
  "html": "<p>This should be delivered.</p>"
})
```

**Go**

```go
import "github.com/shekhu10/mailblastr-sdks/mailblastr-go"

client := mailblastr.NewClient("mb_xxxxxxxxx")

params := &mailblastr.SendEmailRequest{
    From:    "Acme <hello@yourdomain.com>",
    To:      []string{"delivered@example.com"},
    Subject: "hello world",
    Html:    "<p>it works!</p>",
}
sent, err := client.Emails.Send(params)
```

**Rust**

```rust
use mailblastr::{Mailblastr, CreateEmailBaseOptions};

let mb = Mailblastr::new("mb_xxxxxxxxx");

let email = CreateEmailBaseOptions::new(
    "Acme <hello@yourdomain.com>",
    ["delivered@example.com"],
    "hello world",
).with_html("<p>it works!</p>");
let _sent = mb.emails.send(email).await?;
```

**Java**

```java
import com.mailblastr.*;

Mailblastr mailblastr = new Mailblastr("mb_xxxxxxxxx");

SendEmailRequest request = SendEmailRequest.builder()
    .from("Acme <hello@yourdomain.com>")
    .to("delivered@example.com")
    .subject("hello world")
    .html("<p>it works!</p>")
    .build();
mailblastr.emails().send(request);
```

**.NET**

```csharp
using Mailblastr;

IMailblastr mailblastr = MailblastrClient.Create("mb_xxxxxxxxx");

var resp = await mailblastr.EmailSendAsync(new EmailMessage
{
    From = "Acme <hello@yourdomain.com>",
    To = "delivered@example.com",
    Subject = "hello world",
    HtmlBody = "<p>it works!</p>",
});
```

**cURL**

```bash
curl -X POST 'https://api.mailblastr.com/emails' \
  -H 'Authorization: Bearer mb_xxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -d '{
  "from": "Acme <hello@yourdomain.com>",
  "to": ["delivered@mailblastr.dev"],
  "subject": "Delivery test",
  "html": "<p>This should be delivered.</p>"
}'
```

**CLI**

```bash
mailblastr emails send \
  --from 'Acme <hello@yourdomain.com>' \
  --to 'delivered@mailblastr.dev' \
  --subject 'Delivery test' \
  --html '<p>This should be delivered.</p>'
```

## 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](https://www.mailblastr.com/docs/webhooks/overview) and per-email log handling get a true rehearsal.

> **Warning:** After a `bounced@` or `complained@` test, that exact simulator address is added to your **suppression list** and future sends to it are skipped — this is expected, because MailBlastr drops suppressed recipients before sending. The event is still recorded on the first send.

> **Note:** Simulator mail still counts toward your [daily sending quota](https://www.mailblastr.com/docs/api/limits). Keep automated test volume modest.

For an automated workflow built on these addresses, see [Setting up E2E testing](https://www.mailblastr.com/docs/kb/e2e-testing).