DMARC for Gmail: what Google actually requires and how to set it up

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS TXT record that tells receiving mail servers what to do with mail claiming to be from your domain when SPF or DKIM fails. Gmail does not use a different DMARC than anyone else - what changed is that since February 2024, Google requires any sender pushing more than 5,000 messages a day to Gmail addresses to have a DMARC record published, at minimum p=none. Below that volume it is not mandatory, but every sender benefits from it regardless of volume.

The record Gmail is checking for

At minimum, Google wants to see this at _dmarc.yourdomain.com:

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

• v=DMARC1 - the version tag, always this exact string.
• p=none - the policy. none means "do nothing special, just report." This is the minimum Gmail requires; it is not asking you to reject your own mail on day one.
• rua=mailto:... - where aggregate reports get sent. Use an inbox you actually read, or a DMARC monitoring service's ingestion address.

Why p=none is the right starting policy, not a cop-out

A domain that jumps straight to p=reject before confirming every legitimate sending source is correctly aligned will silently drop its own transactional mail - password resets, invoices, support replies - the moment one unlisted sending tool is in the mix. p=none gives you weeks of aggregate reports showing exactly which IPs and tools send as your domain and whether they pass SPF/DKIM alignment, with zero risk to delivery. Move to p=quarantine once those reports are clean, then p=reject once quarantine has run clean for a few weeks.

What DMARC actually checks

DMARC does not add a new authentication mechanism. It checks that SPF or DKIM passed *and* that the domain that passed matches the visible From domain - this is called alignment. A message can pass SPF outright and still fail DMARC if the SPF-authenticated domain doesn't match the From header. This is the single most common reason a domain with "working" SPF and DKIM still fails DMARC: one of the two passes, but on the wrong domain.

Setting it up for a domain that sends through Google Workspace

1. Confirm SPF is published and includes include:_spf.google.com if you send through Gmail/Workspace, plus any other platform (ESP, helpdesk, CRM) you send through.
2. Confirm DKIM is turned on in Google Admin console under Apps > Google Workspace > Gmail > Authenticate email, and that the generated TXT record is published.
3. Publish the DMARC record above at p=none.
4. Read the aggregate reports (they arrive as XML attachments, roughly daily, from receiving mail servers) for at least two to three weeks.
5. Fix any sending source showing as unaligned - usually a marketing tool, a helpdesk, or a CRM sending as your domain without being added to SPF or DKIM-signed.
6. Move to p=quarantine; pct=25 to start enforcing gradually, then to full enforcement and finally p=reject.

What not to do

• Don't skip straight to p=reject. It is the single most common way a domain blocks its own mail.
• Don't ignore the aggregate reports once you've set p=none and move on - the point of none is to read them.
• Don't assume one DMARC record covers subdomains differently unless you set sp= explicitly - the default is that the main policy applies to subdomains too, which can surprise you if a subdomain sends unauthenticated mail.
• Don't conflate "Gmail requires it above 5,000/day" with "it's optional below that." Mailbox providers that don't technically require it still use its absence as a negative reputation signal.

DMARC reporting: what the two report types tell you

DMARC generates two kinds of reports, and they answer different questions:

Forensic reports have largely been phased out across major providers due to privacy concerns, so in practice, aggregate reports are what you'll actually receive and should plan around. A dedicated DMARC monitoring service parses these XML reports into a readable dashboard - reading raw XML by hand is possible for a handful of reports a day but becomes impractical once several sending sources are in the mix.

A Gmail-specific wrinkle worth knowing

Google Workspace's own DKIM key rotation and the "Authenticate email" toggle in the Admin console are a common place where a DMARC setup silently breaks: if DKIM signing is turned on in Workspace but the generated TXT record was never actually published (or was published under the wrong selector), SPF can still pass while DKIM fails, and DMARC passes anyway as long as SPF is aligned - masking the DKIM gap until the day SPF itself fails for an unrelated reason, at which point mail starts failing DMARC with no obvious recent change to explain it.

MailPilot checks SPF, DKIM, and DMARC status on every connected mailbox and flags when a domain's policy and alignment don't match what it's actually sending, alongside the mailbox's daily reputation score, so an authentication gap surfaces before it turns into a Gmail delivery problem.