# What addresses can I use for testing?

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

SendPing 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@test.sendping.co` | Accepted and **delivered** — produces a delivery event. |
| `bounced@test.sendping.co` | A **hard bounce** — the recipient is added to your suppression list. |
| `complained@test.sendping.co` | A **complaint** (marked as spam) — the recipient is suppressed. |
| `suppressed@test.sendping.co` | 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.sendping.co/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@test.sendping.co
bounced+signup@test.sendping.co
complained+newsletter@test.sendping.co
```

Each still triggers the same delivered / bounce / complaint behavior, but the label rides along on the event — handy for matching a [webhook](https://www.sendping.co/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 { SendPing } from 'sendping';

const mb = new SendPing('mb_xxxxxxxxx');

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

**Ruby**

```ruby
require "sendping"

SendPing.api_key = "mb_xxxxxxxxx"

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

**PHP**

```php
<?php
require 'vendor/autoload.php';

use SendPing\SendPing;

$sendping = SendPing::client('mb_xxxxxxxxx');

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

**Python**

```python
import sendping

sendping.api_key = "mb_xxxxxxxxx"

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

**Go**

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

client := sendping.NewClient("mb_xxxxxxxxx")

sent, err := client.Emails.Send(&sendping.SendEmailRequest{
    From:    "Acme <hello@yourdomain.com>",
    To:      []string{"delivered@test.sendping.co"},
    Subject: "Delivery test",
    Html:    "<p>This should be delivered.</p>",
})
```

**Rust**

```rust
use sendping::{SendEmailOptions, SendPing};

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

let params = SendEmailOptions::new(
    "Acme <hello@yourdomain.com>",
    ["delivered@test.sendping.co"],
    "Delivery test",
)
.with_html("<p>This should be delivered.</p>");
let _sent = mb.emails.send(params).await?;
```

**Java**

```java
import co.sendping.SendPing;
import co.sendping.SendPingResponse;
import co.sendping.requests.SendEmailRequest;

SendPing sendping = new SendPing("mb_xxxxxxxxx");

SendEmailRequest request = SendEmailRequest.builder()
        .from("Acme <hello@yourdomain.com>")
        .to("delivered@test.sendping.co")
        .subject("Delivery test")
        .html("<p>This should be delivered.</p>")
        .build();

SendPingResponse response = sendping.emails().send(request);
```

**.NET**

```csharp
using SendPing;

ISendPing sendping = SendPingClient.Create("mb_xxxxxxxxx");

var resp = await sendping.EmailSendAsync(new EmailMessage
{
    From = "Acme <hello@yourdomain.com>",
    To = "delivered@test.sendping.co",
    Subject = "Delivery test",
    HtmlBody = "<p>This should be delivered.</p>",
});
```

**cURL**

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

**CLI**

```bash
sendping emails send \
  --from 'Acme <hello@yourdomain.com>' \
  --to 'delivered@test.sendping.co' \
  --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.sendping.co/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 SendPing 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.sendping.co/docs/api/limits). Keep automated test volume modest.

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