Introduction
Plenty of managed-services practices are built almost entirely on Google Workspace tenants, and the arrival of DMARCbis in May 2026 raises a fair question: does the new standard change how you run DMARC for those clients? The short answer is that it changes the records you publish and the way you stage enforcement, but not the underlying mechanics of how Workspace authenticates mail. DMARC still passes when either aligned SPF or aligned DKIM passes, and Workspace still handles SPF and DKIM signing from the admin console rather than from mail-server configuration.
What did change lives in the tags and the rollout discipline. The percentage-based pct tag is gone, enforcement is now all-or-nothing, a new t tag signals a transitional state, and the np tag lets you set policy for non-existent subdomains. This guide walks a Workspace-heavy MSP through a DMARCbis-aware rollout, and it is the Google counterpart to the DMARCbis for Microsoft 365 clients guide for anyone running both platforms. For the wider context, the three RFCs are RFC 9989, RFC 9990 and RFC 9991, which together obsolete the 2015 RFC 7489.
What DMARCbis changes for a Workspace tenant
It helps to separate the parts that moved from the parts that did not. The core evaluation is untouched: a message from a Workspace tenant still authenticates when its aligned SPF result or its aligned DKIM signature passes, and the visible From domain still has to line up with the authenticated identity. Workspace's role in that process — publishing _spf.google.com in SPF and signing with the google DKIM selector — is exactly as it was before.
The changes that matter to your records are threefold. The pct tag has been removed, so you can no longer ask receivers to enforce against a percentage of failing mail; a policy now applies at full strength or not at all. In its place, the t tag lets you publish an enforcing policy while signalling that you are still in a transitional, testing period, which is the honest successor to what pct was often used for. And the np tag gives you a dedicated policy for subdomains that do not exist in DNS, separate from the sp tag that governs subdomains that do. The new DMARC tags explained article covers all three in detail. On the reporting side, RFC 9990 now requires the DKIM detail inside aggregate reports, which makes diagnosing a Workspace selector or a third-party sender easier than it used to be.
Start with a sender inventory, not a record
The single most important step for a Workspace client is also the least glamorous: build a complete inventory of everything that sends mail as the domain before you publish anything at enforcement. Workspace tenants tend to accumulate third-party SaaS senders faster than most, because the platform integrates cleanly with a long tail of cloud services. A typical client is sending from Workspace itself plus a CRM, a marketing platform, a helpdesk or ticketing tool, an e-signature service, an invoicing or billing system, and often a scheduling or survey tool that nobody remembers approving.
Each of those senders either needs to authenticate in a way that aligns with the client's domain, or it needs to be documented as a known exception. Publishing an enforcing policy before you have that list is how legitimate mail gets quarantined and how an MSP ends up firefighting instead of delivering a clean rollout. The reliable way to build the inventory is to publish DMARC at p=none first and let the aggregate reports show you who is actually sending, then reconcile that against what the client believes they use. The gap between those two lists is usually where the interesting findings are.
SPF and DKIM alignment still carry the rollout
Because DMARC depends on alignment, the SPF and DKIM groundwork is where most of the real work sits. Workspace's baseline SPF is v=spf1 include:_spf.google.com ~all, and every additional sender adds an include: that consumes part of the ten-lookup budget defined for SPF. Workspace's own include expands through a couple of nested lookups, so on a busy tenant with several SaaS senders it is easy to approach the limit; an SPF analyzer will show you the expanded lookup count and flag when flattening or consolidation is needed.
DKIM signing is off by default on a fresh Workspace tenant, and a surprising number of long-lived tenants are still running a legacy 1024-bit key that should be rotated to 2048-bit during any DMARC project. Beyond Workspace's own signing, each third-party sender has to be configured so that its SPF authorization or its DKIM signature aligns with the client's organizational domain rather than the vendor's. When alignment behaves unexpectedly, a DNS lookup on the relevant selector and SPF records usually reveals the cause quickly — a missing include, a key published at the wrong selector, or a record that never propagated.
Rolling the policy out under DMARCbis
Once the inventory is reconciled and the legitimate senders align, you move the policy through its phases. The sequence is familiar — start at p=none, advance to p=quarantine, then reach p=reject — but DMARCbis changes how you stage the cautious middle. Where you might once have leaned on pct to enforce against a slice of traffic, you now publish the full policy and use t=y to mark that you are still in a transitional period while you finish confirming senders. A record part-way through a careful Workspace rollout might read:
“ v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected] “
The t=y signal should come off once you are confident, rather than lingering indefinitely, because leaving it in place tells the world you are perpetually just testing. The mechanics of doing this safely — what to watch in the reports before each step, and how to hold a rollback window — are covered in DMARC enforcement after RFC 9989. The point worth internalising is that p=reject still requires the same care it always did; the standard got clearer, but a premature jump to enforcement breaks mail just as effectively as it ever did.
Subdomain and non-existent subdomain policy
Workspace's multi-domain capability makes subdomain handling worth a deliberate review rather than an afterthought. A single tenant can host several primary domains, and each one needs DKIM enabled separately, which is an easy thing to miss on aliases. Beyond the domains that send, you should decide policy for the subdomains that do not.
The sp tag sets policy for subdomains that exist in DNS, while the new np tag sets policy for subdomains that do not exist at all. Non-existent subdomains are a favourite of spoofers precisely because no legitimate mail uses them, so np=reject is a low-risk hardening step for almost any Workspace client. A hardened organizational record might set the domain to reject, keep real subdomains at quarantine while you finish validating them, and reject anything from a made-up subdomain outright. The one place to slow down is a tenant using wildcard DNS, where a broad record can change which names count as existing; the non-existent subdomains and the np tag article covers those cases.
Keep monitoring after enforcement
Reaching p=reject is a milestone, not an endpoint. Workspace clients keep adding SaaS tools, marketing teams keep spinning up new sending platforms, and a sender that authenticated cleanly last quarter can start failing after a vendor changes its infrastructure. Aggregate reporting should be monitored on an ongoing basis after enforcement, not just during the rollout, so that a new or broken sender surfaces as a report finding rather than as a client complaint about undelivered mail.
This is where the now-required DKIM detail in RFC 9990 reports pays off, because it lets you see exactly which selector a Workspace or third-party sender used without guessing. For a portfolio of Workspace tenants, the value of a managed DMARC service is precisely this steady interpretation of reports over time, translated into a clear per-sender picture the client can act on.
What MSPs should do now
For Google Workspace clients, treat DMARCbis as a reason to standardise your rollout rather than as an emergency. Confirm your tooling ingests the RFC 9990 format, retire any pct staging from your record templates in favour of t=y, and add an np review to every client's subdomain posture. Then run the same disciplined sequence you always have — inventory first, alignment second, phased enforcement third, ongoing monitoring throughout — with records that reflect the standard now in force. The DMARC for MSPs pillar ties the commercial and technical threads together for a Workspace-heavy practice.
Related articles
- DMARCbis for Microsoft 365 clients
- New DMARC tags explained: np, psd and t
- Non-existent subdomains and the DMARC np tag
- DMARC enforcement after RFC 9989: p=reject still requires care
- DMARC for MSPs — complete guide
Tools mentioned
- SPF analyzer — check the expanded lookup count behind a Workspace tenant's SPF record.
- DNS lookup — confirm SPF, DKIM selector and DMARC records resolve as expected.
Authoritative references
- RFC 9989 — core DMARC protocol
- RFC 9990 — DMARC aggregate reporting
- RFC 9991 — DMARC failure reporting
- RFC 7489 — the obsoleted 2015 specification
Author: DMARC AI editorial team Last updated: August 2026