Google Workspace SPF, DKIM and DMARC Setup

If Google Workspace is your only sender, Google's SPF TXT value is:

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

Publish it at the sending domain's root. For DKIM, generate a domain key in the Google Admin console, publish the supplied TXT record, then start authentication. Add DMARC after verifying the senders; Google recommends beginning with p=none and reading the reports before enforcing quarantine or rejection.

The values and console steps below were checked against Google's documentation on October 2, 2026. Older instructions may call the product G Suite or use the phrase “DKIM GSuite.” The current setup is in Google Workspace.

SPF Record for Google Workspace

SPF tells a receiver which sending services are authorized for the domain used in the message's envelope sender. The authorization lives in DNS, so you edit it at the host responsible for the domain's DNS records. Your registrar, website host and DNS host can be different companies.

For Google-only sending, add or update the root TXT record:

Use one SPF record per domain. Multiple TXT records are normal when they have other purposes, such as verification or DKIM. The conflict is multiple records starting with v=spf1 at the same name. The receiver cannot choose between those SPF policies. SPF standard, RFC 7208

Google's record covers Google Workspace. If a help desk, website, CRM or another service also sends using your domain, inventory those services before replacing the existing value. Obtain each service's required authorization from its own documentation, then combine the legitimate senders into a single policy. Google's SPF setup

An SPF policy has a limit of 10 DNS-querying terms during evaluation. Nested includes count too. The number of visible include: entries alone is insufficient to judge whether the policy fits. A term can lead to more lookups inside another provider's record; exceeding the limit produces a permanent error. Use the SPF, DKIM and DMARC test guide for the lookup investigation.

Google recommends ~all, the SPF soft-fail qualifier. -all expresses a fail for an unauthorized sender. The qualifier tells the receiver the SPF outcome; the receiver's filtering policy determines the final action. Avoid changing to a stricter policy while you are still discovering legitimate senders. Keep the policy's ending consistent with the complete sender inventory. Google, RFC 7208

If you use a separate sending subdomain, check its SPF policy independently. Record the full name you edited and the previous value. That small record makes a DNS change easier to review or correct if a service stops passing authentication.

Set Up DKIM in Google Workspace

1. Open the domain's authentication settings. Sign in as a super administrator. Go to Apps → Google Workspace → Gmail → Authenticate email, then select the sending domain

2. Generate the domain key. Choose Generate New Record, select 2048 bits if the DNS host supports it, and use the default google selector unless that selector is already in use. Google also offers 1024 bits for hosts that cannot support the longer key

3. Copy the supplied DNS values. Save the displayed TXT host name and the complete TXT value. With the default selector, the relative host is google._domainkey. The public key is specific to your domain

4. Publish the TXT record. Add the supplied host and value at the authoritative DNS host, then save. Check the returned public value before proceeding

5. Start authentication. Return to the selected domain in Authenticate email and choose Start authentication. Allow for DNS propagation; Google says DKIM can take up to 48 hours to start working after the key is added

6. Verify a received message. Send to another Gmail or Workspace account. Open More → Show original in the received message and check the DKIM authentication result

Google's DKIM setup instructions

For a newly enabled Gmail service, Google says to wait 24–72 hours before generating its DKIM key. If generation fails during that window, check the activation timing before changing DNS records. Generate and publish a distinct key for each sending domain you configure.

Save the selector with the DNS change record. It tells a checker which name to query and lets a colleague connect a received signature to the published key. Copy the actual key from the console each time; a public key copied from an unrelated setup cannot verify your domain's signature.

Add the Record at Your DNS Host

First check the domain's nameservers. Edit the zone served by those nameservers. Changing TXT records in a registrar's inactive DNS panel has no effect on public answers.

A relative host such as google._domainkey becomes google._domainkey.your-domain in the zone. If a host appends the domain for you, pasting the fully qualified name into the wrong field can repeat it. Inspect the saved name to make sure you created the name that the receiver will query.

For long DKIM values, preserve every character in the generated key. Some DNS interfaces handle a long TXT value automatically; others require multiple quoted strings inside the same TXT record. Follow the host's current instructions. Avoid splitting the value into separate records at the same name.

Google's DKIM troubleshooting documentation explains how to compare the public TXT result with the Admin console and how to handle a 255-character string limit. If the interface rejects your key, investigate the supported format before shortening it or regenerating it repeatedly.

Add DMARC

DMARC checks whether authenticated SPF or DKIM aligns with the domain people see in the From address. It also publishes the domain owner's requested handling of messages that fail that check. A passing authentication result from an unrelated domain does not establish DMARC alignment.

For an initial monitoring policy, publish a TXT record at _dmarc:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the report address with a dedicated mailbox or report service you control. Confirm that it exists and can receive reports. If the address belongs to another domain, follow that report provider's external-report authorization instructions. Google's DMARC setup

p=none requests no DMARC enforcement action. It lets you observe authentication before asking receivers to quarantine or reject failures. It does not turn off the receiver's normal spam filtering. Check legitimate third-party services in the reports as well as Workspace mail.

After the authorized senders consistently authenticate and align, plan the move to p=quarantine or p=reject. Google recommends a gradual rollout. Keep the reports coming while tightening the policy so that a neglected service is visible before its mail is disrupted.

For the relationship between these checks and outbound campaigns, read SPF, DKIM and DMARC for cold email. A mailbox provider's successful DNS setup is one part of the delivery process. Message content, sending history and recipient feedback still influence filtering.

Verify the Records

Use the free SPF, DKIM and DMARC checker to inspect the public records. Enter the sending domain and its actual DKIM selector. With Google's default selector, the checker needs google; if you chose another one, use that value.

Record presence and message authentication are separate checks. DNS confirms that a receiver can retrieve the intended public policy and key. A received message shows whether the sender used that configuration and whether the receiver accepted the signature and alignment.

Send a fresh message to a separate Gmail account. In the received message, open the More menu beside Reply and choose Show original. Read SPF, DKIM and DMARC results, then inspect the domains associated with those checks. Save the result with the sender and time. Google's DKIM troubleshooting guide

Repeat the received-message check for each legitimate sending service. Testing Workspace mail alone leaves the website, CRM or help desk unverified. Keep a simple list of services and their last passing check so that later DNS edits have a clear set of senders to retest.

The email DNS audit skill can organize the domain, selector, record values and messages into an audit. Keep secrets out of a shared report: this setup needs a public DKIM value, while private signing keys belong with the sending service.

Troubleshooting

Google DKIM troubleshooting, DMARC setup and RFC 7208 explain the relevant checks. For broader testing across providers, use the authentication test guide.

When asking a DNS host for help, include the record name, type, current public result and the error message. When asking a sender for help, include a received message's authentication results. Those details make the failing step visible and avoid repeated edits to a record that is already correct.

Forwarding deserves a separate check because it changes the delivery route. Our Google Workspace forwarding guide covers that setup; retest authentication after changing the forwarding configuration.

For Cold Email Senders

Authentication does not increase a Workspace account's sending quota. Check Google Workspace sending limits when planning volume, and keep normal business mail protected when selecting domains for cold email.

If you are comparing mailbox types, Google Workspace alternatives for cold email covers SMTP/IMAP options. Outreach2day sells SMTP/IMAP mailboxes, and sets up SPF, DKIM and DMARC for its own provisioned domains. A Google Workspace domain remains the responsibility of its Workspace and DNS administrators.

Frequently Asked Questions

Does Google Workspace have an SPF record?

Workspace has a published SPF authorization for Google's sending infrastructure. Your domain needs its own TXT policy using that authorization. Check existing DNS first, because a partner setup may already have configured it.

What SPF should I use for Google Workspace?

For Google-only sending, Google specifies v=spf1 include:_spf.google.com ~all. If other services send for the domain, authorize them in the same SPF policy using their own documentation. Keep one SPF record at each sending domain name.

How do I set up DKIM in Google Workspace?

Generate the domain's key in Authenticate email, publish the displayed TXT values at its DNS host, then start authentication. Verify a fresh message received by a separate account. The step-by-step section above describes the console choices.

Does Gmail require both SPF and DKIM?

Google's personal Gmail sender guidelines require SPF or DKIM for all senders. Bulk senders must use SPF, DKIM and DMARC. Google recommends all three for sending domains. These are authentication requirements; delivery also depends on the other sender guidelines. Google sender guidelines

Where can I find my SPF record?

Look up TXT records at the sending domain's root and find the one beginning v=spf1. You can use the authentication checker, a DNS query or the authoritative host's panel. The public lookup shows what receiving servers can retrieve.

Sources

Checked October 2, 2026:

• Google SPF setup: Google-only value, root TXT setup and soft-fail recommendation

• Google DKIM setup: console procedure, key sizes, selector and activation timing

• Google DKIM troubleshooting: TXT limits, received-message checks and forwarding

• Google DMARC setup: monitoring policy, reports, alignment and enforcement rollout

• Google sender guidelines: personal Gmail authentication requirements

• RFC 7208: one SPF policy, qualifiers and DNS lookup limit

• Cloudflare DNS records, GoDaddy TXT records, Namecheap TXT setup and Squarespace DNS records: DNS host instructions

Outreach2day SMTP/IMAP mailboxes include authentication, warm-up and sending. Check Outreach2day pricing while comparing your cold email setup.