# Deliverability Is a Commons

*Published 2026-08-20* | Author: civic-team

<blockquote><p><strong class="lede-label">tl;dr</strong> <span class="lede-lead">Email deliverability is a commons: every over-sender degrades the channel for everyone, including themselves.</span> <a href="https://support.google.com/mail/answer/81126" target="_blank">Google</a> and <a href="https://senders.yahooinc.com/best-practices/" target="_blank">Yahoo</a> now enforce a 0.3% spam-complaint ceiling, most fully autonomous AI SDR pilots get pulled inside 90 days, and warmup tricks do not fix a grazing problem. The fix is an audience cap: an explicit ceiling on how much of your market any sequence may touch. A usage cap protects the budget. An audience cap protects the channel. They are not the same cap.</p></blockquote>

<p>Your domain reputation is grazing land.</p>

<p>Every mailbox provider maintains a shared ledger of trust between senders and inboxes, and every message you send draws on it. So does every message your competitors send, and every message their agents send. In 2026 the herd got very large very fast: agents that write, sequence, and send without a human touching the workflow, each one grazing the same pasture your deals have to cross.</p>

<p>Economists have a name for what happens next. In a commons, each grazer captures the whole benefit of one more animal and pays only a fraction of the cost, so everyone adds one more animal until the field is dirt. Nobody intended the dirt. The incentives did it.</p>

<p>That is not a metaphor stretched over email. It is a literal description of how inbox trust works: a finite, shared resource, drawn down fastest by whoever sends most, with the damage billed to everyone on the channel.</p>

<h2>The 90-day pattern</h2>

<p>On Tuesday, <a href="/field-notes/ramp-spent-four-years-rebuilding-outbound">Chris wrote about Ramp</a>: a company that shut down the AI SDR program behind a meaningful share of its pipeline and spent four years rebuilding outbound around selection, bounded action, and a record. Ramp is the famous case. The pattern underneath it is bigger, and it runs on a schedule.</p>

<p>Most fully autonomous AI SDR pilots get pulled inside 90 days. <a href="https://www.digitalapplied.com/blog/ai-sdr-statistics-2026-outbound-sales-data-points" target="_blank">Digital Applied's 2026 aggregation of AI SDR benchmarks</a> puts a number on the leading cause: 47% of attempted deployments hit a domain-reputation wall inside their first 90 days, and roughly a fifth never recover the inbox placement they started with. The 47% is that one aggregation's figure, drawn from sender-platform data, so hold it loosely. The 90-day shape it describes, volume up fast, reputation down faster, pilot pulled, repeats across the independent 2026 summaries of the same benchmark set.</p>

<p>The cycle is almost boring in its regularity. A pilot launches. Volume multiplies, because volume is the one thing the new tooling makes free. Complaint rates creep. The provider throttles. Reply rates fall, which the dashboard misreads as a copy problem, so the pilot sends more. And somewhere around day 90, someone with a title pulls the plug on a program that was killed by its own throughput.</p>

<p>Warmup tricks, domain pools, and clever openers move the wall a few weeks. They do not remove it, because the wall is not a filter to outsmart. It is the pasture running out.</p>

<h2>The fence line</h2>

<p>The fence exists, and it is public.</p>

<p>Since February 2024, <a href="https://support.google.com/mail/answer/81126" target="_blank">Google's sender guidelines</a> require senders to keep spam-complaint rates reported in Postmaster Tools below 0.3%, with bulk senders held to the same 0.30% line. The same page tells you where Google actually wants you: keep spam rates below 0.10%, and avoid ever reaching 0.30% at all. <a href="https://senders.yahooinc.com/best-practices/" target="_blank">Yahoo's sender requirements</a> hold the identical line: keep your spam rate below 0.3%.</p>

<p>Read that number the way it is written. Three complaints per thousand delivered messages is the enforcement threshold. One per thousand is the comfort zone. The distance between a healthy channel and a burned one is two annoyed recipients per thousand, and a fully autonomous sender can close that distance in an afternoon.</p>

<p>The asymmetry is the part most teams learn the expensive way. Damage is fast and recovery is not. Google's guidance says plainly that <a href="https://support.google.com/mail/answer/81126" target="_blank">it can take time for improvements in spam rate to reflect positively on spam classification</a>. The <a href="https://www.digitalapplied.com/blog/ai-sdr-statistics-2026-outbound-sales-data-points" target="_blank">same aggregation</a> reports post-incident reputation recovery measured in weeks: roughly three at Google, closer to seven at Microsoft 365. The over-grazing took days. The regrowth takes a quarter.</p>


CHANNEL HEALTH (interactive: slide sends this month, as a share of your addressable audience, from 10% to 500%; a marker follows an illustrative complaint-rate curve against the two sourced thresholds)
Thresholds sourced: Google enforces at a 0.30% spam rate and recommends staying below 0.10%; Yahoo requires below 0.3%.
100% of your addressable audience (1x): illustrative complaint rate 0.05%. Inside Google's recommended 0.10% ceiling.
200% (2x): 0.13%. Above the recommendation, drifting toward the fence.
350% (3.5x): 0.31%. At the 0.30% enforcement threshold Google and Yahoo publish.
500% (5x): 0.57%. Past the threshold; recovery measured in weeks.
Curve values illustrative, not a benchmark. Thresholds sourced to Google's sender guidelines and Yahoo's sender requirements. Damage is faster than recovery: post-incident reputation rebuilds are reported in weeks, not days.


<h2>Two caps, two jobs</h2>

<p>Part of what Ramp spent four years building, per <a href="/field-notes/ramp-spent-four-years-rebuilding-outbound">Tuesday's piece</a>, was volume discipline enforced in the system rather than promised in a slide. That discipline has a name worth separating from its look-alike.</p>

<p>A usage cap limits how much work a system may do for you: actions run, spend incurred. It protects your budget. It is priced into every plan tier on the internet, ours included, and it knows nothing about your audience.</p>

<p>An audience cap limits how much of your addressable market any sequence may touch in a given window. It protects the channel. It knows your audience and how often that audience has already been grazed, and no plan tier can set it for you, because it is a policy about your pasture, not a feature of anyone's product.</p>


A USAGE CAP IS NOT AN AUDIENCE CAP (static figure). Two caps, two jobs.
USAGE CAP protects the budget. What it limits: how much work the system may do, actions run and spend incurred. Who it protects: you; it keeps the invoice inside the plan. What it knows: your plan tier, nothing about your audience. What it cannot do: stop a sequence from touching the same market twice in a week.
AUDIENCE CAP protects the channel. What it limits: how much of your addressable market any sequence may touch this month. Who it protects: everyone sharing the channel, including you next quarter. What it knows: your audience, and how often it has already been touched. What it is: a policy you set and enforce against the record, not a plan tier.
Do not let anyone sell you the first as the second.


<p>The failure mode is buying the first and believing you bought the second. A usage cap with no audience cap will happily spend its entire monthly allowance on the same three thousand people, twice a week, until the complaint rate crosses the fence line. The budget was protected the whole way down.</p>

<p>Do not let anyone, including us, sell you the first as the second.</p>

<h2>Where Bryn stands</h2>

<p><a href="/bryn">Bryn</a> is the governed execution layer that runs Plays through your stack, and its position on this is deliberately narrow. Plays write only to the channels you name. Usage limits constrain what a month of execution can cost. Suspend stops execution. And every run writes a per-run record: what was sent, where, under which Play.</p>

<p>What Bryn does not do is set your volume policy. The audience ceiling, how much of your market a sequence may touch and how often, stays yours to set. That is not a missing feature. A commons survives when the grazers own their fences.</p>

<p>What the record changes is enforceability. An audience cap you can audit against actual sends, channel by channel and run by run, is a policy. One you cannot audit is a hope. The difference between the two is what the 90-day pattern keeps collecting on.</p>

<h2>The Monday checks</h2>

<p>Two checks, neither of which requires buying anything.</p>

<p>First, open <a href="https://postmaster.google.com" target="_blank">Google Postmaster Tools</a> and read your spam-complaint rate against the published lines: below 0.10% you have room, between 0.10% and 0.30% you are drifting toward the fence, and at <a href="https://support.google.com/mail/answer/81126" target="_blank">0.30% you are on the line Google enforces</a>. If you have never opened Postmaster Tools, that is the finding.</p>

<p>Second, set an audience cap: an explicit ceiling on the share of your addressable market any sequence may touch this month. Write it down, tell the team, and check actual sends against it at the end of the month. If nothing in your stack can produce the actual-sends number, that is the second finding.</p>

<p>The pasture recovers. That is the good news buried in every commons story: fences work, and the grazers who set them are the ones still selling into the channel next year.</p>

<p>Bryn starts at $49 a month with a 7-day trial. Pricing is public at <a href="/bryn/pricing">civic.com/bryn/pricing</a>.</p>

<hr>

<h3>Further reading</h3>

<ul>
<li><a href="/field-notes/ramp-spent-four-years-rebuilding-outbound">Ramp Spent Four Years Rebuilding Outbound. You Shouldn't Have To. (Civic Field Notes)</a>: the famous case, and the architecture that replaced the program.</li>
<li><a href="/field-notes/buy-your-way-out-of-the-signal-gap">Buy Your Way Out of the Signal Gap (Civic Field Notes)</a>: why selection, not sending, is where the advantage moved.</li>
</ul>

<h3>Sources</h3>

<ul>
<li><a href="https://support.google.com/mail/answer/81126" target="_blank">Email sender guidelines (Google)</a>: the 0.30% enforcement threshold and the 0.10% recommendation, verified live 2026-08-16.</li>
<li><a href="https://senders.yahooinc.com/best-practices/" target="_blank">Sender Requirements and Recommendations (Yahoo Sender Hub)</a>: the matching 0.3% spam-rate requirement, verified live 2026-08-16.</li>
<li><a href="https://www.digitalapplied.com/blog/ai-sdr-statistics-2026-outbound-sales-data-points" target="_blank">AI SDR Statistics 2026 (Digital Applied)</a>: the 90-day pattern; the 47% deliverability-collapse figure is this aggregation's number and is single-source.</li>
</ul>

Source: https://www.civic.com/field-notes/deliverability-is-a-commons
