Gmail and Yahoo Bulk-Sender Requirements, Decoded: SPF/DKIM/DMARC, One-Click Unsubscribe, and the 0.3% Complaint Ceiling

Answer first: since February 2024, Google and Yahoo treat any sender crossing 5,000 messages per day to Gmail as a bulk sender, and the rules are no longer best-effort — they gate acceptance at the mailbox side. Four duties carry almost all of the enforcement weight: SPF + DKIM signing on the sending domain, a published DMARC record (even at p=none), RFC 8058 one-click unsubscribe on every marketing and subscribed message, and a spam-complaint rate under 0.3% measured in Google Postmaster Tools. Miss one and Gmail's answer shifts from a deferral to a rejection: 550 5.7.26 for unauthenticated mail and 550 5.7.1 once the complaint rate crosses its ceiling.

The duties bind the sender, the tenant — not the platform — but each one maps to a concrete Devotel Orbit surface: sender-domain verification, the List-Unsubscribe header pair Orbit stamps on every outbound email, the suppression ledger behind the click, and the tenant-level reputation endpoint. This post decodes each requirement in the mailbox providers' own terms, then points at the surface that already enforces it. For the statutory layer that sits underneath (CAN-SPAM opt-out in the US, CASL opt-in in Canada), the CAN-SPAM vs CASL explainer is the companion — the mailbox rules stack on top of the law, not instead of it.

The 5,000-a-day threshold — who counts as bulk

Google's definition is a rolling one: send 5,000 or more messages to Gmail addresses within any 24-hour window, even once, and every message from that sending domain is treated as bulk-sender traffic from then on — Google states plainly that once traffic qualifies as bulk, it is permanently categorized as bulk. Yahoo adopted the same threshold on the same timeline, so one posture covers both.

Two calibration points tenants get wrong:

1. The count is per sending domain, not per campaign. Three 2,000-message sends from news.example.com in one day is 6,000 — over the line. Splitting campaigns across subdomains splits the count; splitting them across schedule slots does not.
2. Below the threshold, the authentication duties relax, not disappear. Under 5,000/day, Google still requires SPF or DKIM; the full stack — SPF and DKIM and DMARC, plus one-click unsubscribe — binds the bulk tier. The sane posture is to configure for the bulk tier before growth forces it, because a domain that crosses the threshold mid-quarter has no grace period.

Authentication — SPF, DKIM, and DMARC as one gate

The three records form a single acceptance gate, and Gmail evaluates them together: SPF proves the connecting server may send for the domain, DKIM proves the message body was signed by the domain, and DMARC tells the receiver what to do when alignment fails. Bulk senders need all three, with SPF or DKIM alignment passing against the DMARC record.

On the Orbit side this is one surface: sender-domain verification. A custom sending domain accepts traffic only once its DNS records verify — add the domain under Channels → Email → Domains, publish the records the setup flow prints, and a daily health re-check keeps watching them after they go green. When a record drifts — a TTL expires into a changed answer, someone edits the zone at the registrar — the dashboard's per-record traffic light goes yellow or red, a bell notification flags the regression, and sends from that domain return 403 at send time rather than dying inside Gmail unread. The full recovery loop is on the email DNS verification drift troubleshooting page; the Cloudflare DNS auto-configure guide removes the copy-paste step entirely for zones on Cloudflare.

Two DMARC notes worth internalizing before a compliance review:

• `p=none` passes the mailbox rule but fixes nothing. Google's bulk-sender floor accepts a p=none record — it proves you published — but p=none instructs receivers to deliver spoofed mail anyway. Treat p=none as the start of the ramp toward quarantine and then reject, never the destination. The ramp is the tenant's call; Orbit surfaces the record status, not the policy decision.
• Alignment, not just presence, is what Gmail checks. A DMARC record with SPF that passes on a non-aligned Mail-From domain and DKIM signed by a third-party domain still fails alignment. This is the failure hidden inside "we have all three records."

One-click unsubscribe — RFC 8058, 48 hours, and where the click lands

For bulk senders, every marketing and subscribed message must carry both List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers, the mechanism must be one step — no login wall, no "reply with UNSUBSCRIBE" — and the sender must honor the unsubscribe within 48 hours. Yahoo's wording matches; both point at RFC 8058 for the one-click form. Pure transactional mail (receipts, OTPs, security alerts) is outside the one-click requirement, but the classification is Gmail's to second-guess — a "your order is on the way" message with a promotional tile reads as marketing to a complaint-driven classifier.

Orbit stamps the header pair on every outbound email by construction, including an in-body unsubscribe link as the non-one-click fallback, so the mechanics are not something a template author can forget. What the click does matters more than the header existing: the click writes a scope-email entry against the address in the suppression ledger idempotently and fires an email.unsubscribed audit event, and every later send to that address is dropped at dispatch. That is immediate — well inside the 48-hour ceiling even before the mailbox providers tightened the wording — and it is auditable, which is what a deliverability review actually asks for. The scope semantics (an email opt-out stops email, not SMS, unless the tenant broadens scope) sit on the consent and suppression model concept page; statutory overlays are the opt-out and suppression compliance page.

The 0.3% complaint ceiling — the requirement with telemetry

Authentication and unsubscribe are configuration; the complaint rate is a budget. Google enforces spam-rate ceilings in Postmaster Tools: keep the reported spam rate under 0.1% as healthy territory and never at or above 0.3% — past 0.3%, Gmail says plainly it may reject or route to spam and "a rate of 0.3% or higher makes you ineligible for mitigation of delivery issues." Yahoo's published guidance is the same shape — keep complaint rates low, below 0.3%. The number that matters is the complaint rate computed from recipients marking the message as spam against messages delivered to the inbox, not the tenant's raw volume.

Three operational truths about that ceiling:

1. The budgets are crossed by recipients, not by send volume. A 5% spam-rate on 100 messages is 5 complaints; a 0.3% ceiling on a 100,000-message day is 300 complaints. Growth raises the numerator no matter how clean the content is — list hygiene is what keeps the denominator from filling.
2. The mitigation path closes above the ceiling. Once the 0.3% line is crossed, Postmaster Tools stops offering mitigation guidance — the mailbox provider tells you the complaint posture is yours to repair, not theirs to remediate. That is the operational argument for keeping the rate under 0.1% even when 0.3% is the published hard line.
3. The sender's own telemetry must lead the mailbox's. Postmaster Tools reports on Google's own lag; the tenant-level summary endpoint GET /api/v1/email/suppressions/reputation returns aggregate sent / delivered / bounced / complaint counts and rates, the health tier, and the suppression-list size over a lookback window, so a tenant sees complaint drift on its own dashboard before it surfaces inside Gmail's. The bounces and spam complaints page decodes the DSN codes and SMTP replies behind each bounce family — hard, soft, spam complaint, spam trap — and maps each to the fix.

Marketing vs transactional — the classification both mailboxes police

The bulk-sender stack treats classification as the sender's problem: marketing and subscribed messages carry the one-click duty, and the complaint ceiling is computed on the aggregate sending domain regardless of class. Tenants that run both classes from one domain inherit the worst-case of both — a promotional campaign that draws complaints degrades the OTP lane's inbox placement on the same domain, and re-classifying a promotional send as "transactional" reads as evasion to a complaint-driven classifier, not as nuance.

The mitigation is a posture decision, and it is tenant-owned: run the two classes from separate sending subdomains (receipts.example.com vs news.example.com), so a complaint wave in one lane cannot drag the other's sender reputation beneath it. Orbit supports multiple sending domains per tenant and verifies each independently — same verification flow, same daily health re-check, per-domain DNS traffic light on the dashboard. The email channel guide covers the per-domain setup surface; whether a given program warrants a split is a deliverability-review question for the tenant, not a platform mandate.

Before-and-after for a tenant crossing the threshold

The posture note applies to the whole table: the duties bind the sender, and Orbit surfaces the controls — verification, headers, suppression, reputation telemetry — but does not mandate the tenant's DMARC policy ramp, subdomain split, or list-hygiene cadence. This is an explainer, not legal or deliverability advice; final posture rests with the tenant's own review.

Frequently asked questions

Does the 5,000/day threshold count messages or recipients?

Gmail counts messages sent to Gmail addresses within a 24-hour window across the whole sending domain — and once traffic qualifies as bulk, Google says it is permanently categorized as bulk. The count is per sending domain, not per campaign or schedule slot, so splitting sends across subdomains splits the count while splitting them across hours does not.

Does DMARC p=none actually satisfy the bulk-sender rule?

It satisfies the letter of it — a published record at any policy passes Google's "publish a DMARC record" check. Operationally it only starts the ramp: p=none tells receivers to deliver even when alignment fails, so spoofed mail still lands. Sanely-run programs move to quarantine and then reject on a monitored cadence; Orbit reports the DMARC record's per-record status alongside SPF and DKIM but the policy decision is the tenant's.

Do transactional emails need one-click unsubscribe?

Not under the mailbox rule — the RFC 8058 duty binds marketing and subscribed messages, not purely transactional ones. The classification is Gmail's to judge by content, not by the sender's label, so an OTP or receipt stays clean only if its content reads transactional; a promotional block inside a "receipt" tilts it into the marketing class. Orbit stamps the header pair on every outbound email regardless of class, which means the affordance never depends on an author's classification choice.

Where does the spam-rate ceiling actually live?

In Postmaster Tools for Gmail (postmaster.google.com) and Yahoo's sender dashboard, not in the sender's own delivery log. The ceiling is a complaint rate — recipients marking messages as spam over inbox-delivered messages — and it is computed on the mailbox side. The tenant-level reputation endpoint (GET /api/v1/email/suppressions/reputation) is the leading indicator on the Orbit side: it returns the same counts and rates on the tenant's own telemetry so complaint drift is visible before the mailbox's lagged report catches up.

If my domain crosses the threshold once, does it stay a bulk sender?

Yes — Google is explicit that once traffic qualifies as bulk, the sending domain is permanently categorized as bulk-held, even if volume later drops below 5,000/day. The durable posture is to configure SPF, DKIM, DMARC, and the unsubscribe path before crossing, not after.