How to Set Up DMARC for Google Workspace: A Step-by-Step Guide

DMARC for Google Workspace doesn’t live in the Google Admin Console — and that one fact trips up most first-time admins. To set up DMARC for Google Workspace, you publish a DNS TXT record at your domain host, not inside any Google settings page. This guide is for the IT admin or founder-operator running their own Workspace tenant who needs a working DMARC record published and progressing toward enforcement without blocking legitimate mail.

The stakes are concrete, not alarmist. Google’s bulk-sender rules require a DMARC record at a minimum policy of p=none for anyone sending more than 5,000 messages per day to Gmail accounts, a threshold in force since February 1, 2024 (Google’s 5,000-email-per-day rule). Below that volume you still need SPF or DKIM. Either way, DMARC (RFC 9989) is the layer that tells receivers what to do when a message claiming to be from your domain fails authentication.

By the end you will have the exact TXT record, the steps to publish it at your specific registrar, and the p=none → quarantine → reject rollout that gets you to enforcement safely.

Personal Gmail vs. Google Workspace: which one needs DMARC?

You can’t add DMARC to an @gmail.com address — Google owns and controls gmail.com and publishes its own DMARC policy for it. You publish DMARC only on the custom domain you brought to Google Workspace (@yourdomain.com).

This is the single most common point of confusion, so it’s worth settling first. If you send from a free @gmail.com mailbox, there is no record for you to create: the platform’s servers aren’t in gmail.com’s SPF record and no third party can DKIM-sign as gmail.com, so that mail can never pass DMARC for you, and Google is moving gmail.com toward a quarantine enforcement policy of its own (Valimail). Google Workspace is the opposite case — you brought your own domain, so you both can and, as a bulk sender, must publish DMARC on it.

Before you begin: SPF and DKIM must be live first (the 48-hour bake)

Google requires SPF and/or DKIM to be live for at least 48 hours before you turn on DMARC. DMARC only passes when a message aligns on SPF or DKIM — so the prerequisites must exist first, or every message fails. In Google’s own words: “Allow 48 hours after setting up SPF and/or DKIM before setting up DMARC.”

Publish the SPF record

If you send only through Google Workspace, publish this exact value as a TXT record at the root of your domain (Sender Policy Framework, RFC 7208):

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

The ~all tag tells receiving servers to mark mail from servers not listed in the record as suspect. Publish only one SPF record per domain — multiple SPF records is itself a failure mode — and keep the record under the limit of 10 include: mechanisms.

Google’s include is cheap: include:_spf.google.com costs just 1 of your 10 allowed DNS lookups, so a Google-only SPF record is well within budget.

Enable DKIM in the Google Admin Console

Enabling DKIM (DKIM signing, RFC 6376) is the one part of Workspace email authentication that does live in the Admin Console. The path is:

One correction worth stating plainly: until you complete this, Google signs your outgoing mail with a default key on d=*.gappssmtp.com. That default key uses a Google domain, so it does not align to your domain for DMARC — which is why manual custom-domain DKIM is still required. Expect 24–72 hours after turning on Gmail before the key is available in the console, and up to 48 hours for DKIM to activate after you publish the record.

Why 48 hours? (the reason no vendor gives)

The wait isn’t arbitrary. Two things need time: DNS propagation, so receivers worldwide can actually see your new SPF and DKIM records at their TTL, and a consistent prior authentication history, so that when you do enable DMARC, receivers are evaluating mail that has been authenticating cleanly rather than flipping enforcement on against records they only just learned about.

One platform note for teams running both: Microsoft enables DKIM in the Defender portal, while Google uses the Admin Console — see the Microsoft 365 equivalent for that flow.

How to set up DMARC in Google Workspace

To set up DMARC for Google Workspace, add a single DNS TXT record at your domain registrar with the host _dmarc and the value v=DMARC1; p=none; rua=mailto:[email protected]. DMARC is not configured inside the Google Admin Console — it lives at your domain host. Wait 48 hours for SPF and DKIM to bake before turning DMARC on.

The work breaks into three steps, which mirror the order Google’s own documentation uses (Google Workspace Admin Help — Set up DMARC).

Step 1 — Determine your DMARC record

Start with a monitoring record. For most Workspace admins the practical starter record is:

v=DMARC1; p=none; rua=mailto:[email protected]

The v tag must be listed first; the rest can appear in any order. p=none puts you in monitor mode — no message is quarantined or rejected, but you start receiving aggregate (XML) reports at the rua mailbox so you can see exactly which sources are sending as your domain. Use a dedicated mailbox or group for rua, because the report volume adds up. If you’d rather not hand-assemble the tags, a DMARC record generator builds a valid record from your inputs and explains each tag as you go.

Step 2 — Add the record at your domain host (TXT)

Google defers this step to “your domain host,” which is where most guides stop. Here are the exact field labels per registrar, each verified against the registrar’s own documentation.

One warning applies to every host: enter the host as _dmarc only — never _dmarc.example.com. All of these registrars automatically append your zone, so typing the full name produces a broken _dmarc.example.com.example.com record. This single mistake is the most common reason a DMARC record silently fails.

• Cloudflare — DNS Records → Add record → Type TXT. Put _dmarc in Name and the policy string in Content. Cloudflare adds the surrounding quotes automatically, so don’t type your own.
• GoDaddy — Domain Portfolio → DNS → Add New Record → TXT. Name is the prefix only (_dmarc), Value is the raw string; the default TTL is 1 hour. This is the godaddy dmarc google workspace setup most people search for.
• Namecheap — Advanced DNS → Host Records → Add New Record → TXT Record. Host is _dmarc, Value is the raw string. Records only take effect if your domain uses Namecheap’s BasicDNS/PremiumDNS nameservers — if your nameservers point elsewhere, edit DNS there instead.
• Squarespace — DNS Settings → Custom Records → Add Record → TXT. Name is _dmarc, Text is the value (no quotes), and Squarespace allows only one DMARC record per domain. If you migrated from Google Domains, confirm the domain’s DNS is actually editable in Squarespace’s DNS Settings before adding the record — a domain still on a legacy configuration can’t be edited until you change its DNS provider.

The quoting rules are opposites, and mixing them up is the second most common failure: Route 53 requires double quotes around the value, Cloudflare adds them for you, and GoDaddy, Namecheap, and Squarespace take the raw string.

Step 3 — Verify your DMARC record

After saving, run a DMARC lookup against your domain. Your p=none record should appear live within the propagation window — usually a few hours, up to 48 hours. Confirm the record resolves as exactly _dmarc.yourdomain.com and that no other record collides at that host. DMARCguard’s DMARC checker reads the live record and flags syntax problems so you can confirm it’s valid before you move on.

Your Google Workspace DMARC record, tag by tag

Every DMARC tag has a job: v sets the version, p sets the enforcement policy, and rua is where your aggregate reports go. Google’s own documentation lists the full set, but it buries one Gmail-specific quirk — the ruf tag does nothing here.

Choosing your policy: the p=none → quarantine → reject rollout

Start at p=none to monitor without affecting delivery, then tighten to quarantine and finally reject once your legitimate senders all align. Never start at reject — you’ll block your own mail.

Google’s documented rollout is deliberate. Sit at p=none and read the daily aggregate reports; one week is usually enough to capture every mail stream. Then move to quarantine. Under DMARCbis (RFC 9989) the old pct percentage tag has been removed — staged enforcement is now signalled with the t (test mode) tag. Publish p=quarantine; t=y so receivers apply the policy one level below what you declared (effectively still monitor-only) while you watch the reports, then drop t=y to enforce quarantine. Repeat the same dry run for reject with p=reject; t=y before committing to plain p=reject. If legitimate mail starts failing at any step, roll back one step, fix the failing sender, and resume. If you’re stuck at p=none and unsure when to advance, the p=none escape plan generates a personalised four-week migration plan with the exact record at each step.

The reason teams get stuck at p=none is that enforcement is unforgiving of senders you haven’t accounted for yet. Hold there until you’ve seen every legitimate source report in — including the monthly, quarterly, and annual senders that only appear occasionally.

To protect domains you don’t send from, publish sp=reject to cover existing subdomains, and np=reject (new in RFC 9989) to cover non-existent ones — the parked or never-used labels attackers like to spoof — while the parent domain still collects data at p=none. And if a Gmail brand logo (BIMI) is on your roadmap, note that BIMI requires an enforced policy of p=quarantine or p=reject — p=none is not eligible. The mechanics of policy, alignment, and subdomain discovery are now governed by DMARCbis (RFC 9989/9990/9991), which obsoletes the original RFC 7489 — worth a read before you finalize a long-term posture.

Troubleshooting: “no DMARC record found” and “policy not enabled”

Most DMARC errors after a Google Workspace setup come down to three things: the record is at the wrong host, the record exists but is still p=none, or a third-party sender fails alignment. Here’s the verdict you’ll see, the likely cause, and the fix.

That third row is the most common failure in practice, and it’s a subtle one. SPF and DKIM can both pass for a vendor’s domain yet still fail alignment to your From domain — a valid DKIM signature from mailservice.com does not align with yourdomain.com. Many SaaS senders (Mailchimp and Salesforce among them) use their own Return-Path, so SPF won’t align by default; DKIM is the more reliable alignment path. Set up the vendor’s own DKIM signing for your domain so at least one mechanism aligns. When a verdict isn’t obvious, the DMARC failure diagnoser maps a failing source to the specific record change that fixes it. (Google documents these cases on its Troubleshoot DMARC page.)

Frequently asked questions

Does DMARC live in the Google Admin Console?

No. DMARC is published as a DNS TXT record at your domain host, not in the Admin Console. The only Google Workspace setup that happens in the Admin Console is enabling DKIM. SPF and DMARC are both added at your domain registrar’s DNS panel.

How do I set up DMARC for Google Workspace?

Publish SPF and enable DKIM first, wait 48 hours, then add a _dmarc TXT record at your registrar with v=DMARC1; p=none; rua=mailto:[email protected]. Verify it resolves, monitor the aggregate reports, then progress to quarantine and reject once your senders align.

Can I add DMARC to my @gmail.com address?

No. Google owns and controls gmail.com and publishes its own DMARC policy for it, which it is moving toward quarantine enforcement. You can only publish DMARC on a custom domain you control — the domain you brought to Google Workspace.

Does Google Workspace require DMARC?

All senders to Gmail need SPF or DKIM. Senders of more than 5,000 messages per day to Gmail accounts must also publish a DMARC record at minimum p=none, effective February 1, 2024. Bulk-sender status is permanent once met.

How long until my DMARC record is active?

A new _dmarc TXT record typically resolves within a few hours and up to 48 hours after DNS propagation. Separately, Google needs SPF and DKIM live for 48 hours before DMARC enforcement behaves correctly.

Does Google Workspace support DMARC forensic (ruf) reports?

No. Gmail and Google Workspace send aggregate (rua) reports only and never send forensic (ruf) reports, for privacy reasons. Adding a ruf tag has no effect for Gmail — rely on aggregate reports plus Postmaster Tools.

The short version

• DMARC for Google Workspace lives at your DNS host, not the Admin Console — only DKIM is enabled in the console.
• Publish SPF and DKIM first, then wait 48 hours so propagation and a clean authentication history are in place.
• Start at p=none to monitor, then progress to quarantine and reject once every legitimate sender aligns.
• Enter the host as _dmarc only, and mind your registrar’s quoting rule.
• Gmail sends aggregate (rua) reports only — never forensic (ruf) reports.

Getting Google Workspace DMARC right is a sequence, not a single switch, and the records are unforgiving of typos.