# Send test (deliverability-grade check)

> Some addresses cannot be settled by SMTP probing alone, a catch-all domain accepts everything, so "accepted" proves nothing. A send test resolves those the…

Source: https://warmerly.com/docs/verify/send-test-deliverability-grade-check

Some addresses cannot be settled by SMTP probing alone, a catch-all domain accepts everything, so "accepted" proves nothing. A send test resolves those the only way that actually works: it sends one real message from one of your own warmup mailboxes and watches for a bounce.

```text
POST /verify/send-test
GET  /verify/send-test/{id}
```

| Field | Type | Required | Description |
| --- | --- | --- | --- |
| `email` | string | Yes | Address to test, 3 to 320 characters. An address that is not valid returns `400 bad_request` (`invalid_email`). |
| `checkId` | string (UUID) | No | Links the result back to an earlier verification, so the original check is refined rather than duplicated. |

```json
{
  "test": {
    "id": "9f1c2d3e-4a5b-4c6d-8e7f-0a1b2c3d4e5f",
    "email": "sam@example.com",
    "status": "awaiting_bounce",
    "fromAccount": "jane@yourdomain.com",
    "bounceCode": null,
    "bounceMessage": null,
    "failureReason": null,
    "deadlineAt": "2026-09-12T10:15:00.000Z"
  }
}
```

`GET /verify/send-test/{id}` is the poll: each call does a throttled IMAP check for the bounce and returns the current `status`, `awaiting_bounce`, `valid`, `invalid` or `failed`. The watch window is about five minutes (`deadlineAt`). A bounce inside it makes the test `invalid`. A reply from the address, or reaching `deadlineAt` with no bounce, makes it `valid`. So `valid` here means "no bounce came back in the window", not proof the mailbox is read. A poll made after `deadlineAt` is what settles the test, so keep polling until the status is no longer `awaiting_bounce`.

Notes worth knowing before you wire this up:

- It requires a connected sending mailbox, one of your own that is active or aging, can send, and whose inbox Warmerly can read. With none, the test comes back immediately as `failed` with `failureReason: "no_account"` rather than erroring. Other send failures also come back as `failed`, with the error text in `failureReason`. A recipient server that refuses the address while the message is being sent makes the test `invalid` straight away.
- Your plan must include email features, otherwise the call returns `403 channel_not_included`.
- Polls are throttled: calls within 15 seconds of the last inbox check return the stored status without a new check. `GET /verify/send-test/{id}` returns `404 not_found` for a test that is not yours.
- It sends **real email from your mailbox**, so it affects that mailbox's reputation like any other send. Use it to settle a handful of ambiguous addresses, not as a bulk strategy.
- It is **not** billed as a separate verification. It refines a check that was already counted.

## More from Verify

- [Bulk verification](https://warmerly.com/docs/verify/bulk-verification): Submit a list of addresses as an asynchronous batch, then poll for results. Quota for the full batch size is…
- [Verification history](https://warmerly.com/docs/verify/verification-history): Returns the recent single verifications (from POST /verify) recorded against your active workspace, most…
- [Usage / quota](https://warmerly.com/docs/verify/usage-quota): Returns your current verification usage against your plan's limit for the billing period. Checking usage…