Google Workspace DMARC: An Organization-Wide Rollout Plan

Publishing a DMARC record for a Google Workspace domain takes a few minutes. Getting an organisation to enforcement without breaking a business system takes several weeks, and the work is almost entirely inventory rather than DNS. The identities that break a rollout are the ones nobody listed: aliases routing through a legacy gateway, a delegated sender configured by a departed administrator, a subsidiary subdomain running its own mail. Plan against the whole estate or plan to roll back.

Sequence and prerequisites

Google's Workspace DMARC documentation states the dependency plainly: "You must turn on SPF and/or DKIM for your domain before you can use DMARC." It also asks administrators to "allow 48 hours after setting up SPF and/or DKIM before setting up DMARC".

The reason is not arbitrary. DMARC does not perform its own authentication check. It evaluates results produced by SPF and DKIM and tests whether those results align with the visible From domain. Turning it on before the underlying mechanisms are stable means you are enforcing against measurements that have not settled.

Google's guidance on the starting policy matches the specification's intent: "when you start using DMARC, we recommend setting the policy option (p) to none". For the enforcement phase, the documentation advises administrators to "start with a small percentage of your messages" and raise it as authentication improves.

Those three points set the sequence. What decides whether the sequence survives contact with your estate is the inventory you build between them.

Inventory the identities, not the domains

A domain list is the easy part. Most Workspace organisations can produce one in a minute. The rollout breaks on the identity layer underneath it.

The delegated sender row deserves particular attention because it is the least visible. An internal script or a vendor integration granted send-as rights years ago will keep sending, will not appear in any mailbox list, and will surface in your aggregate reports as unidentified volume from an address you recognise.

LeadHaste practice: we ask clients to produce the vendor list from accounts payable rather than from IT, because the systems that send mail on a company's behalf are more reliably tracked by who pays for them than by who provisioned them. That is an operating shortcut we use, not a Google recommendation.

Assign report ownership before anything else

The aggregate report address is the instrument the whole rollout depends on, and it is routinely set to a mailbox that nobody monitors.

Decide who reads the reports, how often, and what they do with unidentified volume. Aggregate reports arrive as compressed XML from many receivers. Somebody needs either a tool that parses them or the patience to do it manually, and that person needs enough organisational reach to ask the finance team about an unfamiliar sending source.

Set the report destination, then confirm a real report arrives before treating the monitoring phase as started. A rollout that has been at p=none for six months without a single report read has gathered no evidence at all, and the elapsed time creates false confidence.

Close the exceptions before raising the tag

Every unaligned legitimate sender found during monitoring resolves one of four ways, and each needs an owner and a date.

The sender can be brought into alignment, which usually means the vendor publishes a DKIM selector on your domain and signs with it. It can be moved to a subdomain with its own policy, which suits bulk senders you do not want sharing the corporate domain's reputation. It can be retired, which is the correct answer more often than people expect once someone checks whether the system is still in use. Or the decision can be deferred with a recorded reason and a revisit date.

What you cannot do is carry an unresolved exception into enforcement and hope. RFC 7489 is clear about the test being applied: a message passes when a mechanism "produces a pass result" and "produces that result based on an identifier that is in alignment". An unaligned sender at p=reject is mail that stops arriving.

Work the exception list until every row has an owner and a resolution. The length of the monitoring phase should be decided by that list rather than by a calendar.

Handle subdomains deliberately

RFC 7489 defines the subdomain policy tag as applying "only to subdomains of the domain queried and not to the domain itself", and specifies that "if absent, the policy specified by the p tag MUST be applied for subdomains". Google's documentation describes the same tag as one that "sets the policy for messages from subdomains".

Inheritance is the trap. A parent domain moved to p=reject with no sp tag takes every subdomain to reject along with it, including a sending subdomain that was mid-rollout and a subsidiary's domain that nobody in the Workspace team manages.

The specification adds a limitation worth knowing: sp "will be ignored for DMARC records published on subdomains of Organizational Domains". A policy you publish on a subdomain to protect that subdomain works; an sp tag on that same subdomain record does not do what it looks like it does.

Set the subdomain policy explicitly at every stage of the rollout. If a sending subdomain should stay at monitoring while the corporate domain moves to quarantine, that has to be written down in the record rather than assumed.

Staged enforcement with a real rollback

Move in steps that can each be reversed inside an hour.

Confirm alignment coverage at p=none with reports being read. Move to p=quarantine at a low percentage, watch for legitimate mail landing in quarantine, and raise the percentage in increments. Move to p=reject only after a full percentage at quarantine has produced no surprises across a period that includes your monthly billing and payroll cycles.

Before each change, lower the TTL on the record so a rollback takes effect quickly, record the previous record text verbatim, and tell the teams whose systems could be affected that the change is happening. Finance and recruiting should know the date, because they will notice a problem before the mail team does.

Keep an approval record for each step: what changed, who authorised it, what the reports showed beforehand, and what the rollback is. That record is what lets you move forward confidently rather than restarting the analysis at every stage.

Our DMARC policy audit guide covers the evidence gate in more detail, and Google Workspace email deliverability covers the broader sending configuration around it.

Ready to plan enforcement without breaking your business mail?

We can review your identity inventory, report ownership and staged rollout as part of an ICP and campaign-fit discovery call. Book your free discovery call →