Google and Microsoft Bulk Sender Policy Changes for B2B Outbound

Google and Microsoft have stopped treating sender requirements as guidance and started treating them as a gate. Non-compliant mail is refused outright rather than filtered into a spam folder, and that change in enforcement model, not the text of the rules, is what B2B outbound teams need to understand first. Google and Yahoo announced their requirements in October 2023, Microsoft followed in April 2025 with enforcement beginning May 5, 2025, and by 2026 all three providers are actively enforcing. The error codes mark the practical consequence: before November 2025, Gmail returned temporary 421 errors on non-compliant mail, giving senders a chance to retry; after November 2025, it returns permanent 550 rejection codes, and the message simply does not arrive. A spam-foldered email still reaches a mailbox, however unlikely a human is to find it. A rejected email is gone, and a pattern of rejections erodes the sending reputation attached to a domain or IP, making every subsequent send harder. That shift in consequence is why the rest of this piece treats compliance as a pass/fail operational requirement, not a best practice to get to eventually.

The enforcement timeline both providers followed

Google gave the market roughly two years to adjust, and it moved through distinct phases that senders could track and plan around. Microsoft compressed a comparable set of demands into weeks, and many teams that had calibrated their compliance timelines to Google's pace were caught flat-footed when Outlook moved far faster.

Google's rollout proceeded in stages. Gradual rejection of non-compliant emails began in April 2024. By June 2024, one-click unsubscribe became mandatory for all commercial and promotional messages, not an optional courtesy. On September 30, 2025, Google retired the legacy Postmaster Tools v1 and moved all users to Postmaster Tools v2, a dashboard that had actually launched back in 2024 and that replaced the old Good/High/Medium/Low reputation gradient with a binary Pass/Fail compliance status. Then, starting in November 2025, Gmail ramped up enforcement further, and messages failing the requirements began facing real disruptions, including both temporary and permanent rejections.

Microsoft's sequence ran on a far faster clock. Microsoft announced its requirements in April 2025 and set an enforcement date of May 5, 2025, giving senders just 33 days to come into compliance. Outlook.com enforcement began that May, and high-volume senders saw non-compliant messages get rejected for hotmail.com, live.com, and outlook.com addresses. Teams that had budgeted months for authentication work, based on how Google had handled its own rollout, found Microsoft's window had already closed by the time they started.

The three requirements both providers share and the floor every B2B sender must meet regardless of volume

Both providers converge on the same baseline for bulk senders, defined as anyone sending 5,000 or more emails a day: SPF, DKIM, and DMARC are mandatory, and what the current enforcement model actually tests is alignment across all three records with the From domain, not merely whether each one passes in isolation. Two passing records out of three, or three records that pass individually but fail to align, no longer clears enforcement at either provider. SPF is a DNS TXT record that authorizes which IPs can send mail on a domain's behalf, and the most common failures are exceeding the DNS lookup limit or leaving the actual sending platform out of the record. DKIM attaches a cryptographic signature to outgoing mail, and a 2048-bit key is now the floor; anything weaker is treated as insufficient. DMARC ties SPF and DKIM together and instructs receiving servers on what to do when a message fails either check. A policy of p=none is technically acceptable and still widely published, but Google's filtering increasingly reads a sender stuck at p=none as a negative signal rather than a neutral one, and p=quarantine is the recommended minimum heading into 2026. Publishing DMARC at p=none is a reasonable starting point for a domain still building its authentication practice, but providers expect movement toward quarantine or reject over time, and a domain that sits at p=none indefinitely is read as a sender that has stopped paying attention to its own setup. Google adds one more floor requirement specific to its ecosystem: TLS encryption is required for all transmission to personal Gmail accounts, and senders using custom SMTP configurations rather than a managed sending provider need to confirm that encryption is in place.

Where Google and Microsoft diverge

Google and Microsoft build their enforcement on the same authentication floor but weigh different signals on top of it, and that difference is why identical sending programs can pass one provider's checks and fail the other's. Google weights domain reputation as its primary filter. Microsoft weights IP reputation heavily and layers machine-learning-based engagement signals on top, so a sender can hold a clean domain reputation and still run into trouble at Outlook if the IP it sends from carries a poor history.

Google's specific layer rests on Postmaster Tools v2, which launched in 2024 and became the only option once v1 was deprecated on September 30, 2025. Google also enforces a spam complaint threshold: campaigns that exceed it and fail to adjust quickly show measurable reputation degradation within days. Forwarding services, including mailing lists and inbound gateways, are required to attach ARC headers once they exceed Google's bulk-sender threshold and send to Google inboxes, and ARC is recommended practice for every forwarder regardless of volume.

Microsoft's additions run through a different set of mechanisms. An update rolled out in April 2026 introduced machine-learning-based pattern detection that flags accounts based on recipient engagement, including open rate, reply rate, and whether recipients move a sender's mail out of the junk folder, extending enforcement well past raw spam complaint volume. Microsoft's 2026 update also doubled the minimum domain age a sender needs before a first cold send, moving it to 14 days. Shared IP addresses introduce a further risk specific to Microsoft's model: when one sender on a shared pool gets flagged, every other account on that same pool absorbs reputation damage alongside it. Dedicated IPs are the recommended path for any team running serious outreach volume. Microsoft also recommends including a plain-text alternative alongside every HTML email, but it does not formally penalize HTML-only mail as part of its enforced requirements, so the recommendation and the enforced rule are not the same thing.

The Google Workspace exemption and what it means for B2B cold outreach

Google's bulk sender requirements exclude mail sent to Google Workspace accounts, and that carve-out reshapes the compliance math for B2B cold email, but it covers less ground than most senders assume. The rules apply only to messages sent to personal Gmail accounts, meaning addresses ending in @gmail.com and @googlemail.com; paid Google Workspace accounts sit outside the bulk sender threshold. Most B2B cold email targets contacts on corporate domains running Workspace, so the 5,000-per-day threshold, measured only against @gmail.com addresses, is far harder to hit than a team's total outbound volume might suggest, and a typical B2B program rarely triggers the formal bulk-sender classification.

None of that touches authentication. SPF, DKIM, and DMARC remain required for every sender regardless of recipient type or volume, and the Workspace exemption only removes the stricter bulk-classification triggers and the formal message-count threshold, not the underlying setup work. Google's filtering has also grown sophisticated enough to watch smaller senders for outbound prospecting patterns, so even a modest volume of cold email from a poorly authenticated domain can trip the same filters a high-volume newsletter would, whether or not you ever cross 5,000 messages a day.

Microsoft offers no equivalent exemption. Its rules apply to consumer domains, specifically Outlook.com, Hotmail.com, and Live.com, and because a large share of B2B buyers operate inside Microsoft's ecosystem at work, the Microsoft compliance path carries the higher operational priority for most B2B outbound teams, even though Google's requirements tend to dominate the conversation.

The provider-specific monitoring tools senders must register for

Most deliverability failures become visible only after reputation damage has already set in, because teams rely on lagging indicators instead of the tools each provider gives them for near-real-time feedback. Registering for those tools, and reading them correctly, is what turns a one-time authentication fix into a durable compliance posture.

Google Postmaster Tools v2 launched in October 2025, and it replaced the earlier Good/High/Medium/Low reputation gradient with the binary Pass/Fail compliance dashboard described earlier. It surfaces spam complaint rates as measured directly by Google, the same input that feeds the complaint thresholds responsible for reputation degradation and eventual rejection, making it the authoritative source for that signal. A domain left unregistered has no visibility into its own complaint data, and problems accumulate invisibly in that blind spot until they appear as rejections.

Microsoft splits the equivalent function across two separate registrations. SNDS, Smart Network Data Services, functions as Outlook's counterpart to Postmaster Tools. JMRP is a distinct registration, and it delivers direct copies of complaint reports filed against a sender's mail. Most senders register for SNDS and stop there, missing JMRP entirely, and without it, complaint spikes only become visible weeks after they occur, by which point reputation has already taken the hit. Microsoft's April 2026 engagement monitoring raises the stakes here, because low open and reply rates now trigger automated review and potential restriction on their own, independent of spam complaint volume.

The operational rule that follows from both systems is straightforward: register Postmaster Tools for every domain sending through Google and SNDS for every domain sending through Microsoft, across the full set of domains actively used in outbound campaigns. If a program monitors some of its sending domains while others send unmonitored, that gap is one enforcement will find before the sending team does.

The compliance checklist for each provider, structured as pass/fail decisions rather than aspirational guidance

Google's checklist starts with the authentication stack: SPF, DKIM, and DMARC must all pass and align with the From domain, since two of three passing, or three that pass without aligning, fails enforcement. DKIM needs a 2048-bit key at minimum, and if you're running anything weaker, treat it as a failing configuration, not a legacy setting to revisit later. DMARC should be moving toward p=quarantine rather than sitting at p=none, because Google's filtering treats a static p=none policy as a sign of neglect, not a neutral starting position. TLS encryption must cover every transmission to personal Gmail accounts, and any team running custom SMTP rather than a managed sending platform needs to confirm this directly. One-click unsubscribe is mandatory on every commercial and promotional message, a requirement that became binding in June 2024 and has not loosened since. Spam complaint rates need to stay under Google's threshold, because if campaigns exceed it and don't adjust quickly, they show measurable reputation decline within days. Forwarding services sending to Google inboxes above the bulk-sender threshold need ARC headers in place, and every other forwarder should treat ARC as standard practice regardless of volume. Finally, every sending domain needs an active Postmaster Tools v2 registration, because the dashboard's binary Pass/Fail status is the only reliable early warning a sender has before a compliance gap turns into a rejection.

Microsoft's checklist shares the same authentication floor: SPF, DKIM, and DMARC all need to pass and align with the From domain, with no exceptions for volume or sender history. Domain age needs to clear 14 days before any first cold send, following the doubling of that requirement in Microsoft's 2026 update. IP reputation deserves direct attention given how heavily Microsoft weights it, and dedicated IPs are the safer choice for serious outreach volume, because shared pools expose a sender to reputation damage caused by other senders on the same pool. Engagement signals, specifically open rate, reply rate, and whether recipients move mail out of junk, now feed Microsoft's ML-based pattern detection introduced in April 2026, so campaigns with weak engagement face automated review even when spam complaints stay low. SNDS registration should be treated as a baseline, not a complete solution, since it leaves complaint visibility incomplete on its own. JMRP registration closes that gap by delivering direct copies of complaint reports, and if a sender skips it, complaint spikes surface only after weeks of accumulated reputation damage. A plain-text alternative alongside HTML email is good practice, worth building into standard templates, though it carries no formal enforcement penalty when left out, a distinction that matters for teams prioritizing engineering time against Microsoft's actual enforced requirements.