DMARC for Google Workspace

Before you start: turn on DKIM

DMARC performs no authentication of its own. It reads the results of SPF and DKIM and asks whether the domain that passed matches the domain in the visible From header. Publishing a DMARC record before either is in place produces reports of your own mail failing, and nothing else.

Google Workspace signs outbound mail with DKIM once you generate a key and publish it, and setting up DKIM for Google Workspace covers that on its own. The documented path is:

1. In the Google Admin console, go to Menu, then Apps, Google Workspace, Gmail. This requires the Gmail Settings administrator privilege.
2. Click Authenticate email, then choose the domain in the Selected domain menu.
3. Click Generate New Record. Google recommends a 2048-bit key where the domain provider supports it. Its sender guidelines add that sending to personal Gmail accounts requires a key of at least 1024 bits.
4. Publish the generated TXT record at the host google._domainkey in your DNS, then return to Authenticate email and click Start authentication.

Google asks you to allow 48 hours after SPF or DKIM is in place before setting up DMARC, so that both are authenticating real mail first.

SPF is a separate record in the same DNS zone. If Google Workspace is your only sender, v=spf1 include:_spf.google.com ~all is the shape Google documents, but every other service that sends as your domain has to be represented too.

How to set up DMARC for Google Workspace

Google's Set up DMARC page breaks the work into four steps, and they are worth following in that order.

1. Set up a mailbox or group for reports

Aggregate reports arrive as XML, one file per receiver per day. Point the rua tag at a mailbox you control. Gmail does not support the ruf tag at all, so a forensic address on a Workspace domain collects nothing from Google. On a domain of any size, reading them by hand stops being practical almost immediately, which is why most people point the reporting address at a monitoring service rather than a person's inbox.

If you send reports to an address on a different domain, that domain has to publish an authorization record before receivers will send anything. This is the quietest failure in the whole setup: the record looks correct, and no reports ever arrive.

2. Make sure third-party senders authenticate

Authenticating third-party senders is the step that decides how long the rest takes. A CRM, a billing platform, a help desk, a marketing tool, and a form on the website can all use the same From domain while authenticating differently, or not at all.

Each one needs either an SPF authorization or a DKIM signature that aligns with your domain. Work through the inventory you built above, sender by sender.

3. Decide the record

Start at p=none. Receivers deliver everything exactly as before and send you reports naming every source using the domain, which is the evidence the later steps depend on.

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

One caveat about Google's own documentation. The example record on Google's Set up DMARC page includes pct=100, and RFC 9989 removed the pct tag in May 2026, along with rf and ri. A record carrying it is not broken, but new records should leave it out. Google's example also sets adkim=s; aspf=s, which is strict alignment on both. Relaxed alignment is the default and suits nearly every domain, because legitimate services routinely send from subdomains. Choose strict only when you know exactly which senders exist.

4. Add the record to your domain

Publish it as a TXT record in the DNS zone that answers for the domain. Google documents the fields as the record type TXT, the host _dmarc.yourdomain.com, and the value being the DMARC string itself.

Two details cause most of the confusion here. The first is that this is not an Admin console setting: there is no DMARC page in Google Workspace to switch on. The second is that your registrar may not be your DNS host. Running dig NS yourdomain.com settles it. Whichever nameservers come back is where the record belongs, and the provider guides for Cloudflare, GoDaddy, Namecheap and Amazon Route 53 cover the click paths.

For the provider-neutral version of this whole sequence, see how to set up DMARC.

What Gmail actually requires

Google's Email sender guidelines set two tiers, and the distinction matters because a lot of writing on this subject collapses them.

Every sender to Gmail, at any volume, must set up SPF or DKIM, have valid forward and reverse DNS records for sending domains or IPs, use TLS, keep the spam rate reported in Postmaster Tools below 0.30%, and format messages to RFC 5322.

Google's sender guidelines FAQ defines a bulk sender as one sending close to 5,000 messages or more to personal Gmail accounts within a 24-hour period, counted by primary domain, and says the status does not expire once assigned. "Close to" is doing real work there. Google publishes no lower bound, so treat a domain steady at 4,700 a day as inside the rule rather than outside it.

Bulk senders must, since 1 February 2024, additionally set up both SPF and DKIM, publish a DMARC record, align the From header domain with either the SPF domain or the DKIM domain, and support one-click unsubscribe on marketing and subscribed messages. Google states plainly that the DMARC enforcement policy can be set to none to meet this requirement.

That last sentence is the one worth internalizing. Publishing p=none satisfies the letter of Google's rule while leaving the domain fully spoofable, which is why so many domains stop there and report themselves as compliant.

How to validate the setup

Validation runs at four layers, and a pass at one says nothing about the others.

• Public DNS. Query _dmarc.yourdomain.com as a TXT record at a public resolver with dig +short TXT _dmarc.yourdomain.com @8.8.8.8. Confirm exactly one policy record comes back and that its value is the one you intended. If two come back, multiple DMARC records is its own failure mode: receivers treat the domain as having no usable policy.
• Google Workspace. Confirm the Authenticate email page shows "Authenticating email with DKIM" for the domain in scope.
• A delivered message. Send a message through each production sender and read the Authentication-Results header the receiving system added. This is the only layer that shows whether a sender actually authenticates.
• Aggregate reports. Review reports across enough normal sending to cover every known source. This is what decides whether it is safe to tighten the policy.

Moving past monitoring

Move in stages and read the reports at each one. p=quarantine sends failing mail to spam, which is recoverable if you missed a sender. p=reject refuses it, which is not. If subdomains send mail and are not ready, the sp tag gives them their own policy so the parent domain can enforce without breaking them.

Troubleshooting

The record is missing from a public lookup

Query _dmarc.yourdomain.com rather than the root domain, and check for a duplicated zone suffix such as _dmarc.yourdomain.com.yourdomain.com, which happens when the DNS host appends the zone to a fully qualified name. If a different provider is authoritative for the domain, the record you added elsewhere will never resolve however correct it looks.

DKIM shows as not authenticating

Google notes that a newly created Google Workspace account may need to wait before a key can be generated, and that generating a key is not the same as turning authentication on. Publish the google._domainkey TXT record first, then return to Authenticate email and click Start authentication. Verify by sending to a different mailbox, since a message to yourself does not prove DKIM is working.

Mail from another application fails after enforcement

Compare the visible From domain against the SPF smtp.mailfrom domain and the DKIM d= domain for an affected message. An SPF or DKIM pass that does not align with the From domain is not a DMARC pass. Return the policy to the last known-good value while you fix that sender, rather than deleting the record, which also removes the reporting you need to diagnose it.

Gmail returns a 4.7.31 rate-limit error

Google's wording is that the message "has been rate limited because the sending domain doesn't have a DMARC record, or the DMARC record doesn't specify a DMARC policy". It is a throttle, not a bounce, and it names the two conditions that trigger it: no record at _dmarc, or a record without a usable p= tag. Publish a record with an explicit policy, starting at p=none, and confirm it resolves before retrying the send.

No aggregate reports are arriving

Check that the rua address is valid and accepts external mail, and that it matches the published record. If it is on a different domain, that domain has to authorize it. Some receivers never send reports at all, so silence from one receiver is not evidence of a broken record.

Where Palisade fits

Palisade is agentic DMARC software. It reads the aggregate reports the record generates, identifies every sending source and the authentication or alignment issues behind each one, and files prioritized remediation tickets. It proposes the next policy step when the evidence supports it, and a person reviews and applies every change.

Start with Palisade