Configure DMARC in Google Workspace: Step-by-Step

To configure DMARC in Google Workspace, start DKIM signing in the Admin console, keep include:_spf.google.com in one SPF record, and publish a TXT record at _dmarc.example.com with p=none and a rua address. Review reports before enforcing.

How do you configure DMARC in Google Workspace?

You work in four stages: authenticate your mail with DKIM and SPF, publish a DMARC TXT record at _dmarc in your domain's DNS, read the aggregate reports, then tighten the policy. The record always lives at your DNS host, and in most setups Google does not add it for you.

1. Generate and start DKIM signing in the Google Admin console.
2. Make sure your SPF record authorizes Google.
3. Publish a DMARC record with p=none and a rua reporting address.
4. Review reports, fix gaps, then move to p=quarantine and p=reject.

For the general process beyond Google, see the DMARC setup guides.

Do you need SPF and DKIM before DMARC?

Yes. DMARC passes only when SPF or DKIM passes and the authenticated domain aligns with the domain in the visible From address. Without a custom DKIM key, Google signs with a default domain that does not match yours, so alignment depends on SPF alone. Set up both first.

Enable DKIM in the Admin console

Sign in as an admin and go to Apps > Google Workspace > Gmail > Authenticate email. Select your domain and generate a new record. Google offers a 2048-bit key if your DNS host supports long TXT values, and the default selector is google.

Publish the TXT record Google gives you at your DNS host:

google._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key)"

DNS changes can take time to appear. Once the record is visible, return to the same Admin console page and click Start authentication. Until you do, outgoing mail is not signed with your domain. To find a selector on a sent message, check the s= value in its DKIM-Signature header.

Check your SPF record

Google Workspace sends through Google's servers, so your SPF record must include Google's mechanism. A domain that sends only through Google Workspace publishes:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

If other services send as your domain, add their includes to the same record. A domain can have only one SPF record, and SPF allows a maximum of 10 DNS lookups during evaluation, so check the total as you add includes. The free domain scanner shows your SPF, DKIM and DMARC records in one place. Our setup guides cover SPF and DKIM configuration in more depth.

How do you publish the DMARC record for Google Workspace?

Create a TXT record named _dmarc in your domain's authoritative DNS zone, with a value starting v=DMARC1 and a policy of p=none. Add a rua tag with a mailbox that receives aggregate reports. Save it, wait for DNS to update, and confirm it resolves.

Use these values at your DNS host:

• Type: TXT
• Name/Host: _dmarc (some providers want the full _dmarc.example.com)
• Value:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

A few details prevent common failures:

• Publish exactly one DMARC record per domain. If a receiver finds more than one at _dmarc, RFC 7489 (section 6.6.3) says it applies no DMARC processing at all. The domain is treated as having no policy, so your policy is silently ignored rather than failing visibly.
• Edit the zone that is actually authoritative. If your name servers are at a different provider than your registrar, the registrar's DNS page has no effect.
• If the rua mailbox is on a different domain, that domain must authorize receiving your reports by publishing a TXT record named example.com._report._dmarc.reportdomain.example with the value v=DMARC1. This is defined in RFC 7489.
• Do not put reject in the first record. Start with p=none.

After publishing, check the record with the DMARC lookup tool. It shows whether the record is found, parses correctly and has a valid policy.

How do you check that DMARC is working?

Send a message from a Workspace mailbox to an outside address, open it, and view the original headers. In the Authentication-Results header you should see dmarc=pass, along with spf=pass or dkim=pass for your own domain. A DNS query for _dmarc.example.com should also return your record.

In Gmail, open the received message, choose Show original, and read the summary at the top, which lists SPF, DKIM and DMARC results. From a terminal:

dig +short TXT _dmarc.example.com

If DKIM shows a gappssmtp.com signing domain instead of your own, DKIM authentication has not been started for your domain. Revisit the Admin console step above. If results still look wrong, work back through the setup guides to find the step that was missed.

A passing test message proves only that one path works. Receivers send aggregate reports, usually daily, showing every system sending as your domain. Raw XML is hard to read, so many teams use DMARC monitoring, which collects and visualizes these reports. yourDMARC offers this.

When should you move from p=none to p=reject?

Move to enforcement only after your reports show every legitimate sending source passing DMARC with alignment. Then raise the policy in stages: p=none, then p=quarantine, then p=reject. Enforcing before you have found all your senders risks blocking your own legitimate mail.

A practical sequence:

1. Inventory senders. Use reports to list Gmail, CRM, billing, marketing, helpdesk and forgotten legacy systems.
2. Fix failures. For each legitimate source, add it to SPF, enable DKIM signing with your domain, or move it to a dedicated subdomain it can authenticate.
3. Quarantine. Change the record to p=quarantine. Optionally, the pct tag applies the policy to only a share of failing messages first.
4. Reject. After reports stay clean, set p=reject and remove pct or set it to pct=100.

A quarantine example:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com

Treat pct as a rough dial, not a precise control: receivers sample messages, so the split will not be exact. It is also on its way out. DMARCbis, the revision of the DMARC specification, drops pct and adds a t= testing flag instead, so do not build your rollout around pct alone. Staging by sender and by subdomain, guided by your reports, works under either version.

Subdomains and the sp tag

The sp tag sets a separate policy for subdomains. When sp is absent, subdomains inherit the p value, so at p=reject your subdomains are already covered. sp matters while the main policy is weaker, for example p=none; sp=reject on a domain whose subdomains never send mail and whose main domain is still being tested.

Google's bulk-sender rules also expect DMARC to be in place, which you can read about on the email sender compliance page.

If you would rather not manage the rollout yourself, a managed DMARC service has the yourDMARC team run the path to p=reject. Plans are on the pricing page.

Common mistakes when you set up DMARC in Google Workspace

• DKIM never started. Generating the key is not enough; click Start authentication after the DNS record is live.
• Duplicate DMARC records. Receivers ignore the policy, so merge them into one.
• Multiple SPF records. Merge them into one record.
• Too many SPF lookups. Going beyond 10 causes an SPF permanent error.
• Third-party senders ignored. Mail from tools that use their own domain in the return path and cannot sign with your DKIM key will fail alignment.
• No one reads the reports. A DMARC record without report review is only a placeholder.

Key takeaways

• Authenticate first: start DKIM for your own domain in the Admin console and keep include:_spf.google.com in a single SPF record.
• Publish one TXT record at _dmarc.example.com, starting with p=none and a rua address. Two records mean the policy is ignored.
• Verify with the Authentication-Results header, a DNS query and a DMARC lookup.
• Use aggregate reports to find every sending source before changing the policy.
• Move gradually from none to quarantine to reject, and treat pct as a rough, soon-to-be-removed aid.
• Subdomains inherit p unless sp is set; keep SPF under the 10-lookup limit.