Bulk sender requirements — the 0.3% complaint ceiling and what triggers it.

What the policy actually says

The bulk-sender policy is not an RFC. It is published guidance from two private mailbox providers acting in coordination, enforced at their inbound MTAs at the discretion of their classifier infrastructure. A sender that fails the policy does not receive a 5xx SMTP rejection with a citation; the sender receives degraded inbox placement, then routing to spam, then in the limit a temp-fail (4xx) at SMTP transaction without explanation. The policy is enforceable because the receivers control the inbox.

The four criteria, stated at the receivers' own level of formality:

1. Mail is authenticated. SPF and DKIM both pass and align, and a DMARC record is published at minimum p=none.
2. Bulk commercial mail offers a one-click unsubscribe mechanism conforming to RFC 8058, surfaced in standard mail-client UI within a single user gesture.
3. Spam complaint rate, measured at the receiver and exposed via Postmaster Tools, stays below 0.30% as a rolling daily average — with stated guidance to aim under 0.10%.
4. All SMTP transactions on both inbound and outbound legs occur over TLS.

Each criterion has more operational surface area than the one-line summary suggests. The third criterion — the complaint rate — is the criterion most senders fail.

The 5000-per-day threshold

Bulk-sender status is triggered at 5000 messages per day, measured aggregate per sending domain to a single mailbox provider's user population. Three components of that definition each break an operator's mental model.

Per sending domain. Not per inbox, not per IP, not per sending platform. Every authenticated From: domain a sender controls contributes to a single rolling counter, regardless of whether the messages originated from a CRM, a sequencing platform, a transactional service, or a billing system. A 12-inbox cold-outbound stack on one organizational domain operates under one threshold, not twelve.

To a single mailbox provider. The counter resets per receiver. 5000 to Gmail is the trigger; 5000 to Yahoo is a separate trigger. The consumer mailbox population is asymmetrically concentrated at one provider, so the Gmail counter is the one that matters for any English-language outbound program targeting a US or European prospect base.

Per day. A rolling 24-hour window, not a calendar day. A sender pushing 4900 messages at 9pm and 4900 at 10am next morning is over the threshold by the receiver's reckoning, even though the calendar-day arithmetic looks compliant.

The mental-model gap: operators reason about volume per inbox — typically 30 to 40 messages per day per mailbox during steady-state sequencing. A 12-inbox estate at 35/day is 420 messages, comfortably under 5000, and the operator concludes the policy does not apply. The arithmetic is correct and the conclusion is wrong, because once the estate scales to 150 inboxes or once a transactional flow on the corporate domain is included in the count, the per-domain-per-receiver aggregate crosses the threshold on a normal workday. Senders typically discover this at the moment placement degrades.

Requirement 1 — Authentication

The first requirement is a hard prerequisite of the prior four chapters of this reference: SPF (Chapter 1) configured under the 10-lookup limit, DKIM (Chapter 2) signing operational at 2048-bit, and DMARC (Chapter 3) published at minimum p=none with a functioning rua destination. The receiver evaluates SPF and DKIM independently; both must produce a pass result, and at least one must produce an aligned pass result for DMARC.

The word aligned is operative. A sender publishing SPF and DKIM correctly but with the authenticated domain not matching the visible From: header — a common failure mode on third-party platforms that sign DKIM under their own domain — produces unauthenticated mail by the receiver's definition, regardless of the cryptographic correctness of the signatures.

A DMARC record at p=none satisfies the letter of the policy. A DMARC record at p=quarantine or p=reject satisfies the policy and produces receiver-side trust signal that reduces classification pressure on every other criterion. The senders who treat p=none as the compliance bar typically discover, at the moment volume grows, that compliant and delivered are not the same word.

Requirement 2 — One-click unsubscribe

RFC 8058 specifies a one-click unsubscribe mechanism layered on the older RFC 2369 List-Unsubscribe header. A compliant bulk message includes two headers:

List-Unsubscribe: <mailto:unsub@example.com>, <https://example.com/u/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe header carries two URIs: a mailto: and an https://. Both are required. The mailto: handler is the legacy path; the https:// handler is the one the modern receiver UI actuates when the recipient clicks the unsubscribe affordance.

The List-Unsubscribe-Post header is the RFC 8058 addition. It signals that the https:// URI accepts an HTTP POST with a body of List-Unsubscribe=One-Click, and that this POST is itself the unsubscribe action — no further interaction required.

The semantic constraints on the https:// endpoint are strict. The URI must accept an unauthenticated POST. The POST must execute the unsubscribe without further interaction — no confirmation page, no login wall, no captcha, no preferences-center routing. The endpoint must return a 2xx within roughly two seconds. The receiver's classifier observes endpoint behavior across senders; a URI that returns a confirmation HTML page instead of processing the POST scores the same as no unsubscribe at all.

The operator failure mode here is endemic. The compliance team adds a List-Unsubscribe header pointing at the existing marketing preferences center, the preferences center requires a login or presents an "are you sure?" page, and the deployment is technically headered but functionally non-compliant. The receiver-side classifier does not parse the header in isolation; it scores the URI's actual behavior across the message population carrying that header.

Requirement 3 — Spam complaint rate under 0.3%

The spam complaint rate is the single binding constraint for cold outbound. The other three requirements are configuration checkboxes — set once, audited periodically, otherwise stable. The complaint rate is a continuous output of message-by-message recipient behavior, and it is the criterion cold-outbound senders most often fail.

A complaint, in the receiver's accounting, is a recipient clicking "Report spam" in the mail client. Not an unsubscribe, not a soft-bounce, not a no-reply. The receiver does not operate a complaint feedback loop the way older ISPs do — there is no inbound stream of complaint notifications a sender can subscribe to. The only visibility a sender has is the rolling daily average exposed in the receiver's postmaster dashboard (Chapter 11).

The policy sets enforcement at 0.30% and stated good at 0.10%. The three-times gap is the operational warning band. A sender at 0.15% is not in violation but is producing receiver-side signal that the campaign is closer to unsolicited than to wanted. Sustained 0.30%+ is enforcement territory, and enforcement at scale is not gradual — degraded placement begins on the first day the metric crosses, and recovery from a single bad campaign requires weeks of clean volume.

The arithmetic is unforgiving. 0.30% of 5000 messages per day is 15 complaints. A single bad campaign — wrong list, off-target persona, content read as bulk — produces complaint rates an order of magnitude above the threshold, and the rolling 24-hour window means a single bad day is visible in the next day's classification.

Requirement 4 — TLS for all SMTP transactions

The fourth requirement mandates encrypted SMTP on both inbound and outbound legs of every transaction a sender participates in. For outbound, this means the sending MTA must initiate STARTTLS on every connection to the receiver's inbound MX. For inbound — which applies to any sender domain that accepts mail at all, including the bounce-handling address on a cold-sending domain — the sender must publish MTA-STS (Chapter 4) at policy mode enforce and accept inbound mail only over TLS.

The implication for a cold-outbound estate: the bounce-handling and reply-routing infrastructure on the sending domain is itself a receiving MTA in the policy's reckoning. Sending domains that route replies through a poorly configured forwarder without TLS — observed in the wild on several mid-tier sequencing stacks — fail the criterion on the inbound leg without the operator's awareness.

Cold outbound and the bulk-sender threshold

The architectural implication of the per-domain-per-receiver threshold is the single most consequential design constraint on a cold-outbound estate operating at scale. Consider a steady-state program: 50 mailboxes, 35 messages per day per mailbox, all on the same root organizational sending domain — 1750 messages per day total, well under the threshold by any reasonable arithmetic. Apply the realistic distribution: roughly 75% of business email addresses in a North American prospect base resolve to a Gmail-hosted tenant, either consumer Gmail or Workspace-hosted business email, which from the policy's perspective is the same receiver. The Gmail-bound count is approximately 1300/day, still under.

Scale to 200 mailboxes — a routine number for a Series A SDR organization — and the Gmail-bound aggregate is approximately 5200/day. The threshold is crossed. Scale to 500 mailboxes, typical of a growth-stage operation, and the count is 13,000/day. The operator who reasoned at the per-mailbox tier was always going to cross it; the only question was when.

The architectural response is separation of cold-outbound sending across multiple organizational domains, each individually below the threshold and each individually reputation-isolated. This is the topic of Chapter 7, and the bulk-sender policy is the receiver-side reason that chapter's pattern exists.

The progressive enforcement timeline

The policy announced October 2023 specified enforcement beginning February 1, 2024. The receiver's actual enforcement has tracked roughly the following timeline:

The practical implication: a sender configured to the February 2024 standard is configured to a 2024 receiver. The 2026 receiver weighs the complaint rate more heavily, evaluates the unsubscribe endpoint more rigorously, and tolerates less drift on any single criterion.

The 0.1% vs 0.3% gap

The receiver publishes guidance to aim under 0.10%. The enforcement threshold is 0.30%. The operator who reads the latter as the target is making an error of risk arithmetic.

A sender operating at 0.25% is in compliance. A sender operating at 0.25% on a Monday is one bad campaign — one mis-segmented list, one tone-deaf subject line, one wrong-persona prospect batch — from sustained 0.40% on Tuesday. The complaint rate is a rolling average and the rolling window is shorter than the campaign cycle. The operational target is the stated guidance number, 0.10%, with margin. The enforcement number is the floor under which compliance is technically maintained, not the ceiling under which a sender should plan to operate.

The senders observed in production at sustained sub-0.05% complaint rates are not sending the most personalized content. They have the most disciplined list construction — narrow ICP definitions, recent activity signals, willingness to suppress prospects whose engagement pattern signals likely complaint. List quality dominates content quality in the complaint metric by a factor that surprises operators arriving at outbound from a content-marketing background.

Common deployment failures observed in production

• List-Unsubscribe header with a confirmation page. The header is published, the URI accepts the POST, the POST returns an HTML page that asks the recipient to confirm. The classifier observes endpoint behavior across senders and discounts the header. Compliant on inspection of message source; non-compliant in the receiver's accounting.
• Counting the threshold per inbox. The operator audits per-mailbox volume, concludes the estate is well under 5000/day, and is correct at the per-mailbox tier. The receiver counts per organizational domain. The realization arrives at the moment placement degrades.
• DMARC at p=none with no aggregate report parsing. The policy is technically satisfied. The sender has no visibility into whether alignment is holding across the third-party platforms in the sending stack. Compliance is observable; operational health is not.
• Postmaster Tools not enrolled. The complaint rate is the binding constraint and the only authoritative source is the receiver's own dashboard. The sender who has not enrolled has no visibility into the metric that determines the campaign's fate. The most consequential single oversight observed in production.
• TLS on outbound but not inbound. The sending MTA initiates STARTTLS correctly; the bounce-handling infrastructure accepts inbound mail over plaintext. The criterion is failed on the leg the operator did not audit.
• Unsubscribe processing latency over the 2-second threshold. The endpoint is correct, the semantics are correct, the database write recording the suppression takes four seconds and the POST times out at the evaluator. Honored at the application tier; discounted at the classifier tier.

Pre-compliance checklist

• SPF, DKIM, and DMARC published correctly per Chapters 1–3, with aggregate report parsing operational
• DMARC at minimum p=none; preferably p=quarantine or p=reject for trust signal
• List-Unsubscribe header carrying both mailto: and https:// URIs on every bulk message
• List-Unsubscribe-Post: List-Unsubscribe=One-Click header per RFC 8058
• https:// unsubscribe endpoint accepting unauthenticated POST, returning 2xx in under 2 seconds, processing the suppression without any further interaction
• Postmaster Tools enrollment for every authenticated sending domain in the estate
• Continuous complaint-rate monitoring with alert thresholds at 0.10% (warning) and 0.20% (escalation)
• MTA-STS published at mode: enforce on every sending domain that accepts inbound mail
• Outbound MTA configured for STARTTLS on every connection; downgrades logged and reviewed
• Per-receiver aggregate volume monitoring with the 5000-per-day threshold tracked at the organizational-domain tier
• A documented response procedure for a complaint-rate excursion above 0.20%, including campaign pause authority

Where this fits in the broader infrastructure

The bulk-sender policy is the receiver-side codification of a posture the major providers had operated informally for years. The change in 2024 was not the introduction of the criteria — competent senders had been meeting all four for the prior decade — but the introduction of enforcement at a level a non-expert operator can observe in placement metrics.

For cold outbound specifically, three of the four criteria are configuration. Authentication is a one-time DNS exercise audited periodically. Unsubscribe headers are a one-time application change. TLS is a one-time MTA configuration. The fourth criterion — the complaint rate — is the binding constraint, and it binds continuously, every campaign, every day. Every upstream architectural decision in the sending estate — the domain isolation of Chapter 7, the warmup methodology of Chapter 9, the seed-list testing of Chapter 13, and the list construction and personalization disciplines this reference does not cover — exists in service of one receiver-side metric: keeping the rolling complaint rate under the stated 0.10% target, with margin.

A sender at sustained 0.05% has solved the hard problem the policy surfaces. A sender at the 0.30% enforcement threshold has, in the receiver's accounting, become indistinguishable from the senders the policy was designed to exclude. The policy is the contract; the complaint rate is the score; everything else is preparation.