Table of Contents
- What SPF Record Does Google Workspace Need?
- DNS values for a Google Workspace-only SPF record
- What does each part mean?
- Should the ending be softfail or hardfail?
- How to verify it
- How Do You Combine Other Senders With Google Workspace?
- Single SPF record for Google Workspace combined with other senders
- How to verify it
- How Many DNS Lookups Can Your SPF Record Use?
- How should includes be counted?
- SPF mechanisms and their DNS lookup cost
- How to verify it
- How to Publish Your Google Workspace SPF Record
- What should the administrator change?
- How to verify it
- Why Does Your Google Workspace SPF Record Fail?
- Google Workspace SPF failures, causes and fixes
- Which apparent SPF problems aren't SPF problems?
- Google Workspace SPF Questions Answered
- Can a domain have separate SPF records for Google Workspace and a marketing tool?
- How long does an SPF change take to appear?
- Does a newsletter subdomain need its own SPF record?
- Does passing SPF guarantee inbox placement?
- Confirm the Record Before You Send
- What can generation and automation do?
Do not index
Do not index
v=spf1 include:_spf.google.com ~all is the Google Workspace SPF record for Google-only sending, published as a TXT record at host @ with a TTL of 3600 seconds. Other authorized senders belong inside that same record, before ~all, rather than in a second SPF record.Adding a provider's perfectly valid SPF record can break authentication if an SPF policy already exists at that host. Treat SPF as a shared policy that every sending integration edits, not as a separate DNS entry for each application.
Table of Contents
What SPF Record Does Google Workspace Need?DNS values for a Google Workspace-only SPF recordWhat does each part mean?Should the ending be softfail or hardfail?How to verify itHow Do You Combine Other Senders With Google Workspace?Single SPF record for Google Workspace combined with other sendersHow to verify itHow Many DNS Lookups Can Your SPF Record Use?How should includes be counted?SPF mechanisms and their DNS lookup costHow to verify itHow to Publish Your Google Workspace SPF RecordWhat should the administrator change?How to verify itWhy Does Your Google Workspace SPF Record Fail?Google Workspace SPF failures, causes and fixesWhich apparent SPF problems aren't SPF problems?Google Workspace SPF Questions AnsweredCan a domain have separate SPF records for Google Workspace and a marketing tool?How long does an SPF change take to appear?Does a newsletter subdomain need its own SPF record?Does passing SPF guarantee inbox placement?Confirm the Record Before You SendWhat can generation and automation do?
What SPF Record Does Google Workspace Need?
For a domain sending exclusively through Google Workspace, Google's SPF setup guidance recommends
v=spf1 include:_spf.google.com ~all and a typical TTL of 1 hour, or 3,600 seconds.Sender Policy Framework (SPF) is a DNS TXT policy that identifies which servers may send mail using a domain's envelope-sender identity. The receiving server compares the connecting server's address with that policy.
DNS values for a Google Workspace-only SPF record
The subdomain above is an example, not a suggested sending configuration. Some DNS panels expect a relative label; others accept the complete hostname. Check the resulting name before saving so the panel doesn't append the domain twice.
What does each part mean?
- Version marker:
v=spf1identifies the value as an SPF policy.
- Google authorization:
include:_spf.google.comdelegates authorization to Google's published sender ranges. There's no need to copy Google's changing addresses.
- Ending mechanism:
~allproduces softfail for a source that hasn't matched an authorized mechanism.
The underscore in Google's include hostname matters. Copy the value instead of retyping it from memory.
Should the ending be softfail or hardfail?
Use
~all as a neutral starting point while collecting DMARC reports and confirming legitimate senders. Consider -all, which produces fail for unmatched sources, after the inventory and authentication paths are understood.Neither ending guarantees delivery or rejection. Receivers apply their own policies, and DMARC evaluates alignment rather than merely checking which SPF ending was published.
How to verify it
Check the live SPF policy with mailX. A good result shows Google's include, valid syntax, and no duplicate-policy warning; a missing record usually means the wrong host, record type, or DNS provider was edited.
How Do You Combine Other Senders With Google Workspace?
Each additional authorization goes inside the existing policy, before the ending mechanism. The following are configuration patterns, not client records or proof that a particular account requires root-domain SPF changes.
Single SPF record for Google Workspace combined with other senders
The HubSpot row is a template, not a publishable value. Replace the bracketed placeholder with the hostname supplied by HubSpot's current domain setup. If the interface supplies a complete mechanism, don't accidentally prepend another
include:.Provider requirements can change with the sending product or authentication configuration. Confirm the current instructions before publishing, particularly when a provider uses its own return-path domain or a delegated sending subdomain.
Amazon SES, Mailgun, and Postmark require the same inventory discipline, but they don't necessarily require an include on the organizational domain. Follow the setup for the actual envelope-sender domain instead of adding every provider used by the business.
The mailX SPF generator can prepare provider-specific values. Compare its output with the existing policy before making a DNS change; generating a new value isn't permission to discard existing authorizations.
How to verify it
Run the mailX SPF checker after publishing the merge. A good result has a valid policy, resolvable includes, and no lookup-budget warning; compare its authorizations against the sender inventory to catch omissions.
A checker can't infer every application the business uses. Confirm actual authorization by sending from each platform and inspecting the recipient's authentication results.
How Many DNS Lookups Can Your SPF Record Use?
RFC 7208 limits SPF evaluation to 10 DNS-query-causing terms across the evaluation path; exceeding that limit produces
permerror.Counting visible includes isn't enough. An included policy can contain further includes and other DNS-dependent mechanisms, which consume the same budget.
A printed policy helps with review, but nested dependencies require recursive inspection.
How should includes be counted?
- Read the root policy and identify DNS-dependent terms.
- Resolve each included policy and inspect its mechanisms.
- Continue through nested includes and any applicable redirect.
- Evaluate the possible paths, including the path where no sender matches, and remove obsolete authorizations.
SPF evaluation short-circuits when a mechanism matches. A diagnostic should therefore assess the worst relevant path, not just a successful Google Workspace send.
SPF mechanisms and their DNS lookup cost
These are term-budget rules, not a count of individual DNS packets. Some mechanisms perform additional queries and have separate constraints.
How to verify it
Run the mailX SPF checker and inspect recursive lookup warnings and
permerror findings. Recheck after provider changes, not just after local DNS edits.Remove unused includes first. Replacing provider includes with copied addresses creates an ongoing maintenance obligation and can leave legitimate mail unauthorized when those addresses change.
How to Publish Your Google Workspace SPF Record
Start the publishing workflow with the sender inventory. List Google Workspace, transactional applications, customer relationship management platforms, marketing tools, website servers, and relays. Record the envelope-sender domain each system uses; the visible From address can differ.
Google's publishing instructions recommend checking the existing policy before modifying it and validating authentication after publication.
Every authorized sender shares this one policy, so the edit is a merge of existing authorizations, not a Google-only change.
What should the administrator change?
- Inspect existing TXT records. Copy the current SPF value and save it with the change ticket. Leave unrelated verification TXT records alone.
- Confirm each sender's requirements. Document the required include or managed address, along with the hostname where authorization belongs.
- Build the replacement policy. Preserve active authorizations, add the required Google authorization, and remove only entries confirmed obsolete.
- Edit the existing SPF TXT entry. If no policy exists, create it at the intended host. Don't create another SPF entry just because a setup wizard provides a complete record.
- Save and allow for caching. Compare the authoritative DNS value with a fresh recursive lookup before treating a discrepancy as a failed save.
- Send through every legitimate platform. Open the received message's original headers and inspect authentication results alongside the envelope-sender identity.
An SPF pass for a provider-owned return path doesn't prove the visible From domain is aligned for DMARC. Record both identities in the test results so another administrator can interpret them.
For managed service providers, change communication matters too. NewsletterAsAService's editorial support for MSP newsletters can help explain scheduled authentication maintenance to customers; the technical change record should still contain the exact DNS edit and verification outcome.
The accompanying video provides another view of the setup workflow.
How to verify it
Verify at two layers. First, query the edited hostname for its TXT record and confirm the merged policy reads as intended, with every inventoried sender still authorized. Then send mail through each platform and read
Authentication-Results in the received headers: look for spf=pass and check that the smtp.mailfrom value matches an envelope sender from the inventory.The mailX SPF checker confirms the published side of that pair. The header test confirms what a receiver concluded about one specific message, which a DNS query alone cannot show.
Where the record already reads correctly, a header failure points elsewhere: the wrong sending identity, or a provider relaying through a host the policy never authorized. Compare the queried hostname, the envelope sender, and the authoritative record, and allow for resolver caching before editing a value that is already correct.
Why Does Your Google Workspace SPF Record Fail?
Duplicate SPF policies at the same hostname cause
permerror, not a choice between Google Workspace and the other sender. Receivers don't merge separate policies on the administrator's behalf.Other failures need different fixes. A misspelled include can invalidate evaluation, while an omitted sender usually reaches the policy's ending mechanism.
Google Workspace SPF failures, causes and fixes
A CNAME can lead a DNS resolver to another hostname, but it isn't interchangeable with the TXT value a setup screen requests. Don't delete provider-required authentication CNAMEs elsewhere in the zone.
Which apparent SPF problems aren't SPF problems?
- Wrong DKIM selector: Query the selector used in the message signature. Verify your DKIM record rather than changing SPF to fix a missing signing key.
- Wrong port or encryption pairing: Use the mailX SMTP test to diagnose transport negotiation. SPF doesn't control application-to-server login.
- Missing app password: Where the account's authentication method requires an app password, a normal account password won't substitute. Resolve the login error before testing message authentication.
Forwarding changes the connecting server, so direct mail can pass while a forwarded copy fails. Test direct, forwarded, and mailing-list routes separately; intact, aligned DKIM can help when SPF no longer passes.
Class A Media's broader guidance on how to keep marketing emails out of spam provides context beyond authentication, but an SPF repair should remain focused on the policy and sending path.
Google Workspace SPF Questions Answered
Can a domain have separate SPF records for Google Workspace and a marketing tool?
No. One hostname gets one SPF policy, so the Google include and every other sender mechanism belong in the same TXT value. Remove the second SPF entry rather than trying to balance two policies; other TXT records can stay because the conflict is only between TXT values that each declare themselves to be SPF.
How long does an SPF change take to appear?
Plan the verification window from the TTL in the publishing steps, then recheck the hostname and authoritative nameservers if the old value still appears after that window.
Does a newsletter subdomain need its own SPF record?
Only if the newsletter platform returns mail to that subdomain. Check the return path or bounce host in the platform, then put the needed authorization on that exact hostname; a root-domain policy does not automatically authorize subdomain sending.
Does passing SPF guarantee inbox placement?
No. SPF proves the connecting server is authorized for the envelope domain. Placement still depends on reputation, content, and recipient filtering, and DMARC still needs an aligned SPF or DKIM result. Inspect received-message headers and check your DMARC record with mailX before treating authentication as finished.
Confirm the Record Before You Send
Treat the merged policy as shared infrastructure: every sender that edits it can break authorization for all the others. Keep it under change control with a named owner and a sender inventory listing each authorized service. Review that inventory on a regular cadence, because tools your team stopped using often keep an include and consume a lookup slot long after the account closed.
What can generation and automation do?
The SPF Generator endpoint,
spf-generate, returns a TXT value ready to publish or explains the alternative setup when a provider doesn't need a root SPF include. Set hard_fail_boolean to true for a strict -all ending or false for ~all. mailX returns the record; it doesn't publish it or change DNS.- For administrators: Compare generated output with the live policy before replacing anything. A merged record replaces every sender's authorization at once, so a missing include takes down more than the service you meant to edit.
- For developers: Call
spf-checkfrom the deployment pipeline before releasing any change that touches sending infrastructure, and fail the release when the check fails.
- For agents: The MCP server exposes diagnostics and generation inside Claude, Cursor, or ChatGPT without modifying external infrastructure.
Before the next integration or sending run, validate your SPF record against live DNS. Save the result with the change record, then send a test message from each authorized platform and read the
Received-SPF header on arrival. A pass on the domain scan plus clean headers on real mail closes the loop.mailX is a free email deliverability diagnostics toolkit by Mailwarm Inc. (YC S20), with live checks and plain-English fixes on the web, through its REST API and MCP server, and inside ChatGPT. Visit mailX and run an SPF check on the sending domain now, free and without signup.