Deliverability is an infrastructure problem in a copywriting costume

The one-click unsubscribe button in a Gmail header is not a button. It is a pair of message headers, List-Unsubscribe and List-Unsubscribe-Post, and they only work if they sit inside the DKIM signature. If those two header names are missing from the h= tag your signer emits, the receiving mailbox provider sees headers it cannot trust, and the one-click unsubscribe that Google requires of bulk senders is simply not honoured.

That is why our own signing code carries both headers in its default signed set, and why a committed test fails the build if either one ever leaves it. The comment in the test says the quiet part: one-click unsubscribe is only honoured when both headers fall within the DKIM h= tag.

Now consider how much of the deliverability advice you have read this year would have caught that. Shorter subject lines. Fewer links. Warmer opening paragraph. Write like a human. None of it reaches a signing configuration. The advice is not wrong so much as aimed at a different layer of the stack than the one that decides whether the message arrives.

What the receiving side actually asks for

Google's sender guidelines for bulk senders are short and none of the entries are about prose (https://support.google.com/a/answer/81126, fetched 14 August 2026). Set up SPF and DKIM for your domain. Set up DMARC for your sending domain. Support one-click unsubscribe and include a clearly visible unsubscribe link in the body. Keep spam rates reported in Postmaster Tools below 0.30 percent, with Google's own guidance recommending you stay below 0.10 percent and never reach 0.30 percent.

Four requirements. Three of them are DNS records, key management and header construction. The fourth, the complaint rate, is the only one copy influences, and it influences it indirectly, through whether the recipient wanted the message at all.

So the honest split is this. Copy determines whether a message is welcome. Infrastructure determines whether it is delivered. A brilliant email that fails DMARC alignment does not land in a spam folder where a human might rescue it. Increasingly it is rejected at the edge and never enters the mailbox at all.

What you cannot fix from the copy layer

Here is the practical test for whether a deliverability problem is a writing problem. Ask what you would have to change to fix it.

If the answer is a DNS TXT record, a key rotation, a return-path domain, a signing header list, a dedicated sending IP, a connection concurrency budget, a bounce classification rule, a suppression list write, or a warmup ramp, then no amount of rewriting touches it. Those are all operational properties of the machine that puts the message on the wire. When that machine belongs to someone else, you cannot change any of them, and the vendor selling you the copywriting course cannot either.

This is not an argument that copy is unimportant. It is an argument that the two layers fail differently, and that most teams have visibility into one of them and none into the other, which is exactly the situation in which the visible layer gets blamed for everything.

What owning the layer looks like

SAGARIS runs its mail platform as its own Go module with its own service boundary, rather than posting messages to a third-party sending API. The pieces are named in its README, and the list is a fair description of what "deliverability is infrastructure" means in practice:

- Edge injection: durable claim, safety recheck, MIME assembly, DKIM and egress preparation, injection into KumoMTA at the edge, and acknowledgement state. - Mailbox store: mailbox provisioning and mailbox-visible delivery, backed by a Stalwart IMAP and JMAP store. - Inbound MX listener: an SMTP listener of our own, so replies arrive over our infrastructure rather than through a polled third-party inbox. - Submission: internal HTTP and authenticated SMTP submission. - Public router: signed tracking, redirects, and the unsubscribe projection that the header above points at. - Domain authentication: DKIM signing, DMARC report intake, and registrar and DNS automation. - Deliverability control: admission, suppression, limits, enforcement, shaping and transport, with per-IP state resolved rather than assumed. - Warmup: schedule and ramp evaluation, reservations, usage and recipient caps. - Measurement: collectors, placement, scoring and reputation history.

Owning the boundary is what makes the opening example possible. Deciding which headers get signed is a decision you can only make if you control the signer.

There is a nice second-order property of building it this way. A committed test binds the Go worker-mode constants to the literal strings in the Terraform environment blocks that deploy them, in both directions. Terraform cannot read Go and Go cannot read Terraform, so a rename in one place used to be invisible until something silently stopped running. Now it fails a test.

The number we do not publish, and why

Every deliverability vendor wants to tell you an inbox placement rate. We do not have one to tell you, and the way the code handles that absence is the most useful thing in this article.

The measurement code defines a placement status with four values. Three of them are the ones you would expect: healthy, watch, degraded. The fourth is no data, and its comment states the invariant: it is the only honest status when the distribution denominator is zero, and it is deliberately distinct from every other status so that absence of data can never be presented as health. A guard error carries the rule in its message: placement status requires distribution observations, and no-data is never healthy.

That sounds like a small typing decision. It is the difference between a dashboard that goes grey when nothing has been measured and a dashboard that goes green.

The same discipline governs what appears on this site. SAGARIS publishes no inbox placement percentage, because no such measurement exists at scale to publish. The mail platform is claimable as architecture and as a set of fail-closed operational postures. It is not claimable as delivery results, and any article, page or sales conversation that turns it into a placement figure is making something up.

While we are here: the deliverability statistics circulating in this market are worth treating with the same suspicion. The commonly repeated figures, an 89 percent inbox placement rate for compliant senders and a 3x to 7x penalty for non-compliance, trace only to vendor marketing pages rather than to any Google, Yahoo or Microsoft postmaster documentation. We checked for a primary source and did not find one, so we do not repeat them, and neither should the vendor quoting them at you.

Fail closed, and mean it

The mail module states its safety invariants at the top of its README, and two of them matter for anyone evaluating a sending platform.

The first is that the outbound gate stays closed until an explicit go-live decision. Not closed by convention, not closed by a runbook step someone remembers, closed as the committed default. Nothing sends because a deploy happened.

The second is that required suppression, admission, limit, credential and egress dependencies fail closed. If the suppression store cannot be reached, the answer is not "send anyway and reconcile later". The answer is that the message does not go.

There is a third that is easy to skim past and is really a lesson about every health check you have ever trusted. The README separates health from readiness: health answers whether the process is alive, readiness answers whether the configured mode can safely do its work. A memory store, a fake publisher, a fake object store, a missing credential source or an unreachable edge cannot report production-ready for work that requires them. Its instruction to operators is to read the returned detail rather than infer readiness from an HTTP status. A green check that never looked at anything is the most expensive kind of green.

What this is and what it is not

The mail module carries 4,166 test functions across 584 test files at the commit this article was written against. That is a real number about a real body of code and it is also, precisely, not a claim about your reply rate. It says the machinery is tested. It says nothing about whether a given campaign lands, because the thing that determines that is a combination of your domain history, your list, your complaint rate and your copy, and three of those four are yours.

The reason to care about the infrastructure layer is not that it replaces good writing. It is that when deliverability drops, the copy layer is the only place most teams can look, so that is where they look, and the actual cause sits three layers down in a signing configuration nobody owns.