How to Set Up DMARC for Google Workspace (Gmail)

DMARC for Google Workspace (Gmail) tells receiving servers what to do when emails from your domain fail SPF or DKIM checks, whether to quarantine, reject, or just report on them. Google Workspace handles outbound delivery and DKIM key generation, but it does not publish a DMARC record for you. That part is a DNS record you set up yourself, and it’s the only thing standing between your domain and spoofing attacks.

Since Google’s 2024 bulk sender requirements, DMARC is no longer optional for high-volume senders – any domain sending 5,000 or more messages a day to Gmail must have a valid DMARC record or risk rejection.

If you’re looking for how to set up DMARC for Gmail specifically, the process is the same: Gmail uses Google’s mail infrastructure, so the setup steps below apply whether you’re on a personal Google Workspace plan or sending through Gmail for business. This guide covers everything you need – SPF and DKIM prerequisites, the exact record to publish, a breakdown of every tag, and a step-by-step path from monitoring (p=none) to full enforcement (p=reject), including record examples and the common mistakes that break mail flow along the way.

What Is DMARC, and Why Does Google Workspace Need It?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS-based email authentication standard that ties together SPF and DKIM, tells receiving servers how to handle messages that fail those checks, and sends you reports on who is using your domain to send mail.

Here’s the part people miss: Google Workspace secures the transport. It encrypts connections with TLS, filters inbound spam, and delivers your outbound mail reliably. But DMARC is a domain-level control that only the domain owner can set up. Google doesn’t publish a DMARC record for you, and no amount of Google-side spam filtering stops an attacker from spoofing your domain to send phishing emails to other people. That gap is exactly what DMARC closes.

It also stopped being optional. Under Google’s bulk-sender requirements that rolled out in February 2024 and continue to ramp up, any domain sending 5,000 or more messages per day to Gmail addresses must publish a DMARC record, or Google will start rejecting the mail. Even below that threshold, DMARC is now the baseline expectation for good deliverability. 

If you want the full conceptual explainer, see our detailed guide on what is DMARC. 

Prerequisites: Set Up SPF and DKIM First

DMARC doesn’t authenticate mail on its own. It sits on top of SPF and DKIM and enforces the result. For DMARC to pass, at least one of them must pass and align with your domain. So before you publish a DMARC record, get these two in place. Below are the compact versions; each links to the full walkthrough.

SPF for Google Workspace (Quick Setup)

SPF is a single TXT record at your root domain that lists the servers allowed to send mail for you. For Google Workspace, the essential record is:

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

v=spf1 opens the record, include:_spf.google.com authorizes Google’s mail servers, and ~all soft-fails everything else. If you send through additional services, add their includes to the same record (never create a second SPF record):

v=spf1 include:_spf.google.com include:servers.mcsv.net include:sendgrid.net ~all

For the complete deep-dive on flattening, lookups, and edge cases, see our full SPF record for Google Workspace guide.

DKIM for Google Workspace (Quick Setup)

DKIM adds a cryptographic signature to your outbound mail. Google Workspace generates the key for you; you publish it in DNS:

1. In the Admin Console, go to Apps → Google Workspace → Gmail → Authenticate Email.
2. Select your domain and click Generate New Record (2048-bit is recommended).
3. Copy the TXT record Google produces. This will be a host/name like google._domainkey and a long value beginning with v=DKIM1; k=rsa; p=….
4. Publish that TXT record at your DNS host.
5. Return to the Admin Console and click Start Authentication.

The record looks like this:

Host/Name:  google._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

For the complete walkthrough, view how to set up DKIM for your domain.

Note: Google Workspace handles DKIM signing (you generate the key in the Admin Console) and SPF is a DNS record you publish yourself, but Google does not create or publish a DMARC record for your domain. That part is entirely on you, and it's what the rest of this guide covers.

How to Set Up a DMARC Record for Google Workspace

With SPF and DKIM live, you’re ready for DMARC. Here’s the full process, step by step.

Step 1: Build Your DMARC Record

A DMARC record is a single TXT entry made up of tags. A simple starter record looks like this:

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

You can build this visually with our DMARC generator, which assembles the syntax for you. Here’s what each tag does:

• v: is used to define the protocol version which is always DMARC1. This is a mandatory tag
• p: is used to define the DMARC policy mode, which is also a mandatory tag. 
• rua: is used to designate the aggregate reporting address. This is an optional tag but is highly recommended to monitor authentication results. 

Note: The one tag people misread is p. p=none, which is the starting point, not the end state, as it only monitors and reports, it doesn't protect anything yet. The goal is to reach p=reject without breaking mail flow.

Step 2: Publish the Record in DNS

DMARC goes in your DNS, at your domain registrar or DNS host, and not in the Google Admin Console. DMARC is a DNS record, not a Google Workspace setting. In your DNS panel, add:

Save it. DNS propagation can take up to 48 hours, though it’s usually much faster often within an hour.

Step 3: Verify Your DMARC Record

Once published, confirm it resolves correctly with our DMARC record checker. A successful check returns your record and confirms the syntax is valid. For example, it will show the policy detected as p=none, a valid rua reporting address, and no syntax errors. If the checker can’t find the record, give DNS more time to propagate or double-check the host/name field.

Step 4:Monitor Reports Before Enforcing

With p=none live, Google and other receiving servers begin sending aggregate (RUA) reports to the address in your RUA tag. These show every source sending mail as your domain and whether each one passes or fails SPF and DKIM alignment.

What you’re looking for: legitimate sources that are failing. A marketing platform, CRM, help-desk tool, or invoicing service you actually use might be failing alignment because its SPF or DKIM isn’t set up under your domain yet. Fix those before you enforce, otherwise moving to quarantine or reject will start blocking your own mail. 

Since raw DMARC XML is hard to read, you can use our How to Read DMARC Reports guide to interpret them. It’s best practice to plan on a monitoring window of 2-4 weeks minimum, so you capture your full sending cycle.

Step 5: Move to Enforcement (p=quarantine, then p=reject)

Once your reports show every legitimate sender passing, tighten the policy in stages:

1. p=none → p=quarantine: failing mail lands in spam instead of the inbox. Watch the reports again.
2. p=quarantine → p=reject: failing mail is blocked outright. This is where real anti-spoofing protection kicks in.

For an even safer rollout, use the t (t=y) tag to test your policy before committing to maximum enforcement.  Learn more about choosing and progressing your enforcement level in our DMARC policy guide.

Google Workspace DMARC Record Examples

Three ready-to-copy records for the stage you’re at. Replace the email addresses with your own.

Basic Monitoring (Getting Started)

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

Quarantine with Reporting

v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r;

Full Enforcement

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s;

Note: the strict alignment here (adkim=s, aspf=s) requires the domain in the DKIM signature or SPF to match your sending domain exactly, with no subdomains. Relaxed (r) allows subdomains to align. Example mail from mail.yourdomain.com still aligns with yourdomain.com. Use relaxed while you're stabilizing, and only switch to strict once you're certain every legitimate sender uses your exact domain.

Common Google Workspace DMARC Mistakes

Publishing DMARC Without SPF or DKIM in Place

DMARC has nothing to enforce if neither SPF nor DKIM passes and aligns. Publishing DMARC first, especially at quarantine or reject means your own mail can start failing. Always get SPF and DKIM working, then layer DMARC on top.

Staying on p=none Indefinitely

p=none only watches; it blocks nothing. A lot of domains publish it, see the reports arrive, and never progress. Spoofers are unaffected until you reach p=reject. Treat none as a temporary monitoring phase, not a destination.

Missing Third-Party Senders in SPF/DKIM

Marketing tools, CRMs, ticketing systems, and invoicing services all send “as you.” If they aren’t authorized in your SPF include list or signing with aligned DKIM, they’ll fail DMARC, and their mail will be blocked once you enforce. Use your monitoring reports to catch everyone before tightening the policy.

Using the Wrong DNS Host Name

The most frequent syntax error is putting _dmarc in the record’s value field instead of the host/name field, or forgetting the leading underscore entirely. The host/name must be _dmarc (resolving to _dmarc.yourdomain.com); the value is the v=DMARC1; … string.

Having Multiple DMARC Records on One Domain

A domain may have exactly one DMARC record. Two or more _dmarc TXT records cause receivers to ignore DMARC altogether, disabling your protection. If you’re updating the record, edit the existing one instead of adding a second.

How PowerDMARC Simplifies DMARC for Google Workspace

Manual DMARC works, but the ongoing part, like reading raw XML reports, spotting failing senders, and safely progressing from none to reject, is where most domains stall.

PowerDMARC turns those XML reports into human-readable dashboards, gives you hosted DMARC so you can update your policy without touching DNS each time, guides you through automated enforcement progression, and sends real-time alerts the moment a new source starts sending as your domain, so you reach full p=reject protection faster and without breaking legitimate mail.

Frequently Asked Questions

1. Does Google Workspace have DMARC built in?

No. Google Workspace handles transport security, spam filtering, and DKIM key generation, but it does not create or publish a DMARC record for you. DMARC is a DNS record that the domain owner must publish separately.

2. How do I add a DMARC record to Google Workspace?

You don’t add it in the Admin Console, you publish it as a TXT record at your DNS host with the host/name _dmarc and a value like v=DMARC1; p=none; rua=mailto:[email protected].

3. What is the correct DMARC record for Google Workspace?

Start with v=DMARC1; p=none; rua=mailto:[email protected] for monitoring, then progress to p=quarantine and finally p=reject once your legitimate senders pass.

4. Do I need SPF and DKIM before setting up DMARC?

Yes. DMARC enforces the results of SPF and DKIM, so at least one must be in place and aligned before DMARC can pass. It’s recommended to set up both before implementind DMARC . 

5. What does p=none mean in a DMARC record?

p=none is monitoring mode. Receivers report on mail that fails, but take no action against it. It’s the safe starting point, but it does not protect until you move to quarantine or reject.

6. How long does it take for a DMARC record to start working?

The record can propagate in as little as a few minutes, though DNS changes may take up to 48 hours. Aggregate reports typically begin arriving within a day or two.

7. Why are my Google Workspace emails still failing DMARC?

Usually this happens because a legitimate sender (often a third-party service) isn’t authorized in your SPF record or isn’t signing with aligned DKIM. You can check your aggregate reports to identify the failing source and fix its alignment.

8. Is DMARC required for Google’s bulk sender guidelines?

Yes. Under Google’s bulk-sender requirements, domains sending 5,000 or more messages per day to Gmail must have a valid DMARC record, or their mail may be rejected. You can view our Google and Yahoo compliance guide for more details.

• About
• Latest Posts

Ahona Rudra

Domain & Email Security Expert at PowerDMARC

Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.

Latest posts by Ahona Rudra (see all)

• How to Perform an Email Analysis (2026 Guide) - July 28, 2026
• Introducing DNS Takeover Alerts: Closing the Gap DMARC Cannot Cover - July 27, 2026
• Best DMARC AI Tools in 2026: Which Providers Actually Use AI (and How) - July 27, 2026