--- title: "DMARC for Google Workspace: Step-by-Step Setup [2026]" description: "Set up DMARC for Google Workspace step-by-step: the exact TXT record, where to publish it, and the p=none to reject rollout. 2026 guide." publishedAt: 2026-06-08 tags: ["google-workspace", "dmarc", "email-authentication", "setup", "dns"] faq: - question: "Does DMARC live in the Google Admin Console?" answer: "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." - question: "How do I set up DMARC for Google Workspace?" answer: "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:dmarc@yourdomain.com. Verify it resolves, monitor the aggregate reports, then progress to quarantine and reject once your senders align." - question: "Can I add DMARC to my @gmail.com address?" answer: "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." - question: "Does Google Workspace require DMARC?" answer: "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." - question: "How long until my DMARC record is active?" answer: "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." - question: "Does Google Workspace support DMARC forensic (ruf) reports?" answer: "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." --- # 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](/blog/google-yahoo-dmarc-requirements/)). Below that volume you still need SPF or DKIM. Either way, DMARC ([RFC 9989](/learn/dmarc/)) 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](https://www.valimail.com/blog/the-gmail-dmarc-policy-update-you-may-not-know-about/)). 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. | Address | Whose DMARC policy? | Can you edit it? | | -------------------- | ----------------------------------------- | ----------------------------------------- | | `@gmail.com` | Google's — published and controlled by Google | No. This guide does not apply. | | `@yourdomain.com` | Yours — published on your own domain | Yes. This is the domain you configure here. | ## 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](/learn/spf/), [RFC 7208](https://datatracker.ietf.org/doc/html/rfc7208)): [The `~all` tag](/blog/spf-softfail-vs-hardfail/) tells receiving servers to mark mail from servers not listed in the record as suspect. Publish [only **one** SPF record per domain](/blog/spf-permerror-fix/) — multiple SPF records is itself a failure mode — and keep the record [under the limit of 10](/blog/spf-too-many-dns-lookups/) `include:` mechanisms. Google's include is cheap: `include:_spf.google.com` [costs just **1** of your 10 allowed](/tools/spf-flattener/?domain=google.com) DNS lookups, so a Google-only SPF record is well within budget. We verified it on 2026-06-01: `dig +short TXT _spf.google.com` returns a single flat record made only of `ip4:` and `ip6:` mechanisms with no nested `include:`, so `include:_spf.google.com` costs exactly **1** of your 10 DNS lookups. Google collapsed this from four lookups to one in December 2025 — always re-verify the live count, because provider records change. ### Enable DKIM in the Google Admin Console Enabling DKIM ([DKIM signing](/learn/dkim/), [RFC 6376](http://datatracker.ietf.org/doc/html/rfc6376)) is the one part of Workspace email authentication that does live in the Admin Console. The path is: 1. In the Google Admin Console, go to **Menu ▸ Apps ▸ Google Workspace ▸ Gmail**, then click **Authenticate email**. (You need the Gmail Settings administrator privilege and must be signed in as a super administrator.) 2. In the **Selected domain** menu, choose your domain, then click **Generate New Record**. Keep the default selector `google` and the recommended 2048-bit key length. 3. Publish the generated value as a TXT record at the host `google._domainkey` in your DNS. The value starts with `v=DKIM1`. 4. Return to the Admin Console and click **Start authentication** to switch on signing. Google is explicit here: "Do not click Start Authentication yet. You'll do that later" — only click it after the DNS record is published. 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](/blog/microsoft-dmarc-enforcement/) 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:dmarc@yourdomain.com`. 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](https://support.google.com/a/answer/2466580)). ### Step 1 — Determine your DMARC record Start with a monitoring record. For most Workspace admins the practical starter record is: 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](/tools/dmarc-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. | Host | Host-field label | Enter in host field | Value-field label | Quote the value? | | -------------- | ---------------- | ------------------- | ----------------- | ----------------------------------------- | | **Cloudflare** | Name | `_dmarc` | Content | No — Cloudflare adds the quotes for you | | **GoDaddy** | Name | `_dmarc` | Value | No — paste the raw string | | **Namecheap** | Host | `_dmarc` | Value | No — paste the raw string | | **Squarespace**| Name | `_dmarc` | Text | No — paste the raw string | | **AWS Route 53** | Record name | `_dmarc` | Value | Yes — wrap the value in double quotes | - **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](/tools/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. | Tag | Required? | What it does | | ------- | ----------- | ---------------------------------------------------------------------------- | | `v` | Required | DMARC version — must be `DMARC1`. Listed first. | | `p` | Required | Policy on failure: `none` (monitor) / `quarantine` (spam) / `reject`. | | `rua` | Recommended | Aggregate (XML) report address(es); must include `mailto:`. | | `ruf` | — | **Not supported by Gmail.** Google never sends forensic reports. | | `sp` | Optional | Subdomain policy for **existing** subdomains; falls back to `p` if omitted. | | `np` | Optional | Policy for **non-existent** subdomains; falls back to `sp`, then `p`. New in RFC 9989. | | `t` | Optional | Test mode (`y`/`n`, default `n`). `t=y` makes receivers apply one policy level lower — the rollout signal that replaced the removed `pct` tag. | | `adkim` | Optional | DKIM alignment: `s` strict, `r` relaxed (default). | | `aspf` | Optional | SPF alignment: `s` strict, `r` relaxed (default). | Gmail and Google Workspace send aggregate (`rua`) reports only — never forensic (`ruf`) reports. Including a `ruf` tag does nothing for Gmail. Rely on aggregate reports plus Google Postmaster Tools instead. {/* TODO (after 2026-06-15): link /blog/how-to-create-dmarc-record/ ("the protocol-agnostic DMARC record guide") here for the full tag reference. That post publishes AFTER this one — do not live-link before it goes live. */} ## 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](/tools/pnone-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](/blog/dmarc-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. | Verdict you see | Most likely cause | Fix | | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | **No DMARC record found** | Host isn't `_dmarc`; the domain doubled (`_dmarc.example.com.example.com`); record added at the wrong registrar/nameserver; not yet propagated; or a CNAME collides at `_dmarc`. | Confirm the FQDN resolves as exactly `_dmarc.yourdomain.com`; check your nameservers point where you edited; re-check after propagation; remove any CNAME at `_dmarc`. | | **DMARC policy not enabled** | The record exists but is `p=none` (monitor-only) — scanners collapse "no record" and "p=none" into one warning. | Confirm which state your DNS is actually in. If it's `p=none`, fix failing senders, then ramp to `quarantine` and `reject`. | | **`550 5.7.26` Unauthenticated email … DMARC policy** | A sender — often a third-party SaaS tool — fails _alignment_ even when SPF or DKIM "pass" for the vendor's own domain. | Set up that vendor's own DKIM for your domain plus its SPF include, so DMARC aligns on at least one mechanism. | 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](/tools/dmarc-failure-diagnoser/) maps a failing source to the specific record change that fixes it. (Google documents these cases on its [Troubleshoot DMARC](https://support.google.com/a/answer/10032578) 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:dmarc@yourdomain.com`. 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.