Two separate things are true in 2026. Gmail and Yahoo’s bulk sender requirements have not changed since February 2024. Separately, the DMARC specification itself was formally updated in May 2026 through a set of new RFCs. These are not the same event, and treating them as one leads to the wrong fixes. This article keeps three things distinct: what Gmail and Yahoo actually require, what changed in the DMARC standard, and what Nozentra recommends as good practice beyond the minimum.
Key takeaways
- Gmail and Yahoo’s bulk sender rules are unchanged since February 2024: authentication, a DMARC record, a low spam complaint rate, and one-click unsubscribe support.
- DMARC’s own specification was updated in May 2026 (informally called DMARCbis), a protocol change from the IETF, separate from any Gmail or Yahoo policy.
- Neither Gmail nor Yahoo requires the new DMARC tags. A basic, valid DMARC record still satisfies their requirement.
- A DMARC policy of p=none is technically compliant with Gmail and Yahoo’s rules. Moving to enforcement is a security best practice, not a compliance requirement.
- Authentication supports deliverability but does not guarantee inbox placement, which depends on several signals together.
Two different stories, often told as one
Gmail and Yahoo’s bulk sender requirements, enforced since February 2024, ask senders of 5,000 or more daily messages to Gmail addresses to authenticate their mail, publish a DMARC record, support one-click unsubscribe, and keep spam complaints low. None of that has changed.
Separately, DMARC as a protocol was updated in May 2026 through three new IETF RFCs, an update commonly called DMARCbis. This is a specification change, not a Gmail or Yahoo announcement, and neither provider has said the new record tags are required for compliance. A 2024 DMARC record remains valid and compliant under both frameworks today.
What Gmail and Yahoo actually require
In plain terms: SPF and DKIM configured so mail can be authenticated, a published DMARC record (even at the lightest setting, p=none, which only monitors), a low spam complaint rate, and one-click unsubscribe under RFC 8058, which needs a List-Unsubscribe header plus a List-Unsubscribe-Post header. A single working one-click method satisfies this. Offering both a mailto and an https method simultaneously is not required.
Google’s own Postmaster Tools guidance recommends a spam complaint rate under 0.10%, with enforcement risk rising as it nears 0.30%. That is Gmail-specific guidance. Other providers set their own thresholds, so treat 0.10% as a Gmail benchmark, not an industry-wide rule.
What DMARCbis actually changed
The update deprecated three older tags (pct, the percentage rollout tag; rf, report format; ri, report interval) and added three new ones (np, a policy for non-existent subdomains; psd, a public suffix flag; t, a binary testing flag).
The t tag is often described as replacing pct, but the replacement is partial. The old pct tag allowed a percentage-based staged rollout toward enforcement. The new t tag is only on or off, with no percentage step between. Gmail’s own team raised this exact concern during the standard’s development, questioning whether losing staged rollout was worth the simplification. If your rollout plan depended on pct, that mechanism is gone and needs a manual, staged approach instead.
Existing v=DMARC1 records remain valid, and the version tag has not changed, so nothing stops working because of this update on its own. Support for the new tags and reliance on the deprecated ones will likely shift gradually as providers and tooling adopt the new specification.
A distinction worth getting right: alignment
DMARC does not have its own separate alignment step. It checks whether SPF or DKIM, when they pass, are also aligned with your visible From domain: SPF alignment means the return-path domain matches or is a subdomain of your From domain, and DKIM alignment means the signing domain in your DKIM signature does the same. DMARC passes if at least one of those checks both passes and aligns. Confirming SPF and DKIM exist is not the same as confirming they align with what subscribers see, and that gap is where most real problems sit.
What we see when reviewing accounts
One pattern that comes up when we review a start-up’s setup is SPF and DKIM present but not aligned with the visible From domain, often because a third-party sending platform’s default configuration routes the return path through its own domain. The record looks correct on inspection. The alignment underneath does not hold up without a specific check.
What actually helps, and what it does not guarantee
Correct authentication and alignment give mailbox providers a clear signal about who is sending your mail. That is a precondition for good delivery, not a guarantee of it. Gmail and Yahoo weigh authentication alongside engagement, complaint history, and list quality together, and no single fix moves inbox placement on its own.
Nozentra recommendations beyond the minimum
These are practices we suggest, not formal Gmail or Yahoo requirements.
Check SPF and DKIM alignment specifically against your visible From domain, especially if you send through a third-party platform with its own default configuration.
If you plan to move your DMARC policy from p=none toward quarantine or reject, treat it as a deliberate, staged process and monitor your aggregate reports at each step, since the automated percentage-based rollout tool is no longer part of the current specification.
Review engagement periodically and consider re-permissioning or removing subscribers who have gone quiet for an extended stretch. There is no provider-mandated cutoff for this. A window somewhere in the 90 to 180 day range is a reasonable starting point, adjusted to your own list.
Set a recurring reminder, quarterly is reasonable for most small teams, to revisit your authentication setup, since it is easy to configure once and forget.
Confirm with your specific email platform whether it has adopted the new DMARC tags, since adoption varies. Many platforms handle this automatically, but not all, particularly custom-built sending systems.
Nozentra can help
We offer a deliverability review that checks authentication and alignment against your actual sending configuration, and explains clearly which findings are formal provider requirements and which are our own recommendations.
FAQs
Do I need to update my DMARC record because of the May 2026 changes?
Not immediately. Your existing record stays valid. Adopting the new tags is optional and depends on whether you want the added control, such as a policy for non-existent subdomains.
Is p=none enough to comply with Gmail and Yahoo’s bulk sender rules?
Yes, for the specific requirement of having a DMARC record in place. Moving to a stricter policy is a security recommendation, not a compliance requirement under those rules.
Will fixing DMARC alignment guarantee inbox placement?
No. It removes one barrier to good deliverability. Inbox placement also depends on engagement, complaint rate, and list quality, which authentication alone does not control.
Conclusion
The DMARC specification changed in 2026. Gmail and Yahoo’s bulk sender rules did not. Confusing the two sends start-ups chasing a compliance deadline that does not exist, while the more common and more fixable problem sits underneath: authentication that is present but not properly aligned with the domain subscribers actually see.