The Bulk-Sender Clearance Standard: When a Domain May Send Outbound

Before a new sending domain and its mailboxes carry a single real campaign, someone has to say whether the setup meets the inbox providers' bulk-sender requirements. This guide is the gate for that decision. It is written for the RevOps, marketing-ops, or deliverability owner who is answerable for how mail gets sent, and it gives you a gradeable definition of done: a pass/fail checklist two people would score the same way, ending in one verdict of cleared, remediate-first, or blocked.

This is deliberately narrow. The library already has a playbook for recovering a burned domain and a reference for reading ongoing health signals. Neither defines the pre-launch gate. That gap matters more than it looks, because in Refolk's index of professional profiles, 389 US professionals list email deliverability as a skill but only 1 holds a dedicated specialist title, and 0 do in the UK. The gate almost always lands on a generalist who owns ten other things. A written standard is the substitute for a specialist you do not have.

What "cleared to send" means

A sending domain is cleared when it passes every item in the gate at the same time: dedicated infrastructure, aligned authentication, working one-click unsubscribe, a completed warmup verified by placement, clean list hygiene, and a seed test at or above 80% inbox placement across Gmail, Outlook, and Yahoo. Miss one and the verdict is not cleared.

The gate produces exactly three grades, and the definitions are chosen so two people score the same case the same way.

The line between remediate-first and blocked is whether the fault is a config error or a structural one. A missing DKIM signature is remediate-first. Planning to send cold volume from your corporate root domain is blocked, because the fix is not a change to that setup, it is a different setup entirely.

The provider bulk-sender gate

Google, Yahoo, and Microsoft each publish bulk-sender requirements, and they overlap heavily but not perfectly. Gmail and Microsoft apply their rules at 5,000+ messages per day to their consumer users; Yahoo phrases its trigger as "significant volume." All three require SPF, DKIM, and a published DMARC record. Read the table as the spine of the gate.

Three things about this table decide most gate outcomes.

First, the complaint ceiling is not a soft target. Gmail asks you to keep the user-reported spam rate below 0.1% and to prevent it ever reaching 0.3%. Beginning June 2024, bulk senders above 0.3% became ineligible for mitigation and stay ineligible while above it. You regain eligibility only after the rate stays below 0.3% for 7 consecutive days. That is a week of cleanup for one bad day.

Second, Yahoo is stricter than Gmail on identical behaviour. Both use inbox-delivered mail as the denominator, but Yahoo excludes spam-foldered mail, so a sender compliant at Google can breach Yahoo at the same raw complaint count. Grade the two dashboards separately. A Gmail pass does not license a Yahoo send.

Third, Microsoft's enforcement is now live and its failure mode is loud. Enforcement for 5,000+/day senders to Outlook.com, Hotmail.com, and Live.com began May 5, 2025. Non-compliant high-volume mail first routes to Junk, with outright rejection to follow. When Microsoft rejects, it returns "550 5.7.15 Access denied, sending domain does not meet the required authentication level." If you see that code, you failed the gate at send time rather than before it.

The classification is also permanent. A domain that crosses 5,000/day to Gmail is classified as a bulk sender, and that label does not expire when volume drops. This is why the gate is a one-way door: you grade the setup before it ever crosses the threshold, because you cannot un-cross it.

Authentication and one-click unsubscribe

Authentication is the cheapest, highest-leverage item on the gate, and it is where "passes" most often lies. All three providers require SPF, DKIM, and a published DMARC record at minimum p=none, aligned with either SPF or DKIM. The word doing the work is aligned. A DMARC record can exist, show a green checkmark, and still fail because the From domain does not align to the SPF or DKIM domain. Verify alignment, not presence.

The payoff for getting this right is measurable: domains without proper authentication see about 52% lower inbox placement. That is one of the two largest swings in this whole document, and it costs an afternoon of DNS work.

One-click unsubscribe under RFC 8058 is a separate requirement, and it is precise enough to fail on a typo.

The exact requirements, so you can grade them without interpretation:

• The List-Unsubscribe-Post header value must equal exactly List-Unsubscribe=One-Click with no variations.
• The List-Unsubscribe header must contain at least one HTTPS URL, not HTTP.
• DKIM must cover at least the List-Unsubscribe and List-Unsubscribe-Post headers.
• The endpoint must receive the POST and process the unsubscribe within 48 hours.
• A visible body unsubscribe link is still required alongside the headers.

Here is the header pair to copy and adapt.

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

The warmup ramp: benchmark, not standard

Warmup has no official provider figure. Every number you will see is a vendor benchmark, and the vendors disagree, so treat the range as a range and the seed test as the truth. What is not in dispute is the payoff: accounts that skip warmup reach about 61% inbox placement versus 94% for properly warmed accounts. Warmup and authentication are the two cheapest gate items and they produce the two largest measurable swings.

The published ramps, side by side, so you can pick a conservative point inside them:

A defensible reading: begin at 5 to 10 emails per day per inbox, build toward roughly 25 to 30 over several weeks, and do not exceed 30 before reputation is established. Google Workspace ramps are cited as the longest, so if any of your mailboxes are on Workspace, take the 15-day minimum as a floor, not a target. Note also that Google Workspace's daily cap is 2,000 messages, but the realistic cold cap is around 50 per inbox per day, so the cap is not your permission slip.

The clearance procedure

The procedure below takes a raw setup to a graded verdict. It runs roughly in order, though authentication and warmup overlap. Ownership and rough effort are noted so you can staff it.

The seed test in step five is the item people cut when they are in a hurry, and it is the one that catches the failures the dashboards hide. GlockApps runs a seed list of about 70 addresses at $59 to $129 per month; Validity Everest offers panel-based placement; Mail-Tester scores content and authentication out of 10. Use Mail-Tester as a pre-check for content and auth only, then confirm real placement with a seed test. A seed test showing less than 80% inbox placement is a clear signal to reduce volume or pause until the underlying issue is resolved.

How this gate goes wrong

The gate fails most often not because a check is missing but because a check passes for the wrong reason. Every item below is a false positive: a green light over a real problem. This is the section to reread before you sign off.

The seven documented failure modes, and how to catch each:

• Complaint rate looks fine but the denominator is wrong. If Gmail already spams half your mail, those recipients cannot click Report Spam, so a low rate hides a reputation collapse. Check placement, not just the rate.
• DMARC "passes" at p=none but is unaligned. The record exists yet From does not align to the SPF or DKIM domain. Green checkmark, real fail. Verify alignment, not mere presence.
• One-click unsubscribe GETs instead of POSTs. Link scanners silently unsubscribe live recipients. Test an actual POST and confirm DKIM covers the headers.
• Warmup declared done on the calendar, not the signal. A mailbox at day 21 can still fail placement. Verify with a seed test at 80%+, not the date.
• Mail-Tester 10/10 mistaken for clearance. A 10/10 does not guarantee placement; placement depends on reputation and engagement Mail-Tester cannot measure. Confirm with a live seed test.
• Missing or generic PTR ignored because SPF/DKIM pass. rDNS is checked at connection before the body is parsed, so broken rDNS is a hard fail at many gateways. Run an rDNS lookup on the sending IP and confirm it forward-resolves to the same address.
• Catch-all and unverified lists treated as clean. A list with about 5% invalid addresses spikes bounces regardless of authentication. Verify the list and keep catch-all addresses under 2 to 3% of daily volume.

The dangerous failures are not missing checks. They are checks that pass for the wrong reason.

The through-line is the first failure mode: the complaint rate masks itself. Gmail's denominator is inbox-delivered mail, so as placement drops, fewer recipients can report spam, and the rate flattens even as reputation falls. This is precisely why the gate includes a seed test rather than trusting the Postmaster rate alone. The metric you would most want to rely on is the one that lies most convincingly when things are already bad.

Deliverability is a skill, not a seat

Grade this gate yourself, because almost no one has a specialist to hand it to. In Refolk's index of professional profiles, the shape of the market is stark.

The reading is that deliverability is a distributed competency, not a job. It lives inside RevOps and marketing-ops generalists who own the whole outbound stack. That is exactly why a written, gradeable standard earns its keep: when no single person owns the discipline, the checklist is the owner. When you do need outside help, the search is for the skill inside a broader role, not for a title that barely exists. Refolk is built for that kind of plain-English search, so you can ask for operators who list sender reputation as a skill rather than hunting for a job title that only one person in the country holds.

The clearance checklist

Run this before you call any setup cleared. Every item is a checkable statement, not a topic, so two people grading the same domain reach the same verdict. A single unchecked box moves the grade to remediate-first, or to blocked if it is structural.

Keeping the gate current

Grade at launch, then re-grade on a trigger, not a whim. The gate is a snapshot; reputation moves. The mechanism to watch is the daily spam rate in Postmaster Tools calculated against inbox-delivered mail, plus a periodic seed test to catch the masking effect the rate cannot show you. Re-run the seed test whenever you add a domain, add mailboxes, change your unsubscribe endpoint, or raise volume toward the 5,000/day threshold, because crossing it classifies you permanently.

The provider rules themselves shift on published deadlines rather than gradually, so treat this document as a template whose thresholds you confirm against the three provider guidelines when a provider announces a change. The stable parts are the shape of the gate and the failure modes; the exact numbers are what you re-check. When a rejection code appears in production, do not tune volume blindly. Match it to the failure it names, fix that item, re-test it, and only then re-grade. A standard that overclaims is worse than none, so where a number here is a vendor benchmark rather than a provider rule, treat it as a starting range and let your own seed placement settle the argument.