# Deliverability & karma

{/* // TWO-WAY, NOT BLAST */}

Postern is positioned as **two-way transactional and agentic mail — not cold-outreach volume.** That
framing drives every deliverability control: the goal is that an agent's real, expected mail lands,
and that one misbehaving agent can't poison the pool.

## Authenticated sending

Every Postern mailbox sends through Azure Communication Services as an **authenticated sender**,
registered at create time. That means:

- **SPF + DKIM pass**, aligned to the sending domain;
- **DMARC** is published at least `p=none`, aligned;
- behind an [NS-delegated](https://docs.agents.mszazu.com/concepts/domains-and-onboarding/) zone, our DNS auto-serves the DKIM
  CNAMEs, SPF, and MX so authentication is correct without you adding records.

This is why a Postern send doesn't bounce the way a raw SMTP relay would — the authentication story is
handled before the first message goes out.

## 2026 bulk-sender rules, enforced platform-wide

Postern enforces the Gmail / Yahoo bulk-sender requirements across the whole platform, so you inherit
compliance instead of implementing it:

| Requirement | How Postern meets it |
|---|---|
| SPF + DKIM pass | Authenticated ACS sender + served DNS records |
| DMARC ≥ `p=none`, aligned | Published per domain (delegated or manual) |
| One-click unsubscribe (RFC 8058) | Added on subscribed mail |
| Low complaint rate | Auto-throttle + kill-switch keep complaints `<0.1%` (hard ceiling `<0.3%`) |

## Ramping send caps

New mailboxes don't get full volume on day one. Per-mailbox daily send caps **ramp** as a mailbox
proves itself — roughly 5–10/day to start, climbing to 30–50/day over weeks. This mirrors how warmed
infrastructure behaves and keeps a fresh address from tripping spam heuristics.
**Caps are per-mailbox and per-token:** Two limits stack: an enrollment key's mailbox quota (`max_mailboxes`) and each mailbox's ramping
  daily send cap. Both are surfaced in error responses (`429` with `Retry-After`) so your agent can
  back off cleanly. See [Rate limits & quotas](https://docs.agents.mszazu.com/operating/limits/).

## Karma — throttle, don't blunt-cap

Instead of a single hard ceiling, Postern tracks **karma** per agent. Sends spend karma; **replies
earn it back**. A high-karma agent (the kind that holds real two-way conversations) gets more
headroom; a low-karma agent (one that only blasts and never gets replies) gets throttled. The effect:
legitimate transactional patterns are rewarded, and one-directional spray is naturally slowed without
punishing fan-out across many mailboxes.

## Reputation segmentation

Reputation is **segmented per subdomain**, each with its own DKIM. One bad agent's blast radius is
contained to its subdomain rather than the whole pool. Reputation-sensitive cohorts route to
isolated `spring*` domains so a risky workload can't drag down a healthy one. segmentation by design

## Auto-throttle & kill-switch

Postern watches bounce and complaint signals continuously. A spike triggers automatic throttling and,
past a threshold, a kill-switch on the offending mailbox or agent — before the pool's reputation is
damaged. This is enforcement, not advice: it happens platform-side without you wiring anything.
**Built for the right shape of mail:** These controls assume agentic, two-way, transactional mail: sign-ups, confirmations, replies,
  notifications. Postern is not a cold-outreach volume tool in V1, and the deliverability model is
  tuned for that on purpose.

## Next

- [Domains & onboarding](https://docs.agents.mszazu.com/concepts/domains-and-onboarding/) — the DNS authority these controls use.
- [Rate limits & quotas](https://docs.agents.mszazu.com/operating/limits/) — the concrete numbers and headers.
- [x402 test mode](https://docs.agents.mszazu.com/payments/x402-test-mode/) — economic anti-abuse alongside karma.