2026 Update: Enforcement has tightened considerably since this post first went written. Starting in November 2025, Google began ramping up enforcement on non-compliant bulk mail, and failing messages can now see temporary or permanent SMTP rejections rather than just being routed to spam. Microsoft has also joined Google and Yahoo, enforcing its own SPF, DKIM, and DMARC requirements for Outlook.com, Hotmail.com, and Live.com senders since May 5, 2025. And the DMARC standard itself has changed: in May 2026, the IETF officially published DMARCbis, an update to the DMARC specification that adds a few new record tags and retires a few old ones. We've updated the guidance below to reflect all of this.
In the past, businesses have often used more relaxed standards for marketing via email. Google began enforcing stricter authentication requirements for mail sent to personal Gmail accounts back in February 2024, and Yahoo introduced closely aligned requirements around the same time. What started as a gradual rollout, with warnings and error codes meant to help senders self-correct, has since escalated into stricter enforcement, and Microsoft has since introduced its own version of these requirements for Outlook.com. As a result, industry leaders have shifted toward a more targeted, personalized, and properly authenticated approach to email communication with prospective customers.
So what does this mean for your business?
As a best practice, any domain used for business email communication should consider implementing DMARC to authenticate its outgoing mail. DMARC is a hard requirement only for bulk senders (those sending 5,000 or more messages a day to personal Gmail or Microsoft consumer accounts), but Google and other mailbox providers increasingly factor authentication into their spam filtering more broadly, so it's good practice for B2B senders too, not just the B2C bulk senders the rule was originally written for.
Where Things Stand in 2026
The core requirements haven't changed dramatically since 2024. What's changed is how strictly they're enforced, and who's enforcing them.
Google has escalated enforcement. Since November 2025, Google's Email sender guidelines FAQ has stated that Gmail is ramping up enforcement on non-compliant traffic, and that failing messages can experience disruptions including temporary and permanent rejections. That's a real shift from the earlier, softer period, when non-compliant bulk mail was mostly just filtered to spam. However, to be precise, this isn't a blanket switch where every failure now results in outright rejection. Depending on which specific requirement a message fails, Google may still route it to spam rather than reject it at the SMTP level. Either way, the practical takeaway hasn't changed: non-compliance now carries real deliverability risk, not just a warning.
Microsoft has joined in. Per Microsoft's own announcement, effective May 5, 2025, any domain sending 5,000 or more messages per day to Outlook.com, Hotmail.com, or Live.com addresses must have SPF and DKIM configured and passing, plus a DMARC record (at minimum p=none) aligned to SPF or DKIM. Non-compliant messages are rejected with a 550 5.7.515 error rather than simply filtered to junk, a decision Microsoft actually finalized just days before enforcement began; it had originally planned to route non-compliant mail to spam instead.
A reminder on scope: these requirements apply to mail sent to personal Gmail and Googlemail accounts and to Microsoft's consumer domains, not to paid Google Workspace or Microsoft 365 business mailboxes. That said, if you're sending B2C or mixed B2B and B2C email, you're almost certainly touching personal inboxes and need to comply.
Once a domain crosses the bulk sender threshold, that status is permanent. Google counts all messages sent from the same primary domain, including subdomains, toward the 5,000-per-day threshold, and once a domain has hit it, Google continues treating it as a bulk sender indefinitely, even if sending volume later drops. It’s a good idea to plan around that rather than treat bulk sender status as something you can undo later.
The bulk sender requirements themselves remain: any business sending 5,000 or more messages per day to Gmail addresses must, at minimum:
- Authenticate with both SPF and DKIM. For bulk senders, passing one or the other is no longer sufficient.
- Publish a DMARC record aligned with SPF or DKIM. A policy of p=none satisfies this minimum bar; stronger policies (quarantine or reject) aren't required, though they're recommended over time.
- Keep user-reported spam complaint rates below 0.10%, and never let them reach the hard ceiling of 0.30%.
- Support one-click unsubscribe (via the List-Unsubscribe and List-Unsubscribe-Post headers) on marketing and promotional email specifically; transactional messages like password resets and order confirmations are excluded from this requirement
- Format messages according to RFC 5322 and maintain valid forward and reverse DNS (PTR) records
Even businesses sending under 5,000 messages a day are expected to meet the baseline requirements (valid SPF or DKIM, TLS for transmission, and low spam rates). DMARC isn't technically mandated for senders below that threshold, but it's still a good idea, since weak or missing authentication generally makes a domain look less trustworthy to spam filters even outside the bulk sender rules.
DMARCbis: What's Changing in the DMARC Record Itself
Separately from the enforcement changes above, the DMARC specification itself was updated in 2026. In May 2026, the IETF published DMARCbis (formally RFC 9989, 9990, and 9991), which makes the original DMARC specification, RFC 7489, and its companion PSD DMARC spec, RFC 9091, obsolete. This is not a breaking change. Existing DMARC records still start with v=DMARC1 and remain valid; there is no "DMARC2." But a handful of tags have been added or retired, and it's worth knowing about them if you manage DMARC records for your domain.
New tags:
- np (non-existent subdomain policy): Sets a distinct policy for mail claiming to come from subdomains that don't actually exist, closing a spoofing gap the original spec left open. It works alongside the existing sp tag, which covers subdomains that do exist.
- t (testing flag): A simple yes or no flag (t=y or t=n) indicating whether a domain's policy should be treated as provisional. This is the replacement for the retired pct= tag: instead of the gradual percentage-based rollout described later in this post, testing is now all or nothing.
- psd (public suffix domain): Lets large organizations that operate a public suffix domain (think shared registries like .bank or .gov) explicitly declare that status. It works alongside a new DNS tree walk method that replaces reliance on the external Public Suffix List for determining organizational domain boundaries.
Retired tags:
- pct, the percentage tag used to gradually ramp up enforcement (described in the deployment steps below), has been removed. Receiver support for pct was always inconsistent in practice, which undercut its purpose.
- rf (forensic report format) and ri (report interval) have also been removed, since receivers rarely honored them in practice anyway.
None of this requires urgent action. Existing records that still use pct, rf, or ri won't break, since receivers simply ignore tags they don't recognize, which is largely how these particular tags were already treated in practice. Adoption of the new spec by receiving mail servers will be gradual, so there's no need to rewrite your records overnight, and pct-based records will likely keep working as expected for a good while yet. That said, the general industry guidance is to clean these tags out the next time you update your DMARC record, rather than leave them in place indefinitely. If you're currently using pct at less than 100, the rough equivalent under the new spec is t=y (testing, not yet fully enforced). If you're already at pct=100, you can simply drop the tag and move on.
DMARC Deployment Best Practices
We recommend following these best practices when deploying DMARC:
- Start with Monitoring: Before enforcing DMARC policies, begin by monitoring your email traffic and analyzing the incoming DMARC reports sent from external domains. These reports will give you insights into your current email practices and help you identify any issues or unauthorized sending mail servers.
- Implement SPF and DKIM: Ensure that your domain has SPF and DKIM records properly configured. SPF verifies that emails are sent from an authorized mail server or gateway, while DKIM signs your outgoing emails to help receiving domains verify their authenticity. For bulk senders, Gmail expects both to be configured and passing, not just one or the other.
- Set Up Your DMARC Policy: Use rua= and ruf= tags to indicate where aggregate and forensic DMARC reports should be sent.
DMARC records use a "p=" tag to indicate the DMARC policy. For example: p=none, p=quarantine, or p=reject. - Analyze and Adjust: Regularly review the DMARC reports to identify any anomalies or unauthorized senders. If you notice legitimate sending mail servers or gateways that are not reflected in your SPF record, then update your SPF record to include all sending servers and gateways. Use these reports to eliminate any issues with DKIM signing, for example, legitimate messages from your domain that are not yet properly signed by DKIM.
- Support One-Click Unsubscribe: If you send marketing or bulk mail, make sure your sending platform adds List-Unsubscribe and List-Unsubscribe-Post headers so recipients can opt out in one click, directly from Gmail or Outlook. This is a hard requirement for bulk senders under both Google's and Microsoft's guidelines, specifically for marketing and promotional messages.
- Collaborate with Partners: Work with your email service providers, partners, and vendors to ensure that they also implement DMARC and adhere to best practices. This helps create a secure email ecosystem and protects all parties involved.
Gradually enforce DMARC policies by starting with a monitoring-only policy (p=none). This allows you to gather data on email sources and potential issues without impacting email delivery.
Here is an example of a DMARC record showing its policy:
v=DMARC1; p=none; rua=mailto:dmarc@example.com
When first deploying DMARC, it's a good idea to start out with a policy of p=none. This means email messages claiming to come from your domain that don't properly align with DMARC will not be quarantined or rejected. You can use this period to analyze incoming DMARC reports to verify proper alignment with SPF and DKIM. For what it's worth, p=none also satisfies the minimum DMARC requirement under Google and Microsoft's bulk sender rules, so there's no requirement to rush past this stage. That said, sitting at p=none indefinitely once you've resolved your authentication issues doesn't buy you much protection against spoofing, so most organizations should still plan to progress toward quarantine and eventually reject.
Once you've verified proper SPF and DKIM implementation, you can set your DMARC policy to p=quarantine while you continue to monitor incoming reports for any remaining issues with DKIM and SPF. A good starting strategy would be to use the pct= tag in your DMARC record. The pct= tag allows you to specify a given percentage of emails that should be handled based on your DMARC policy. (As covered earlier, pct= has been retired in the newest DMARC specification in favor of the t= testing flag, but it remains widely supported today. See the note at the end of this step.)
For example, if you have a policy of p=quarantine, you can start out with a pct= tag of pct=20. This indicates that 20% of all messages that do not properly align with SPF and DKIM should be quarantined, while the remaining 80% should be delivered.
Take some time to continue monitoring incoming reports, and then gradually increase the pct= tag (example: pct=50, pct=80).
After you've had some time to monitor your DMARC reports with a policy of p=quarantine, and after any remaining SPF and DKIM issues have been sorted out, you can then change your DMARC policy to p=reject.
Again, after changing your DMARC policy to p=reject, consider using the pct= tag, ramping up from a low number gradually until you've had more time to monitor incoming DMARC reports. Once you're comfortable that SPF and DKIM are properly implemented for all legitimate sending servers sending on behalf of your domain, you can remove the pct= tag from your DMARC record.
A quick note on the pct= tag described above: as covered in the DMARCbis section earlier in this post, the newest version of the DMARC specification has retired pct= and replaced it with the t= testing flag. Instead of applying your policy to a percentage of messages, t= is all or nothing: t=y tells receiving servers to treat your policy as still in testing, and t=n (the default when the tag is absent) means the policy should be fully enforced. The t= tag is not strictly enforced yet. The new specification was only published in May 2026, so support for t= among receiving mail servers is still rolling out, and servers simply ignore tags they do not recognize. That works in your favor during the transition: servers that have not yet adopted the new specification will keep honoring pct= as described above, and existing pct= records will not break on servers that have. If you are setting up a new record today, the staged percentage approach still works in practice, but be aware that it is being phased out at the specification level, with t=y serving as the rough equivalent of a partial pct= rollout.
Monitoring and Analyzing DMARC Reports
Monitoring and analyzing DMARC reports is an essential part of maintaining email security. DMARC reports provide valuable insights into your email traffic, including information about authorized and unauthorized senders, email authentication failures, and potential phishing attempts.
Here is an example of a DMARC report.
To effectively monitor and analyze DMARC reports, consider the following:
1. Regularly Review Reports: Set up a process to regularly review your DMARC reports to identify any anomalies or suspicious activities. Take note of any email sources that fail SPF or DKIM checks and investigate them further.
2. Use Available Reporting Tools: There are various DMARC reporting tools available that can help you analyze the reports and visualize the data. These tools can provide valuable insights and make it easier to identify patterns and potential threats.
3. Take Action on Suspicious Emails: If you identify any suspicious emails or unauthorized senders in the DMARC reports, take appropriate action. This can include quarantining or rejecting the emails and investigating the source of the emails.
4. Update DMARC Policy: Based on the insights gained from the DMARC reports, adjust your DMARC policy accordingly. Strengthen your policies to reject or quarantine suspicious emails and update your SPF and DKIM records if necessary.
What do Google and Microsoft's email policies mean for your business in 2026?
Businesses that send bulk email as part of their marketing efforts are now held to strict, actively enforced authentication standards, not just by Google, but by Microsoft as well, with Yahoo applying closely aligned rules of its own. Non-compliant bulk mail carries real risk of outright rejection now, not just spam-folder placement. While this may mean fewer prospects receive your marketing emails if you're not yet compliant, properly authenticated senders will generally see better deliverability and a better chance of converting recipients into viable sales leads. If you haven't checked your SPF, DKIM, and DMARC configuration recently, now is a good time. The grace period most mailbox providers offered when these rules first rolled out is over, and the DMARC record format itself is now beginning to shift too.
