Sendtier is in public preview
What works in the Sendtier public preview today, the limits that apply, where the service runs, and what is still planned.

Sendtier is a transactional email API that shows what happened to each email you send. Next to the usual statuses, it shows the receiving server's own reply for each recipient, so a bounce or a deferral comes with the reason the other side gave. Sendtier has been in public preview since 7 October 2026. This post lists what works today, the limits that apply, and what is still planned.
What works today
Sending. POST /v1/emails accepts one email, and POST /v1/emails/batch accepts several. An Idempotency-Key header makes a retry safe: Sendtier keeps the key for at least 24 hours, and a repeat of the same request returns the stored result instead of sending again.
Test and live keys. Keys that start with st_test_ run the full flow without delivering anything. A test email is accepted, checked against your suppressions and recorded, and it never reaches a mailbox. Keys that start with st_live_ send real mail. Scopes limit what a key can do: full, sending (send routes only) or read_only (usage only).
Domain verification. You publish three DNS records: a DKIM key, a return-path CNAME and a DMARC record. Sendtier signs your mail with a 2048-bit DKIM key for your domain, and the return-path record makes SPF align with your domain too. The DMARC guide explains how to go from the suggested p=none to p=reject.
Events with server replies. Each email collects events: email.queued, email.sent, email.delayed, email.delivered, email.bounced, email.complained and email.failed. A delivered event carries the receiving server's reply. A bounce carries its type and the diagnostic text. Why delivered is not the inbox explains what those replies can and cannot tell you.
Signed webhooks. Webhook requests carry a Sendtier-Signature header with an HMAC-SHA256 signature over the timestamp and the body. Test and live endpoints are separate, and each has its own secret. See webhooks.
Suppressions. A permanent bounce or a spam complaint adds the address to your suppression list, and a later send to it returns 422 recipient_suppressed. You can add your own entries with the reason manual. See suppressions.
What one email looks like
Take a password reset sent with a live key. The API accepts it and records email.queued. The worker builds the message, signs it with your domain's DKIM key and hands it to Sendtier's mail server. When the mail server accepts it, the email gets email.sent. From there, one of three things happens for each recipient:
- The receiving server accepts the message. The email gets
email.delivered, with the server's reply, for example250 2.0.0 OK. - The receiving server defers it. The email gets
email.delayedwith the reply, and the mail server tries again later. - The receiving server rejects it. The email gets
email.bouncedwithbounce_type, the enhanced status code and the diagnostic text, such as550 5.1.1 user unknown. A permanent bounce also suppresses the address.
You see the same events in the dashboard, in GET /v1/emails/{email_id} with a full key, and on your webhook endpoints. A test-mode email stops after email.sent, because it is never handed to a receiving server.
What "preview" means
Preview is about capacity and scope, not about the API contract. Paths start with /v1, and changes within /v1 stay backward compatible; a breaking change would use a new prefix such as /v2 (authentication). What can change during the preview are the limits below and the list of features that are still planned.
Limits in the preview
| Limit | Value |
|---|---|
| Free plan, live recipients | 100 per UTC day, 3 000 per month |
| Test sending | 1 000 recipients per UTC day, separate from the live caps |
| Live sending | Limited during the preview |
Live sending follows a warm-up schedule for our sending IPs, so daily caps can be lower than the plan cap while the schedule runs. The rate limits page has the current rules. Every recipient counts toward the caps, including recipients in batch and scheduled sends.
Where it runs
The API, the dashboard and the database run on Laravel Cloud. Live mail leaves from Sendtier's own mail server, which runs KumoMTA on an OVHcloud server in Limburg, Germany. The subprocessor list names each provider, what it processes and where.
Not yet
- Paid plans. Pro (€49 per month, 100 000 recipients) and Scale (€399 per month, 1 000 000 recipients) are planned and not on sale. See pricing.
- Published SDKs. The SDKs are not published to package registries yet. Use the HTTP API.
- SMTP relay on a public host. The relay exists, and its public rollout is still pending.
- Inbox placement. Sendtier reports what the receiving server said. It does not measure where the message landed.
- Open and click tracking. Sendtier adds no tracking image and does not rewrite links.
- Receiving mail. Inboxes that receive mail for your customers are not available yet.
Send a test email
Create an account at app.sendtier.com. Add a domain you own in Domains → Add domain; its DNS records can stay pending for a test send. Switch the dashboard to Test and create a key with the sending scope. Then run the request below, with hello@mail.example.com replaced by an address on your domain and user@example.com by your own address:
The API answers 202 Accepted with an em_ ID and the status queued. Queued means accepted, not delivered. The quickstart covers the domain, the keys and the first live send.
If something does not work the way this post says, write to hello@sendtier.com.