Google Workspace DMARC setup: publish the record, then enforce

The DMARC record for a Google Workspace domain is a TXT record at the _dmarc host:

Field	Value
Type	TXT
Host / Name	_dmarc
Value	v=DMARC1; p=none; rua=mailto:[email protected];
TTL	Default

Replace the rua address with your own reporting address. Publish the record at your DNS host, not in the Google Admin console. Google’s DMARC setup documentation is explicit: “You don’t need to do anything in your Google Admin console to set up DMARC.” There is no DMARC screen in the Admin console the way there is for DKIM. We verified Google’s documentation in August 2026.

Google recommends starting with p=none, and so do we. The rest of this guide covers the prerequisites, the record, the DNS steps, verification, and the path from monitoring to enforcement.

Before you start: SPF and DKIM

DMARC does not authenticate anything by itself. It asks receivers to check SPF and DKIM, compare the authenticated domains against your visible From domain, and apply your policy to mail that fails both. So SPF and DKIM come first:

1. Publish the Google Workspace SPF record: v=spf1 include:_spf.google.com ~all, merged with any other senders you have.
2. Set up Google Workspace DKIM: generate the key in the Admin console, publish google._domainkey, and click Start Authentication.

Google says to allow 48 hours after setting up SPF and DKIM before setting up DMARC. You also need DNS access for the domain in your users’ From addresses. If people send as [email protected], you are editing DNS for example.com.

A DMARC record published before DKIM signing is enabled is not dangerous at p=none; observing an incomplete setup is what the monitoring policy is for. Just do not skip to enforcement with SPF as your only aligned identifier. Forwarding breaks SPF; DKIM survives it.

Step 1: check for an existing DMARC record

Run your domain through our DMARC checker before touching DNS. It shows whether a record already exists at _dmarc, what it says, and whether SPF and DKIM are in place.

If a record exists, edit it instead of adding a second one. Receivers that find multiple TXT records starting with v=DMARC1 at _dmarc treat DMARC discovery as failed, so a duplicate is worse than either record alone.

Step 2: build the record

For a first record, use:

v=DMARC1; p=none; rua=mailto:[email protected];

Three parts, in order:

• v=DMARC1 identifies the record. It must come first.
• p=none is the monitoring policy. Receivers still evaluate SPF, DKIM, and alignment on every message; they just do not change delivery solely because DMARC failed. Google’s documentation recommends starting here.
• rua=mailto:... is where receivers send aggregate reports. Without it you publish a policy blind: you get no data on who is sending as your domain or whether legitimate mail aligns.

Google recommends pointing rua at a dedicated mailbox, a group, or a third-party service rather than a personal inbox, because the reports arrive as gzipped XML attachments meant for machine parsing. When you sign up for DMARCTrust and add your domain, you get a dedicated reporting address on reports.dmarctrust.com to use as the rua destination. The cross-domain authorization that RFC 9990 §4 requires is already published on our side, so reporting needs no extra DNS work from you.

Our DMARC generator builds the value, validates the syntax, and explains every tag.

Step 3: publish the record at your DNS host

Sign in to whichever service hosts your domain’s DNS and add the TXT record from the table at the top of this page.

One update if you registered your domain through Google: Google Domains no longer exists. Google sold the registrar business to Squarespace, and every Google Domains registration was migrated to Squarespace by July 2024. If your domain came from Google Domains, your DNS now lives at Squarespace: open the domains dashboard at account.squarespace.com/domains, click the domain, and select DNS in the side panel. Add a record with Type TXT, Name _dmarc, and the record value in the Data field. Squarespace says record changes can take 24 to 48 hours to propagate.

At any DNS host, watch for the same two traps as with DKIM:

• Some providers append your domain to the host automatically. Entering _dmarc should create _dmarc.example.com, not _dmarc.example.com.example.com. Check the resulting name.
• Paste the value as plain text. Smart quotes and stray spaces break the record.

Step 4: verify the record

Run the domain through our DMARC checker again. You want to see:

• One DMARC record at _dmarc, syntactically valid.
• A valid SPF record within the 10-lookup limit.
• Google Workspace DKIM published at google._domainkey.
• The rua destination accepted, including the cross-domain authorization check when the reporting address is on another domain.

Then send a test message from Google Workspace to a Gmail mailbox and open Show original on the received copy. The authentication summary should show SPF PASS, DKIM PASS with your domain, and DMARC PASS.

Aggregate reports are the slower signal: expect roughly one report per receiver per day once receivers see mail from your domain, so the first data typically lands within a day or two of publishing.

Step 5: move from p=none to enforcement

p=none protects nothing. It only observes. The monitoring phase exists to inventory every source sending as your domain. Google Workspace is one of them. So are the CRM, the helpdesk, and the invoicing tool. Fix alignment for each before you ask receivers to quarantine or reject.

The sequence:

1. Monitor at p=none until reports account for every legitimate sender.
2. Configure aligned DKIM (or an aligned return path) for each third-party source that fails.
3. Move to p=quarantine, optionally with t=y first to request test mode.
4. Move to p=reject only after quarantine ran clean and you have checked indirect mail flows such as forwarding and mailing lists.

RFC 9989 §5.1.6 says to remediate unaligned or unauthenticated mail streams before enforcement, and §7.4 recommends at least a month at p=none and another at p=quarantine for domains whose users post to Internet mailing lists. The full sequence, including what to check in the reports at each stage, is in our DMARC enforcement rollout playbook.

Does Gmail require DMARC?

For bulk senders, yes. Google’s Email sender guidelines have been in force since February 1, 2024. They require DMARC for any sender that sends close to 5,000 or more messages to personal Gmail accounts within a 24-hour period. p=none satisfies the requirement. Google also states the classification is permanent: once a domain is a bulk sender, it stays one.

Below that volume, DMARC is not mandatory for Gmail delivery, but all senders must authenticate with SPF or DKIM, and bulk senders need both plus From-domain alignment. If Gmail is already rejecting your mail with a 5.7.26 error, our Google DMARC check guide covers the full sender-requirement diagnosis, including the parts a DNS check cannot see.

FAQ

Does Google Workspace set up DMARC for me?

No. Google Workspace evaluates DMARC on inbound mail and signs outbound mail with DKIM once you enable it, but it does not publish a DMARC record for your custom domain. You create the TXT record at _dmarc in your own DNS.

What DMARC record should I use for Google Workspace?

Start with v=DMARC1; p=none; rua=mailto:[email protected]; at the _dmarc host, with your own reporting address in rua. Move to p=quarantine and p=reject only after aggregate reports show every legitimate sender aligned.

How long until DMARC reports arrive?

RFC 9989 §8 says receivers SHOULD send aggregate reports on at least a daily basis, and participating receivers send roughly one per day each. Expect the first reports within a day or two of publishing the record, provided receivers saw mail from your domain in that window.

Does DMARC affect mail between users in my own organization?

Google Workspace evaluates authentication on inbound mail, including mail from your own domain. That is a reason to finish SPF and DKIM first and start at p=none: an enforcement policy published before DKIM signing is enabled can affect your own mail wherever it fails alignment, such as messages relayed through an unaligned third-party tool.