DMARC for Google Workspace

8 June 2026 · 13 min read

If you send email from a domain on Google Workspace, your messages already pass through some of the best-run mail infrastructure on the internet. That does not mean your domain is protected. By default a new Google Workspace domain has no DKIM signing turned on, an SPF record you have to add yourself, and no DMARC policy at all. Until you fix those three things, anyone can put your domain in the From address of a phishing email and most receivers will deliver it.

This guide walks through the exact sequence for a Google Workspace domain: get SPF right, switch on DKIM properly, then publish DMARC and ratchet it from monitoring to full enforcement without breaking a single legitimate message. It assumes you control your domain's DNS, whether that lives in Cloudflare, Google Domains, GoDaddy, Namecheap or anywhere else. The DNS host barely matters. What matters is the order you do things in and how you read the evidence before you tighten the screws.

Why Google Workspace does not protect you out of the box

Google Workspace handles authentication for inbound mail extremely well. The confusion is that people assume the same protection covers their outbound domain. It does not. Authentication on the sending side is a set of DNS records you publish, plus a signing key you activate in the Admin console. Google cannot publish those records for you because they live in your DNS, not Google's.

Three mechanisms work together:

• SPF lists the servers allowed to send mail for your domain. For Google Workspace that means authorising Google's sending infrastructure with include:_spf.google.com.
• DKIM attaches a cryptographic signature to every outbound message, proving it was not altered and that it genuinely came from an authorised sender. Google Workspace can sign your mail, but only after you generate a key and publish it.
• DMARC ties the two together. It tells receivers what to do when a message claims to be from your domain but fails both SPF and DKIM alignment, and it asks them to send you reports so you can see who is sending as you.

Skip any one of these and you have gaps. Skip DMARC and you have no enforcement and no visibility. Google itself, alongside Yahoo, now requires a DMARC policy for anyone sending in bulk to their users, so this is no longer optional for serious senders. See /requirements for the current bulk-sender thresholds and what counts as compliant.

If you want a fast read on where your domain stands before you change anything, run it through the DMARC checker, the SPF checker and the DKIM checker. Those three results tell you exactly which of the steps below you still need.

Step 1: get SPF correct for Google Workspace

SPF is a single TXT record at the root of your domain. For a domain that sends only through Google Workspace, the minimal correct record is:

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

That include expands at lookup time into Google's published ranges, so you never hardcode IP addresses. The ~all at the end is a soft fail, which tells receivers that anything not listed is suspicious but should not be hard-rejected on SPF alone. Once DMARC is enforcing you can move to -all (hard fail), but start with ~all so you do not accidentally bounce legitimate mail while you are still discovering all your senders.

The rules people get wrong

There are a few mistakes that quietly break SPF, and they are worth stating plainly.

• One SPF record only. A domain may publish exactly one TXT record starting v=spf1. If you have two, for example one from a previous email provider and one for Google, SPF returns a permerror and everything downstream fails. Merge them into a single record.
• Ten DNS lookups maximum. SPF allows at most ten DNS lookups during evaluation. include:_spf.google.com alone uses several, because it nests further includes. Add a payroll tool, a CRM, a newsletter platform and a help desk, each with its own include, and you blow past the limit, which produces a permerror that makes everything fail. This is the single most common SPF failure for growing companies. The glossary entry on the 10-lookup limit explains the mechanics.
• Order and overlap do not matter, count does. Receivers do not stop at the first match in a useful way for your purposes; what bites you is the lookup count, not the order.

Add every legitimate sender, not just Google

The whole point of SPF is to list everyone who sends on your behalf. If you use Mailchimp, SendGrid, a Salesforce org, Zendesk, Xero or any third party that sends from your domain, each needs its own authorisation, normally another include:. A realistic record might look like:

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

That example already uses a lot of your lookup budget. If you are close to ten, SPF flattening replaces the nested includes with the resolved IP ranges so the whole thing counts as fewer lookups. We do this automatically as part of the hosted SPF product, and you can read the trade-offs at /glossary/spf-flattening. To see your current lookup count and whether you are over budget, the SPF checker counts them for you.

When you are ready to build or rewrite the record from scratch, the SPF generator produces a valid single record from a checklist of your senders.

Step 2: turn on DKIM in Google Workspace

This is the step most people miss entirely, because Google Workspace does not enable DKIM signing by default. Without it, your mail is signed only with a generic Google key that does not align to your domain, which is not enough for DMARC.

Here is the process inside the Admin console.

1. Sign in to the Google Admin console at admin.google.com with a super administrator account.
2. Go to Apps, then Google Workspace, then Gmail, then Authenticate email.
3. Select the domain you want to sign for from the drop-down. If you have multiple domains, you do each one separately.
4. Click Generate new record. Choose the 2048-bit key length if your DNS provider supports the longer TXT value, which almost all now do. Leave the default prefix selector of google unless you have a reason to change it.
5. Google shows you a DNS host (something like google._domainkey) and a long TXT value beginning v=DKIM1; k=rsa; p=....
6. Add that TXT record to your DNS exactly as shown. The host is google._domainkey.yourdomain.com.
7. Wait for DNS to propagate. This can take minutes to a few hours depending on your provider and TTL. You can watch propagation with the DNS propagation checker.
8. Return to the Authenticate email screen and click Start authentication. Google verifies the published key and begins signing your outbound mail.

A note on the 2048-bit key and long TXT values

Some older DNS interfaces refuse TXT values longer than 255 characters, and a 2048-bit DKIM key exceeds that. The fix is to split the value into multiple quoted strings within the one record; most modern DNS panels do this automatically, but if your provider rejects the value you may need to split it manually or, as a fallback, generate a 1024-bit key. Prefer 2048 where you can. The glossary entry on the DKIM selector explains why the google._domainkey host is structured the way it is.

Verify the signature is actually applied

Do not trust the Admin console alone. After you click Start authentication, send a test message to an external address you control, open the raw headers, and look for a DKIM-Signature header with d=yourdomain.com and s=google. If the d= value is your domain, alignment will work. You can confirm the published key directly with the DKIM checker by entering your domain and the google selector. For the deeper how-and-why of signing, the DKIM product page and the DKIM record guide go further.

If you ever need to rotate the key, generate a new selector before retiring the old one so there is no signing gap. See /glossary/dkim-key-rotation.

Step 3: understand alignment before you publish DMARC

DMARC does not simply ask whether SPF or DKIM passed. It asks whether they passed and aligned with the domain in the visible From address. This is the concept that trips up almost everyone, so it is worth slowing down.

• SPF alignment compares the domain in the hidden Return-Path (the envelope sender) against your From domain. For Google Workspace mail sent directly, these align. But mail sent through a third party often uses that third party's bounce domain in the Return-Path, so SPF can pass for the third party while failing to align with your From domain.
• DKIM alignment compares the d= domain in the DKIM signature against your From domain. This is why getting the Google DKIM key signing with d=yourdomain.com matters so much: it gives you an aligned pass even when SPF does not align.

A message passes DMARC if either SPF aligns or DKIM aligns. You only need one. That redundancy is exactly why you set up both: forwarding frequently breaks SPF, but a correctly applied DKIM signature usually survives forwarding intact. With both in place, normal Google Workspace mail almost always produces at least one aligned pass. The /glossary/dmarc-alignment entry has worked examples if you want to see the comparisons spelled out.

Step 4: publish DMARC at p=none and watch

Now publish your first DMARC record. Crucially, start at p=none. This is monitoring mode: it changes nothing about how your mail is delivered, but it switches on the reporting that tells you who is sending as your domain. Never jump straight to enforcement, because you cannot see what you would break until the reports arrive.

A sensible starting record, published as a TXT record at the host _dmarc.yourdomain.com, is:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1; adkim=r; aspf=r

What each part does:

• p=none is the policy: monitor only, take no action.
• rua=mailto:... is where aggregate reports are sent. These are daily XML summaries from each receiver.
• fo=1 requests failure reporting when either authentication mechanism fails, which gives you finer-grained diagnostics where supported.
• adkim=r and aspf=r set relaxed alignment, which allows subdomains to align with the organisational domain. Relaxed is the right default; only move to strict (s) if you have a specific reason.

You can build a record tailored to your situation with the DMARC generator, and the DMARC record guide walks through every tag. Confirm it is live and syntactically valid with the DMARC checker.

A real-world reporting address problem

Aggregate reports are XML, and a busy domain can receive dozens a day from Google, Microsoft, Yahoo and others. Pointing rua at a human inbox means you will drown in unreadable XML and learn nothing. Point it at a parsing service instead. You can drop individual reports into the DMARC report analyzer to read one by hand, but for an ongoing picture you want continuous monitoring that aggregates every report into a single view of your senders, pass rates and alignment. That is what /monitor and the analytics product do.

Step 5: read the reports and fix the gaps

Leave the domain at p=none for two to four weeks. During that window the aggregate reports build a picture of every source sending mail that claims to be from your domain. You are looking for three categories.

1. Your known Google Workspace mail, which should show DKIM aligned, SPF aligned, or both. If your direct Gmail traffic is failing alignment, something is wrong with the DKIM setup from Step 2, and you fix that before going further.
2. Legitimate third-party senders you forgot about. This is the real value of monitoring. Almost every organisation discovers a forgotten newsletter tool, an old marketing platform, a billing system or a departmental app still sending as the domain. Each one needs either an SPF include, its own DKIM signing set up with that vendor, or both. Work through them one at a time until each shows an aligned pass.
3. Genuine spoofing and abuse, which is mail you do not recognise failing authentication from servers you do not control. This is precisely what DMARC enforcement will stop, but you cannot block it safely until the first two categories are clean.

The discipline here is simple: do not advance the policy until every legitimate sender in your reports is producing an aligned pass. Enforcement does not care about your intentions; it acts on alignment. Anything legitimate that is still failing when you move to enforcement will be quarantined or rejected.

Step 6: ratchet to quarantine, then reject

Once your reports show legitimate mail passing cleanly and the only failures are mail you do not recognise, start tightening. Do it in stages, and use the pct tag to roll out gradually so you can sample the effect on a fraction of traffic first.

A measured progression looks like this:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com

That sends a quarter of failing mail to spam while leaving the rest unchanged. Watch the reports for a week. If nothing legitimate is being caught, raise pct to 50, then 100:

v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc@yourdomain.com

Sit at full quarantine for a couple of weeks, keep watching, and when you are confident, move to the final policy:

v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com

At p=reject, mail that fails DMARC is refused outright at the receiving server, never reaching the inbox or the spam folder. This is the goal. It is the policy that actually stops someone spoofing your domain, and it is the policy Google and Yahoo's bulk-sender rules are pushing everyone towards. The /how/enforce overview covers the staged rollout in more depth.

When you reach reject, you can also tighten SPF from ~all to -all with confidence, because by now you know every legitimate sender is accounted for.

Subdomains need their own thinking

Your DMARC policy can govern subdomains through the sp tag. If you do not set sp, subdomains inherit the p policy. Some organisations send all their bulk mail from a subdomain like mail.yourdomain.com precisely so it can be governed separately. If you have subdomains that never send mail, an explicit sp=reject shuts down a common spoofing route. See /glossary/subdomain-policy-sp.

Common Google Workspace gotchas

A few issues come up again and again on Workspace domains specifically.

• Google Groups and aliases. Mail sent to a Google Group and redistributed can break SPF alignment, but DKIM normally survives, which is another reason DKIM is non-negotiable. Watch your reports for group traffic and confirm it is passing on DKIM.
• The "Send mail as" feature. If users send from external addresses through Gmail's "Send mail as" setting, that mail is sent through Google but with a different From domain, which can show up in another domain's DMARC reports. Make sure each domain involved is authenticated.
• Aliased domains. If you added a domain as an alias rather than a separate Workspace domain, it shares the primary domain's setup, but it still needs its own DMARC record published at its own _dmarc host. DMARC is never inherited across separate registrable domains.
• Forgetting the test loop. After every DNS change, give propagation time and re-check rather than assuming. The DNS record checker and DNS propagation checker save you from chasing phantom failures caused by stale caches.

Optional next step: BIMI and a verified logo

Once you are at p=reject with DKIM aligned, you have unlocked the prerequisite for BIMI, which displays your brand logo next to authenticated mail in supporting clients, including Gmail. Gmail requires a Verified Mark Certificate for display, but the authentication groundwork you have just laid is the hard part. If a logo in the inbox interests you, see the BIMI product page and the BIMI checker. It is genuinely a reward for getting authentication right, not a separate project.

The practical takeaway

For a Google Workspace domain the path is the same every time. Publish one correct SPF record with include:_spf.google.com and every other sender, keeping under ten lookups. Turn on DKIM in the Admin console with a 2048-bit key and confirm the signature aligns to your domain. Publish DMARC at p=none, point the rua at a real monitoring service, and read the reports until every legitimate sender passes with alignment. Then ratchet through quarantine with pct, and finish at p=reject. Done in that order, you reach full enforcement with no email outage and a domain that can no longer be spoofed.

If you would rather not babysit XML reports and DNS edits for a month, that is exactly the work we take off your plate. The hosted DMARC product sets up SPF, DKIM and MTA-STS, manages the staged rollout to reject, and gives you continuous monitoring with alerts when anything changes. To start right now for free, run your domain through the DMARC checker and see exactly which of the steps above you still need.