DMARC on Google Workspace: Read the Example Record as a Destination

You open the Google Admin console to switch DMARC on for your domain and there is no setting for it. Google says so directly on its own setup page: "You don't need to do anything in your Google Admin console to set up DMARC. Instead, determine your DMARC record by following the instructions on this page. Then, log into your domain host and add the DMARC record."

That is the right place to start, because it tells you who owns the change. Google signs and sends your mail. The policy record lives at whoever answers DNS for your domain, and Google's documentation is a set of recommendations rather than a control panel. Two of those recommendations are worth arguing with before you publish them.

The prerequisites Google states, in order

Google's page carries two conditions before the record goes anywhere.

The first is that authentication has to exist already: "You must turn on SPF and/or DKIM for your domain before you can use DMARC," with the warning that skipping it means "messages sent from your domain will probably have delivery issues." A DMARC policy on a domain with nothing to align against is a policy that fails everything you send.

The second is patience: "Allow 48 hours after setting up SPF and/or DKIM before setting up DMARC." That interval is about propagation and Google's own verification, not about caution for its own sake, and publishing inside it produces a stretch of failures that look like a configuration error and are not.

The SPF half of that prerequisite has its own trap on this platform, since a Workspace domain that has collected a few vendors runs into the ten-lookup ceiling that the Google Workspace SPF record covers.

The record Google publishes as its example, and the two things in it

Google's setup page gives a worked example, meant to be adapted:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Two elements of that string deserve a second look before it goes into a zone.

pct=100 refers to a tag the current standard removed. RFC 9989, published on 20 May 2026, obsoletes RFC 7489, and its Appendix A.6 is titled "Removal of the pct Tag". The DMARC tag registry now carries pct, rf and ri with a status of historic. Nothing breaks: receivers ignore tags they do not recognise, and 100 was the default anyway, so the tag is inert rather than harmful. It is simply not a thing to copy forward into new records, and the DMARC record tag by tag covers what replaced the part of it that was worth keeping.

adkim=s; aspf=s sets strict alignment on both halves, and that is a real decision presented as a default. Under RFC 9989 both tags default to r for relaxed, which accepts a match at the organizational domain. Strict demands the fully qualified names match exactly. The practical difference shows up immediately with third-party senders, because a platform sending as you with a bounce subdomain for the return path aligns under relaxed and fails under strict. So does an internal system sending from a subdomain.

Strict alignment is a hardening step for a domain where you already know every sender and want to close the subdomain path deliberately. Publishing it on day one, from a copied example, on a domain that has a CRM and an invoicing tool and a helpdesk on it, manufactures failures on mail that was fine yesterday.

Google's examplev=DMARC1; p=reject; rua=...; pct=100; adkim=s; aspf=s

• Enforces at reject immediately
• Strict alignment on both SPF and DKIM
• Carries pct=100, a tag RFC 9989 removed
• Assumes every sender is already known and aligned

A first recordv=DMARC1; p=none; rua=mailto:dmarc@acme.com

• Reports without acting on anything
• Relaxed alignment by specification default
• No historic tags carried forward
• Produces the source list the enforcement decision needs

Neither is wrong. Google's example is what a finished rollout looks like, and reading it as a starting point is the ordinary mistake.

Where the reports go, and the record that stops them arriving

Google's guidance on the reporting address is operational and worth following. It recommends creating "a group or a dedicated mailbox to receive and manage DMARC reports", and it sets an expectation about volume that explains why: "The number of DMARC reports you receive by email can vary, and depends on how much email your domain sends and how many domains you send to. You can receive many reports every day. Large organizations might get up to hundreds or even thousands of reports daily."

A shared mailbox or group survives the person who set it up leaving, has no personal filing rules quietly foldering gzipped attachments from unknown senders, and can be granted to more than one person so that reading reports is a role rather than a habit.

The failure that produces an empty mailbox with no error anywhere is the cross-domain one, and Google names it: "Typically, the email address for reports is in the same domain as the domain that hosts your DMARC record. If the email address has a different domain, you must add a DNS record at the other domain." Point twenty sending domains at one central reporting mailbox and every one of those domains needs that authorisation published on the mailbox domain, not just the first one you set up. The exact record and where it goes are in DMARC aggregate reports.

Third-party senders, which is where the failures are

Google's step two is about everything that sends as you and is not Google. Its instruction is to contact the provider and confirm SPF and DKIM are configured, to "make sure the provider's envelope sender domain matches your domain", and it offers a third route specific to this platform: "Route outgoing mail from the provider through Google using the SMTP relay service setting."

That third option is the one people miss, and it is genuinely useful when a vendor offers no way to sign with your domain. Relaying through Google puts the message on infrastructure your SPF record already authorises and lets Google's DKIM signing apply.

The general shape of this problem does not change by platform: a third party sending with your address and its own return path passes SPF for its domain and aligns with nothing you own. That is the first entry in the six causes of DMARC failure, and it is where most of the failing volume in a first month of reports comes from.

Before the record goes in the zone

• ✓Yes: SPF and DKIM are live on the domain and have had 48 hours
• ✓Yes: rua points at a group or shared mailbox rather than a person
• ✓Yes: If the reporting address is on another domain, that domain publishes the authorisation record
• ✓Yes: Every third-party sender has been asked to sign with your domain
• ✕No: adkim and aspf are being set to s because the example record had them
• ✕No: pct= is being carried into a new record as part of a rollout plan
• ~Depends: A subdomain sends real mail and may need its own policy via sp=

The Gmail requirement this question usually sits behind

A lot of Workspace DMARC work starts with a compliance deadline rather than a security project, so it is worth stating the bar precisely, in Google's own words. Its sender guidelines require SPF or DKIM from every sender to Gmail accounts. The section headed "Requirements for sending 5,000 or more messages per day" then asks those senders to "Set up SPF and DKIM email authentication for your domain" and to "Set up DMARC email authentication for your sending domain", and adds the sentence that surprises people: "Your DMARC enforcement policy can be set to none."

One wording note, because the difference matters if you are near the line. The section heading reads "5,000 or more messages per day" while the paragraph under it reads "more than 5,000 messages per day". Google's page carries both phrasings, so a domain sending exactly 5,000 sits in the gap between them, and the safe reading is to treat the stricter one as the threshold.

So compliance and enforcement are separate projects. Publishing the record clears the bar. Moving off none is a security decision layered on top, and what that decision costs and buys is in DMARC policy not enabled.

One distinction is worth keeping straight while reading about this, because two different domains get called Gmail. The requirement above concerns mail you send to gmail.com recipients. The DMARC policy published on gmail.com itself is Google's own policy on its own consumer domain, and it governs people sending as a gmail.com address rather than anything about your domain. If your outbound is sent from a Workspace domain you own, that policy is not yours to configure and not yours to satisfy.

What this looks like across a fleet of sending domains

Teams running B2B outbound generally send from domains separate from the primary company domain, and each of those is a Workspace-connected domain in its own right or a domain attached as a secondary. Either way, DMARC does not inherit between domains.

The arithmetic is unglamorous. Thirty sending domains is thirty DMARC records, thirty reporting destinations, and thirty cross-domain authorisation records if the reports go anywhere central. None of it comes from the Admin console, so none of it appears in a Workspace audit, and the whole set lives in registrar zones nobody opens after launch.

The compensating advantage is that a purpose-built sending domain is the easiest domain on earth to enforce on. It has one sending platform behind it, one SPF include and one DKIM key, so the population of legitimate senders you might have missed is close to empty. The month of monitoring that a primary company domain genuinely needs is mostly a formality on a domain that has only ever done one thing.

We authenticate every sending domain before it carries a message and run one message per campaign, so a domain that fails authentication does not get a second attempt at the same person later. That is why the record is launch work rather than debugging work, and why a domain with a problem is replaced rather than repaired in flight. The Microsoft equivalent of this procedure, including the subdomain inheritance rule that catches tenants, is in setting up DMARC on Microsoft 365.

If you would rather not run DNS and reporting across a portfolio, we operate the sending infrastructure as part of the engagement.

The short version

Google's Admin console has no DMARC setting, so the TXT record goes at your DNS host on the _dmarc hostname. Turn on SPF and DKIM first and wait 48 hours, because Google says both and both matter. Send reports to a group or shared mailbox rather than a person, and publish the cross-domain authorisation record if that mailbox sits on a different domain from the one being monitored.

Read Google's example record as a destination rather than a starting point. It publishes p=reject with strict alignment on both halves and carries pct=100, a tag RFC 9989 removed in May 2026. A first record on a domain whose senders you have not yet enumerated is p=none with a working reporting address and the specification's own relaxed alignment defaults. Google accepts p=none as satisfying its bulk sender requirement, so compliance does not require enforcement.

Google Workspace procedures and recommendations are per Google's published Set up DMARC documentation and its email sender guidelines, both verified as of August 2026. Specification behaviour is per RFC 9989, published 20 May 2026. Verify current guidance with the source before making DNS changes.

Sources: Set up DMARC, Google Workspace Admin Help, Email sender guidelines, Gmail Help, RFC 9989