How to Set Up DMARC for Google Workspace in 2026

If your business runs on Google Workspace and you've ever had a customer say "I got a weird email from your domain that didn't look like you," you have a DMARC problem. Or more accurately: you don't have DMARC, and someone is using that gap to impersonate you.

This guide walks through DMARC setup for Google Workspace from scratch. By the end, you'll have a working DMARC record that protects your domain from impersonation, and you'll understand what the report data actually tells you.

What DMARC actually does (in 60 seconds)

DMARC is a DNS record that tells receiving mail servers what to do when an email claiming to be from your domain fails authentication. There are three possible outcomes you can dictate:

• none — Just monitor. Don't reject anything. This is where everyone starts.
• quarantine — Send failed emails to the recipient's spam folder.
• reject — Bounce failed emails entirely. Recipient never sees them.

DMARC works by checking two underlying authentication methods (SPF and DKIM) and verifying that at least one of them matches the visible "From" address. If neither aligns, the message fails DMARC, and your policy decides what happens.

The whole system only works if SPF and DKIM are set up correctly first. So we'll do those before touching DMARC.

Step 1: Verify SPF is correct

Google Workspace requires a specific SPF entry. Check your current SPF record using the DNS Tools on this site, or run:

dig TXT yourdomain.com +short | grep spf

You're looking for a TXT record at the apex of your domain (not at a subdomain) that includes Google's mail servers. The minimum-viable SPF record for a Google Workspace-only domain looks like this:

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

If you also send email through other services (Mailchimp, SendGrid, HubSpot, your CRM, your help desk), each one needs to be added as an include: entry. A real-world SPF record for a small business might look like:

v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org ~all

Common mistake #1: Multiple SPF records. SPF allows exactly one TXT record per domain. If you have two — one for Google, one for SendGrid — receivers will reject both. Merge them into one record with multiple include: entries.

Common mistake #2: Exceeding the 10-lookup limit. Each include: entry counts as one DNS lookup, and the includes themselves can have nested includes. Microsoft's _spf.protection.outlook.com alone uses 4 of your 10. If you blow past 10, the whole SPF check fails. SPF flattening tools like AutoSPF solve this by resolving the includes into static IP lists, which they update automatically.

Common mistake #3: Using +all or ?all. These mechanisms tell receivers "anyone can send for me." Use ~all (soft fail) for the first few weeks while you monitor, then move to -all (hard fail) once you're confident.

Step 2: Enable DKIM signing in Google Workspace

DKIM adds a cryptographic signature to outgoing mail that proves the email actually came from your domain. Google Workspace generates and rotates the keys for you — you just need to enable it and publish the public key in DNS.

In the Google Workspace admin console:

1. Navigate to Apps → Google Workspace → Gmail → Authenticate email
2. Select your domain from the dropdown
3. Click Generate new record
4. Choose 2048-bit key length (default and recommended)
5. Leave the prefix selector as google unless you have a specific reason to change it
6. Copy the generated TXT record — it'll look like a long string of letters and numbers prefixed with v=DKIM1; k=rsa; p=...

Now publish that TXT record in your DNS. The hostname is google._domainkey.yourdomain.com (the google part comes from the prefix selector you saw in step 5).

After the DNS propagates (usually 5-30 minutes, sometimes hours), return to the same admin console screen and click Start authentication. Google will verify your DKIM record is reachable and start signing all outgoing mail.

You can verify DKIM is working by checking the DKIM record on this site, or by looking at the headers of an email you've sent — there should be a DKIM-Signature header with d=yourdomain.com.

Step 3: Publish your DMARC record

Now the actual DMARC record. Add this TXT record to your DNS at the hostname _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r

Breaking that down:

• v=DMARC1 — required version tag
• p=none — start in monitor-only mode. Don't reject anything yet.
• rua=mailto:[email protected] — where aggregate reports get sent. You'll get one daily email per receiving domain that processed your mail.
• pct=100 — apply policy to 100% of mail. (Some guides recommend starting with 10%; in monitor mode this doesn't matter.)
• adkim=r and aspf=r — relaxed alignment. This is the right starting point.

Create the [email protected] inbox if it doesn't exist. The reports are XML files attached to emails, and you'll get hundreds per week if you have any meaningful email volume — don't use your personal inbox.

Step 4: Read the reports for 2-4 weeks

This is where most people quit, and where DMARC actually proves its value.

Aggregate reports tell you which servers are sending email claiming to be from your domain, broken down by SPF result, DKIM result, and DMARC result. After two weeks of data, you'll see things like:

• Your own Google Workspace mail (passes everything)
• Your CRM's mail (probably passes SPF, may not pass DKIM)
• Your transactional email service (depends on setup)
• Random servers in countries you've never heard of (these are the impersonators)

The reports come as XML which is essentially unreadable in raw form. You have three options for parsing them:

1. Free DMARC analyzers with limited monthly volume — Postmark's free tier handles up to 10,000 messages per month, which covers most small businesses
2. Paid DMARC platforms — EasyDMARC, PowerDMARC, dmarcian, Valimail — typically $30-200/month depending on volume and features
3. Self-hosted parsers — open source like parsedmarc, requires you to run infrastructure

For most small businesses, a paid platform pays for itself in time saved. The dashboards make it obvious which legitimate sources need fixing and which are impersonation attempts.

Step 5: Move to enforcement

After 2-4 weeks of monitoring, you should have a clean picture of your legitimate mail sources. Now it's time to graduate from p=none to actual protection.

The standard progression is:

p=none → p=quarantine pct=10 → p=quarantine pct=100 → p=reject pct=10 → p=reject pct=100

Spend at least a week at each step. Watch your reports for a sudden spike in legitimate mail being quarantined or rejected — that means you missed a sending source.

When you reach p=reject; pct=100, your domain is protected. Anyone trying to impersonate you in mail will be rejected outright by Gmail, Outlook, Yahoo, and every other major receiver that respects DMARC (which is essentially all of them in 2026).

Common pitfalls when moving to enforcement

Forwarding breaks SPF. When someone forwards an email from your domain, the forwarding server's IP isn't in your SPF record, so SPF fails. DKIM still passes if it's intact, which is why DKIM is critical — DMARC requires only one of the two to align.

Mailing lists rewrite the From header. Some old-school mailing list software rewrites your message in ways that break DKIM. For these, you'll need to either configure the list to preserve DKIM signatures or accept that those specific senders won't pass.

Subdomain policy. By default, your DMARC policy applies to the apex domain AND all subdomains. If you want different behavior for subdomains, use the sp tag. Most businesses should not need this.

Forensic reports (ruf). You can also request per-message failure reports with the ruf tag. These contain actual email content (with PII) and most providers don't send them due to privacy laws. Skip this tag unless you have a specific need.

What this looks like when it works

Once you're at p=reject with clean DMARC pass rates, three things happen:

1. Impersonation attempts fail silently. Nobody using your domain to phish your customers will succeed. Your customers won't see those emails.
2. Your legitimate email deliverability improves. Google, Microsoft, and Yahoo all weight DMARC-passing mail more favorably in inbox placement.
3. You're compliant with bulk-sender requirements. Google and Yahoo's 2024 bulk-sender requirements made DMARC mandatory for high-volume senders. The thresholds are dropping every year. Better to be ahead of this than scrambling.

What to verify after setup

• Your DMARC record is published and parses correctly
• Your SPF record is one record, under 10 lookups, with ~all or -all
• Your DKIM record returns a valid public key
• Aggregate reports are arriving at your dmarc@ mailbox
• After 4 weeks, your DMARC pass rate from Google Workspace is 100%

If any of those fail, fix them before moving to p=quarantine or p=reject. Premature enforcement breaks legitimate mail and is the most common DMARC mistake.

---

Have a domain to test? Run a free DMARC check right now to see your current configuration.