Defaults.Exposed › Setup walkthroughs › DMARC › Google Workspace

How to set up DMARC on Google Workspace

There is no DMARC (Domain-based Message Authentication, Reporting and Conformance) control anywhere in the Google Admin console, including under Gmail and Authenticate email. The record is published at whoever runs your domain’s DNS (Domain Name System), and Google’s only part in this is receiving mail and sending you reports about it.

The record to publish

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The version tag v=DMARC1 has to lead the record. p=none sets the policy, and none asks receivers to carry on exactly as they would have. rua=mailto: is the mailbox that receives aggregate reports, and it has to be an address you can actually receive at and do read.

Starting at p=none is a safety measure. Publishing an enforcing policy before SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) are working can get the domain’s own legitimate mail blocked, which is why the policy starts here and moves up only once the reports show it is safe.

Find out who runs the domain’s DNS

Google Workspace is the mailbox provider here. The DNS host is whoever runs the domain’s nameservers, so there is no Google console screen to check for this record. Confirm which company runs the domain’s DNS by checking the Nameservers section in the registrar account, or by asking whoever set up the website, and publish the record in that company’s DNS settings.

Google Workspace runs the domain’s mail, sending and receiving through Gmail. It publishes nothing for this record and generates none of its values: the whole record, its host name and its reporting address, is typed by you at your DNS host.

Add the record at your DNS host

1. Sign in to the DNS host for the domain, which is the registrar, web host or DNS provider. The Google Admin console has no place for it.
2. Open the DNS settings for the domain, looking for a menu labelled DNS, Records or Advanced DNS.
3. Add a new record and choose the type TXT from the record type list.
4. In the Name or Host field, enter exactly _dmarc, including the leading _ character.
5. Do not type _dmarc.yourdomain.com in that field, because the DNS host appends the domain automatically.
6. In the Value or Content field, paste v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com, replacing the email with a real address that is monitored.
7. Leave the TTL field at the DNS host’s default setting.
8. Save the record.

In the Name or Host field type _dmarc on its own, with the leading _ character, since the DNS host appends the domain automatically rather than needing _dmarc.yourdomain.com written out. In the Value or Content field paste the DMARC string plain, with the rua address changed to a mailbox that is read.

Traps specific to this setup

• The record is not found by hunting through Google’s Admin console, because Google Workspace has no DMARC control; the record belongs in the DNS zone the domain’s nameservers point at.
• Leaving off the _ character on _dmarc, or typing the full domain after it, puts the record at the wrong host name and DMARC will not be found there.
• Most DNS hosts add the surrounding quoting to a TXT (Text) value automatically, so the string should be pasted plain rather than wrapped in quotation marks by hand.
• There should be exactly one TXT record at _dmarc; if one already exists, edit it rather than adding a second.
• The rua address has to be a mailbox you can receive at and do read, since it is where the aggregate reports arrive.
• Publishing this record before SPF and DKIM are working can get the domain’s own legitimate mail blocked, which is why the policy starts at p=none.

What a Workspace domain usually finds in its reports

The reports arrive from receiving providers rather than from Google’s sending side, so they cover everything using your domain, Gmail included. Three patterns turn up on nearly every Workspace domain.

The first is Google itself, passing cleanly, provided your SPF record carries include:_spf.google.com and your DKIM key is published and signing has been switched on at Authenticate email. If Google’s own traffic is failing, one of those two is missing and it is the first thing to fix.

The second is a Google Group that relays to outside members. Relayed mail fails SPF at the receiving end, because the connecting server is Google rather than the original sender’s, and it passes on DKIM if the original signature survived. That is normal and needs no change to your record.

The third is the long tail: a CRM, an invoicing tool, a helpdesk, an events platform. Each needs either an SPF include or, better, its own DKIM signature on your domain so it aligns. Work down the list by volume rather than trying to clear it all at once.

Moving the policy up without breaking anything

Three values exist for p=. none changes nothing and reports. quarantine asks receivers to treat failing mail as suspicious. reject asks them to refuse it outright.

The jump from none to reject in one move is where domains hurt themselves. The safer path uses pct=, which applies the policy to a proportion of failing mail: v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc@yourdomain.com quarantines a fifth of failures and leaves the rest as they were. Anything you overlooked surfaces in the reports at a fifth of the scale, and you raise the number as the picture stays clean.

Two further tags become relevant later. sp= sets a different policy for subdomains, which matters if a campaign platform sends from one. adkim= and aspf= control how strictly the authenticating domain has to match your From domain, defaulting to relaxed, which is what you want while a subdomain is doing legitimate work on your behalf.

A Workspace-specific note on timing. If you use Google Groups with external members, relayed mail will always fail SPF and pass only on DKIM, so make sure DKIM is signing and verifying before you go past p=none, or those relays are the first mail the policy catches.

Wait, then read the result

The change takes effect at the DNS host, from minutes up to a couple of hours, and the saved record appears back in that DNS host’s own records list rather than anywhere inside Google Workspace.

How the scan grades this record: the DMARC policy check, with its pass and fail rules and how many domains pass it.

The gap this closes is large. In the October 2026 census, 249,025,625 domains (74.9%) publish no DMARC record at all, and among those parked at p=none, 35,049,364, or 80.17%, carry no rua= address, so they collect nothing to act on.

When the reports show every legitimate sender aligning, move to p=quarantine, then p=reject. Receivers act on the record only at p=quarantine or p=reject.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.