How to set up DMARC on Google Workspace

Add a DMARC record in your DNS to tell receivers what to do with email that fails your SPF and DKIM checks.

Why this matters to your business

DMARC is the policy that ties SPF and DKIM together. It tells receiving mail servers what to do when an email claiming to be from your domain fails those checks — ignore it, send it to spam, or reject it outright — and it can email you reports showing who is sending (and forging) mail as you. In plain terms: DMARC is what actually stops criminals from impersonating your domain to scam your customers and staff. It’s free, and it turns SPF and DKIM from “nice to have” into real protection.

Do SPF and DKIM first

DMARC depends on SPF and DKIM. Set those up before, or alongside, DMARC. A DMARC record on its own — with no working SPF/DKIM — can cause your own legitimate email to be blocked. Start gently (see the policy note below) and tighten over time.

Important: where this gets done

Like SPF, DMARC is a DNS record, not a setting inside the Google Admin console. Google Workspace runs your email, but the DMARC record is added wherever your domain’s DNS lives — your registrar, web host, Cloudflare, or whoever controls your nameservers. There’s nothing to switch on inside Google for DMARC; Google’s part is simply that working SPF and DKIM (set up separately) are what DMARC relies on.

First: which company runs your DNS?

A DMARC record only works if it’s added wherever your domain’s nameservers point. If you’re not sure, check the Nameservers section in your registrar account, or ask whoever set up your website. Add the record in that company’s DNS settings (look for DNS / Records / Advanced DNS).

What you’ll add

A single TXT record at a special host name: _dmarc.

A safe starting value, which only monitors and never blocks anything, is:

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

p=none = monitor only; nothing gets blocked yet. Good for the first few weeks.
rua=mailto:... = where the summary reports are sent. Use a real mailbox you check.
Once you’ve confirmed (via the reports and the free check) that your genuine mail passes, you can tighten the policy to p=quarantine (send fails to spam) and later p=reject (refuse fails outright).

Steps

Sign in to your DNS host (your registrar, web host, or DNS provider — not the Google Admin console).
Open the DNS settings for your domain (look for DNS / Records / Advanced DNS).
Add a new record and choose TXT.
In the Name / Host field, enter exactly _dmarc (with the leading underscore). Do not type _dmarc.yourdomain.com — the DNS host appends your domain automatically.
In the Value field, paste your DMARC string, e.g. v=DMARC1; p=none; rua=mailto:[email protected] (replace the email with a real address you monitor).
Leave TTL at the default.
Save.

Quirks people get wrong

It’s not in the Google Admin console. People hunt through Google’s settings for “DMARC” — it isn’t there. It belongs in your DNS host.
The host name is _dmarc, with the underscore. Leaving off the underscore, or typing the full domain after it, puts the record in the wrong place and DMARC won’t be found.
Watch the quoting. Paste the value plain; most DNS hosts add the quoting for you. Don’t wrap it in "..." yourself.
Only one DMARC record. There should be exactly one TXT record at _dmarc. If one already exists, edit it rather than adding a second.
Start with p=none. Jumping straight to p=reject before SPF/DKIM are solid can block your own invoices and quotes. Monitor first, tighten later.
Use a real reporting mailbox. The rua address must be one you can actually receive at.
Allow time. DNS changes can take from minutes up to a couple of hours to take effect everywhere.

Verify it worked

Once saved, confirm your DMARC record is live and sensible with the free check on Defaults.Exposed. Enter your domain and it’ll tell you in plain language whether DMARC is set up correctly and what to do next. Your data is processed in the EU.

Done? Check your domain free to confirm it worked — and see your full grade across all 34 checks.