Google Workspace DMARC: Record and Rollout

What does Google Workspace DMARC actually check?

DMARC, defined in RFC 7489, tells receiving servers what to do with mail that claims your domain in the visible From header but can't prove it. A message passes DMARC when SPF or DKIM passes and the passing domain aligns with the From domain. It only needs one of the two. With Google Workspace, DKIM is signed with the key you generate in the Admin console (selector google by default), and SPF covers Google's servers through include:_spf.google.com. Both live on your domain. DMARC is the layer on top that turns those two checks into a policy. One thing surprises people: Google Workspace never publishes a DMARC record for you. The Admin console has a page for DKIM, but nothing for DMARC. The record goes in at your DNS host, and it applies to every service that sends as your domain, not only to Gmail. Since February 2024, Google's bulk sender rules require a DMARC record (p=none is enough) from anyone sending 5,000 or more messages a day to Gmail addresses, along with alignment of the From domain with SPF or DKIM.

How do I set up DMARC for Google Workspace?

Google Workspace DMARC setup is a DNS job done in a fixed order. Google's own guidance asks for SPF and DKIM to be authenticating mail for about 48 hours before you publish DMARC, so the first aggregate reports reflect a working baseline and not a half-configured domain. If your MX, SPF and DKIM aren't in place yet, start with the Google Workspace DNS records for MX, SPF and DKIM and come back once they're live.

1. 1 Publish SPF as a single TXT record at the root of the domain containing include:_spf.google.com, and keep it under SPF's 10 DNS-lookup limit.
2. 2 In the Admin console go to Apps, Google Workspace, Gmail, Authenticate email, generate a 2048-bit key, publish the google._domainkey TXT record, then click Start authentication.
3. 3 Wait at least 48 hours and confirm that mail you send shows dkim=pass and spf=pass in the Authentication-Results header.
4. 4 Create a TXT record with host _dmarc and the value v=DMARC1; p=none; rua=mailto:your-report-address.
5. 5 Check it with dig TXT _dmarc.yourdomain.com and make sure exactly one record starting with v=DMARC1 comes back.

What should the DMARC record for Google Workspace look like?

The DMARC record for Google Workspace is the same as for any domain. Google doesn't need a special tag, and there's no Google-specific value to paste in. A sensible first version is v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. That collects data without telling receivers to act on failures. The tags you'll actually touch are below. Only v and p are required, and v=DMARC1 must come first.

Tag	What it does	Starting value
v	Version; must be the first tag	DMARC1
p	Policy for the domain: none, quarantine or reject	none
rua	Address for daily aggregate (XML) reports	mailto:dmarc@yourdomain.com
sp	Policy for subdomains; inherits p if omitted	leave out at first
adkim / aspf	Alignment mode: r (relaxed, default) or s (strict)	leave at default r
pct	Share of failing mail the policy applies to, 0-100	leave out while p=none

Two mistakes come up again and again. The first is publishing two TXT records at _dmarc. RFC 7489 treats that as no valid record at all. The second is pointing rua at a mailbox on another domain without that domain publishing an authorisation record at yourdomain.com._report._dmarc.otherdomain.com. If that record is missing, reports simply don't arrive.

Why does Brevo mail fail DMARC on a Google Workspace domain?

Your _dmarc record covers the domain, not the mailbox provider. So a Brevo campaign sent as you@yourdomain.com is judged by the same policy as a message typed in Gmail. Google's DKIM key does nothing for Brevo mail, because Brevo signs with its own key. That key has to be published on your domain for the signature to align. The setup is covered in G Suite DKIM with the Google record and Brevo setup. Common reasons Brevo traffic shows up as failing in your aggregate reports:

• Brevo's DKIM records were never added, so the message is signed with a Brevo domain that doesn't align with your From.
• The envelope sender (Return-Path) is on Brevo's domain, so SPF can pass for Brevo but can't align. DKIM has to carry DMARC alone.
• Brevo's include was added as a second SPF TXT record. Two SPF records produce a permerror, and SPF fails for every sender on the domain.
• adkim=s (strict) is set while Brevo signs with a subdomain of yours, so relaxed alignment would pass but strict doesn't.
• A DNS host appended the domain to the host field and published the DKIM key at the wrong name, so lookups return nothing.

None of these show up while p=none is set, apart from in the reports. That's exactly why you start there.

When should I move from p=none to quarantine or reject?

Move only when the aggregate reports show that every legitimate source sending as your domain passes DMARC: Google Workspace, Brevo, your CRM, invoicing tools, anything else. Reports arrive roughly daily (the default ri interval is 86400 seconds), so give it at least a couple of weeks to capture monthly senders like billing systems. Then step up. Go to p=quarantine, optionally with pct below 100 to apply it to part of the failing mail, and finally to p=reject. Skipping straight to reject is what goes wrong most often. A forgotten tool that sends invoices from your domain will have its mail refused by receivers that honour the policy, and nobody notices until a customer asks where the invoice went. Forwarding is the other known weak point. Forwarded mail often breaks SPF, and mailing lists that rewrite the body break DKIM, so some legitimate mail will fail under any strict policy. For a cold outreach domain, p=none with clean reports already meets Google's bulk sender minimum. Tightening is a separate decision about spoofing risk. It isn't a deliverability switch. The wider picture is in DKIM, DMARC and SPF for cold email senders.

How does EmailFlow OS work with a Google Workspace DMARC setup?

EmailFlow OS doesn't add a sender of its own to your domain, so there's no extra source to authorise in your DMARC record. You record one video and upload it to EmailFlow OS, connect your Brevo account and your sending domain, and import your prospect list into EmailFlow OS. EmailFlow OS then personalises that single recording for each recipient, not each company, and sends every version from your own inbox through your Brevo account and your sending domain. There's no shared platform address in the From line. In practice, the DMARC result for those messages depends on the same records you already control: Brevo's DKIM key published on your domain and your single _dmarc TXT record. If Brevo mail aligns in your aggregate reports today, the video emails go through that same path. If it doesn't, fix the Brevo DKIM records before sending, because no tool can align a signature your DNS doesn't publish. Whether a receiving server accepts the message is still that server's decision. For a new domain, ramp volume first, as described in the email warm-up with daily volumes and DNS setup.

Questions people ask

? Does Google Workspace create a DMARC record automatically?

No. The Admin console generates your DKIM key and shows the google._domainkey record, but DMARC is never created for you. You publish one TXT record at _dmarc.yourdomain.com with your DNS host, starting with v=DMARC1 and a p tag. Without it, receivers apply no DMARC policy, and Gmail's bulk sender rules for 5,000 or more messages a day aren't met.

? Can I have two DMARC records, one for Google and one for Brevo?

No. DMARC allows exactly one record per domain at _dmarc. Under RFC 7489, if a lookup returns more than one v=DMARC1 record, the domain is treated as having no DMARC policy at all. Google Workspace and Brevo share the one record. Each service needs its own aligned DKIM key, but the policy itself is a single TXT entry.

? How long after DKIM should I add DMARC in Google Workspace?

Google's setup guidance asks for SPF and DKIM to be authenticating mail for about 48 hours before you publish DMARC. That also covers typical DNS propagation, which can take up to 48 hours. Check that your outgoing messages show dkim=pass in the Authentication-Results header before adding the _dmarc record.

? Is p=none enough for Gmail's sender requirements?

Yes, for the DMARC part. Google's rules for senders of 5,000 or more messages a day to Gmail require a published DMARC record with at least p=none, plus a From domain aligned with SPF or DKIM. p=none still sends you aggregate reports. It just doesn't tell receivers to quarantine or reject mail that fails.