Deliverability

We publish the numbers we judge you by. Every figure on this page is read out of packages/deliverability/src/thresholds.ts at build time, which is 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

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

No automatic step until the rolling window holds 100 delivered-or-bounced sends. One step per evaluation. The throttle figures on GET /trust/thresholds equal the pause lines — the ladder does not enter a throttle rung.

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.

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.