Google and Yahoo's Bulk Sender Rules: Getting DMARC Right

Starting in February 2024, Google and Yahoo will require bulk email senders to authenticate their mail with SPF and DKIM, publish a DMARC policy, make sure the From: domain aligns with an authenticated domain, offer one-click unsubscribe on marketing mail and keep spam complaints below 0.3%. If your organization sends around 5,000 or more messages a day to Gmail addresses, a DMARC record of at least p=none and properly aligned authentication will be the minimum for reaching the inbox from February.

Meeting the minimum is only half the value, though. The same work sets you up to move DMARC to enforcement, which stops anyone else from sending mail that claims to come from your domain. This post covers what the new rules require and how to roll DMARC out without breaking legitimate mail.

What did Google and Yahoo announce?

Both companies announced new sender requirements on October 3, 2023. Google's post said that by February 2024, Gmail would require bulk senders to authenticate their email, support easy unsubscription and stay under a clear spam rate threshold. Yahoo announced closely matching requirements the same day, also taking effect in February 2024.

Google's detailed rules live in its email sender guidelines, which split the requirements into two groups: rules for everyone who sends to Gmail, and additional rules for bulk senders. The background is in Google's announcement post.

Who counts as a bulk sender?

Google's threshold is roughly 5,000 or more messages a day to Gmail addresses. Yahoo hasn't tied its definition to a published number, so it's safer to treat the rules as applying to any organization that sends meaningful volume.

When you estimate your volume, count every stream that uses your domain: newsletters, transactional mail, invoices, product notifications and support tickets. Plenty of mid-sized organizations cross the line without thinking of themselves as email marketers.

Even if you're well below the threshold, Google's baseline for all senders applies from February 1, 2024:

• SPF or DKIM authentication for your sending domain
• Valid forward and reverse DNS for sending IP addresses
• TLS for transmitting email
• Spam rates in Google Postmaster Tools below 0.3%
• Messages formatted according to RFC 5322
• No impersonating Gmail addresses in the From: header, because Gmail plans to begin applying a DMARC quarantine policy to its own domain

What do the bulk sender requirements include?

Google's and Yahoo's lists cover the same core items.

Google also expects a clearly visible unsubscribe link in the body of marketing messages, in addition to the header-based one-click option.

What is DMARC and how does alignment work?

DMARC (Domain-based Message Authentication, Reporting and Conformance, defined in RFC 7489) sits on top of two older standards:

• SPF lists the servers allowed to send mail for a domain. It checks the envelope sender, also called the Return-Path or bounce address, which recipients never see.
• DKIM adds a cryptographic signature to each message. The signature names a signing domain in its d= tag.

Neither one checks the From: address people actually see. DMARC closes that gap. A message passes DMARC when SPF or DKIM passes and the authenticated domain aligns with the visible From: domain.

Alignment is relaxed by default, so mail.example.com aligns with example.com. Strict alignment requires an exact match and is rarely needed at the start.

This is why many organizations fail the new rules despite having SPF and DKIM in place. A marketing platform might pass SPF using its own bounce domain and sign DKIM with its own domain. Both checks pass, but neither aligns with your From: domain, so DMARC fails.

How do you roll out DMARC from p=none to p=reject?

A DMARC policy tells receiving servers what to do with mail that fails: none (take no action, just report), quarantine (treat as suspicious, usually the spam folder) or reject (refuse delivery). Moving straight to reject without visibility is how legitimate invoices end up bouncing. A phased rollout avoids that.

Phase 1: Publish p=none with reporting

Start with a monitoring record at _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:[email protected]

The rua tag is where receivers send aggregate reports. These are XML files, typically sent daily, listing which IP addresses sent mail using your domain and whether each source passed SPF, DKIM and alignment. Raw XML is hard to read at volume, so use a parser or reporting service to turn it into something a person can review.

If the reporting address is on a different domain, that domain has to publish a verification record authorizing it, in the form example.com._report._dmarc.reports-domain.net with the value v=DMARC1.

This phase alone satisfies the new DMARC requirement, as long as your mail is aligned.

Phase 2: Find and fix every legitimate sender

Spend a few weeks reading reports. You'll usually find more senders than expected: the CRM, the helpdesk, the billing system, an HR platform, a web form plugin, a scanner in the office that emails PDFs.

For each legitimate source, get it to pass DMARC with alignment, preferably through DKIM. Anything unrecognized that still claims to be your domain is exactly what enforcement will stop.

Phase 3: Move to quarantine gradually

Once legitimate sources consistently pass, switch to p=quarantine. The pct tag lets you apply the policy to a share of failing mail first:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Raise pct in steps to 100 while watching reports and help desk tickets for delivery complaints.

Phase 4: Move to reject

When quarantine at 100% has run cleanly for a while, move to p=reject. Keep rua reporting on permanently. New tools and vendors will appear, and reports are how you'll notice them before users do.

How long this takes depends on how many senders you have. A small organization with a handful of services can move in weeks. One with dozens of platforms should plan for months.

How do you handle third-party senders?

Most DMARC work is really vendor work. For each service that sends as your domain:

• Set up custom DKIM. Most reputable email platforms let you publish their public key under your domain so they sign with d=example.com. This is the most reliable path to alignment, because DKIM survives forwarding better than SPF.
• Use a custom bounce domain if offered. This aligns SPF too, which gives you a second path to a DMARC pass.
• Watch the SPF lookup limit. SPF allows at most 10 DNS lookups per evaluation (RFC 7208). Every include: for a new vendor adds to the count, and exceeding it causes SPF to fail.
• Consider a subdomain. Sending marketing from something like news.example.com keeps its reputation and configuration separate from your main domain's mail.
• Put it in procurement. Make custom DKIM support a requirement for any new platform that will send on your behalf.

What about subdomains and domains that don't send mail?

Subdomains without their own DMARC record inherit the policy of the organizational domain. You can set a separate subdomain policy with the sp tag, for example p=reject; sp=quarantine, though most organizations eventually want both at reject.

Domains that never send mail, such as parked or defensive registrations, are easy wins. Publish:

• An SPF record of v=spf1 -all
• A DMARC record with p=reject
• A null MX record (RFC 7505) if the domain doesn't receive mail either

That tells receivers no legitimate mail will ever come from those domains.

What does one-click unsubscribe require?

RFC 8058 defines two headers that let mailbox providers show an unsubscribe button and process the request with a single POST:

List-Unsubscribe: <https://example.com/unsubscribe/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe header must include an HTTPS URI, and the message needs a valid DKIM signature covering both headers. Google and Yahoo both expect unsubscribe requests to be honored within two days. Most email platforms support this already, but check that it's enabled for every marketing stream.

Frequently asked questions

Does p=none protect our domain from spoofing?

No. It only asks for reports. Receivers still apply their own judgment to failing mail. Protection comes from quarantine and reject, which is why p=none should be a starting point rather than a destination.

Does one-click unsubscribe apply to transactional email?

Google's rule applies to marketing and subscribed messages. Password resets, receipts and account notifications don't need it. Authentication and alignment still apply to all of your mail.

We send well under 5,000 messages a day. Should we still set up DMARC?

Yes. The baseline rules for all senders already require SPF or DKIM, and a DMARC policy at enforcement protects your domain regardless of volume. Smaller senders also tend to have fewer platforms, which makes the rollout faster.

Who should own DMARC reports?

Someone who understands both DNS and the business's sending tools, usually in IT or security. Marketing needs to be involved, since most third-party senders sit in their budget.

Next steps

• Count your daily volume to Gmail across every platform that sends as your domain.
• Publish a p=none DMARC record with rua reporting before February.
• Configure custom DKIM for every legitimate sender and confirm alignment in the reports.
• Enable RFC 8058 one-click unsubscribe on all marketing streams and set up Google Postmaster Tools to track your spam rate.
• Lock down non-sending domains, then step your main domain from none to quarantine to reject.

The February deadline covers the minimum. Enforcement is where DMARC starts protecting your domain.