The Gmail and Yahoo bulk-sender requirements, in plain terms

In October 2023, Google and Yahoo announced the first shared baseline for bulk email, and in February 2024 they started enforcing it. Before that, deliverability best practice was exactly that — advice. Authentication was strongly encouraged, a low complaint rate was smart, an easy unsubscribe was polite. None of it was a gate. Now the two providers that hold most consumer inboxes have turned the advice into a pass-or-fail check at the door.

The rules read like a compliance document, which is why so many senders half-implement them and then wonder why placement slipped in the spring of 2024. In practice they collapse to five requirements, and none of them is exotic — we were already doing all five for the sending operations we run. This is the plain-terms version: who the rules apply to, what each requirement actually asks for, how to check you have met it, and where teams most often get it wrong.

01What changed in February 2024?

The floor moved. What used to be a set of things good senders did became a set of things every bulk sender must do, checked by the receiver rather than trusted from the sender. Google and Yahoo published near-identical requirements so that meeting one meets the other, which is the useful part — there is one bar, not two.

Enforcement was deliberately gradual, and that gentleness fooled people. Through the first months of 2024 non-compliant mail got temporary errors — 4xx deferrals with a message pointing at the requirement it failed — rather than outright rejection. A sender watching only their delivered count saw nothing alarming, because deferred mail eventually squeezes through. By mid-2024 the deferrals turned into rejections and the rejection rate for non-compliant traffic climbed. If your numbers wobbled that year and never fully recovered, this is usually why.

02Do the rules apply to you?

If you send more than 5,000 messages a day to Gmail addresses, or the same to Yahoo personal accounts, you are a bulk sender and all five requirements apply. The count is per sending domain across a rolling day, and Google has been explicit that once you cross the threshold you are treated as a bulk sender permanently — you do not drop back out on a quiet day.

Two things trip people here. First, the 5,000 counts recipients at that one provider, not your total list, so a 4,000-a-day Gmail stream plus a 4,000-a-day Yahoo stream clears neither threshold on paper yet should absolutely be run to the full standard. Second, the threshold is a floor for enforcement, not a target for good practice. Authentication, a real unsubscribe, and a clean complaint rate are correct at 500 messages a day too. Our position is simple: build every sending stream to the bulk standard from the first message, because retrofitting DMARC alignment onto a live domain under a placement drop is the worst time to learn how it works.

03Authenticate every message: SPF and DKIM

Both, not either. The pre-2024 world let you get by with one form of authentication; the current rules require SPF and DKIM on bulk mail, and a message carrying only one is non-compliant even if that one passes.

SPF is a DNS record listing the IPs allowed to send for your domain; it authenticates the envelope-from (the return path) the receiver sees at the SMTP layer. DKIM attaches a cryptographic signature to each message using a private key you hold, which the receiver verifies against a public key published in your DNS. SPF proves the connection came from an authorised host; DKIM proves the message content and its From domain were not altered in flight. Bulk senders need both to pass. If you want the mechanics rather than the checklist, we wrote them up in SPF, DKIM and DMARC explained.

The common failure is not a missing record — it is a DKIM key that was generated on one sending node and never published, or never copied to a second node that also signs. The mail goes out signed with a selector the DNS cannot resolve, verification fails, and the whole authentication story falls apart while every record looks present. Verify the signature from the outside, on a real send, not by reading your own zone file.

04DMARC, and the alignment part people miss

You need a DMARC record on your sending domain, and at minimum it can be p=none. That is the easy half, and it is where most senders stop. The half that actually gets mail rejected is alignment.

DMARC does not just check that SPF or DKIM passed — it checks that the domain they passed for matches the domain in the visible From header. A message can have a passing SPF on your bounce domain and a passing DKIM on your ESP's domain and still fail DMARC, because neither aligns with the From address the recipient reads. Under the bulk rules, at least one of SPF or DKIM must pass and align with the From domain. Relaxed alignment — a shared organisational domain, so mail.yourbrand.com aligns with yourbrand.com — is enough; you do not need an exact match.

Start the policy at p=none with an rua reporting address so the aggregate reports come back to you, read them until you trust that your legitimate mail aligns, then tighten toward p=quarantine and eventually p=reject. Do not publish p=reject on day one — you will bin your own transactional mail before you find the source that was not aligned. And a specific 2024 wrinkle: Gmail applies a DMARC quarantine posture to messages that put a Gmail address in the From header from outside Google, so stop using from: [email protected] on mail you send through your own infrastructure.

05One-click unsubscribe (RFC 8058), honoured in two days

Commercial and promotional bulk mail has to carry a working one-click unsubscribe, and you have to act on it within two days. This is the requirement teams most often fake, because a visible "unsubscribe" link in the footer is not what the rule asks for.

RFC 8058 one-click means two message headers: a List-Unsubscribe header carrying an HTTPS URL (a mailto: alone does not satisfy the one-click part), and a List-Unsubscribe-Post: List-Unsubscribe=One-Click header that lets the mailbox provider send an unsubscribe POST on the recipient's behalf without them ever loading your page. When Gmail or Yahoo shows its own "unsubscribe" control next to your sender name, that is the header at work. You still need the ordinary visible link in the body — both, not one.

• Add List-Unsubscribe with an HTTPS endpoint (a mailto: may be included as a second value, but the HTTPS one carries the one-click).
• Add List-Unsubscribe-Post: List-Unsubscribe=One-Click so the provider can post the opt-out directly.
• Keep a plainly visible unsubscribe link in the message body as well.
• Process every unsubscribe within two days — and mean it, because the provider is watching whether the opt-out actually stops the mail.

The two-day clock is the teeth. An unsubscribe that suppresses the address next Tuesday is a complaint waiting to happen, and complaints are the metric in the next section.

06How low does your spam rate have to be?

Keep the spam rate that Google Postmaster Tools reports under 0.3%, and treat 0.1% as the real ceiling. Google states the requirement as "avoid ever reaching a 0.3% spam rate", which is a stricter instruction than a monthly average under 0.3% — a single day that spikes above the line is a day you were out of compliance, and providers remember spikes.

That number is reported spam: the fraction of recipients who hit the "report spam" button, as measured by the provider itself, not your own guess from bounces. You cannot see it without authenticated domains feeding Postmaster Tools, which is one more reason authentication comes first — no auth, no reputation dashboard, no way to know you are inside the rule. Yahoo does not publish an equivalent self-serve dashboard, but it runs a complaint feedback loop, and the discipline is identical: watch the complaint signal per provider and treat any climb as a stop-and-diagnose event, not a rounding error.

The way you stay under 0.3% is not a filter on the way out. It is list hygiene and consent on the way in: send wanted mail to people who asked for it, drop dormant addresses before they sour, and make the unsubscribe from section 05 so easy that a bored recipient opts out instead of reaching for the spam button. Every "report spam" you prevent is worth more than the send that earned it.

07Forward and reverse DNS, TLS, and an honest From

The last requirements are the hygiene ones, and they are pass-or-fail too. Every sending IP needs valid reverse DNS — a PTR record resolving to a hostname you own — and that hostname needs a matching forward record pointing back, so the pair agrees in both directions. Mail from an IP with no PTR, or a PTR that does not resolve forward, reads as anonymous, and anonymous is how throwaway spam sources look.

You also have to transmit over TLS. Offer encryption on the connection to Gmail and Yahoo; plaintext SMTP for bulk mail is no longer acceptable to them. Finally, format messages to the RFC 5322 standard, keep the From and other identifying headers honest, and make sure your HELO/EHLO hostname, envelope-from domain, and DKIM domain tell one consistent story rather than three unrelated ones. Providers reward coherence between identifiers and distrust senders whose names do not match.

08The requirements at a glance

Here is the whole standard as a checklist, with what each provider expects and the fastest honest way to confirm you have met it. Treat every row as pass-or-fail, because that is how the receiver treats it.

None of this replaces the slow work of building a reputation — the rules are the entry ticket, not a good seat. A brand-new IP that passes every check on this list still has to earn its volume, which is a separate discipline covered in how to warm up a sending IP. And meeting the standard is not the same as landing in the inbox rather than the promotions tab; for the placement question underneath compliance, see what PowerMTA does and does not do for inbox placement.

09How we keep client sending compliant

For the sending operations we run, these requirements are not a checklist someone works through before a campaign — they are properties of the infrastructure, set once and verified continuously. We run this through Mailflow, our control plane for sending infrastructure, which automates the DKIM keys, SPF records, and reverse DNS that the rules demand, and publishes them as part of building each node rather than as a manual afterthought. The keypair is generated per domain and shipped to every node that signs with it, which is exactly the failure mode from section 03 designed out.

Measurement is the other half. Mailflow folds the accounting logs off every sending node into per-ISP delivery, bounce, and complaint statistics, and monitors blacklist status on a schedule, so the spam-rate and complaint signals from sections 06 and 07 are read as they move rather than discovered after placement drops. For Relentia, the email marketing operation whose infrastructure we have run since January 2024, we built per-provider reporting that reads Gmail's domain reputation, spam-rate reporting, and SPF, DKIM and DMARC pass rates directly, and attributes Yahoo complaints against the DKIM signing domain — because a Gmail compliance problem and a Yahoo one are diagnosed from different evidence. Suppression and opt-out data feeds back into the address records, so honouring an unsubscribe is automatic rather than a task someone has to remember inside the two-day window.

We take the same posture on every engagement, including EMG, whose sending infrastructure we have run remotely since January 2025: authentication published at build time, alignment verified before volume, complaint rate watched per provider, and the whole team trained to read the signals rather than trust a green dashboard. The 2024 rules did not change how we work — they wrote down the standard we already held. Meet them once in the infrastructure, verify them from the outside, and the door stays open.