The 2024 and 2025 bulk-sender requirements in full

19 May 2026 · 12 min read

Why the rules changed, and why they are not going away

For most of email's history, authentication was optional. You could send millions of messages a day with no SPF record, no DKIM signature and no DMARC policy, and the big mailbox providers would still try to deliver them on reputation alone. That era ended in February 2024. Google and Yahoo, acting in lockstep, turned a long list of "best practices" into hard entry requirements for anyone sending to their users in volume. Microsoft followed with its own enforcement timeline, beginning to apply the same baseline to Outlook, Hotmail and Live addresses from May 2025.

The headline is simple: if you send bulk email and you cannot prove the messages are really from you, they will be rejected or sent to spam. There is no reputation score high enough to buy your way out of missing authentication. This is now a pass-or-fail gate that sits in front of delivery.

This guide lays out exactly what Google, Yahoo and Microsoft each require, what the numeric thresholds actually are, who counts as a "bulk sender", and how the rules differ in the fine print. At the end there is a single compliance checklist you can work through line by line. If you would rather confirm your current state in thirty seconds, run your domain through the free DMARC checker first, then come back and read what each result means.

Who the requirements apply to

The first question every sender asks is "does this apply to me?", and the honest answer is that it applies to almost everyone, just with different strictness.

Google defines a bulk sender as any domain sending close to 5,000 messages or more to Gmail addresses within a 24-hour period. The 5,000 count is measured across the primary domain and its subdomains together, so you cannot dodge it by spreading mail across mail.example.com and news.example.com. Once you cross that line on any single day, Google treats you as a bulk sender from then on. It does not reset if your volume drops the next day, and Google has been clear that it will not publish a "you are now a bulk sender" notification. You are expected to assume you qualify.

Yahoo never published a precise number. Its public guidance describes the rules as applying to anyone "sending email in bulk" and, crucially, says the underlying authentication requirements are good practice for all senders, not only high-volume ones. In practice Yahoo enforces the authentication baseline broadly and reserves the volume-specific rules (one-click unsubscribe, spam-rate thresholds) for genuine bulk traffic.

Microsoft's threshold matches Google's: domains sending more than 5,000 messages per day to Outlook.com, Hotmail.com and Live.com consumer mailboxes fall under its bulk-sender enforcement, which began rolling out in May 2025.

There are two practical takeaways. First, the authentication requirements (SPF, DKIM, DMARC, alignment) effectively apply to every sender now, because even below 5,000 messages a day, missing authentication damages deliverability and all three providers recommend it universally. Second, the volume-gated extras (one-click unsubscribe headers, the published spam-rate ceiling) kick in once you cross the bulk line at any of the three providers. If you run marketing campaigns, transactional notifications at scale, or newsletters, assume you are a bulk sender and build to the strict standard.

Requirement one: authenticate every message with SPF and DKIM

All three providers require that bulk mail be authenticated with both SPF and DKIM. This is not "either or". Relying on SPF alone is the single most common reason senders fail, because SPF breaks the moment a message is forwarded, and it does nothing to protect the visible From: address.

SPF publishes, in DNS, the list of servers allowed to send mail for your envelope domain. A receiver checks the connecting server's IP against that list. Your record must exist, must be syntactically valid, and must not exceed the ten DNS-lookup limit that the SPF specification imposes. Exceed ten lookups and SPF returns a permerror, which counts as a failure. If you use several third-party senders (a CRM, a payroll system, a help desk, a marketing platform), it is easy to blow past ten lookups without realising. Check yours with the SPF checker, and if it is over the limit, read the ten-lookup limit explained and consider SPF flattening.

DKIM attaches a cryptographic signature to each message using a private key, with the matching public key published in DNS under a selector. Receivers verify the signature to confirm the message body and key headers were not altered and that they came from a domain that holds the key. Google's guidance is explicit that DKIM keys should be at least 1024 bits, and 2048-bit keys are strongly preferred; very short keys are rejected outright by some receivers. Confirm your signature is live and your key length is adequate with the DKIM checker, and see 1024 vs 2048-bit keys for the trade-offs.

A subtle point that trips people up: it is not enough for SPF or DKIM merely to pass. They have to pass and align with the From: domain. That is what DMARC enforces, and it is the subject of the next requirement.

Requirement two: publish a DMARC policy with alignment

Every bulk sender must publish a DMARC record for the sending domain. At minimum this means a TXT record at _dmarc.yourdomain.com containing a valid policy. The simplest compliant record is:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

p=none is enough to pass the entry requirement at all three providers. They check that a policy exists; they do not (yet) force you to enforce. But p=none provides no protection against spoofing, so it is a starting line and not a destination. For what each policy value actually instructs receivers to do, see none, quarantine and reject explained.

The requirement that does real work is alignment. DMARC passes only when at least one of SPF or DKIM both passes and is aligned with the domain in the From: header that the recipient sees.

• DKIM alignment means the d= domain in the DKIM signature matches (or is a subdomain of, in relaxed mode) the From: domain.
• SPF alignment means the envelope MAIL FROM domain matches the From: domain.

This is the protection that authentication exists to provide. An attacker can easily make SPF pass for their own server while forging From: you@yourbank.com; alignment is what blocks that, because the passing domain would not be yourbank.com. If you have ever seen SPF and DKIM "pass" in a header but DMARC still fail, alignment is almost always why. Read DMARC alignment explained for worked examples, and note that forwarding is the classic alignment-breaker, covered in forwarding and DMARC.

You can build a correct first record with the DMARC generator, then verify what receivers actually see with the DMARC checker.

The subdomain and apex trap

Microsoft and Google both evaluate the organisational domain's DMARC policy when a subdomain has none of its own. If you send from mail.example.com but only example.com has a record, the subdomain inherits the apex policy (or the explicit sp= subdomain policy if you set one). A common mistake is publishing DMARC only on a subdomain you send from while leaving the apex undefended, or vice versa. Make sure the domain in your visible From: address has a policy that resolves correctly. See the sp subdomain policy for how inheritance works.

Requirement three: one-click unsubscribe (List-Unsubscribe)

This is the requirement most senders had not implemented before 2024, and it is enforced specifically for bulk marketing and promotional mail.

Bulk senders must include a working one-click unsubscribe mechanism that conforms to RFC 8058. Concretely, that means two headers on the message:

• List-Unsubscribe, containing a mailto: and/or an https: URL.
• List-Unsubscribe-Post: List-Unsubscribe=One-Click, which signals that the https: URL accepts a single HTTP POST to unsubscribe with no further confirmation step.

The behaviour required is precise. When a recipient clicks "unsubscribe" in the Gmail or Yahoo interface, the provider sends a POST request to your URL, and you must honour it within two days. You cannot redirect the user to a preference centre, make them log in, or ask them to confirm a second time for that one-click path. The user-visible unsubscribe link inside the email body is still expected as well, but it is the header-based one-click flow that the providers test.

Two further points worth stressing:

• One-click unsubscribe is required only for bulk mail. Transactional messages (password resets, receipts, shipping notifications) are not subject to it, though adding it does no harm.
• "Honour within two days" is a hard processing-time expectation, not a suggestion. Slow or broken unsubscribe handling feeds directly into the next requirement, the spam-rate ceiling.

Requirement four: keep the spam rate under threshold

This is the requirement with explicit numbers, and the numbers are unforgiving.

Google requires bulk senders to keep their user-reported spam rate below 0.3%, measured in Google Postmaster Tools, and states plainly that senders should aim to stay under 0.1% to be safe. The 0.3% figure is the line at which delivery problems begin; it is not a comfortable cruising altitude. To put it in human terms: 0.3% is three spam complaints for every thousand delivered messages. A single badly targeted campaign can blow past that in an afternoon.

Yahoo's guidance mirrors the spirit of Google's and points senders at the same idea: keep complaints low and stay well under the danger threshold. Microsoft applies comparable expectations and, like Google, measures complaints from its own users' "report spam" actions.

A few practical notes on the spam rate:

• It is measured by the provider from real user "report spam" clicks, not by you. You need Google Postmaster Tools connected to see your number; there is no other accurate source.
• The threshold is per provider and is calculated over a rolling window, so a spike does not vanish instantly. Recovery takes sustained good behaviour.
• A working one-click unsubscribe is the single biggest lever for keeping this number down, because users who can leave quietly do not report you as spam.

The reason the spam rate sits in a requirements list alongside cryptographic authentication is that the providers see them as one system. Authentication proves identity; the spam rate proves that the identified sender is wanted. You need both.

Requirement five: valid forward and reverse DNS, and TLS

These are the quieter infrastructure requirements that are easy to overlook because they live below the application layer.

Valid PTR records (reverse DNS). The IP address you send from must have a PTR record that resolves back to a hostname, and that hostname should forward-resolve to the same IP. This is "forward-confirmed reverse DNS", and Google checks it. Senders on shared infrastructure or a major email service provider usually inherit this automatically; senders running their own mail servers must configure it deliberately with their hosting provider.

A valid HELO/EHLO identity. The hostname your server announces in the SMTP conversation should be a real, resolvable name that matches your sending identity, not a generic or mismatched value.

TLS for transport. Google requires that connections delivering mail to Gmail use TLS. Opportunistic TLS is now effectively the floor for any serious sender. This is separate from, but complementary to, MTA-STS, which lets you tell senders to refuse to deliver to you over an unencrypted or improperly certificated connection. If you receive mail as well as send it, an MTA-STS policy is worth publishing; check yours with the MTA-STS checker.

How the three providers differ

The rules overlap heavily, but the differences matter when you are diagnosing a specific bounce.

• Volume threshold. Google and Microsoft both use roughly 5,000 messages per day to consumer mailboxes. Yahoo declines to publish a number and enforces "bulk" more by behaviour, while treating the authentication baseline as universal.
• Enforcement timing. Google and Yahoo enforced from February 2024, with a gradual tightening through the year (temporary failures first, then rejections). Microsoft announced its programme in 2025 and began enforcing for high-volume senders from May 2025, initially routing non-compliant bulk mail to the Junk folder rather than rejecting it outright, with rejection to follow.
• Where you read your spam rate. Google exposes it in Postmaster Tools; Microsoft has its own Smart Network Data Services (SNDS) and Junk Mail Reporting Program. The numbers are not interchangeable, so monitor each platform you send to in volume.
• Strictness of "bulk". Because Yahoo applies the authentication rules to everyone, a small sender who ignores DMARC will feel Yahoo's enforcement before Google's bulk gate ever applies to them.

The safe engineering decision is to build to the strictest interpretation of all three and stop worrying about which provider does what. A domain with aligned SPF and DKIM, an enforced DMARC policy, RFC 8058 one-click unsubscribe, a healthy spam rate, valid PTR and TLS will pass everywhere.

The compliance checklist

Work through these in order. Each line is pass or fail.

1. SPF record exists and is valid. A single v=spf1 ... -all (or ~all) record, syntactically correct, listing every legitimate sender. Verify: SPF checker.
2. SPF stays within ten DNS lookups. No permerror. If you are over, flatten or consolidate senders. See SPF flattening.
3. DKIM is signing live mail. A published public key under a selector, at least 1024-bit (prefer 2048-bit), with the signature passing on real messages. Verify: DKIM checker.
4. DMARC record is published at _dmarc.yourdomain.com with at least p=none and a rua= reporting address. Build it with the DMARC generator; verify with the DMARC checker.
5. DMARC actually passes via alignment. Confirm that SPF or DKIM passes and aligns with the visible From: domain on your real outbound streams, not just in theory. See DMARC alignment explained.
6. The From-domain you send from is the one with the policy. No apex/subdomain mismatch. See the sp subdomain policy.
7. One-click unsubscribe headers are present on bulk mail. Both List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058), and your endpoint processes the POST within two days.
8. A visible unsubscribe link also appears in the body of marketing messages.
9. User-reported spam rate is under 0.3%, ideally under 0.1%. Monitored in Google Postmaster Tools and the equivalent at each provider.
10. Valid reverse DNS (PTR) on every sending IP, forward-confirmed.
11. TLS is used for delivery to Gmail and other providers.
12. You are reading your DMARC reports. Aggregate (RUA) reports tell you which senders are passing and which are forging your domain. Without them you are flying blind. See DMARC reports vs the inbox and RUA vs RUF reports.

Beyond compliance: getting to p=reject safely

Passing the entry requirements with p=none keeps your mail flowing, but it leaves your domain spoofable. Anyone can still forge your From: address and the policy tells receivers to do nothing about it. The real prize, and the only state that stops impersonation, is an enforced policy of p=quarantine or p=reject with alignment across every legitimate sending source.

Getting there is where most teams stall, because moving to enforcement before every legitimate source is aligned will silently send your own mail to spam. The correct sequence is: publish p=none with reporting, read the aggregate reports until you can account for every source sending as your domain, fix or align the stragglers, then ratchet the policy up. Our guide on moving from none to reject walks through the staged rollout, and you can sample a percentage of mail at each step using the pct tag.

If reading raw XML reports and chasing down stray senders is not how you want to spend the next quarter, that is exactly what DMARC Engine does for you: it ingests your aggregate reports, shows you every sending source in plain English, tells you what to fix, and takes the domain from p=none to p=reject without an email outage. You can also set up emailed monitoring so you are alerted the moment a record changes or a new source appears.

The practical takeaway

The 2024 and 2025 bulk-sender requirements are not a temporary hurdle; they are the new permanent floor for email delivery. The whole list reduces to one idea: prove your mail is really from you, make it easy to leave, and do not annoy people. Authenticate with aligned SPF and DKIM, publish and eventually enforce DMARC, ship a working one-click unsubscribe, keep your spam rate under 0.3% (target 0.1%), and get your reverse DNS and TLS in order.

Start by finding out where you stand today. Run your domain through the free tools, beginning with the DMARC checker, and work down the checklist above. The requirements page keeps the live thresholds in one place, and the glossary defines any term here you want to dig into further.