How to Set Up SPF, DKIM and DMARC for Google Workspace

Spoofed mail sent in your name damages your domain's reputation, and mail from a domain with no authentication is more likely to land in spam. SPF, DKIM, and DMARC are three DNS-based checks that close that gap. You publish them in two places: the Google Admin console (DKIM only) and your domain host's DNS settings (all three).

Set them up in this order: SPF, then DKIM, then DMARC. DMARC depends on the other two, so it goes last.

Why does email authentication matter for Google Workspace?

SPF lists the servers allowed to send mail for your domain. DKIM signs each outgoing message so receivers can verify it. DMARC tells receivers what to do when a message fails both checks. Together they block spoofing and make Gmail less likely to reject or spam-mark your mail.

The requirements are not optional if you email Gmail users. Gmail's sender guidelines require every sender to set up SPF or DKIM. Anyone sending more than 5,000 messages per day to Gmail accounts must set up SPF, DKIM, and DMARC. Even if you send far less, setting up all three is worth it, because authenticated messages are less likely to be rejected or marked as spam.

Before you touch DNS, check what already exists. Some domains already have SPF and DKIM configured by default, particularly when the domain was bought from a Google partner during Workspace signup. Run your domain through any free SPF, DKIM, and DMARC lookup tool. If a record exists, edit it instead of adding a second one. Two SPF records on one domain is a common way to break authentication.

Check: A lookup tool shows you either no records or the exact records you're about to replace.

Step 1: Set Up SPF for Your Domain

Add one SPF TXT record to your domain that lists every server sending mail as you. If you send only through Google Workspace, the record is v=spf1 include:_spf.google.com ~all. If anything else sends as your domain, add its include entry too.

Identify every sender

Start by listing what sends mail with your domain in the From address. Google's SPF setup page names the usual suspects:

• Web servers

• On-premise mail servers such as Microsoft Exchange

• Mail servers used by your hosting provider

• Outbound gateways

• Services that send automatic email, such as "Contact us" forms

• Any third-party provider that sends for your domain

Ask your web admin and check each third-party tool's email settings. Missing one sender is the classic mistake, and it shows up weeks later as a marketing platform whose messages start landing in spam.

Build the record

Every SPF record starts with v=spf1. Put an include: tag in front of each sender's domain or IP address. A record can hold up to 10 include: tags. The ~all at the end tells receivers to treat mail from unlisted servers as suspect, and Google recommends it.

Here are the records Google gives for common combinations:

You send with	SPF record
Google Workspace only	v=spf1 include:_spf.google.com ~all
Google Workspace and Mailchimp	v=spf1 include:_spf.google.com include:servers.mcsv.net ~all
Google Workspace and Microsoft Office 365	v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
Google Workspace and Salesforce	v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all
Google Workspace and Zendesk	v=spf1 include:_spf.google.com include:mail.zendesk.com ~all

The page also lists records for Amazon, GoDaddy, and Shopify. For any other provider, copy the pattern and swap in that provider's domain.

Publish it at your domain host

Nothing happens in the Admin console for SPF. Everything happens at your domain host, usually the registrar where you bought the domain.

1. Sign in to your domain host and open the page for DNS TXT records.

2. Add a record with Type set to TXT.

3. Set Host to @ when you're adding the record to the main domain. For a subdomain, use the full name instead.

4. Paste your SPF string into Value. Some hosts want it wrapped in quotes, so check their help pages.

5. Save.

Subdomains and extra domains each need their own SPF record. It can take up to 48 hours for SPF to start working.

Check: A DNS lookup for TXT records on your domain returns exactly one record beginning with v=spf1.

If it fails: Look for a duplicate SPF record, a typo in an include domain, or a host that added your domain name to the Host field automatically.

Step 2: Generate and Deploy DKIM Keys

Generate a DKIM key pair in the Admin console, publish the public key as a TXT record at your domain host, and only then switch signing on. Do them in that order. Turning on authentication before the DNS record exists means signatures that receivers can't verify.

Prepare first

You must be signed in as a super administrator. If you turned on Gmail recently, wait. Google warns that you need to wait 24 to 72 hours after turning on Gmail before you can get a DKIM key, and trying earlier can produce an error that the DKIM record wasn't created.

If you route mail through an outbound gateway, confirm its settings don't rewrite messages. A gateway that adds a footer to every message alters the body after it's signed, and the signature can fail.

Generate the key

1. In the Admin console, go to Menu, then Apps, then Google Workspace, then Gmail.

2. Click Authenticate email.

3. In the Selected domain menu, pick the domain.

4. Click Generate New Record.

5. Choose the key length. Pick 2048 if your domain host supports it. Fall back to 1024 if it doesn't.

6. Keep the default prefix selector, google, unless your domain already uses a DKIM key with that prefix. In that case, enter a different one.

7. Click Generate.

Gmail requires a DKIM key of 1024 bits or longer for mail to personal Gmail accounts. Its guidelines also recommend 2048 bits when your provider can handle it.

Copy two values from the screen: the DNS Host name (TXT record name) and the TXT record value. Do not click Start Authentication yet.

Publish the public key

At your domain host, add a TXT record. Set Host to the record name you copied, which looks like google._domainkey. Paste the long TXT record value into Value. It starts with something like v=DKIM1. Save.

Some domain providers cap the length of a TXT record. A 2048-bit key is long enough to hit that limit, so if your host rejects it, read Google's DKIM troubleshooting page on TXT character limits. Each domain needs its own key from the Admin console, and subdomains need their own TXT records.

Give DNS up to 48 hours. During that window the Admin console may keep showing "You must update the DNS records for this domain." If you added the record correctly, ignore the message.

Turn signing on

Return to Authenticate email, select the domain, and click Start authentication. When it works, the status at the top reads Authenticating email with DKIM.

Check: Send a message to a Gmail or Google Workspace address that isn't yours, since a message to yourself won't prove anything. Open it, choose More, then Show original. Under Authentication-Results, look for DKIM=pass or DKIM=OK.

If it fails: If the header has no DKIM line at all, messages aren't being signed. Reread the steps for a skipped stage, then check whether your outbound gateway alters messages.

Step 3: Configure DMARC Policy and Reporting

Publish a DMARC TXT record at _dmarc.example.com with a starting policy of p=none and a report address. Set it up only after SPF and DKIM have been authenticating mail for at least 48 hours. If you turn on DMARC without them, according to Google's DMARC guide, messages sent from your domain will probably have delivery problems.

Set up a place for reports

DMARC reports arrive by email, and the volume adds up. Large organizations can get hundreds or even thousands each day. Create a Google group or a dedicated mailbox to receive them instead of pointing them at your own inbox. The address should normally sit in the same domain as your DMARC record. If it doesn't, the other domain needs an extra DNS record to accept the reports.

Confirm third-party senders can pass

If a third-party service sends as your domain, its messages must pass SPF and DKIM. Ask the provider to confirm both are set up. Then check that the provider's envelope sender domain matches yours and that its sending servers are in your SPF record. You can also route the provider's mail through Google using the SMTP relay service setting.

Build the record

Write v and p first. The remaining tags can go in any order. These are the ones that matter:

Tag	What it does
v	Required. Must be DMARC1.
p	Required. none delivers failing mail and logs it, quarantine sends it to spam, and reject bounces it.
pct	Optional. Percentage of failing messages the policy applies to, from 1 to 100. Omit it and the policy covers 100%.
rua	Optional but recommended. Each report address needs the mailto: prefix, with commas between addresses.
sp	Optional. Sets a separate policy for subdomains. Omit it and subdomains inherit the parent policy.
adkim, aspf	Optional. s is strict alignment and r is relaxed, which is the default.

Gmail doesn't support the ruf tag for failure reports, so leave it out.

Alignment decides whether a passing SPF or DKIM result counts. A message passes DMARC if it passes SPF with alignment or DKIM with alignment. It fails only when both break. Strict alignment demands an exact domain match, while relaxed accepts subdomains. Strict is tighter, so if a third party sends for you from a subdomain, you may want to test carefully before using it.

Publish the record

At your domain host, add a TXT record. Set Host to _dmarc.example.com, with your own domain in place of example.com. Paste the record string into Value and save. Some hosts append the domain name automatically, so afterward, look up the record to confirm the host name didn't come out as _dmarc.example.com.example.com.

Worked example: all three records for example.com

Say example.com sends through Google Workspace and Mailchimp. These are the three TXT records you'd publish (DKIM value shortened; paste the full value the Admin console gives you):

Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Type: TXT
Host: google._domainkey
Value: v=DKIM1; ... (paste the full TXT record value from Authenticate email)

Type: TXT
Host: _dmarc.example.com
Value: v=DMARC1; p=none; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100

The DMARC record above starts from Google's sample in monitoring mode with p=none, which means nothing gets blocked while reports start arriving. It leaves out Google's strict alignment tags, so the relaxed default applies. Mailchimp mail passes DMARC through DKIM, not SPF, because Mailchimp sends from its own bounce domain. Before you move past p=none, authenticate your domain in Mailchimp, which gives you two DKIM CNAME records to publish.

Check: A DMARC lookup tool shows your record at _dmarc.example.com, correctly formatted. Within a day or so, reports begin landing in your group or mailbox.

If it fails: If no reports arrive, check that each rua address carries mailto: and that an address in a different domain has its extra DNS record.

How do I verify SPF, DKIM, and DMARC are working?

Check each protocol separately. For DKIM, read the Authentication-Results line in a delivered message's header. For SPF and DMARC, run your domain through a free lookup tool. Then read your first DMARC reports. Allow up to 48 hours after any DNS change before judging results.

Here's a quick way to run through it:

• SPF: One TXT record starting v=spf1, listing every sender and no more than 10 include: tags.

• DKIM: The Admin console status reads Authenticating email with DKIM, and a message received in Gmail shows DKIM=pass or DKIM=OK.

• DMARC: The record resolves at _dmarc.example.com, and reports arrive at your group or mailbox.

If mail is still landing in spam, think about what could be different. Did a new sender start using your domain without being added to SPF? Did an outbound gateway begin editing messages? Gmail also reports rejections with an error such as 5.7.26 for unauthenticated messages, so bounce messages are worth reading.

Google also offers a Postmaster Tools dashboard that shows whether your messages are authenticated, along with your spam rate and domain reputation. The Google Admin Toolbox's CheckMX tool can review your domain's DNS settings as well.

Check: All three protocols pass on a message you sent to an outside Gmail address, and reports confirm the same for real traffic.

If it fails: Fix the earliest broken layer first. DMARC can't pass without SPF or DKIM passing with alignment.

What does Gmail require based on your sending volume?

Every sender to Gmail needs SPF or DKIM plus a handful of infrastructure basics. Senders above 5,000 messages per day to Gmail accounts must add SPF and DKIM together, DMARC, alignment, and one-click unsubscribe. Google's guidelines set these lines as of February 1, 2024.

Requirement	All senders	5,000+ messages per day
SPF or DKIM	Yes (one of the two)	Both required
DMARC	Recommended	Required (policy can be none)
Valid forward and reverse DNS (PTR) records	Yes	Yes
TLS connection	Yes	Yes
Spam rate in Postmaster Tools	Below 0.3%	Below 0.3%
Message format	RFC 5322	RFC 5322
No impersonation of Gmail From: headers	Yes	Yes
From: domain aligned with SPF or DKIM domain	Not listed	Yes
One-click unsubscribe for marketing and subscribed mail	Not listed	Yes

Two details deserve attention. First, a none policy satisfies the DMARC requirement, so you can meet the rule while still only monitoring. Second, Gmail's own advice is to keep your spam rate below 0.10% and avoid ever reaching 0.30%.

The one-click unsubscribe requirement means adding two headers to bulk mail: List-Unsubscribe-Post: List-Unsubscribe=One-Click and a List-Unsubscribe header pointing to an unsubscribe URL.

Check: You meet every requirement marked Yes, Both required or Required in the column for your sending volume.

How do I keep authentication working over time?

Update SPF when your senders change, read DMARC reports on a schedule, and tighten the DMARC policy as results improve. Authentication is not a one-time job. New tools that send as your domain break SPF quietly, and the reports are how you catch that.

Here's a maintenance routine:

• Add new senders to SPF before they start sending. If you adopt a new mail server or third-party service and skip this step, Google notes that its messages could be marked as spam.

• Remove old senders. Delete any domain or IP you no longer send from.

• Read your DMARC reports. They show authentication problems and possible spoofing attempts, and they're the input for changing your policy.

• Watch Postmaster Tools. Check your spam rate and domain reputation, especially after volume increases.

Then move the policy forward. Google's advice is to start at p=none and move to quarantine or reject over time as you learn how receivers treat your mail. You can also use pct to apply the policy to a small share of failing mail first. Once your reports look clean, an enforcement record looks like this:

Type: TXT
Host: _dmarc.example.com
Value: v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100

If you plan to add your logo through BIMI, note that it requires p=quarantine or p=reject and a pct of 100. It doesn't work with p=none.

Your next move is to open your DMARC report mailbox this week and identify every sending source it lists. Any legitimate sender that fails, fix in SPF or DKIM before you raise the policy above none.

References

1. support.google.com — Set up SPF | Apps & integrations | Google Workspace Help

2. support.google.com — Set up DKIM | Security & data protection | Google Workspace Help

3. support.google.com — Set up DMARC | Security & data protection | Google Workspace Help

4. Email sender guidelines - Gmail Help — support.google.com