Google Workspace SPF record setup, with DKIM and DMARC

Do not copy a Google SPF record into DNS until you know every system that sends mail for the domain.

Google Workspace may be the only sender. It may also sit next to a help desk, transactional service, form tool, CRM, or another outbound system. SPF allows one policy at a hostname. Publishing a second SPF record is not how you add another sender.

The clean sequence is:

1. Inventory every sender.
2. Publish one combined SPF policy.
3. Generate and enable Google DKIM.
4. Publish DMARC with reporting.
5. Send a real message outside the organization.
6. Verify alignment from the received headers.
7. Hand off the records, evidence, and owners.

1. Inventory the message path

For each system, record the visible From domain, the MAIL FROM or Return-Path domain used for SPF, and the DKIM signing domain.

Do not add a vendor because someone remembers using it last year. Confirm that it still sends mail using the domain. Remove stale authorization through a controlled change, not a guess.

Find the sources from messages, not only invoices

The vendor list is a starting point. The message path is the evidence.

Collect recent messages from each active system and inspect the original headers. Record the visible From domain, Return-Path, SPF result and authenticated domain, DKIM selector and d= domain, and DMARC result. Repeat for password resets, support replies, forms, invoices, newsletters, and any outbound platform using the same visible domain.

Use a working sheet like this:

If nobody can produce a recent message, check the current application configuration and owner before deleting its authorization. “We probably stopped using it” is not a change plan.

Give shared corporate domains extra scrutiny. A cold-email sending domain with one job is easier to inventory than a primary company domain used by Google Workspace, support, billing, product notifications, and marketing automation. Do not apply a narrow outbound-domain record to the company-wide domain without finding every legitimate source first.

2. Publish one SPF record

For a domain that sends only through Google Workspace, Google's example is:

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

Publish it as a TXT record at the sending domain's root. DNS providers label the root differently—often @, the domain itself, or a blank host field.

That example is not universal. If another legitimate source uses the same domain, its documented SPF mechanism must be merged into the single policy. Do not publish this:

v=spf1 include:_spf.google.com ~all
v=spf1 include:another-vendor.example ~all

Two SPF records at the same hostname can produce an SPF error. Build one policy and keep its DNS-lookup path within the SPF processing rules.

Record the source for every mechanism:

SPF authenticates the MAIL FROM path. DMARC later asks whether that authenticated domain aligns with the visible From domain. An SPF pass by itself does not prove DMARC will pass.

Merge mechanisms without breaking the policy

Suppose Google Workspace and a second documented service both send mail using the same SPF identity. The resulting policy needs one v=spf1 prefix, the mechanisms required by both current providers, and one ending mechanism.

A schematic example looks like this:

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

Do not publish that placeholder. Open the second provider's current official documentation and use its exact mechanism only if the real message path requires it.

Keep the record reviewable:

hostname: example.com
record_type: TXT
record_value: v=spf1 ...
each_mechanism_owner:
each_mechanism_source_url:
last_message_verified_at:
rollback_value:

SPF processing has a DNS-query limit. Nested include, a, mx, redirect, and related mechanisms can consume it even when the visible record is short. Count the evaluated path, not only the words in the TXT value. A policy that exceeds the processing rules can return permerror.

Do not “flatten” a provider's changing IP ranges into a copied list unless that provider explicitly requires it and somebody owns the updates. The provider's documented include usually exists so its current infrastructure can change without your DNS record becoming stale.

Choose the ending deliberately

Google's simple example uses ~all. Do not change the ending because an online checker labels another symbol stronger.

The ending describes how sources that did not match the authorized mechanisms should be treated by SPF. It does not create DMARC enforcement by itself, and receivers still apply their own handling. Record why the chosen ending fits the current migration state and who can change it after every legitimate sender is verified.

3. Generate Google DKIM

In the Google Admin console, generate the DKIM record for the domain. Google provides a selector and a TXT value containing the public key.

The DNS record normally looks like:

Publish the exact generated value. Do not copy a public key from another domain, selector, or account.

After DNS resolves, start DKIM authentication in Google Admin. Then send a new message. Old messages do not change after DKIM is enabled.

Gate this step on evidence:

• the selector resolves publicly;
• Google shows signing enabled;
• a newly received message contains a DKIM signature;
• Authentication-Results shows a DKIM pass;
• the DKIM d= domain aligns with the visible From domain for DMARC.

An outbound gateway or service that modifies a message after Google signs it can break the signature. If DKIM passes on a direct test but fails through the real route, compare the two paths.

Keep selector rotation possible

A DKIM selector identifies the public key in DNS. It also gives the organization a way to publish a new key without replacing the old record in place.

Store the selector, DNS value, creation date, Google Admin state, and last successful received-message check. When a selector is replaced, keep the old record only for the period required by the actual message and rollback plan, then remove it deliberately. A pile of unexplained _domainkey records makes the next incident harder.

If several systems sign with the domain, each may use a different selector. That is normal. The inventory should map each selector to its owner and current source instead of assuming every DKIM record belongs to Google.

4. Add DMARC reporting

DMARC sits at _dmarc.example.com. A basic monitoring record can look like:

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

Use a reporting mailbox or processing service that is ready to receive aggregate reports. A p=none policy requests monitoring; it does not ask receivers to quarantine or reject failing mail.

Current DMARC work is governed by RFC 9989, which replaced RFC 7489. One practical change is that the old pct tag was removed. Do not build a rollout around pct; receivers following the current specification ignore it. RFC 9990 documents the DNS tree-walk behavior used to find a DMARC policy.

Before moving to an enforcement policy:

• identify every legitimate sending source in the reports;
• confirm SPF or DKIM passes in alignment for each source;
• resolve forwarded or modified message paths carefully;
• define the owner and rollback plan;
• document the intended policy change.

DMARC passes when at least one aligned authentication path passes. It does not require both aligned SPF and aligned DKIM, although operating both correctly gives the system more resilience.

Do not jump from monitoring to enforcement

Aggregate reports help reveal which sources are passing, failing, and using unexpected domains. They do not identify every message or replace a source inventory.

Before changing p=none to an enforcement policy, build a decision record:

Use separate domains or subdomains to stage change where the operating model allows it. Do not teach the removed pct tag as a dependable cross-receiver rollout control.

5. Verify a real external message

Send from the actual Google Workspace mailbox through the actual route to an external recipient you control. Open the received message's original headers.

Record:

Visible From:        person@example.com
Return-Path:         ...
SPF result:          pass/fail/error
SPF domain:          ...
DKIM result:         pass/fail
DKIM d= domain:      ...
DMARC result:        pass/fail
Recipient provider:  ...
Message timestamp:   ...

Then ask the three alignment questions:

1. Does the SPF-authenticated domain align with the visible From domain?
2. Does the DKIM signing domain align with the visible From domain?
3. Did at least one aligned path pass so DMARC passed?

If SPF and DKIM pass but DMARC fails, alignment is the first place to look. The DMARC failure guide walks through that exact comparison.

Troubleshoot from the failed result

Change one layer at a time. Preserve the failing header, DNS value, change timestamp, and new header after the fix. Without both samples, the team has no proof that the intended change affected the real message.

If the failure only appears through a gateway, help desk, or sequencer, test direct Google Workspace mail and the full route separately. That comparison isolates whether Google signing, the additional service, or the alignment between them is the broken step.

6. Hand off something another operator can use

A screenshot saying “DNS done” is not a handoff.

Provide:

• domain and DNS provider;
• all active sending sources;
• SPF hostname, exact value, and source for each mechanism;
• DKIM selector, hostname, and enablement state;
• DMARC hostname, policy, report destination, and owner;
• received-message authentication results;
• change timestamp and reviewer;
• rollback path;
• next review date.

Add a compact acceptance statement at the top of the handoff:

Domain: example.com
Approved senders: Google Workspace, ...
SPF: pass on received sample; aligned yes/no
DKIM: pass on selector ...; aligned yes/no
DMARC: pass on received sample
Policy and report owner: ...
Last verified: ...
Known exceptions: ...

That gives the next operator an answer before they read the record history. The supporting rows are still there when something changes.

Use a controlled DNS change window

Before editing the record, capture the current value and lower the TTL only when the DNS owner has a reason and enough lead time. Confirm the exact hostname; editing the root while testing a subdomain is an easy way to create a second problem.

During the change:

1. Save the previous SPF, DKIM, or DMARC value.
2. Change only the intended record.
3. Record the timestamp, editor, ticket or decision, and expected result.
4. Resolve the record from outside the DNS account.
5. Send a new message through the real route.
6. Preserve the received headers.
7. Compare them with the acceptance statement.
8. Roll back when the real message fails and the cause is not understood.

DNS propagation is not one universal timer. Different resolvers and cached records can update at different times. Do not promise that the setup will be complete in a fixed number of minutes. Use observed DNS resolution and received-message evidence.

After the window, restore any deliberately changed TTL according to the DNS plan, update the owner record, and schedule the next source review. Authentication is maintained infrastructure, not a one-time launch badge.

Review the source inventory when a help desk, form service, billing platform, CRM, or gateway is added or removed. The change should update the SPF mechanism map, DKIM selector ownership, DMARC evidence, rollback record, and received-message sample. Waiting for a DMARC failure to reveal an undocumented sender is the expensive version of maintenance.

Make sender onboarding a gate: no service may send as the domain until its official authentication instructions, owner, hostname, SPF or DKIM requirement, alignment path, test message, and removal procedure are recorded. That keeps “temporarily connected” tools from becoming permanent unknowns in the policy.

Use the same gate when a sender is removed. Delete authorization only after the real traffic has stopped and rollback evidence exists.

Keep the final received-message sample with the change record, not in a personal inbox.

Cheap Inboxes supports domain, DNS, DKIM, DMARC, and mailbox operating workflows. Google remains authoritative for the Google Workspace configuration and message behavior. Technical teams can inspect the developer overview after the authentication path is documented.

Sources

• Google Workspace: set up SPF
• Google Workspace: set up DKIM
• Google Workspace: set up DMARC
• RFC 7208: Sender Policy Framework
• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance
• RFC 9990: DMARC Tree Walk