Gmail & Yahoo Sender Requirements: The Complete 2026 Reference

Last reviewed: 10 August 2026

Any domain sending close to 5,000 or more messages a day to personal Gmail addresses must authenticate with SPF and DKIM, publish a DMARC record (p=none is sufficient), align the From: domain with either SPF or DKIM, support RFC 8058 one-click unsubscribe on marketing mail, honor unsubscribes within two days, and keep its Postmaster Tools spam rate below 0.30%. Every sender — bulk or not — needs SPF or DKIM, valid forward and reverse DNS, and TLS. Yahoo enforces substantially the same list but publishes no volume threshold. Since November 2025, Gmail has been ramping up enforcement with both temporary and permanent rejections.

The Requirements at a Glance

Sources: Google’s Email sender guidelines and the Yahoo Sender Hub best practices. TLS appears nowhere in Yahoo’s own documentation despite widespread claims otherwise — enable it regardless, since Gmail requires it.

Who Counts as a Bulk Sender

Google’s definition is the operative one, because Yahoo declines to publish a number — its FAQ states flatly: “We will not specify a volume threshold.” Google classifies you as a bulk sender at close to 5,000 messages or more to personal Gmail accounts within a 24-hour period.

Counted per domain, not per IP

The threshold is measured against your primary domain, with subdomains rolling up into it. Google’s own example: 2,500 messages from solarmora.com plus 2,500 from promotions.solarmora.com equals 5,000 from the primary domain. Splitting traffic across IPs, ESPs, or subdomains does not keep you under the line.

Only personal Gmail accounts count

The count covers @gmail.com and @googlemail.com only — Google states the guidelines “don’t apply to messages sent to Google Workspace accounts.” A B2B sender mailing 50,000 corporate addresses daily may sit under the threshold while still being judged on authentication by every gateway in front of those mailboxes.

Bulk sender status is permanent

Per Google: “Bulk sender status doesn’t have an expiration date. Email senders that have been classified as bulk senders are permanently classified as such,” and “changes in email sending practices will not affect permanent bulk sender status once it’s assigned.”

Cross 5,000 once — a Black Friday send, a migration blast — and you are held to the bulk requirements from then on. Plan for your peak, not your average.

The trap: under the threshold is not safe

• The all-sender requirements still bind you. SPF or DKIM, valid PTR records, TLS, and RFC 5322 formatting apply at any volume. The 5.7.26 rejection does not check your daily count first.
• Filtering is reputation-driven, not rule-driven. Meeting the minimums gets your mail evaluated, not delivered. A sender at 800 messages a day with a 0.8% complaint rate lands in spam regardless of a clean DMARC record.

If you are within an order of magnitude of 5,000 a day to Gmail, implement the full bulk set now. The work is identical and the classification is irreversible.

Requirement 1: Email Authentication

SPF and DKIM

All senders need SPF or DKIM. Bulk senders need both. Gmail also requires a DKIM key of 1024 bits or longer — use 2048-bit unless your DNS provider cannot hold the record. Keep SPF within the ten-DNS-lookup limit: exceeding it returns permerror, which is a failure, not a warning, and is the most common silent break when a company adds its fourth or fifth SaaS sender.

DMARC: what policy is actually required

The published minimum is p=none. Yahoo’s wording: “Publish a valid DMARC policy with at least p=none – DMARC must pass.” A minimal compliant record:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The rua tag is not required, but publishing p=none without collecting aggregate reports wastes the point of the record — it is a monitoring policy that tells you which senders fail alignment so you can fix them before moving to p=quarantine. Our implementation guide covers record syntax and the staged rollout in full.

Vendor claims that Google now requires p=quarantine or p=reject are contradicted by its live documentation, which still reads “Your DMARC enforcement policy can be set to none.” Google’s FAQ notes that “It’s likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement,” but attaches no date — intent, not a rule.

Alignment — the part that actually fails

Publishing the records is not the requirement. Passing is. The domain in your From: header must align with either the SPF domain (the Return-Path) or the DKIM d= domain. Relaxed alignment is acceptable to both providers, so the organizational domain must match but subdomains may differ.

The classic failure: you send as [email protected] through an ESP that sets the Return-Path to [email protected] and signs DKIM with d=esp-provider.net. SPF passes. DKIM passes. DMARC fails, because neither aligns with example.com. The fix is a custom DKIM signing domain, a custom bounce domain, or both.

Requirement 2: One-Click Unsubscribe (RFC 8058)

Bulk senders must support one-click unsubscribe on marketing and subscribed messages and keep a clearly visible unsubscribe link in the body. It is both, not either.

The exact headers

List-Unsubscribe: <https://example.com/unsubscribe?id=abc123>, <mailto:[email protected]>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

Per RFC 8058, the List-Unsubscribe-Post value must be exactly List-Unsubscribe=One-Click — no variation in spelling, spacing, or casing, because clients string-match it. The List-Unsubscribe header must contain an HTTPS URI; a mailto: may also appear but cannot be the only entry. Both headers must be covered by your DKIM signature.

The honoring deadline

Both providers require unsubscribes honored within two days. Yahoo’s phrasing: “Honor unsubscribes within 2 days.” That is the ceiling, not the service level — process immediately and you never have to defend the number.

The common implementation mistake

Acting on the GET request instead of the POST. RFC 8058 exists because mail clients and security scanners pre-fetch URLs found in headers. If your endpoint unsubscribes anyone issuing a GET, scanners will silently unsubscribe engaged recipients and you will see attrition with no user action behind it. Unsubscribe only on a POST carrying the List-Unsubscribe=One-Click body.

Three more that recur: requiring a login (redirecting to an authenticated preference center is a failed implementation even with the header present); a non-idempotent endpoint (a duplicate POST must not error or re-subscribe); and headers on the wrong mail (add them to marketing and subscribed messages, not to password resets).

Requirement 3: Spam Complaint Rate

The threshold is 0.30% as reported in Google Postmaster Tools. Google’s guidance goes further: keep it below 0.10% and “avoid ever reaching a spam rate of 0.30% or higher.” Both numbers are Google’s and they are two different lines — 0.10% is the target, 0.30% is the cliff. Yahoo uses the same 0.30% figure. Google: “Beginning June 2024, bulk senders with a user-reported spam rate greater than 0.3% will be ineligible for mitigation.” Note the threshold is greater than 0.3%, and eligibility returns once the rate stays below 0.3% for 7 consecutive days.

How it is measured

The denominator is mail delivered to the inbox — not messages sent, and not messages accepted. Yahoo confirms the same denominator in its Sender Hub Insights documentation: complaint rate is computed only on mail delivered to the inbox, which is why it differs from a sender’s own figure that includes spam-foldered mail. Google does not publish a formula, but its figure behaves the same way.

Two consequences follow. First, your ESP’s complaint rate and the provider’s are not the same metric — your ESP divides by messages sent, the providers divide by a smaller number, so their figure always runs higher and it is the only one that counts. Second, as reputation degrades and more mail is routed to spam, the denominator shrinks and the reported rate climbs even when complaint volume is flat. Spam rate accelerates in exactly the situation where you need it stable.

The rate is also daily, so one bad campaign can spike it, and domain-level, so one careless list contaminates every stream on that domain — the argument for separating marketing and transactional mail onto different subdomains.

Where to monitor it

• Google Postmaster Tools (postmaster.google.com) — spam rate, domain and IP reputation, authentication pass rates, TLS and delivery errors. Requires DNS TXT verification, and is the only place Google’s official spam rate appears. Domain and IP reputation are absent from the v2 interface and v2 API and are slated for retirement on an unannounced date — do not build permanent monitoring on them.
• Yahoo Sender Hub (senders.yahooinc.com) — including Insights and the Complaint Feedback Loop. The CFL delivers individual ARF reports rather than an aggregate percentage, so you compute the rate yourself against inbox-delivered volume.
• Your ESP’s reporting — useful for attributing a spike to the campaign that caused it, but remember its denominator differs.

Requirement 4: Forward and Reverse DNS, and TLS

These apply to every sender at any volume, and are checked at connection time — before content, before reputation.

Google’s requirement: “The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.” That is a round trip, often called full-circle DNS: IP → hostname via PTR, then hostname → IP via A record, landing on the same IP. A PTR pointing to a hostname with no A record, or one resolving elsewhere, fails — as does the generic PTR your host assigns by default. Your HELO/EHLO hostname should match too. Only the network operator can set a PTR record, so this is a request to your host or ESP.

Google requires TLS for transmitting email, added to the guidelines in December 2023. Opportunistic TLS via STARTTLS satisfies it — you do not need MTA-STS or DANE, though both are reasonable hardening. Yahoo’s documentation contains no TLS mandate, but there is no scenario in which sending in the clear helps you.

What Happens When You Fail Each Requirement

Gmail publishes a specific code per failure, paired as 4.7.x temporary and 5.7.x permanent. The code names the requirement, which makes this the fastest diagnostic you have:

A 5.x.x is permanent: refused outright, never retried, recorded by your ESP as a hard bounce. A 4.x.x is retryable — but treat deferrals as the last cheap warning you will get, not routine throttling. Two companion guides go deeper: the full 5.7.x reference, and how to respond to a 4.7.x deferral before it becomes a rejection.

A common vendor narrative holds that Gmail “flipped” these failures from 4.x.x to 5.x.x in November 2025. Both code families predate that date, Google published no per-code cutover, and we found no measured telemetry supporting it. Google documented a general ramp-up in severity, not a specific code change.

Unsubscribe and complaint failures behave differently: they generally produce no bounce at all. Mail is accepted with a 250 and filed in spam, so your delivery metrics look healthy while engagement quietly collapses. This is why Postmaster Tools matters more than your ESP’s delivered rate.

Yahoo publishes far less operational detail. In practice it throttles with 4.x.x deferrals under reputation pressure, applies spam foldering for complaint and unsubscribe failures, and rejects unauthenticated mail. Yahoo has published no code-by-code enforcement table equivalent to Google’s — treat this as observed behavior, not documented policy.

How to Verify You Comply Today

Work through this in order. Each item gives a definitive answer — do not rely on a dashboard saying “configured.”

Items 4, 9 and 13 fail most often in otherwise well-configured setups, because each tests behavior rather than the presence of a record. Publishing a DMARC record is trivial; passing alignment on every stream is not.

Changelog: How These Rules Evolved

• May 2026 — DMARC restandardized. RFC 9989 obsoletes RFC 7489 (with RFC 9990 and 9991). Gmail and Yahoo requirements are unchanged, but the record syntax is: pct= is removed, np= (non-existent subdomains) and t= (test mode) are added, and a DNS Tree Walk replaces the Public Suffix List for finding the organizational domain.
• January–July 2026 — no changes. Every Google Workspace Updates monthly archive for 2026 reviewed; no post touching authentication, DMARC, TLS, spam thresholds, the 5,000/day threshold, unsubscribe, or Postmaster Tools. Caveat: this covers announcements. Google has changed support-page text without announcing it, which is exactly how the 2025 escalation happened.
• November 2025 — Gmail escalates enforcement. Google’s FAQ: “Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.” The requirements did not change; the consequence of ignoring them did. Google never announced this — it appeared as a silent support-page edit, with no blog post and no Workspace Updates entry that month. Researcher Al Iverson dates the edit to 3 November 2025.
• 27 October 2025 — Yahoo launches Sender Hub Insights. Per-DKIM-domain complaint rate and delivered volume, replacing reliance on raw feedback-loop reports alone.
• May 2025 — Microsoft joins. Outlook, Hotmail and Live.com applied their own requirements at a 5,000/day threshold from 5 May 2025, with non-compliant mail rejected as 550 5.7.515. Microsoft’s announcement is internally inconsistent and both halves remain live: an April 29 revision states a decision to reject, while surrounding text still says non-compliant messages “will first be routed to Junk” with rejection “at a date to be announced.” That date was never announced and the April 2025 post remains Microsoft’s latest word. Microsoft’s published requirements cover SPF, DKIM and DMARC only — claims that it mandates one-click unsubscribe, PTR records or complaint thresholds are vendor invention. We document Microsoft’s equivalent ruleset separately.
• June 2024 — mitigation support withdrawn above a 0.30% spam rate.
• 1 June 2024 — one-click unsubscribe deadline. Google: “Senders that already include an unsubscribe link in their messages have until June 1, 2024 to implement one-click unsubscribe in all commercial, promotional messages.” A grace deadline for senders already carrying a link, not a universal launch date.
• 1 February 2024 — requirements take effect. Google: “Starting February 1, 2024, all email senders who send email to Gmail accounts must meet the requirements.” Yahoo aligned on the same month.
• December 2023 — TLS added to Google’s guidelines.
• October 2023 — joint announcement by Google and Yahoo, giving roughly three months’ notice. This is what most 2023-era coverage refers to.

How Mailercloud Handles This

At Mailercloud we deliver over a billion emails a month, so these requirements are built into the platform rather than left to configuration. Custom DKIM signing and custom bounce domains are set up at onboarding so DMARC alignment passes on your own domain. RFC 8058 headers are added automatically to marketing sends, with unsubscribes processed immediately rather than within the two-day allowance. PTR records and TLS are managed at the infrastructure level across shared and dedicated pools, and our deliverability team monitors complaint rates against the 0.10% target rather than the 0.30% ceiling.

If you need help getting a domain compliant, talk to our deliverability team — or start free with Mailercloud.

FAQ

Do these requirements apply if I send fewer than 5,000 emails a day?

Partly. SPF or DKIM, valid forward and reverse DNS, TLS, and RFC 5322 formatting apply at any volume, and authentication failures are rejected regardless of how much you send. The bulk-only additions are SPF and DKIM together, DMARC, and one-click unsubscribe. Because bulk classification is permanent once triggered, implement the full set if you are anywhere near the threshold.

Is p=none really enough for DMARC?

Yes, as of this review date. But p=none offers no protection against domain spoofing, and DMARC must actually pass with alignment — a published record that fails alignment does not satisfy the requirement. Use p=none with aggregate reporting to find misaligned streams, then move to p=quarantine.

Does the 5,000 threshold count business email addresses?

No. Only @gmail.com and @googlemail.com count. Google states the guidelines do not apply to Google Workspace accounts, so mail to corporate domains hosted on Workspace is judged by the receiving organization’s own filtering.

If my volume drops below 5,000, do I stop being a bulk sender?

No. Google is explicit that bulk sender status has no expiration date and is unaffected by later changes in sending practice. A single day above the threshold classifies you indefinitely. Microsoft applies the same stickiness.

Why is my spam rate rising when complaints are flat?

Because the denominator is inbox-delivered mail. As reputation degrades and more mail is routed to spam, fewer messages count in the denominator, so the same number of complaints produces a higher percentage. It accelerates once it starts — which is why 0.10% is the number to manage to, not 0.30%.