A marketing team sends its Tuesday newsletter to 60,000 people. On Wednesday the ESP dashboard shows a block of bounces from Hotmail and Outlook addresses, all with the same reply: 550 5.7.515 Access denied, sending domain does not meet the required authentication level. Nothing about the list changed. What changed is that the domain had SPF but no DKIM, and Microsoft stopped accepting that from high-volume senders.

Google and Yahoo began enforcing their bulk sender rules in February 2024. Microsoft followed for Outlook.com in May 2025, and in November 2025 Gmail started ramping up enforcement, including temporary and permanent rejections. The rules overlap heavily, but not completely, and the differences are where teams get caught.

This is the current checklist, checked against each provider’s own documentation on October 18, 2026. Where a provider is vague or contradicts itself, we say so.

What changed in 2025 and 2026

The requirements themselves have barely moved since 2024. The consequences have.

Date Provider Change
February 1, 2024 Gmail Sender requirements take effect for all senders, with extra rules above 5,000 messages a day
February 2024 Yahoo Gradual enforcement of its sender requirements begins
June 1, 2024 Gmail Deadline for senders with an existing unsubscribe link to add one-click unsubscribe
June 2024 Yahoo List-Unsubscribe enforcement begins
April 2, 2025 Microsoft Outlook.com announces SPF, DKIM and DMARC requirements for domains sending over 5,000 messages a day
May 5, 2025 Microsoft Enforcement starts. An April 29 update replaced “Junk first” with rejection using 550 5.7.515
November 2025 Gmail “Ramping up” enforcement on non-compliant traffic, including temporary and permanent rejections
May 2026 IETF RFC 9989 replaces RFC 7489 as the DMARC specification, now on the Standards Track

Microsoft’s announcement page is confusing on this point. Its opening section still says non-compliant mail “will first be routed to Junk”, but the April 29 update further down says failing messages are rejected, and the old Junk paragraph is struck through. Microsoft’s support page for the error says it “now” enforces the requirements. Plan for rejection.

Google also says that a domain which had not sent more than 5,000 messages a day to Gmail since January 1, 2024 is a “new domain” and faces enforcement “on an accelerated timetable”. If you are spinning up a fresh sending domain, you get less patience, not more.

The requirements side by side

  • All senders
  • Bulk senders
  • Recommended
  • Not stated

Who is a bulk sender

Gmail: Close to 5,000+ a day to personal Gmail, counted per primary domain. Temporary and permanent rejections since Nov 2025.

Yahoo: "Significant volume", no number published. Spam folder or rejection.

Outlook.com: 5,000+ a day, same From domain. Rejected with 550 5.7.515 since May 5, 2025.

SPF or DKIM passes

At least one of the two

Gmail
All senders
Yahoo
All senders
Outlook.com
Recommended 1

SPF and DKIM both pass

Both records published and passing

Gmail
Bulk senders
Yahoo
Bulk senders
Outlook.com
Bulk senders

DMARC record

p=none is the minimum

Gmail
Bulk senders
Yahoo
Bulk senders
Outlook.com
Bulk senders

DMARC alignment

From domain aligns with SPF or DKIM

Gmail
Bulk senders 2
Yahoo
Bulk senders
Outlook.com
Bulk senders

Forward and reverse DNS

PTR record on the sending IP

Gmail
All senders
Yahoo
All senders
Outlook.com
Not stated

TLS

Encrypted SMTP connection

Gmail
All senders
Yahoo
Not stated
Outlook.com
Not stated

RFC 5322 formatting

Valid Message-ID, single From, To, Subject, Date

Gmail
All senders
Yahoo
All senders 3
Outlook.com
Not stated

Spam rate under 0.3%

User-reported complaints

Gmail
All senders 4
Yahoo
All senders
Outlook.com
Not stated

One-click unsubscribe

List-Unsubscribe and List-Unsubscribe-Post headers

Gmail
Bulk senders 5
Yahoo
Bulk senders 6
Outlook.com
Recommended 7

Visible unsubscribe link

In the message body

Gmail
Bulk senders
Yahoo
Bulk senders
Outlook.com
Recommended

Unsubscribes honored in 2 days

Removed from that list

Gmail
Bulk senders 8
Yahoo
Bulk senders
Outlook.com
Not stated
  1. 1Microsoft enforces authentication on high-volume senders and says smaller senders "benefit from these best practices".
  2. 2Gmail: required for direct mail. Forwarded and mailing-list messages are exempt.
  3. 3Yahoo asks for RFC 5321 and RFC 5322 compliance.
  4. 4Gmail: the requirement is under 0.3%; the target in its guidelines is under 0.10%.
  5. 5Gmail: marketing and subscribed mail only. Transactional mail is exempt. A mailto link does not count.
  6. 6Yahoo: the POST method (RFC 8058) is "highly recommended"; mailto is acceptable.
  7. 7Microsoft asks for a functional, clearly visible unsubscribe link and does not specify headers.
  8. 8Gmail says 48 hours and calls it a recommendation, but missing it makes you ineligible for delivery mitigation.
Sender requirements at Gmail, Yahoo and Outlook.com as published on October 18, 2026. Not stated means the provider's public requirements do not mention it, not that it is ignored.

Two patterns stand out. Gmail and Yahoo regulate everyone a little and bulk senders a lot. Microsoft only regulates high-volume senders, and only on authentication; everything else on its list is a recommendation, with a reservation of the right to filter or block “non-compliant senders”.

Who counts as a bulk sender

Gmail defines a bulk sender as one that sends “close to 5,000 messages or more to personal Gmail accounts within a 24-hour period”. Three details matter:

  • It is counted per primary domain. Google’s own example: 2,500 messages from solarmora.com plus 2,500 from promotions.solarmora.com in a day makes you a bulk sender. Splitting traffic across subdomains does not keep you under the line.
  • It is permanent. Cross the threshold once and you are a bulk sender forever. Google says changing your sending practices later does not remove the status.
  • Only personal Gmail recipients count. Mail to Google Workspace accounts is outside the requirements, but Workspace users sending to personal Gmail addresses are inside them.

Yahoo refuses to publish a number. Its FAQ says a bulk sender sends “a significant volume of mail”, that a sender is judged at the authenticated domain or From domain level, and that spoofed mail using your domain counts toward the volume Yahoo looks at.

Microsoft uses “over 5,000 emails per day” in its announcement. Its 5.7.515 support page frames it as 5,000 or more messages to Microsoft consumer services (Outlook.com, Hotmail, Live.com, MSN) that all use the same domain in the From address.

Our view: if you send marketing email at all, meet the bulk requirements. The extra work over the all-sender baseline is a DMARC record and two headers, and Yahoo will not tell you when you have crossed its line.

SPF and DKIM: the baseline for everyone

Gmail and Yahoo require every sender to pass at least one of SPF or DKIM. Bulk senders need both. Microsoft’s 5.7.515 page says both checks “must pass” for high-volume senders.

SPF is a single TXT record at your domain listing who may send for it:

example.com.   3600  IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

Publish exactly one SPF record per domain. RFC 7208 caps evaluation at 10 DNS-querying terms (include, a, mx, redirect and friends), and every ESP you add usually costs at least one. Our SPF record generator counts them for you.

DKIM is a public key published under a selector that your mail server or ESP uses to sign each message:

s1._domainkey.example.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu5...IDAQAB"

Gmail requires a key of at least 1024 bits for mail to personal accounts and recommends 2048. Yahoo recommends at least 1024. The detail that trips people up is the signing domain. If your ESP signs with d=esp-mail.example rather than d=example.com, DKIM passes but does nothing for DMARC alignment, which is the next requirement.

DMARC and alignment for bulk senders

All three providers want a DMARC record from bulk senders, and all three accept p=none. Yahoo adds that including a rua reporting address is “strongly recommended”:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

The DMARC record generator builds this for you, including the reporting address.

Publishing the record is the easy half. DMARC only passes when SPF or DKIM passes for a domain that aligns with the domain in the visible From header. Relaxed alignment, the default and explicitly acceptable to Yahoo, means the two only need to share an organizational domain, so news.example.com aligns with example.com. Here is what a passing message looks like in Gmail’s headers:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1;
       spf=pass smtp.mailfrom=bounces@mail.example.net;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

SPF passes, but for example.net, which does not align with example.com. DKIM passes for example.com, which does. One aligned pass is enough, so DMARC passes. This is the most common real-world setup: the ESP owns the bounce domain and you own the DKIM key. Microsoft and Google both suggest aligning both mechanisms, and Google says it is “likely” that alignment with both will eventually be required.

Gmail exempts forwarded and mailing-list messages from the alignment rule, since forwarding breaks SPF by design.

Reverse DNS, TLS and message format

These three are usually your ESP’s job, but you own the consequences.

Forward and reverse DNS. Gmail and Yahoo require every sending IP to have a PTR record, and Gmail wants the PTR hostname to resolve back to the same IP. You can check it in two commands:

$ dig +short -x 203.0.113.25
mta25.mail.example.com.
$ dig +short A mta25.mail.example.com
203.0.113.25

If the first command returns nothing, or the second returns a different address, Gmail answers with 451 4.7.23 or 550 5.7.25. Yahoo also recommends meaningful PTR names rather than generic ones.

TLS. Gmail added “use a TLS connection for transmitting email” to the all-sender list in December 2023, and its rejection for plain-text connections is 550 5.7.29. Yahoo and Microsoft do not list TLS. If you run your own mail server, confirm outbound STARTTLS is on; if you use an ESP, check its documentation rather than assuming.

RFC 5322 formatting. Gmail requires a valid Message-ID on every message and says single-instance headers such as From, To, Subject and Date must appear only once. Yahoo asks for compliance with RFC 5321 and RFC 5322 generally. Home-grown sending code that builds headers by string concatenation is the usual suspect.

One-click unsubscribe, done properly

This is the requirement most often implemented wrong. A footer link labelled “Unsubscribe” does not satisfy it. Gmail and Yahoo want the RFC 8058 mechanism, which lets the mailbox provider show its own unsubscribe button and act on it without the user visiting your site.

It takes two headers on every marketing or subscribed message:

List-Unsubscribe: <https://example.com/u/7f3a9c2e1b>, <mailto:unsub@example.com?subject=7f3a9c2e1b>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

When a recipient clicks the provider’s button, the provider sends your server this request:

POST /u/7f3a9c2e1b HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26

List-Unsubscribe=One-Click

RFC 8058 sets the rules for both sides:

  • List-Unsubscribe must contain one HTTPS URI. A mailto: can sit alongside it, but Gmail says mailto alone does not meet its requirement. Yahoo accepts mailto but calls the POST method “highly recommended”.
  • The message must carry a valid DKIM signature that covers both headers, meaning both names appear in the signature’s h= tag. Without it, receivers should not offer one-click.
  • The URL must identify the recipient and list on its own, ideally with an opaque token. The POST arrives without cookies or login, and your endpoint must not answer with a redirect.

A DKIM signature that covers the headers looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=s1;
        h=from:to:subject:date:message-id:list-unsubscribe:list-unsubscribe-post;
        bh=...; b=...

Both Gmail and Yahoo also require a clearly visible unsubscribe link in the body, which can lead to a preference page. Transactional mail such as password resets, receipts and booking confirmations is exempt from the one-click requirement.

Then process the removal. Yahoo says an unsubscribe not honored within 2 days does not meet the requirement. Gmail says 48 hours and calls it a recommendation, but its own enforcement table lists “unsubscribe requests aren’t honored within 48 hours” as a reason you lose access to delivery mitigation. Removals only need to cover the list the message came from, not every message you send.

Spam complaint rates: 0.10% target, 0.30% ceiling

Gmail’s requirement lists say to keep the spam rate shown in Postmaster Tools below 0.3%. The spam rate section of the same guidelines is stricter: stay below 0.10% and avoid ever reaching 0.30%. Google’s FAQ explains why both numbers exist. The impact is graduated: rates above 0.1% already hurt inbox placement, and 0.3% or more hurts it further and makes you ineligible for mitigation. The rate is calculated daily.

The arithmetic is unforgiving. On 20,000 messages a day, 0.10% is 20 spam reports and 0.30% is 60. One campaign to an old segment can do that in an afternoon.

Yahoo also uses 0.3%, and adds that it calculates the rate on mail delivered to the inbox, so your own numbers from its Complaint Feedback Loop (CFL) need the same denominator. If you have not signed up for Yahoo’s feedback loop, you are blind to who is complaining there. Microsoft publishes no complaint threshold.

What happens when you miss one

Google’s FAQ is the most explicit. Failing alignment, SPF and DKIM, reverse DNS, TLS or RFC 5322 formatting leads to “temporary or permanent failure codes, or spam foldering”. A spam rate above 0.3%, a missing DMARC record, missing one-click unsubscribe or slow removals make “delivery support or mitigations unavailable”: Google will not help you when something goes wrong.

The rejections name the cause, which makes them easy to triage:

550 5.7.27 This message was blocked because it didn't pass SPF authentication.
550 5.7.29 This message was blocked because it wasn't sent over a TLS connection.
421 4.7.32 Your email has been rate limited because the From: header (RFC5322) in this
           message isn't aligned with either the authenticated SPF or DKIM organizational domain.
550 5.7.40 Your message was blocked because the sending domain doesn't have a DMARC record
           or the DMARC record doesn't specify a DMARC policy.
550 5.7.515 Access denied, sending domain example.com does not meet the required authentication level.

The first four come from Gmail, the last from Outlook.com. Yahoo says non-compliant mail “may be sent to the spam folder or rejected”, with a specific error code when it is rejected.

Where list verification fits, and where it does not

Verification and authentication solve different problems, and it is worth being blunt about it. No amount of list cleaning fixes a missing DKIM key. A list where every address is deliverable, sent from a domain without DMARC, will still collect 5.7.40 and 5.7.515 rejections.

What verification does is keep invalid addresses out of your sends. Microsoft lists “List Hygiene & Bounce Management: Remove invalid addresses regularly” among its recommendations for high-volume senders. Google tells senders to confirm each recipient’s address before subscribing them and to automatically unsubscribe recipients after multiple bounced messages. In our view, a high hard-bounce rate is also a symptom: it usually means part of the list is old or was never confirmed, and that same part tends to produce the spam complaints.

In practice, the order of work is:

  1. Fix authentication first, because it fails every message.
  2. Verify the list before the next large send, and on a schedule after that.
  3. Watch spam rate in Postmaster Tools and Yahoo’s CFL, because that is the number most likely to move from week to week.

Clean the list, then keep the records honest

RocketVerifier flags undeliverable, risky and unknown addresses before you send, and never charges for unknowns. Monitors re-check SPF, DKIM, DMARC and blocklists on a schedule and alert you when something breaks.

Start with 100 free credits

You can check a domain’s current SPF, DKIM and DMARC setup in seconds with the free email deliverability checker.

The setup checklist

Meet Gmail, Yahoo and Outlook.com requirements

  • Count daily volume to Gmail and Outlook.com per From domain, including subdomains. If you are anywhere near 5,000, treat yourself as a bulk sender.
  • List every service that sends as your domain: ESP, CRM, helpdesk, billing system and your own servers.
  • Publish one SPF record that covers every sender and stays within 10 DNS lookups.
  • Turn on DKIM for each sender using your own domain in d=, with a 2048-bit key where supported.
  • Publish a DMARC record at _dmarc with p=none and a rua address, and read the aggregate reports.
  • Send a test to a Gmail account and confirm dmarc=pass with header.from set to your domain.
  • Check that each sending IP has a PTR record whose hostname resolves back to the same IP.
  • Confirm your server or ESP sends over TLS and sets a valid Message-ID on every message.
  • Add List-Unsubscribe with an HTTPS URL and List-Unsubscribe-Post to all marketing mail, both covered by the DKIM signature.
  • Keep a visible unsubscribe link in the body and process removals within 2 days.
  • Register your domain in Google Postmaster Tools and join Yahoo's Complaint Feedback Loop.
  • Keep the spam rate under 0.10%, and verify the list before large sends so hard bounces stay low.