Control plane · Published 2026-09-04 · Updated 2026-10-22 · AgentiSend
Deliverability
The published thresholds, what happens at each one, and how to read the reputation panel.
We publish the numbers we judge you by. Every figure on this page is read at build time out of the same module the API enforces with and the console draws.
The two tables
They answer different questions. One is when a human should look; the other is when we act.
When the panel goes amber
| Metric | Warn | Limit |
|---|---|---|
| Bounce rate | 2% | 4% |
| Complaint rate | 0.05% | 0.08% |
The panel's red line is the exact rate at which enforcement begins, so a domain sitting on the line is not a warning you can sit on.
When we act
| Metric | Warn | Pause |
|---|---|---|
| Bounce rate | 2% | 4% |
| Complaint rate | 0.05% | 0.08% |
Complaint counts come from mailbox providers that send us feedback reports; Gmail, Yahoo and Outlook do not send them to us today, so a complaint rate of 0 is not evidence that nobody complained.
From 100 delivered-or-bounced sends in the rolling window, the rate itself is compared with the line. Below that, a step needs at least 5 bounces or 3 complaints and a rate still over the line at the low end of its 95% confidence range (early_min_events on GET /trust/thresholds). One step per evaluation. The throttle figures on GET /trust/thresholds equal the pause lines — the ladder does not enter a throttle rung.
A refusal for spam or for the message's content counts as a bounce: the recipients and the message are yours. A refusal that names our sending address, its reverse DNS or our signature does not.
The headline and the bounce rate tile
The sentence at the top of the Deliverability screen and its bounce rate tile show the rate we enforce, counted the way we enforce it: over the last 7 days, each recipient address once however often it bounced, and without refusals that name our sending addresses. Ten soft bounces to one full mailbox are one bounced address, not ten. Until a domain reaches 100 sends or 5 bounced addresses, the headline gives the count and says it is too few to judge, because that is what enforcement does with it.
The bounce classes and the trend below the tile count every bounce event in the window you pick, retries included, so their totals can be larger than the tile's.
Standing is hysteretic
A domain that dips back under a threshold does not clear at that instant — it clears at the next review. This is deliberate: a rate that oscillates across a line would otherwise flap the standing, and a badge that changes every five minutes is a badge nobody reads.
Bounces are classified, not counted
A hard bounce, a soft bounce, a block and a suppression are four different problems with four different fixes, so the panel separates them and each class links to the messages behind it. A bounce rate with no classes under it tells you something is wrong and nothing about what.
Hard bounces and complaints add the recipient to the suppression list automatically. Sending to a suppressed address is refused rather than delivered — see the suppression.* events in the event catalogue.
Blocklist monitoring
Every verified domain is checked once a day against the Spamhaus Domain Blocklist (DBL), the domain list receivers use on the sender and on the links in a message. A subdomain such as mail.example.com is checked as itself and as example.com, because a listing of the parent hurts mail from both. The first check runs within an hour of the domain verifying.
The list gets one of three answers, shown in the Blocklists panel on the Deliverability screen with the time of the check:
| Answer | Meaning |
|---|---|
| listed | The list names the domain. The panel links the list's own lookup and removal page. |
| not listed | The list answered and does not name the domain. |
| could not check | The list refused the query or did not answer its own test entry. This is never read as not listed. |
When a check finds a domain newly listed, you get a domain.blocklisted event (see the event catalogue) and a notification in the console, mailed to every member of the account unless the email switch for it is off in Settings → Notifications. A listing raises both once; the notification closes when a later check finds the domain clean. The same answers are returned by GET /deliverability/domains/{id} under blocklists.
The mail itself leaves from shared sending addresses we operate. We check those against the IP blocklists every hour and deal with any listing ourselves.
A listing usually has a cause you can find: a sign-up form filled by bots, a hijacked account sending through your key, a link in your mail to a site that is itself listed, or a sudden jump in volume to old addresses. Fix the cause first, then ask for removal on the list's page; a list that sees the same behaviour again lists the domain again.
What actually moves the number
- Send to addresses that asked for mail. There is no supported cold-outreach path here, and there will not be one.
- Publish SPF, DKIM and DMARC and keep them published. See Domains and DNS.
- Handle bounces the day they happen, not at the end of the month.
- Raise volume gradually on a new domain. A domain with no history that sends fifty thousand messages on its first day is indistinguishable from a compromised one.
Sending capacity
No paid plan has a daily cap, but mail still leaves at the pace the receiving side accepts it. Each inbox provider takes a limited number of messages an hour from one sending address, and it raises that number as the address builds a record with it. Our sending addresses are shared across accounts and warmed on a schedule, so the pace to each provider rises week by week.
A message waiting for the next window has not failed: it is still on its way, and you may get an email.delivery_delayed event while it waits. Do not resend it, or the recipient gets it twice. Read its state with GET /emails/{id}.