Deliverability

A newsletter can never break a password reset.

Every rule here exists because of a specific way mail stops arriving. Two identities per domain so reputations cannot bleed. Suppression with a scope so an opt-out blocks the right mail and only that. A gate that refuses the campaign that would get the account reviewed.

Start free Verify a domain

One callPOST /v1/domains

{ "domain": "acme.com" }

Two identities201 Created

{ "data": [
  { "domain": "mail.acme.com",
    "risk_class": "transactional",
    "status": "pending",
    "dns_records": [ … ] },
  { "domain": "news.acme.com",
    "risk_class": "marketing",
    "status": "pending",
    "dns_records": [ … ] }
] }

Two identities

Mailbox providers score the From domain. So there are two.

mail.acme.com   transactional   receipts, resets, replies
news.acme.com   marketing       campaigns, sequences

# routed by the risk class of each message
POST /v1/emails
{ "from": "Acme <hi@mail.acme.com>", … }
→ "risk_class": "transactional"

{ "from": "Acme <hello@news.acme.com>",
  "risk_class": "marketing", … }

# a campaign from the wrong side
403 { "error": { "type": "no_verified_identity" } }

Reputation is scored per sending domain. If transactional and marketing mail share one, a campaign with a complaint spike takes the password resets down with it, and that is the failure this split prevents. mail. and news. are separate identities with separate reputations all the way down: separate DNS records, separate sending configuration in the layer underneath, separate metrics.

risk_class is a required concept, not a tag. Every message is one or the other, the sending identity is resolved from it, and broadcasts and automations only send as marketing. A sequence that tried to go out from mail. is refused when it is defined, not discovered as a failed enrolment later.

Marketing mail also carries a one-click unsubscribe header and a footer with the sender’s postal address. A marketing send without an address on the workspace is refused with no_postal_address, because made optional it is the field nobody fills in.

Suppression

An opt-out has a scope. A bounce does not.

GET /v1/suppressions

{ "data": [
  { "email": "maya@acme.com",
    "reason": "unsubscribe",
    "scope": "marketing" },
  { "email": "old@acme.com",
    "reason": "hard_bounce",
    "scope": "all",
    "detail": "550 5.1.1 user unknown" },
  { "email": "angry@acme.com",
    "reason": "complaint",
    "scope": "all" }
] }

# a receipt to maya still goes out
POST /v1/emails { "to": "maya@acme.com", … }
202 { "status": "sent" }

# a newsletter to her does not
202 { "skipped": true,
      "reason": "suppressed:unsubscribe" }

A marketing unsubscribe never blocks transactional mail. Someone who leaves the newsletter still gets their invoice and their password reset. An opt-out is scoped to marketing; only hard bounces and complaints get scope: "all", because those addresses should get nothing.
Transient bounces are not suppressed. A full mailbox or greylisting resolves on its own. Suppressing it silently shrinks a healthy list, one out-of-office at a time. Only a permanent bounce writes a suppression.
A complaint always suppresses everything. Someone pressing spam is the signal mailbox providers judge a domain on. That address is not mailed again, from either identity.
A suppressed send is recorded, not dropped. It comes back 202 with skipped: true and the reason, and it appears in the log, so support can answer why something did not arrive.

Every send checks the list because every send goes through one function. A caller that could bypass it would mail people who opted out or bounced, which is how an account gets its sending paused. Removing a suppression is possible, and it is never the fix for a failed send.

Unsubscribe

Unsubscribe is two writes.

# one-click, from the header or the footer
POST /api/unsubscribe?token=…

1. suppress  maya@acme.com  scope: marketing
2. cancel    every scheduled send to her
   and end   every automation enrolment

# what a single write looks like from her side
day 0   welcome         (opened, unsubscribed)
day 3   three things    ← still arrives
day 10  how is it going ← still arrives

Suppressing the address stops new sends. It does nothing about the ones already queued. A welcome sequence is three or four messages scheduled days apart, and if the opt-out only writes the suppression, days three, six and ten still arrive. To the person it looks like an unsubscribe that did not work, and the next click is the spam button.

So the unsubscribe path does both: it suppresses, and it cancels every pending scheduled send for that recipient. Because automations generate their next step live, it also ends the enrolment, or the sequence would just produce the next one. Opting down from a single topic does neither; the person still wants some of your mail, and a suppression row would silently block it.

Unsubscribe tokens are scoped to the workspace as well as the address, so a link from one tenant cannot opt someone out of another.

It says no

Refused before it starts. Paced once it does.

GET /v1/broadcasts/:id/previewThe reputation gate: bounce and complaint rates over the last 14 days, checked against ceilings set short of the thresholds that get an account reviewed. A campaign that would cross them is refused with blocked_reason, and the check runs again in the send path just before the fan-out. Campaigns.
50 recipients per call, N per secondThe layer underneath accepts fifty destinations per bulk call and enforces a per-second send rate. Everything that fans out is chunked to that size and paced against the account’s rate on purpose. Ignoring the pacer turns a healthy campaign into thousands of throttle retries; pacing it turns a large list into a long, quiet run.
suppressed before, not duringA fan-out resolves the suppression list once for the whole run, not per recipient, and the count in the preview is already net of it.
workspace_suspendedEvery tenant shares the reputation of the layer underneath, so one tenant’s bounce rate can get sending paused for all of them. Staff can suspend a workspace, and the check sits at the last point before dispatch, so it also halts scheduled mail and a campaign already fanning out.

The checks sit in the send path, not on a dashboard.

Verify a domain and both identities come with it. Read the quickstart, subscribe to bounce and complaint events, or see what else the same key covers.

Start free Quickstart