DMARC for Google Workspace: set up SPF, DKIM and DMARC

Google Workspace and DMARC: what Google signs and what you publish

Google's set-up pages split the work clearly. Nothing about DMARC is configured inside Google Workspace: as Google's Set up DMARC (opens in a new tab) page puts it, "You don't need to do anything in your Google Admin console to set up DMARC." The only step inside the Admin console is generating your DKIM (opens in a new tab) key.

Order matters. Google says to turn on SPF and DKIM before DMARC, and to let them authenticate for at least 48 hours before you publish the DMARC record. If the domain was bought during Google Workspace sign-up, SPF and DKIM may already be set up, so check what is there first with our DMARC checker.

SPF for Google Workspace

Google's Set up SPF (opens in a new tab) page lists ready-made records for common combinations. Use the one that matches every service that sends as your domain:

Points from Google's page worth knowing:

• List every sender. Web servers, on-premises mail servers, outbound gateways, "Contact us" forms and any third-party service that sends for your domain all need to be in the record
• ~all is Google's recommendation. It tells receivers to mark mail from unlisted servers as spam
• Mind the limit. Google's page says an SPF record can have up to 10 include tags. The underlying rule (RFC 7208) is 10 DNS lookups in total, so nested includes and a, mx and redirect mechanisms all count
• One record per domain, one per subdomain. Each domain and each sending subdomain needs its own SPF record
• Allow time. SPF can take up to 48 hours to start working

DKIM in the Admin console

DKIM is where Google Workspace needs the Admin console. You must be signed in as a super administrator, and Google's Set up DKIM (opens in a new tab) page warns that after Gmail is turned on for your organisation you may need to wait 24 to 72 hours before a key can be generated.

1. In the Google Admin console, go to Menu, Apps, Google Workspace, Gmail, then Authenticate email
2. Choose the domain in the Selected domain menu and click Generate New Record
3. Pick a key length of 2048 bits if your DNS host supports it (1024 if it does not) and keep the default prefix selector, google, unless that selector is already in use
4. Copy the DNS host name and TXT record value. Do not click Start authentication yet
5. At your DNS host, add a TXT record with the host google._domainkey and the value in the form v=DKIM1; k=rsa; p= followed by your key
6. Allow up to 48 hours, then return to Authenticate email and click Start authentication. The status changes to "Authenticating email with DKIM"
7. Check it: send a message to someone else on Gmail or Google Workspace (Google says you can't verify by sending to yourself) and look for DKIM=pass in the Authentication-Results header

Each domain needs its own key from the Admin console. If you use an outbound gateway that adds footers or otherwise changes messages, check it does not break the signature.

Adding the DMARC record

Google recommends a group or dedicated mailbox for reports, because a busy domain can receive many reports a day, or a third-party service that specialises in DMARC reports. Its recommended rollout (opens in a new tab) is to start at p=none for a week, review the reports daily, then move to quarantine and, if you choose, reject.

Google's pages still show the pct tag for a gradual start (for example p=quarantine; pct=5). RFC 9989 (opens in a new tab), published in May 2026, made pct historic and added t=y for testing a stricter policy, although Google and Microsoft still document pct. t=y is new in RFC 9989: receivers that have not adopted it ignore the tag and apply quarantine in full, so only publish the t=y stage once your reports show every genuine sender passing. Some other details from Google's tag reference (opens in a new tab):

• rua: optional, but Google recommends you always include it. To send reports to an address in a different domain, that domain must publish a DNS record authorising them
• ruf: Gmail does not support failure reports
• adkim and aspf: relaxed alignment is the default and, in Google's words, "typically provides sufficient spoofing protection"; strict alignment can send mail from your own subdomains to spam
• BIMI: if you want your logo shown in Gmail, the policy must be quarantine or reject

Our DMARC generator builds the record for you.

When a scanner says "DMARC policy not enabled"

Security ratings, domain scanners and email health checks often flag Workspace domains with "DMARC policy not enabled" or "DMARC quarantine/reject policy not enabled". It means the domain either has no DMARC record or is still at p=none, so receivers are not asked to act on spoofed mail. It does not mean your Google Workspace mail is broken.

The fix is to move to quarantine once your reports show every genuine sender passing, not to jump straight to reject. The DMARC policy not enabled guide walks through it, and DMARC policy explains how to choose the end state for each domain.

Google's sender guidelines and your Workspace domain

Google's bulk sender rules are about mail to personal Gmail accounts. Its sender guidelines FAQ (opens in a new tab) says they "don't apply to messages sent to Google Workspace accounts", but that "all senders, including Google Workspace users, must meet the requirements" when sending to personal Gmail accounts. So a Workspace domain that sends newsletters, invoices or notifications to customers on gmail.com is in scope.

Senders of close to 5,000 or more messages a day to personal Gmail accounts must have SPF, DKIM and DMARC (p=none is enough) with the From domain aligned. The full comparison with Yahoo and Outlook.com is in Gmail, Yahoo and Outlook.com DMARC requirements.

Postmaster Tools (opens in a new tab) shows spam rate, reputation, authentication and delivery errors for mail you send to personal Gmail accounts. You add the domain you authenticate with (the DKIM d= domain or the SPF Return-Path domain) and verify it with a TXT or CNAME record.

Third-party senders and moving to enforcement

For any service that sends as your domain, Google's DMARC page gives three options: ask the provider to set up SPF and DKIM correctly, make sure its envelope sender domain matches yours and add its servers to your SPF record, or route its mail through Google using the SMTP relay service. The DMARC for email marketing platforms guide covers Klaviyo, Mailchimp and Mailgun.

The platforms we supply work with Google Workspace domains:

• Valimail says it has full integration with Google Workspace (why Valimail (opens in a new tab)), and its free Monitor (opens in a new tab) includes a check against Google, Microsoft and Yahoo's DKIM, SPF and DMARC requirements
• EasyDMARC lists Google Workspace among its sending platform integrations (opens in a new tab), Google Postmaster as a reputation source, and Google Chat for alerts
• Check Point DMARC Management (opens in a new tab) collects reports in a hosted RUA mailbox and gives per-domain recommendations for moving to a restrictive policy

Whichever you use, the reports tell you when each sender passes and the domain is ready for the next policy step. The DMARC report analyser guide shows what to look for.

How we help with DMARC on Google Workspace

We can check your Workspace domains' SPF, DKIM and DMARC records, set up reporting so you can see every sender, help you choose and supply EasyDMARC, Valimail or the Check Point DMARC Management add-on, and work with you through each step to quarantine or reject.

EasyDMARC and Valimail licences can be billed monthly, with terms confirmed at quote. Ask us for a quote, or contact us for free advice.