How do you set up DMARC for Google Workspace?

Google Workspace doesn't publish DMARC for you. You turn on DKIM in the Admin console, make sure SPF is right, and then publish one TXT record at your DNS host. This guide follows Google's own setup and rollout guidance step by step, notes where the current DMARC standard differs, and shows how to reach p=reject without losing legitimate mail.

What do you need before you publish DMARC?

DMARC builds on SPF and DKIM. A message passes DMARC when SPF or DKIM passes for a domain that aligns with the From address. Google's Set up DMARC page is direct about the order: "You must turn on SPF and/or DKIM for your domain before you can use DMARC." It adds: "Allow 48 hours after setting up SPF and/or DKIM before setting up DMARC."

Turn on both, not just one. SPF often breaks when mail is forwarded, while a DKIM signature usually survives. Our guide to forwarding and DMARC explains why.

You'll need:

• Super administrator access to the Google Admin console, to turn on DKIM.
• Access to your domain's DNS host.
• A list of every service that sends email as your domain: Gmail, plus any newsletter tool, CRM, help desk, billing system, website or scanner.

Step 1: Turn on DKIM in the Google Admin console

Do this first, because it's the part most domains miss. In the Admin console, go to Apps > Google Workspace > Gmail > Authenticate email, select your domain, generate a 2048-bit key, publish it as a TXT record at google._domainkey, then click Start authentication. Google's Set up DKIM page has the full steps.

Our DKIM setup guide for Google Workspace walks through each screen, including what to do if your DNS host rejects a 2048-bit key. Repeat it for every domain that sends mail, including secondary domains. When you're done, check the record with the DKIM Checker, or see the Google Workspace DKIM record format.

Step 2: Publish or fix your SPF record

For a domain that sends only through Google Workspace, Google's Set up SPF page gives this record:

v=spf1 include:_spf.google.com ~all

If other services send as your domain, add their includes to the same record. A domain must have only one SPF record; two records cause a PermError, and so does going over 10 DNS lookups. See too many DNS lookups if your record is long, and SPF for Google Workspace for combined examples. Google says it can take up to 48 hours for SPF authentication to start working.

Step 3: Get your third-party senders aligned

Google's DMARC page asks you to check each outside sender before you enforce anything:

• Confirm with the provider that SPF and DKIM are set up correctly.
• Make sure the provider's envelope sender domain matches your domain.
• Add the provider's sending servers to your SPF record.

Or route the service's outgoing mail through Google with the SMTP relay service, so Gmail signs it.

The fix that matters most is custom DKIM at each service, signing with your domain rather than the provider's. Without it, the service's mail passes SPF for the provider's bounce domain but fails DMARC for yours.

Step 4: Create a reporting address

Reports arrive as XML attachments, and a busy domain can get many a day. Google recommends "that you create a group or a dedicated mailbox to receive and manage DMARC reports", and says, "We don't recommend using your own email address."

A Google Group such as dmarc-reports@yourdomain works well. If you send reports to an address on a different domain, that other domain must publish a DNS record authorizing them, or receivers won't deliver the reports.

Step 5: Publish the _dmarc record at your DNS host

DMARC isn't set in the Admin console. Add a TXT record at your DNS host:

Google notes that some DNS hosts add the domain name to the end of the host automatically, so check that you haven't created _dmarc.yourdomain.com.yourdomain.com. Repeat for each domain, since each one can have its own policy. Our guides for Cloudflare, GoDaddy and Namecheap show where the fields are.

The DMARC Record Generator builds the value for you. Check it afterwards with the DMARC Checker.

What the tags mean

Google notes that "Relaxed alignment typically provides sufficient spoofing protection" and warns that strict alignment can cause mail from your own subdomains to be rejected or sent to spam. Keep the defaults unless you have a reason. Our DMARC subdomain policy guide covers sp and np.

Step 6: Move from p=none to quarantine to reject

Google's recommended rollout has three stages:

1. Monitor with p=none. Messages are delivered normally. Google says to "Review your DMARC reports daily" and that about a week is usually enough for reports to cover your mail streams.
2. Quarantine. Start only after at least a week with no issues in your outgoing mail. Failing messages go to recipients' spam folders.
3. Reject (optional in Google's guide). Google warns that receiving servers drop failing messages and they're never delivered.

A note on pct

Google's examples ramp quarantine with a percentage, such as p=quarantine; pct=5. The current DMARC standard, RFC 9989, removed pct. Its Appendix A.6 explains that the tag "was usually not accurately applied, unless the value specified was either 0 or 100". RFC 9989 adds a test-mode tag, t=y, instead. Receivers that still follow the older specification may honor pct, but you can't count on it. Plan each step as if it applies to all failing mail.

How long should each stage take?

Google's week of monitoring is a minimum. If you use several outside services, or some only send monthly, such as invoices, stay at p=none until you've seen a full cycle. Our none-to-reject roll-out plan suggests timings for small businesses.

How do you read the reports?

Google's About DMARC reports page says reports are "usually sent once a day by email" in XML. Each record summarizes "the number of messages sent from a single IP address" with the SPF, DKIM and DMARC results and any action the receiver took.

What to look for:

• Google's own servers passing. Mail from Gmail should show DKIM aligned with your domain.
• A known service failing. The usual cause is a provider signing DKIM with its own domain. Set up custom DKIM there.
• Unknown IPs failing in volume. This is often spoofing. Your policy is doing its job.
• Small volumes from mailing lists or forwarders. Usually forwarding, not an attack.

Google says raw reports "can be difficult to read and interpret". Our DMARC Report Analyzer reads the XML in your browser, and how to read DMARC reports explains each field.

Do Gmail's sender rules require DMARC?

If you send more than 5,000 messages a day to personal Gmail accounts, yes. Google's email sender guidelines require bulk senders to "Set up DMARC email authentication for your sending domain", and add that "Your DMARC enforcement policy can be set to none." Bulk senders also need the From domain aligned with the SPF or DKIM domain. Senders below that volume must set up SPF or DKIM. Our bulk sender requirements guide covers Yahoo and Microsoft too.

p=none meets the rule, but it doesn't stop anyone spoofing your domain. Only quarantine or reject does that.

Common mistakes

• Publishing DMARC before DKIM is on. Gmail mail then relies on SPF alone and fails DMARC when forwarded.
• Two _dmarc records. RFC 9989 says that if multiple DMARC records are returned, "they are all discarded", so your domain effectively has no policy. Keep one.
• Reports going to a personal inbox. Use a group or dedicated mailbox, as Google recommends.
• Strict alignment by accident. adkim=s or aspf=s fails mail from subdomains.
• Stopping at p=none. Monitoring is a stage, not a destination.
• Forgetting secondary and parked domains. Domains that never send mail should publish v=DMARC1; p=reject; and v=spf1 -all. See protecting parked domains.

If you also use Microsoft 365 for some domains, the steps differ slightly; see DMARC setup for Microsoft 365.

Next steps

• Turn on DKIM for every sending domain in the Admin console, and confirm SPF includes _spf.google.com.
• Publish v=DMARC1; p=none; rua=... with a dedicated reporting group, then read a week or more of reports.
• Check your SPF, DKIM and DMARC together with the free Email Health Check.
• Keep an eye on your records after you reach p=reject. iBlockSpam's domain monitoring alerts you when MX, SPF or DMARC changes: weekly on Protect, daily on Protect Plus.