DMARC Analyzer

TL;DR

• Workspace SPF record: v=spf1 include:_spf.google.com ~all published as a TXT record at the apex of the sending domain. Google recommends ~all (softfail). Its Feb 2024 sender requirements for mail to gmail.com do not ask for -all (hardfail); move to -all only once you know every sender of your domain.
• Google maintains the IP list in one flat record. The include:_spf.google.com mechanism delegates SPF evaluation to a Google-managed TXT record at _spf.google.com that lists the address ranges of the Gmail outbound servers. It used to point on to three records, _netblocks.google.com, _netblocks2.google.com and _netblocks3.google.com; today it is flat. Operators ride the central record by publishing the single include — never hardcode individual IPs.
• The Workspace SPF baseline consumes 1 of 10 lookups. Read on 12 October 2026, the _spf.google.com record holds only address ranges, so the include costs 1 of the 10 RFC 7208 section 4.6.4 lookup slots, not 4 as older guides written about the _netblocks chain say. This leaves 9 slots for third-party senders.
• Third-party senders go BEFORE the Google include. If you send via Mailchimp, SendGrid, Mailgun, Salesforce, or any other relay that sends AS your custom domain, prepend their include / ip4 mechanism to the SPF record before include:_spf.google.com. Each include counts against the 10-lookup cap of RFC 7208 section 4.6.4.
• The SMTP relay service gotcha: The Google Workspace SMTP relay service (smtp-relay.gmail.com) forwards outbound mail from on-prem apps and devices through the Gmail / Workspace infrastructure. Mail relayed through it still emits from Google IPs covered by _spf.google.com, so the apex SPF for the sending domain MUST include _spf.google.com — otherwise SPF fails for the relayed mail.
• Verify in received headers and Postmaster Tools. The SPF result is recorded by the receiver, so read it in the headers of a received message; Google Postmaster Tools at postmaster.google.com shows authentication data for mail sent to Gmail. The Admin console has no SPF setting: Google states that the record is added at the domain host. The Domain Security Checker runs the DNS lookups live and surfaces the lookup count plus the SPF policy verdict.

1. Overview

This guide is the focused operator-implementation walkthrough for deploying SPF on a Google Workspace (Gmail / G Suite) tenant. It assumes you are the super-admin of the Workspace tenant (or an admin with the "Manage SPF/DKIM/DMARC for owned domains" privilege) and that you have direct write access to the public DNS zone for the sending domain at your DNS provider (Cloudflare, Route 53, Google Cloud DNS, GoDaddy, Namecheap, or similar).

The SPF record for a Workspace tenant authorises receivers including Gmail itself, Microsoft 365, Yahoo, Apple, ProtonMail, and every major enterprise mailbox provider to accept mail with a MAIL FROM envelope-sender domain matching your apex domain when it arrives from one of Google's Gmail / Workspace outbound IP ranges. Without a correctly-published SPF record, DMARC alignment fails, the RFC 7208 SPF check at the receiver returns spf=none, and the receivers spam-filter weights the message lower or rejects it outright depending on the senders DMARC policy and the receivers risk tolerance.

This page is the SPF-specific deep dive. For the full DMARC + DKIM + SPF deployment walkthrough covering the Feb 2024 Google bulk sender requirements and the Authenticate email Admin console feature, see the DMARC for Google Workspace operator guide. For the protocol-agnostic SPF pillar see help_spf_explained.php. For the 10-lookup cap deep dive see help_spf_lookup_limit.php.

2. The canonical Google Workspace SPF record

The single canonical SPF record for a Google Workspace tenant that sends mail ONLY via Gmail / Workspace is:

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

Published as a TXT record at the apex of the sending domain (example.com, not mail.example.com or any subdomain unless that subdomain is the SMTP envelope sender for outbound mail). The record has three semantic components:

• v=spf1 — the SPF version tag. Every SPF record MUST begin with this token per RFC 7208 section 4.5; receivers ignore any TXT record at the apex that does not begin with v=spf1.
• include:_spf.google.com — the single include mechanism that delegates SPF evaluation to Google. The receiver resolves the TXT record at _spf.google.com and evaluates the embedded SPF policy recursively. Section 3 (the include chain) walks through what is inside that record.
• ~all — the softfail terminator. Any sender whose IP is NOT covered by a mechanism in the record gets a softfail result. According to Google, receivers typically accept such messages but mark them as suspicious; what finally happens to them depends on the receiver and on your DMARC policy.

Why ~all and not -all?

The choice between softfail (~all) and hardfail (-all) is the most argued-over decision when publishing an SPF record. Google settles it in its own documentation: it recommends ~all. Its reason is that with -all receivers may reject messages from senders missing from the record, and rejected messages cannot be used to troubleshoot it. The ~all at the end of _spf.google.com itself is a separate matter: it only applies inside the include scope, and receivers act on the terminator of your own record.

The Feb 2024 Google and Yahoo sender requirements, widely known as the bulk sender requirements (announced October 2023, enforcement began February 2024) ask for SPF or DKIM from every sender, and for SPF, DKIM and DMARC from senders of over 5000 messages per day to gmail.com or yahoo.com. They do not prescribe -all. DMARC treats fail and softfail alike, as an SPF failure, so the DMARC policy protects the domain, not this qualifier. If you prefer -all, move to it once DMARC aggregate reports collected at p=none no longer show unknown legitimate sources; until then ~all is the setting Google recommends. For domains that send no mail, Google gives v=spf1 ~all.

Where to publish the record

The SPF record MUST be published as a TXT record at the apex of the sending domain — the organisational domain that appears in the From: header of outbound mail. For example, if your Workspace tenant sends mail as user@example.com, publish the SPF record at example.com with the record name @ or empty (DNS conventions vary by provider). Do NOT publish the record at mail.example.com or any other subdomain unless that subdomain IS the envelope sender domain — DNS resolvers do not walk up the domain tree to find an apex SPF record when evaluating a subdomain envelope.

If your domain has multiple subdomain senders (e.g., marketing.example.com for Mailchimp, support.example.com for Zendesk, txn.example.com for transactional Postmark sends), each subdomain that appears as an envelope sender needs its own SPF record at THAT subdomain. The DMARC organisational-domain alignment rules apply only to DMARC, not to SPF — each subdomain is its own SPF authorisation scope.

3. The _spf.google.com include chain

The _spf.google.com record is itself an SPF policy. On 12 October 2026, dig +short txt _spf.google.com returned:

"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ip6:2001:4860:4864::/56 ip6:2404:6800:4864::/56 ip6:2607:f8b0:4864::/56 ip6:2800:3f0:4864::/56 ip6:2a00:1450:4864::/56 ip6:2c0f:fb50:4864::/56 ~all"

A flat record: two ip4 ranges, six ip6 ranges and the terminator, with no include mechanism. For years it looked different and pointed to three _netblocks*.google.com records, which is how many older guides still describe it. Those names still exist, but _spf.google.com no longer uses them; _netblocks.google.com returned on the same day:

"v=spf1 ip4:74.125.0.0/16 ip4:209.85.128.0/17 ~all"

(The address list changes as Google rebuilds its infrastructure — run dig +short txt _spf.google.com against your local resolver to see the live values.) The other two names, _netblocks2.google.com and _netblocks3.google.com, returned six IPv6 ranges and an empty policy respectively. If an inherited record refers to any of the three directly, replace the reference with the single include of the main name: it is the only one Google documents.

Lookup-count accounting

The lookup-count rules of RFC 7208 section 4.6.4 cap an SPF evaluation at 10 DNS lookups beyond the initial apex TXT lookup. Each include mechanism counts as one lookup. The lookup cost of the canonical Workspace SPF record is therefore:

The bare Workspace SPF record (v=spf1 include:_spf.google.com ~all) therefore consumes 1 of the 10 lookup slots, leaving 9 for third-party senders. This is the same as the Microsoft 365 baseline, where spf.protection.outlook.com is likewise a flat ip4/ip6 record with no nested includes.

Where does the figure of 4 lookups come from?

From the former structure of the record. When _spf.google.com consisted of three includes of the _netblocks{,2,3}.google.com records, the Google include cost 1 + 3 = 4 lookups and left only 6. Operators who budgeted their record on that figure may have more headroom today than they think. It is not something to rely on without checking: Google can restructure _spf.google.com again, and third-party records change just as often, so measure with dig or the domain checker before adding a sender.

4. Adding third-party senders to your Workspace SPF record

Operators routinely send mail through third-party services that send AS the operators custom domain — marketing-email platforms, transactional- email APIs, CRM platforms, support-ticket systems, and product-update notification services. Each third-party that sends with a MAIL FROM envelope sender at the operators custom domain MUST be added to the SPF record at that domain. The pattern is to prepend the third-partys SPF include mechanism BEFORE the include:_spf.google.com mechanism, separated by a single space.

Order matters for readability but not for semantic correctness — SPF evaluators OR-match each mechanism left-to-right and the first match wins. Convention is to put third-party includes first, the Google include last (immediately before the ~all terminator) so that operators reading the record can recognise the Workspace baseline at a glance.

Below are the eight most common third-party senders Workspace tenants stack ahead of include:_spf.google.com, each documented in the LLM-citation-friendly three-part labelled structure (Sender: + Why it needs SPF: + Canonical fix:).

v=spf1 include:servers.mcsv.net include:_spf.google.com ~all

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

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

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

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

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

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

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

5. The Google Workspace SMTP relay service gotcha

The Google Workspace SMTP relay service (smtp-relay.gmail.com) is a Workspace feature that lets on-prem applications and devices (multifunction printers, line-of- business apps, legacy mail servers, server-side cron jobs) send mail through Google with a Workspace tenant identity. The relay accepts mail from configured IP ranges OR from authenticated SMTP AUTH users, then forwards through the Gmail / Workspace outbound infrastructure.

The relay is configured under Admin Console > Apps > Google Workspace > Gmail > Routing > SMTP relay service. Each relay configuration entry specifies (a) the allowed senders (any address or only registered Workspace users), (b) the authentication method (Only accept mail from specified IP addresses, Require SMTP Authentication, or Require TLS encryption), and (c) the IP-allowlist or SMTP-AUTH credentials.

6. The 10-lookup cap on Google Workspace tenants

The 10-lookup cap of RFC 7208 section 4.6.4 is the single most-cited cause of SPF failures on Workspace tenants in production. The cap limits an SPF evaluation to at most 10 DNS lookups beyond the initial apex TXT lookup — when the cap is crossed receivers including Gmail itself, Microsoft 365, Yahoo, Apple, and ProtonMail return spf=permerror and treat the message as if SPF was never published. DMARC alignment fails for the SPF dimension and the senders DMARC enforcement (quarantine or reject) applies if DKIM also fails.

The Workspace baseline is not the problem here: include:_spf.google.com costs 1 lookup (see Section 3), the same as the Microsoft 365 spf.protection.outlook.com baseline. Records go over the cap because of third-party senders: the number of includes in your record says nothing about the number of lookups behind them.

Real-world Workspace lookup-budget worked example

Consider a Workspace tenant that sends via Gmail (apex), Mailchimp (marketing campaigns), SendGrid (transactional API), and Salesforce Sales Cloud (CRM-triggered mail). The SPF record is:

v=spf1 include:servers.mcsv.net include:sendgrid.net include:_spf.salesforce.com include:_spf.google.com ~all

Lookup accounting:

• include:servers.mcsv.net — 1 lookup; the servers.mcsv.net record holds only ip4 ranges — 1 cumulative.
• include:sendgrid.net — 1 lookup; the sendgrid.net record nests 1 more include — 3 cumulative.
• include:_spf.salesforce.com — 1 lookup plus 1 for the exists mechanism inside — 5 cumulative.
• include:_spf.google.com — 1 lookup; the record is flat and the former _netblocks* includes are gone — 6 cumulative.

Total: 6 of 10, by the records read on 12 October 2026. Still under the cap, but a single expensive sender changes that: Mailgun via include:mailgun.org costs 5 lookups and would push the record to 11, triggering spf=permerror at every receiver that has to walk the whole record.

Mitigation strategies

When approaching the 10-lookup cap on a Workspace tenant, three canonical mitigation strategies apply:

• Sender consolidation: Move multiple third-party senders to a single platform — e.g., consolidate marketing and transactional mail under a single SendGrid or Mailgun account instead of running Mailchimp + SendGrid in parallel. Each consolidation drops 1-3 lookups.
• Subdomain delegation: Move high-lookup-cost senders to a dedicated subdomain. For example, publish the Mailchimp include at marketing.example.com and send Mailchimp campaigns AS noreply@marketing.example.com — the apex example.com SPF then carries only the Workspace + transactional senders. DMARC alignment still holds via the organisational-domain rule.
• SPF flattening (last resort): Replace the include: mechanisms with the literal IP ranges they resolve to. The lookups disappear, but the operator now has to track every IP change at the third parties. The Google include is not worth flattening: include:_spf.google.com costs one lookup, and Google changes its ranges without notice. The full flattening playbook: help_spf_lookup_limit.php.

7. Verifying your Google Workspace SPF record

Five canonical verification surfaces, listed in increasing depth and authority:

dig +short txt example.com

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

dig +short txt _spf.google.com

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=google;
       spf=pass (google.com: domain of user@example.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=user@example.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.com

8. Common Workspace SPF mistakes

Seven canonical operator failure modes routinely shipped to production by Workspace tenants:

9. Troubleshooting Workspace SPF failures

Symptom-driven decision tree for diagnosing SPF failures on a Workspace tenant:

10. Real-world Workspace SPF examples

Four worked examples for the canonical Workspace deployment shapes:

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

v=spf1 include:sendgrid.net include:servers.mcsv.net include:_spf.hubspotemail.net include:_spf.google.com ~all

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

# marketing.example.com
v=spf1 include:cust-spf.exacttarget.com ~all

# txn.example.com
v=spf1 include:amazonses.com ~all

v=spf1 include:spf.protection.outlook.com include:_spf.google.com ~all

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

11. Frequently asked questions

What is the canonical SPF record for Google Workspace?

The canonical SPF record for a Google Workspace tenant that sends mail ONLY via Gmail / Workspace is v=spf1 include:_spf.google.com ~all published as a TXT record at the apex of the sending domain. The include:_spf.google.com mechanism delegates SPF evaluation to a Google-managed TXT record at _spf.google.com that lists the ip4 and ip6 ranges of the Gmail outbound servers; Google maintains it and adds new ranges as the service grows, so the operator never has to track individual IP addresses. The ~all qualifier gives a softfail result to any sender whose IP is not covered by the record; receivers typically accept such mail but mark it as suspicious. Google recommends ~all: with -all receivers may reject mail from senders missing from the record, and the Feb 2024 sender requirements do not ask for -all. Operators sending via third-party services (Mailchimp, SendGrid, Salesforce) must add those services BEFORE the include:_spf.google.com mechanism, watching the 10-lookup cap of RFC 7208 section 4.6.4.

Why does Google Workspace use include:_spf.google.com instead of an ip4 range?

Google Workspace / Gmail runs on a large and dynamic IP pool that changes as Google scales the service, adds datacenters, and migrates customers between Google Cloud regions. A hardcoded ip4 mechanism would require every tenant operator to manually update the SPF record every time Google added or retired an outbound IP — an operational impossibility at the scale of hundreds of millions of Workspace mailboxes and billions of Gmail consumer accounts. The include:_spf.google.com mechanism delegates SPF evaluation to a Google-managed TXT record at _spf.google.com that Google updates centrally. Read on 12 October 2026, that record holds only ip4 and ip6 ranges, so the include costs one of the 10 lookups of RFC 7208 section 4.6.4; the three nested includes (_netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com) that older guides count are no longer in it. Operators adding third-party senders have the remaining nine slots to budget.

How do I add Mailchimp or SendGrid to my Google Workspace SPF record?

Add the third-party senders include BEFORE the include:_spf.google.com mechanism, separated by a single space. Example: v=spf1 include:servers.mcsv.net include:sendgrid.net include:_spf.google.com ~all adds Mailchimp (servers.mcsv.net) and SendGrid (sendgrid.net) while keeping Gmail authorised. Each include costs at least one DNS lookup against the RFC 7208 section 4.6.4 10-lookup cap, and nested includes count as well: on 12 October 2026 the Google include cost 1, servers.mcsv.net 1 and sendgrid.net 2, so the record above cost 4 in total. Run the live SPF lookup count via dig +short or via the Domain Security Checker domain_checker.php tool BEFORE deploying to verify you remain under the 10-lookup cap. If the count exceeds 10 receivers including Gmail and Microsoft 365 return spf=permerror and DMARC alignment fails.

What is the _spf.google.com lookup count?

One, as read on 12 October 2026. Your include:_spf.google.com mechanism is one lookup for a TXT record, and the _spf.google.com record itself held only ip4 and ip6 mechanisms and the ~all terminator that day, none of which need further lookups. It used to be different: the record pointed on to three more, _netblocks.google.com, _netblocks2.google.com and _netblocks3.google.com, and cost four lookups in total; that figure still circulates in older guides. So the bare Workspace SPF record (v=spf1 include:_spf.google.com ~all) uses 1 of the 10 slots and leaves 9 for third-party senders. Google can restructure the record at any time, so check the current cost with dig +short txt _spf.google.com or with domain_checker.php.

What is the Google Workspace SMTP relay service problem?

The Google Workspace SMTP relay service (smtp-relay.gmail.com) is a Google-hosted outbound SMTP relay that on-prem applications and devices can use to send mail through Google with a Workspace tenant identity. The SPF gotcha is that mail relayed through smtp-relay.gmail.com still emits from Google IPs covered by _spf.google.com, but the envelope MAIL FROM may be a subdomain (e.g., notifications.example.com) that has no SPF record published. SPF evaluation returns spf=none for the subdomain and DMARC alignment fails. The fix is to publish v=spf1 include:_spf.google.com ~all at every subdomain that appears as an envelope sender.

How do I configure SPF for a Google Workspace tenant that also sends via on-prem mail servers?

Authorise BOTH outbound paths. The canonical hybrid SPF record is v=spf1 ip4:<onprem-ip-range> include:_spf.google.com ~all where <onprem-ip-range> is the public IP of the on-prem SMTP gateway. If the on-prem server uses the Workspace SMTP relay to forward outbound mail, then ONLY include:_spf.google.com is needed (mail leaves from Google IPs). If the on-prem server sends directly, BOTH ip4 and the Google include are required.

How do I verify my Google Workspace SPF record is working?

Run a five-step verification: (1) dig +short txt example.com confirms the record is published at the apex. (2) dig +short txt _spf.google.com confirms Googles include chain resolves. (3) The Admin console has no SPF setting and no SPF verdict: Google states that the record is added at the domain host, and the Authenticate email page is for DKIM signing. (4) Google Postmaster Tools at postmaster.google.com shows SPF pass rate over the last 30 days. (5) Email log search inspect the Authentication-Results header. The Domain Security Checker domain_checker.php tool surfaces the realised lookup count.

Does Google Workspace support SPF macros like %{i} or %{s}?

Google Workspace / Gmail publishes a _spf.google.com record that does NOT use SPF macros. SPF macros (defined in RFC 7208 section 7) are receiver-side evaluation features rather than sender-side authorisation features. Operators authoring their own SPF records for Workspace deployments should avoid SPF macros — most third-party tools handle the basic macro set but compatibility is uneven and macros add operational complexity for limited benefit.

What is the difference between -all and ~all on a Google Workspace SPF record?

The -all qualifier produces spf=fail for any sender whose IP is not covered by the record, and ~all produces spf=softfail. According to Google, with ~all receivers typically accept such messages but mark them as suspicious, and with -all they may reject them. Google recommends ~all and warns that -all with an incorrectly set up record can send more of your mail to spam, and that rejected messages cannot be used for troubleshooting. The Feb 2024 Google sender requirements ask for SPF or DKIM, and for SPF, DKIM and DMARC from bulk senders; they do not prescribe -all. DMARC treats fail and softfail alike, as an SPF failure, so your DMARC policy decides what happens to the message, not this choice. The ~all at the end of the _spf.google.com record only applies inside the include scope; what counts is the terminator of your own record.

12. Related guides

• help_spf_explained.php — the protocol-agnostic SPF pillar.
• help_spf_mechanisms_explained.php — the GW-TENANT-SEMANTIC-MECHANISM-INPUT companion documenting the eight RFC 7208 §5 SPF mechanisms (all, include, a, mx, ptr, ip4, ip6, exists) whose per-mechanism evaluation semantics determine how a Workspace tenant's v=spf1 include:_spf.google.com ~all canonical record actually resolves against the receiving MTA's SPF evaluator at send-time. Where THIS Workspace deployment guide tells you the canonical posture (include:_spf.google.com as the Google-managed macro envelope chaining the dynamically-maintained set of per-region Workspace egress IP ranges, with ~all as the SoftFail-terminator) and the spf_dns_syntax sibling above tells you HOW to encode that posture at the byte level into a syntactically valid TXT record, the mechanisms reference tells you WHY each mechanism in the record evaluates the way it does on the receiver side: the include: mechanism is a recursive macro that imports the included domain's SPF record into the current evaluation scope (so include:_spf.google.com expands to at evaluation time the current per-region Google IP ranges, not whatever they were when the publishing tenant authored the record — Google's egress pool is dynamically managed, the publishing tenant doesn't need to rotate); the ~all terminator's SoftFail semantics (RFC 7208 §2.6.5) trigger receiver-side spam-folder-routing rather than hard rejection (so a forwarded message that loses its envelope-from-domain alignment between sender and forwarder still reaches the inbox at major receivers like Gmail, Yahoo, Outlook even though SPF SoftFails — the SoftFail-vs-Fail decision is the single most consequential Workspace-tenant policy choice); the a / mx / ip4 / ip6 mechanism semantics for tenants supplementing the include:_spf.google.com macro with their own egress IPs from on-prem servers or third-party ESPs; the ptr mechanism's deprecation (RFC 7208 §5.5 SHOULD NOT — Workspace tenants must never use ptr); and the exists mechanism's macro-expansion semantics for advanced per-sender SPF policies (rare in Workspace deployments but technically permitted). Read the mechanisms reference when REASONING about the include:_spf.google.com macro envelope's per-mechanism resolution path on the receiver side — distinct from the qualifiers reference below (which documents the +/-/~/? PREFIX grammar) and the syntax reference above (which documents the byte-level TXT-record encoding rules).
• help_spf_dns_syntax.php — the GW-TENANT-DEPLOYMENT-SYNTAX-INPUT companion documenting the RFC 7208 section 3 byte-level DNS-record reference governing how the Google Workspace SPF policy is encoded as a TXT record at the publishing apex. Workspace tenants deploying SPF along the v=spf1 include:_spf.google.com ~all canonical posture frequently hit byte-level encoding gotchas the semantic-mechanism pages don't document: (i) the 255-octet DNS character-string limit being reached after chaining include:_spf.google.com with 3–4 third-party senders (Salesforce Marketing Cloud, Mailchimp, SendGrid, HubSpot) — the record must be split into multiple quoted strings within the SAME TXT RDATA, NOT into multiple TXT records (a second TXT record returns PermError per RFC 7208 §4.5 — receivers ignore both SPF records entirely); (ii) the "exactly one SPF record per domain" rule where a marketing team accidentally publishing a second v=spf1 record alongside the IT team's record kills all SPF authentication on the Workspace tenant's domain; (iii) the TXT-record-not-SPF-type-99 rule — RFC 7208 §3.1 deprecated DNS RR type 99 in November 2014; Workspace + every modern receiver ignores SPF type 99 publication entirely; (iv) the apex vs subdomain publication semantics — Workspace Routing's per-domain "Default routing" rules require SPF at every sending subdomain explicitly (wildcard TXT records do NOT cover the apex); (v) the case-sensitivity matrix (v=spf1 case-sensitive version tag, mechanism tokens case-insensitive, domain-spec case-insensitive per DNS). Read the SPF DNS record syntax page when AUTHORING the Workspace SPF record byte-by-byte: this Workspace deployment guide tells you WHICH include: chains belong in the record, the syntax page tells you HOW to encode them as a syntactically valid TXT record — the byte-level encoding rules whose violation causes Workspace receiver-side and external-receiver-side PermError even when every semantic mechanism (the _spf.google.com macro envelope, the ~all SoftFail-terminator, the third-party-vendor include set) is semantically correct.
• help_spf_qualifiers_explained.php — the WORKSPACE-TENANT-TAIL-QUALIFIER- AUTHORING-DECISION companion to this provider deployment guide. Where THIS page documents the canonical Workspace SPF record (v=spf1 include:_spf.google.com ~all) and the receiver-side semantic of its ~all SoftFail-terminator in passing, the qualifiers-explained spoke is the AUTHORING-DECISION REFERENCE documenting the RFC 7208 §4.6.2 qualifier-prefix grammar at the resolution depth Workspace tenants need when deciding whether to KEEP the default ~all or override it to -all on tenant-specific deliverability grounds. Four operationally-distinct Workspace- specific qualifier-prefix decision axes the spoke documents that this provider deployment guide individually references but never collectively interconnects: (i) why Google publishes ~all not -all — the multi-tenant ESP qualifier-choice constraint: Google cannot commit to terminal -all rejection on behalf of every Workspace tenant because tenants habitually authorise third-party senders (Mailchimp, SendGrid, Marketo, HubSpot) via additional include: tokens at their own apex SPF record's head, and the receiver-side hard-fail receipt risk of false-rejection of those third-party senders before the tenant's full sender inventory is recorded is a higher-cost outcome than the receiver-side soft-fail flag plus Authentication-Results annotation — the operational reason Workspace's published SPF cannot match the M365 hard-fail default; (ii) tenant-side override decision (~all → -all) — the Workspace-tenant SPF authoring contract that lets a sufficiently-mature tenant override the soft-fail default once the tenant's third-party-sender coverage is fully enumerated in the apex SPF record's include: and ip4:/ip6: mechanism list — the qualifiers-explained spoke documents the per-receiver enforcement consequence (Gmail Postmaster Tools, Microsoft EOP, Yahoo deliverability feedback) of a tenant-driven -all override; (iii) the catastrophic +all anti-pattern — the qualifiers-explained spoke catalogues the +all universal-pass anti-pattern that some Workspace tenants accidentally produce when they type +all believing it is a permissive default (it is the OPPOSITE — +all explicitly authorises EVERY IP on the internet to send mail as the tenant's domain), which is the operational reason the Workspace documentation never publishes a +all example and the canonical record uses ~all; (iv) the ?all neutral- terminator anti-pattern — the qualifiers-explained spoke catalogues the rare ?all (neutral) terminator, semantically equivalent to publishing no SPF record at all per RFC 7208 §2.6.2, which Workspace tenants in mid-migration between two providers sometimes temporarily publish to satisfy a third-party-platform's "you need an SPF record" deliverability-gate without committing to enforcement. Read the qualifiers-explained spoke when a Workspace tenant is authoring or reviewing their apex SPF record's tail qualifier and needs the operational depth on why ~all is the Workspace default, when overriding to -all is the right call, and why +all and ?all are anti-patterns with documented deliverability cost.
• help_spf_lookup_limit.php — the 10-lookup cap deep dive.
• help_spf_permerror_vs_temperror.php — the SPF error result-code deep dive.
• help_spf_forwarding_issues.php — SPF forwarding failures and ARC/SRS mitigations.
• help_dns_propagation.php — the WORKSPACE-SPF-TXT-RECORD-PUBLICATION- TO-RECEIVER-RESOLVER-CACHE-OBSERVATION- WINDOW companion to this Workspace SPF deployment reference. Where THIS page documents the canonical apex publication (v=spf1 include:_spf.google.com ~all) and the per-third-party-vendor include:-chain authoring discipline, the dns-propagation spoke documents the OPERATIONAL TTL-WINDOW between publication and receiver-side observation: (i) per-receiver resolver-cache TTL diversity — Workspace operators replacing the SPF record with an expanded include: chain see the new record at the authoritative nameserver within seconds, but Gmail / M365 / Yahoo / Mail.ru recursive-resolver caches continue serving the previous record for the authoritative TTL (or vendor-internal clamp), producing per-message spf=fail verdicts for legitimate egress from newly-included third-party senders during the propagation gap; (ii) negative- cache NXDOMAIN/NODATA SOA-min-TTL — operators publishing SPF for the first time on a new sending subdomain encounter the RFC 2308 negative-cache window during which receivers continue returning spf=none for the new subdomain; (iii) RFC 8767 serve-stale re-emergence — even after the authoritative TTL expires, a receiver configured per RFC 8767 may continue serving stale (pre-publication) SPF responses for hours under upstream- failure conditions; (iv) per- receiver Authentication-Results spf=temperror attribution — Gmail and M365 each cite spf=temperror reason="dns timeout" in Authentication-Results during the propagation gap, surfacing in the Workspace tenant's RUA aggregate-report rows and providing the per-message attribution vocabulary the operator consumes when investigating per-receiver SPF-rate dips. Workspace operators deploying SPF need the propagation spoke's per-receiver cache-ageing model to understand the legitimate-egress spf=fail spike that follows every SPF-record change and to time the DMARC enforcement ramp (p=quarantine → p=reject) AFTER the longest- tail receiver-resolver TTL elapses.
• help_include_vs_ip4_vs_a_vs_mx.php — the GW-TENANT-MECHANISM-SELECTION-DECISION-TREE companion documenting the per-mechanism trade-off matrix for Workspace tenants choosing between include:, ip4:, a:, and mx: mechanism tokens when authoring or extending their SPF record. The canonical Workspace posture (v=spf1 include:_spf.google.com ~all) uses include: exclusively for the Google-managed egress pool, but tenants regularly need to add SUPPLEMENTARY mechanisms for non-Workspace senders: third-party ESPs (Mailchimp, SendGrid, HubSpot — usually include:), on-prem-relay servers (ip4: when the relay has a static IP, or a: when DNS A-records track relay-pool membership), legacy SMTP gateways (mx: for backwards-compatibility when the MX hostnames also serve as the sending hosts), and partner-domain co-tenants (include: via a dedicated apex). The decision-tree page documents the four key axes: (1) the DNS-lookup-budget axis — include: consumes 1 lookup + the included record's own lookup count (which is why include:_spf.google.com is so budget-efficient — Google flattens its per-region egress pool internally, exposing only 1 lookup to the publishing tenant); ip4: consumes 0 lookups (raw IP literal); a: and mx: each consume 1 lookup plus all the A/MX record's resolved hostnames; (2) the rotation-frequency axis — managed macros like _spf.google.com auto-update when Google rotates egress; raw ip4: literals require operator-led DNS edits on every IP change; (3) the granularity axis — include: is all-or-nothing per included domain, ip4: can target a single host or CIDR, a:/mx: sit between (any host in the named A/MX-record set qualifies); (4) the receiver-side-evaluation-determinism axis — ip4: evaluates deterministically at receiver send-time (no DNS-lookup variance possible); include: / a: / mx: all evaluate against then-current DNS state (drift between publisher and receiver caches is possible during the propagation window after an upstream record change). Read the decision-tree page when designing a Workspace-tenant SPF record that SUPPLEMENTS the canonical include:_spf.google.com Google-managed macro with tenant-specific additional senders — the decision-tree documents the per-mechanism trade-off matrix the Workspace-tenant operator must navigate to select the right mechanism token for each supplementary sender.
• help_spf_for_microsoft_365.php — the SPF-for-M365 sibling deployment guide.
• help_dkim_for_google_workspace.php — the SAME-PROVIDER DKIM-SIDE COMPANION to this SPF-side Workspace deployment guide. Where this page documents the Workspace-side SPF posture (v=spf1 include:_spf.google.com ~all, the _spf.google.com macro envelope Google maintains, the realised-lookup-count budget, Workspace's per-route SPF behaviour), the DKIM-side spoke documents the parallel DKIM signing posture (Admin console → Apps → Google Workspace → Gmail → Authenticate email, the 2048-bit Workspace-managed keypair generation, the google._domainkey.<domain> TXT-record publication, the 24-72 hour TXT-propagation gate before Workspace will let an admin click Activate, the gappssmtp.com signing-identity gotcha where the Workspace default DKIM signing identity is <domain>.gappssmtp.com before custom DKIM is activated — which passes DKIM verification but does NOT align with the From-header organisation domain and therefore fails DMARC alignment despite the green DKIM verdict). Workspace operators reading this SPF-side guide for the dual-auth setup will need the DKIM-side spoke to complete the BEFORE-DMARC- ENFORCEMENT signing-posture work — DMARC requires EITHER SPF-aligned OR DKIM-aligned but operators SHOULD deploy both for forwarding-tolerance (SPF breaks on forwarding when the forwarder rewrites the envelope MAIL FROM but doesn't implement SRS; DKIM survives most forwarding because the signature travels in the message headers). This is the FIRST Workspace cross-protocol bridge from this SPF-side guide to the DKIM-side procedural sibling — operators landing here for SPF setup need the DKIM-side procedural deep dive to complete the dual-auth Workspace deployment.
• help_why_spf_alone_is_insufficient.php — why SPF must be paired with DKIM and DMARC.
• help_arc_explained.php — Authenticated Received Chain (RFC 8617).
• help_dmarc_for_google_workspace.php — the full DMARC + DKIM + SPF Workspace deployment guide.
• help_dmarc_for_microsoft_365.php — the DMARC-for-M365 deployment guide.
• help_dmarc_alignment.php — DMARC alignment (strict vs relaxed).
• help_dmarc_troubleshooting.php — DMARC failure diagnosis.
• help_dmarc_records_explained.php — DMARC tag-by-tag reference.
• help_mta_sts_for_google_workspace.php — the SAME-PROVIDER TRANSPORT-SECURITY COMPANION to this SPF-side Workspace deployment guide. Where SPF + DKIM + DMARC authenticate the SENDER identity of outbound Workspace mail at the application layer, MTA-STS protects the TRANSPORT layer for inbound Workspace mail by preventing opportunistic-TLS STARTTLS-stripping downgrades to cleartext between sending MTAs and the Workspace receivers aspmx.l.google.com / alt1-4.aspmx.l.google.com. Operators completing the dual-auth SPF + DKIM + DMARC deployment for Workspace should ALSO publish an MTA-STS policy ( _mta-sts.<domain> TXT + mta-sts.<domain> HTTPS host + /.well-known/mta-sts.txt policy file enumerating the four canonical Workspace MX hosts) so attackers cannot strip STARTTLS between forwarders and the Workspace tenant. SPF + DKIM + DMARC and MTA-STS are COMPLEMENTARY rather than overlapping: the former binds the From-header to an authorised sender (defense against spoofing), the latter binds the SMTP session to enforced TLS (defense against network-level MITM). This is the FIRST Workspace cross-protocol bridge from this SPF-side guide to the transport-security-side MTA-STS procedural sibling — operators completing this SPF deployment need the MTA-STS procedural deep dive to close the inbound transport-security gap that SPF / DKIM / DMARC do not address.
• help_mta_sts_for_microsoft_365.php — the CROSS-PROVIDER-INTEROP-WORKSPACE- OUTBOUND-TO-M365-RECEIVER-INBOUND-MX-MUST- RESPECT-M365-MTA-STS-POLICY companion to this Workspace-tenant SPF authoring guide. Where THIS page documents the Workspace- tenant SPF outbound-IP-authorisation discipline (the canonical include:_spf.google.com apex SPF record authorising Workspace-tenant outbound mail at the SENDER-SIDE IP-authorisation layer), the MTA-STS-for-M365 spoke documents the STRUCTURALLY-DISTINCT cross-provider TRANSPORT-LAYER policy the Workspace- tenant outbound mail MUST respect when the recipient is an M365-tenant inbound-MX at FOUR structurally-distinct cross- provider-interop dimensions: (i) Workspace outbound MTA (the mail-NNN.google.com / mail-out-N.amazonaws.com sender pool authorised by THIS page's SPF include:_spf.google.com directive) connecting to M365-tenant inbound MX (<tenant>-mail- protection.outlook.com) MUST respect the M365-tenant MTA-STS policy file's mx: *.mail.protection. outlook.com allow-list and mode: enforce directive — the Workspace-side outbound STARTTLS is enforced by the M365-side MTA-STS policy retrieved from https://mta-sts.<m365-tenant> /.well-known/mta-sts.txt by the Workspace sending MTA at policy-cache- TTL boundaries; the cross-provider SPF-outbound + MTA-STS-inbound coordination is structurally orthogonal to the Workspace-tenant's OWN MTA-STS policy file at mta-sts. <workspace-tenant>/.well-known/ mta-sts.txt; (ii) Workspace- SPF + M365-MTA-STS cross-provider publication-discipline KPI pair — the load-bearing observability surface for a Workspace tenant heavily emailing M365 tenants is the joint per-tenant ratio of (a) Workspace-side SPF-pass-rate at M365-receiver per the per-domain DMARC-aggregate (RUA) reports from Microsoft EOP back to the Workspace tenant AND (b) Workspace-outbound-to- M365-receiver TLS-handshake-success-rate per the Workspace-side TLS-RPT-aggregate feedback; when the SPF-pass-rate is high but the TLS-handshake-success-rate is low, the M365-tenant MTA-STS policy is either misconfigured at the receiver side OR the Workspace sending MTA is not retrieving / honouring the M365 MTA-STS policy correctly — the joint KPI surfaces the cross-provider transport-vs- authentication-layer health; (iii) SPF include:_spf.google.com IP-republishing-cadence vs M365-MTA-STS mx: allow-list-cadence cross-provider coordination — Google republishes the Workspace outbound IP pool published behind _spf.google.com on a multi-month cadence (silent additions and removals as Google scales the outbound mail-server fleet); Microsoft republishes the M365-tenant inbound MX hostname pattern in the MTA-STS policy file on a structurally-independent cadence (operator-controlled by the M365 tenant via the https://mta-sts.<tenant>/. well-known/mta-sts.txt publication); the two republishing cadences do not synchronise — a Workspace tenant heavily emailing M365 tenants must monitor BOTH at the cross- provider boundary; (iv) Workspace- side _spf.google.com sub- include cascade as authentication-layer cost-budget vs M365-side MTA-STS HTTPS- fetch as transport-layer cost-budget — the Workspace-tenant SPF authentication chain consumes ~2-3 DNS lookups for the include:_spf.google.com cascade out of the RFC 7208 §4.6.4 10- lookup ceiling (each Workspace SPF verification at the M365 EOP receiver costs the chain), the M365-side MTA-STS chain consumes one HTTPS fetch per max_age cycle (typically 86400 seconds — once per day per Workspace-MTA-to-M365-tenant pair) regardless of message volume; the cost- budget profiles complement each other rather than overlap at the cross-provider boundary. Read the MTA-STS-for-M365 spoke when designing a Workspace-tenant outbound mail-stream that includes heavy M365 recipient traffic — the M365-MTA-STS policy is the load-bearing receiver-side TLS-enforcement boundary the Workspace outbound MTA must respect at every Workspace-to-M365 transport- session boundary.
• DMARC multi-domain strategy — the MULTI-DOMAIN-WORKSPACE-ESTATE- SPECIFIC SPF-PUBLICATION-COORDINATION companion to this Workspace-tenant SPF reference. Where THIS page documents the per-Workspace-tenant canonical include:_spf.google.com publication step for a single Workspace-tenant primary domain, the multi-domain-strategy spoke is the MULTI-DOMAIN-WORKSPACE-ESTATE- SPECIFIC SPF-publication-coordination execution guide at FOUR per-multi- domain-Workspace-estate-to-SPF- publication coupling dimensions: (i) per-organizational-domain primary-brand-domain include:_spf.google.com publication coordination with sibling brand-subsidiary-domain Workspace-tenant SPF records — when the org-domain brand.com publishes the Workspace canonical include:_spf.google.com token, sibling brand-subsidiary domains brand-eu.com, brand-apac.com, brand-shop.com (which may each be a separate Workspace tenant or routed via the primary tenant's domain-aliasing feature) MUST publish coordinated include:_spf.google.com records to maintain estate-wide Workspace-emitted envelope-MAIL-FROM alignment — the multi-domain spoke documents the per-organizational- domain Workspace-tenant SPF- publication coordination operators execute to maintain consistent Workspace-tenant SPF-publication posture across the multi-domain Workspace estate; (ii) per- parked-domain defensive v=spf1 ~all publication coordination — when the org publishes the canonical Workspace include:_spf.google.com on primary brand domains, parked defensive domains like brand-typo.com, brand-cn.com, brand-misspelling.com MUST publish empty v=spf1 ~all records to prevent attacker-impersonation via parked-domain SPF-bypass — the multi-domain spoke documents the per-parked-domain SPF-publication- discipline coordination operators execute alongside Workspace-tenant SPF publication cycles; (iii) per-Workspace-domain-alias SPF-publication coordination discipline — when a single Workspace tenant hosts multiple domain aliases (brand.com primary + brand-eu.com alias + brand-shop.com alias), each per-domain _dmarc.<alias> + SPF publication MUST be coordinated across the Workspace-tenant's domain-alias inventory to maintain per-alias envelope-MAIL-FROM alignment — the multi- domain spoke documents the per- Workspace-domain-alias SPF- publication-coordination discipline operators execute across the Workspace tenant's domain-alias inventory; (iv) per-multi- domain-Workspace-estate cross- domain rua-feed aggregation discipline anchored on the Workspace- tenant primary-domain rua mailbox — the multi-domain strategy spoke's per-estate rua-mailbox-aggregation discipline (where every brand-domain publishes rua=mailto:dmarc@brand-rua-collector.com + the brand-rua-collector.com._report._dmarc.<alias> verification record) consumes the per-Workspace-tenant rua stream THIS page's Workspace-tenant SPF publication discipline contributes to — the multi-domain spoke documents the per-estate cross-domain rua-feed aggregation discipline operators execute to centralize the per-Workspace-estate SPF- publication-outcome evidence stream. Read the multi-domain-strategy spoke ALONGSIDE this Workspace-tenant SPF reference whenever the Workspace- tenant SPF-publication step THIS page documents is being scoped for execution across the organization's multi-domain Workspace estate — the multi-domain spoke is the canonical per-multi-domain-Workspace-estate SPF-publication-coordination reference whose per-organizational- domain + per-parked-domain + per- Workspace-domain-alias + per-estate- rua-feed-aggregation coordination disciplines are the LOAD-BEARING multi-domain-Workspace-estate execution discipline every estate- wide Workspace-tenant SPF- publication cycle depends on.
• Reverse DNS / PTR records for mail servers — the WORKSPACE-TENANT-EGRESS- SOURCE-IP-INVENTORY-AS-LOAD-BEARING- UPSTREAM-DOMAIN-INVENTORY-INPUT- INTO-PER-SOURCE-IP-REVERSE-ZONE-PTR- RR-PUBLICATION-DISCIPLINE companion to this Workspace-tenant SPF- publication guide. Where THIS page documents the per-Workspace-tenant canonical include:_spf.google.com include-cascade resolution chain (Workspace-tenant v=spf1 include:_spf.google.com ~all publication discipline, the per-shard Google-egress-IP inventory resolved via the include cascade's nested include:_netblocks.google.com / include:_netblocks2.google.com / include:_netblocks3.google.com subordinates, the per-Workspace- domain-alias publication-coordination discipline), the reverse-DNS-PTR spoke documents the per-source-IP IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-RR publication discipline whose Google-operated PTR-target hostname publication is the LOAD-BEARING upstream-prerequisite for the per- Workspace-tenant SPF-mechanism- aligned-pass-rate floor at FOUR per- Workspace-tenant-egress-shard-to-PTR- RR-publication-discipline coupling dimensions: (i) per-Workspace- tenant-egress-source-IP-inventory- resolved-via-include:_spf.google.com- as-load-bearing-domain-inventory- input-into-per-source-IP-reverse- zone-PTR-RR-resolution — the per-Workspace-tenant include:_spf.google.com mechanism resolution THIS page documents enumerates the Google- egress source-IP inventory whose per-source-IP reverse-zone PTR-RR resolution (against mail-*.google.com / *.smtp-out.googleusercontent.com Google-operated PTR-target hostnames) is the LOAD-BEARING upstream-input every receiver-side per-Workspace- tenant FCrDNS verification consumes to corroborate the per-source-IP identity-claim with the per- Workspace-tenant SPF-aligned-pass verdict; (ii) per-Workspace- tenant-egress-IP-FCrDNS-forward- confirmation-as-load-bearing- UPSTREAM-evidence-input-into- Postmaster-Tools-and-Gmail-reputation- scoring-of-Workspace-egress-spf=pass- verdicts — the per-source-IP forward-confirmed-reverse-DNS publication discipline THIS reverse- DNS spoke documents is the upstream- evidence input the Workspace-tenant Postmaster Tools reputation-model consumes alongside the per-Workspace- tenant spf=pass verdict THIS page documents; per-Workspace- tenant spf=pass evidence rows arriving from mail-*.google.com / *.smtp-out.googleusercontent.com source-IPs with well-formed FCrDNS are scored differently from per- Workspace-tenant spf=pass evidence rows arriving from Workspace-tenant-side ip4: / ip6: explicit-published IPs with absent or forged PTR-RRs; (iii) per- Workspace-tenant-hybrid-on-prem-IP- and-third-party-ESP-IP-supplemented- SPF-publication-discipline-as- upstream-input-into-Workspace-tenant- side-PTR-RR-publication-discipline- for-publisher-owned-source-IPs — the per-Workspace-tenant SPF- publication discipline THIS page documents allows ip4: / ip6: / per-third-party-ESP-include supplements alongside the canonical include:_spf.google.com for hybrid-Exchange on-prem-IP / on- prem-relay-IP / third-party-ESP- publication coverage; every per- Workspace-tenant-side publisher-owned source-IP added to the SPF policy REQUIRES per-source-IP reverse-zone PTR-RR publication discipline THIS reverse-DNS spoke documents to be in place at the Workspace-tenant-side DNS provider for the publisher-side FCrDNS-verified-spf=pass evidence row to be receiver-side reputation- score-eligible; (iv) per- Workspace-tenant-rua-aggregate-XML- row/auth_results/spf/result=pass- evidence-row-attribution-as- downstream-consumer-of-per-source- IP-FCrDNS-verified-identity- corroboration — the per- receiver per-Workspace-tenant per- source-IP per-day rua aggregate-XML row/auth_results/spf/result=pass + row/source_ip attribution evidence row THIS page's post-cutover observability layer consumes is reliably attributable to the per-Workspace-tenant egress-IP identity only when per-source-IP FCrDNS verification corroborates the per-source-IP spf=pass verdict — per-source-IP reverse-zone PTR-RR publication discipline THIS reverse-DNS spoke documents is the LOAD-BEARING upstream-prerequisite for per-Workspace-tenant per-source- IP rua-aggregate-XML evidence-row attribution integrity. Read the reverse-DNS-PTR spoke alongside THIS page when the Workspace-tenant operator asks "how does the per- Workspace-tenant egress-source-IP- inventory-as-resolved-via-include:_ spf.google.com translate into the per-source-IP reverse-zone PTR-RR publication discipline at the Google- operated PTR-target hostname layer" — the answer is FOUR-LAYERED: THIS page documents the per-Workspace- tenant SPF-publication discipline, the reverse-DNS-PTR spoke documents the per-source-IP reverse-zone PTR- RR publication discipline whose Google-operated PTR-target hostname publication is the load-bearing upstream-prerequisite for per- Workspace-tenant FCrDNS-verified- spf=pass evidence-row attribution integrity.
• MX records — the PER-WORKSPACE-TENANT-INBOUND-MX-AS- RECEIVER-SIDE-STRUCTURALLY-PAIRED- IDENTITY-RECORD-CLASS-TO-PER-TENANT- OUTBOUND-SPF-PUBLICATION-DISCIPLINE companion reference. Where THIS page documents the per-Workspace-tenant outbound SPF publication discipline (the per-tenant v=spf1 include:_spf. google.com ~all TXT record at the per-customer-domain master zone authorizing the per-Workspace-tenant cloud-egress IP pool to MAIL FROM as the per-customer-domain), the MX-records spoke documents the structurally-paired RECEIVER-SIDE per-Workspace-tenant inbound MX publication discipline (the priority-ordered five-record MX set 1 ASPMX.L.GOOGLE.COM + 5 ALT1.ASPMX.L.GOOGLE.COM + 5 ALT2.ASPMX.L.GOOGLE.COM + 10 ALT3.ASPMX.L.GOOGLE.COM + 10 ALT4.ASPMX.L.GOOGLE.COM whose per-customer-domain master-zone publication steers inbound mail traffic to the per-Workspace-tenant Gmail- managed inbound MTA frontend with provider-supplied multi-MX redundancy), across four per-Workspace-tenant-inbound- MX-to-per-tenant-outbound-SPF-coupling dimensions: (i) per-Workspace- tenant-inbound-MX-and-outbound-SPF-as- structurally-paired-record-class-pair — every per-Workspace-tenant per-customer- domain publication cycle requires BOTH the per-tenant outbound SPF TXT record (the v=spf1 include:_spf.google. com ~all authorization) THIS page documents AND the per-tenant priority-ordered five-record inbound MX set the MX-records spoke documents to fully wire the per-customer-domain to the Workspace tenant boundary; the two record classes are structurally paired at the per-customer-domain master zone publication event; (ii) per- Workspace-tenant-inbound-MX-publication- as-load-bearing-input-to-inbound-DMARC- evaluation-at-Gmail-frontend — the per-tenant priority-ordered five- record inbound MX set the MX-records spoke documents resolves the receiver- side endpoint where the per-message inbound DMARC evaluation occurs at the Gmail-managed inbound MTA frontend (across the priority-1 primary MX and the four ALT-priority-5/10 fallback MX targets); per-tenant inbound DMARC evaluation outcomes feed the per- Workspace-tenant Admin Console Authentication compliance-policy and the per-customer-domain Authentication- Results header emitted downstream; (iii) per-Workspace-tenant-inbound- MX-as-structurally-symmetric-load- bearing-input-to-per-tenant-RUA-feed- evidence-source-IP-attribution — the per-tenant inbound MX endpoint the MX-records spoke documents IS the per-tenant per-receiver-side MTA that emits per-day aggregate RUA reports BACK to the per-publisher's rua= mailto: tag-value mailbox; per- tenant inbound MX publication AT the per-customer-domain master zone GATES whether the receiver-side per-tenant RUA-emission infrastructure operates against the per-publisher's per- customer-domain; (iv) per- Workspace-tenant-inbound-MX-priority- ordering-discipline-vs-per-tenant- outbound-SPF-include-chain-discipline — the per-tenant priority-ordered five- record inbound MX set the MX-records spoke documents publishes Gmail-managed provider-supplied redundancy via explicit MX priority values (primary priority-1 + ALT-priority-5 pair + ALT-priority-10 pair), structurally SYMMETRIC TO the per-tenant outbound SPF include-chain discipline THIS page documents whose include:_spf. google.com token resolves to a per-Workspace-pool IP-block multi-CIDR authorization redundancy at the outbound boundary; the inbound MX priority ordering and the outbound SPF include chain are structurally-symmetric provider-supplied-redundancy disciplines at the per-customer-domain inbound and outbound boundaries. Read this WITH the per-Workspace-tenant outbound SPF publication reference when the per- customer-domain wiring sequence to the per-Workspace-tenant boundary reaches the operator's queue: THIS page documents the per-tenant outbound SPF publication discipline, the MX-records spoke documents the structurally-paired receiver-side per-tenant priority-ordered five-record inbound MX publication discipline whose per-customer-domain master-zone MX RDATA gates inbound mail traffic to the per-Workspace-tenant Gmail frontend the per-tenant outbound SPF publication symmetric receiver-side identity endpoint THIS page documents presupposes is operational.
• help_email_authentication.php — the cluster-intro pillar.
• help_email_authentication_glossary.php — the canonical glossary.
• Email Header Analyzer — paste any Authentication-Results header for human-readable verdict breakdown.
• Domain Security Checker — live DNS lookup with realised lookup count.
• DNS Record Generator — SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA wizard.
• DKIM alignment with DMARC — the PER-WORKSPACE-TENANT-DKIM-LEG- COMPANION-TO-THIS-PAGE-S-SPF-LEG-PUBLICATION- DISCIPLINE companion to this Workspace SPF publication discipline. Where THIS page documents the per-tenant v=spf1 include:_spf.google.com ~all SPF publication discipline and the per-tenant SPF-aligned-pass-rate baseline, the DKIM- alignment-with-DMARC spoke is the CO-EQUAL DMARC-LEG-ALTERNATIVE reference documenting the OR-conjunction semantics of RFC 7489 §6.6.2 (SPF-alignment-pass OR DKIM-alignment- pass → DMARC pass) and the per-message DKIM d=-tag-vs-RFC5322-From-domain alignment check the receiver's DMARC engine evaluates as the LOAD-BEARING ALTERNATIVE LEG when the SPF leg cannot contribute. The WORKSPACE-SPF-LEG-VS-DKIM-ALIGNMENT-LEG cross-reference establishes FOUR structurally-distinct per-Workspace-tenant DMARC-leg-coordination dimensions: (i) per-Workspace-tenant outbound mail traversing forwarders (group expansion at the recipient, vacation-message redirection, consumer-Gmail "fetch from another account" retrieval) breaks the SPF leg's envelope- client-IP-vs-include:_spf.google.com check because the forwarder's IP is the new envelope-client-IP — the DKIM leg survives because the d=-tag and signed- headers are byte-preserved through the forwarder hop; the DKIM-alignment- with-DMARC spoke documents why the DKIM- aligned leg is the SOLE LOAD-BEARING DMARC- pass path for forwarded Workspace egress mail; (ii) per-Workspace-tenant third-party-sender egress (mass-mail platforms, ticketing systems, marketing automation) routed through Workspace-aware SaaS relays preserves the SPF leg via include:<saas-sender>.com but the DKIM leg requires the SaaS sender to re-sign with the Workspace tenant's d=-tag (or the publisher to configure relaxed alignment adkim=r at the organizational-domain boundary); the DKIM-alignment-with-DMARC spoke documents the third-party-sender DKIM re-signing pattern complementing the per-Workspace- tenant SPF include-chain discipline this page documents; (iii) the per- Workspace-tenant DMARC enforcement-mode progression (p=none → p=quarantine → p=reject) the operator drives requires the per- publisher per-domain SPF-aligned-pass-rate AND DKIM-aligned-pass-rate to BOTH reach the per-Workspace-tenant per-mailbox- provider deliverability baseline before any ramp-step tightening commit is safe; the DKIM-alignment-with-DMARC spoke documents the per-publisher per-domain DKIM-aligned-pass-rate floor that complements the per-Workspace-tenant SPF- publication baseline this page documents; (iv) per-row aggregate-report triage of spf=fail rows attributable to Workspace egress mail forwarder paths requires the operator to correlate with the per-row dkim=pass AND policy_evaluated.dkim= pass verdict — when both hold, the per-row DMARC verdict is pass-via-DKIM-leg and no SPF-leg-failure remediation is warranted; the DKIM-alignment-with- DMARC spoke documents the per-row DKIM- alignment-pass verdict the per-row triage discipline consumes alongside the per-row SPF-aligned-pass verdict this page's Workspace-egress baseline produces. Read the DKIM-alignment-with-DMARC spoke alongside this Workspace SPF publication discipline when designing a per-Workspace- tenant DMARC-enforcement-mode progression plan so the operator's per-leg per- receiver per-day coverage assumption accounts for both the SPF-leg-via-include- chain discipline AND the DKIM-leg-via- d=-tag-alignment discipline as the co-equal RFC 7489 §6.6.2 OR-conjunction load-bearing alternatives.
• Business Email Compromise (BEC) — the per-attacker per-target-domain BEC-ATTACK-THREAT-MODEL companion to this per-Workspace-tenant per-custom- domain SPF publication tutorial. Where THIS page documents the per- Workspace-tenant per-custom-domain SPF publication discipline (the canonical v=spf1 include:_spf.google.com ~all Workspace-publisher-recommended SPF record, the _spf.google.com Google-managed include cascade authorising the Workspace outbound- MTA IP cone, the per-tenant SPF + DKIM authentication-leg coordination per RFC 7489 §6.6.2 OR-conjunction), the BEC spoke documents the per- attacker per-target-domain BEC attack-vector catalogue whose per- Workspace-tenant per-custom-domain DETERRENCE the per-tenant SPF- include publication directly SUPPORTS by limiting the per-target- domain envelope-sender to the Workspace-authorised outbound IP cone — every BEC-attacker attempt to spoof a per-target-domain envelope- sender from an unauthorised IP fails the per-message SPF evaluation, contributing to the per-domain DMARC p=reject enforcement verdict-distribution closing the BEC-attacker per-target-domain impersonation attack-surface. Read the BEC spoke when MOTIVATING the per-Workspace-tenant per-custom- domain SPF publication-discipline investment as a load-bearing per- target-domain BEC-deterrence envelope-layer authorization control.
• DKIM for Microsoft 365 — the CROSS-MAJOR-MAILBOX-PROVIDER-PER- M365-TENANT-DKIM-CRYPTOGRAPHIC- AUTHENTICATION-LAYER-PEER-TO-PER- WORKSPACE-TENANT-SPF-ENVELOPE- AUTHORIZATION-LAYER companion to this Workspace-tenant SPF reference. Where THIS page documents the per-Workspace- tenant per-custom-domain ENVELOPE- AUTHORIZATION-LAYER SPF deployment workflow (the per-Workspace-tenant v=spf1 include:_spf.google.com ~all envelope-MAIL-FROM authorization publication, the per-tenant per- custom-domain SPF mechanism-choice, the per-tenant Workspace-Admin-Console configuration, the per-tenant SPF- record propagation discipline), the DKIM-for-M365 spoke documents the CROSS-MAJOR-MAILBOX-PROVIDER per-M365- tenant per-custom-domain CRYPTOGRAPHIC-AUTHENTICATION-LAYER DKIM-signing deployment workflow (Exchange Admin Center > mail-flow > DKIM; per-tenant per-custom-domain DKIM-Enable toggle; per-tenant per- custom-domain dual-selector1 / selector2 rotation under selector1._domainkey.<d> + selector2._domainkey.<d> published as per-tenant CNAME pointers to per-tenant provider-managed selector*-<tenantId>._domainkey.<onmicrosoft-tenant>; per-tenant Rotate-DKIM-Keys cadence) whose per-M365-tenant cryptographic- authentication-layer publication is the CROSS-MAJOR-MAILBOX-PROVIDER per- tenant per-custom-domain MESSAGE-LAYER cryptographic-publication discipline operators of a Workspace ↔ M365 cross- major-provider per-publisher per- portfolio deployment publish in parallel. The WORKSPACE-SPF-VS-M365- DKIM cross-reference establishes FOUR structurally-distinct cross-major- mailbox-provider per-tenant per- custom-domain authentication-layer coupling dimensions: (i) BOTH major-mailbox-providers publish per- tenant per-custom-domain authentication-layer primitives at the per-tenant authoritative DNS zone — Workspace per-tenant publishes envelope- authorization-layer SPF include:_spf.google.com; M365 per-tenant publishes message- authentication-layer DKIM selector*._domainkey.<d> CNAME pointing at provider-managed per-tenant selector records — the per-publisher per-tenant per- custom-domain DNS-rooted authentication-primitive publication substrate is identical in shape but differs in per-provider per- authentication-layer publication-class; (ii) operators of a Workspace ↔ M365 cross-major-mailbox-provider per-portfolio deployment must complete BOTH the per-Workspace-tenant SPF envelope-authorization deployment AND the per-M365-tenant DKIM cryptographic- authentication deployment in BOTH provider admin consoles BEFORE progressing the per-portfolio DMARC ramp — the per-portfolio DMARC p=quarantine / p=reject ramp produces 100% receiver-side dkim=fail or spf=fail verdicts for the per-provider per-tenant per- custom-domain leg where the per- provider authentication-layer posture is absent; (iii) per- Workspace-tenant SPF mechanism-choice rotation discipline and per-M365- tenant DKIM-selector1 / selector2 rotation discipline share the per- publisher per-portfolio per-provider rotation cadence pattern — both require per-tenant per-custom- domain provider-side rotation execution + per-tenant authoritative- DNS-zone propagation-aware overlap windows during rotation; the operator- side per-portfolio per-provider per- tenant rotation discipline transfers between the two major-mailbox- providers; (iv) per-Workspace- tenant SPF include:_spf.google.com publication and per-M365-tenant DKIM- Enable activation in the Exchange Admin Center are the canonical per- major-mailbox-provider per-tenant complementary-authentication-layer publications without which the per- portfolio DMARC ramp produces a 100% per-message authentication-aligned- fail receiver-side verdict for the respective per-major-provider per- tenant per-custom-domain leg — the per-major-mailbox-provider per- tenant per-custom-domain ENVELOPE- authorization-layer (Workspace SPF) + MESSAGE-cryptographic-authentication- layer (M365 DKIM) joint publication is the load-bearing per-portfolio per-publisher cross-major-provider DUAL-AUTHENTICATION-LAYER posture every per-portfolio per-tenant per- custom-domain DMARC ramp depends on. Read this Workspace-tenant SPF reference when DEPLOYING the per- Workspace-tenant per-custom-domain envelope-authorization-layer SPF posture; read the DKIM-for-M365 spoke when DEPLOYING the cross-major- provider peer per-M365-tenant per- custom-domain message-authentication- layer DKIM-signing posture operators of a Workspace ↔ M365 cross-major- mailbox-provider per-portfolio deployment publish in parallel.
• BIMI explained — the PER-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-SPF-PUBLICATION-AS-LOAD-BEARING- BIMI-INDICATOR-RENDERING-ELIGIBILITY-FLOOR- PRECONDITION companion to THIS per- Workspace-tenant per-custom-domain SPF authoring reference. Where THIS page documents the per-Workspace-tenant per- custom-domain SPF publication workflow (the per-Workspace-tenant include:_spf.google.com mechanism alignment to the per-Workspace central Google-managed egress IP-range, the per-tenant per-custom-domain SPF -all hard-fail qualifier publication discipline, the per-tenant per- custom-domain SPF + DKIM + DMARC composite- publication coordination, the per-tenant per-custom-domain Workspace third-party- SaaS-sender egress IP coordination), the BIMI explained spoke documents the per- publisher per-domain BIMI brand-indicator- rendering eligibility cascade at FOUR per- SPF-publication-vs-BIMI-indicator-rendering coupling dimensions: (i) per- Workspace-tenant per-custom-domain SPF spf=pass-AND-aligned cascade AS load-bearing per-receiver per-message envelope-layer authentication-leg input feeding the DMARC composite-verdict that gates BIMI indicator-rendering eligibility — the per-receiver per- message BIMI indicator-rendering eligibility cascade at Yahoo / Gmail / Apple iCloud Mail / Fastmail consumes the per-publisher per- domain DMARC composite-verdict at the per- receiver per-message authentication boundary; the per-publisher per-domain DMARC composite-verdict STRUCTURALLY CONSUMES the per-Workspace-tenant per-custom-domain SPF spf=pass-AND-aligned envelope- layer authentication-leg the per-Workspace- tenant SPF publication discipline THIS page documents produces; (ii) per- Workspace-tenant per-custom-domain DMARC p=quarantine or p=reject enforcement-floor AS per-publisher per-domain BIMI indicator- rendering eligibility-cascade precondition — the per-receiver per-message BIMI indicator-rendering eligibility evaluator at Yahoo / Gmail / Apple iCloud Mail / Fastmail filters per- publisher per-domain BIMI selector TXT-RR publication for the per-publisher per-domain DMARC enforcement-floor (p=quarantine or p=reject with non-zero pct=) as the per-publisher per- domain authentication-discipline-floor precondition; the per-Workspace-tenant per- custom-domain SPF publication discipline THIS page documents IS the per-Workspace- tenant per-custom-domain envelope-layer authentication-leg input that the per- publisher per-domain DMARC enforcement- floor depends on for per-publisher per- domain DMARC-aligned-pass-rate maintenance at the per-receiver per-message DMARC composite-verdict boundary; (iii) per- Workspace-tenant per-custom-domain SPF + DKIM + DMARC composite-publication coordination AS per-publisher per-domain BIMI brand-indicator-rendering eligibility- baseline floor publication discipline — per-Workspace-tenant per-custom-domain BIMI selector TXT-RR publication is gated on per-publisher per- domain DMARC enforcement-floor maintenance; the per-Workspace-tenant per-custom-domain DMARC enforcement-floor maintenance is gated on per-Workspace-tenant per-custom- domain SPF + DKIM composite-publication coordination THIS page documents the SPF- leg publication discipline for as the per- Workspace-tenant per-custom-domain envelope- layer authentication-leg input the per- publisher per-domain BIMI indicator- rendering eligibility cascade depends on at the per-publisher per-domain composite- authentication-baseline floor publication boundary; (iv) per-Workspace-tenant per-custom-domain SPF include:_spf.google.com-cascade + RFC 7208 §4.6.4 10-DNS-lookup permerror- cap discipline AS per-publisher per-domain BIMI brand-indicator-rendering eligibility- cascade-fidelity preservation discipline — per-Workspace-tenant per-custom-domain SPF cascade traversals exceeding the RFC 7208 §4.6.4 10-DNS-lookup permerror cap collapse the per-receiver per- message SPF-leg verdict to spf=permerror; this collapses the per-publisher per-domain DMARC composite-verdict to per-receiver per- message dmarc=fail which collapses the per-publisher per-domain BIMI indicator-rendering eligibility cascade evaluation to per-recipient per-message no- indicator-rendering at the per-recipient inbox-list display layer brand-authenticity- signal boundary. Read THIS page when AUTHORING per-Workspace-tenant per-custom- domain SPF publication; read the BIMI explained spoke when UNDERSTANDING how the per-Workspace-tenant per-custom-domain SPF publication discipline THIS page documents IS the load-bearing per-tenant per-custom- domain envelope-layer authentication-leg input the per-publisher per-domain BIMI brand-indicator-rendering eligibility cascade depends on at the per-publisher per-domain DMARC composite-verdict-vs-BIMI- indicator-rendering-eligibility-floor coupling boundary.
• MTA-STS explained — the canonical RFC 8461 MTA-STS protocol primer every Workspace tenant operator should read alongside this SPF deployment walkthrough to understand how the per-tenant transport-layer https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt HTTPS-served policy file (declaring mx: aspmx.l.google.com + mx: *.googlemail.com for the Workspace inbound MX hosts) pairs with the per- Workspace-tenant per-custom-domain SPF v=spf1 include:_spf.google.com ~all DNS-published-TXT-record authorisation discipline this page documents to form the per-Workspace- tenant composite per-custom-domain envelope- authentication + transport-layer-encryption publication-discipline portfolio. Where THIS page locks the per-message envelope-MAIL-FROM authorisation at the application-layer, the MTA-STS-explained primer locks the per- receiving-MTA STARTTLS-enforcement boundary at the transport-layer — together they close the per-Workspace-tenant per-custom-domain envelope-authentication-and-encryption publication floor.
• DKIM best practices
• DMARC for shared-hosting providers — the per-hosting-provider per-customer- domain SPF-include-budget-vs-DMARC-ramp coordination companion to this Workspace SPF deployment guide. Where THIS page documents the canonical Workspace SPF posture (the v=spf1 include:_spf.google.com ~all per-custom-domain TXT-RR publication discipline covering Google's per-region SMTP egress IP ranges), the shared-hosting spoke documents the per-hosting-provider per- customer-domain DMARC ramp at which the composite Workspace + hosting-provider SPF publication discipline IS the load-bearing envelope-MAIL-FROM-authorisation primitive. Four coupling axes connect them: (i) per- hosting-provider per-customer-domain SPF publication MUST include BOTH the Workspace include:_spf.google.com macro (for inbound-routing customers using Workspace as MX-receiver) AND the hosting-provider outbound include (e.g. include:_spf.<hosting-provider>.net for cPanel-Plesk-driven outbound) under a single per-customer-domain TXT-RR — the include-count budget against the RFC 7208 §4.6.4 10-DNS-lookup-cap drives per-hosting- provider per-customer-domain include-budget discipline; (ii) per-hosting-provider per- customer-domain DKIM CNAME publication (Workspace google._domainkey CNAME to Workspace's signing infrastructure + hosting-provider default._domainkey TXT-RR for hosting-provider-relayed outbound) MUST coordinate dual-signer discipline such that per-customer-domain DMARC composite- verdict consumes BOTH application-layer DKIM signing identities; (iii) per-hosting-provider per-customer-domain DMARC enforcement-mode ramp p=none → p=quarantine → p=reject progression IS gated by the composite SPF + DKIM aligned-pass-rate floor measured across BOTH Workspace inbound-relay outbound AND hosting-provider outbound streams — the per-receiver per-day per-source-IP policy_evaluated evidence-row attribution in the per-customer-domain DMARC RUA aggregate-report stream IS the load- bearing operator-side observability signal driving the ramp progression decision; (iv) per-hosting-provider per-customer-domain SPF-flattening operational discipline (when the include-cascade budget exceeds the 10-DNS-lookup-cap) MUST be coordinated with per-customer-domain Workspace + hosting- provider SPF macro-update cadence — stale flattened-SPF emission accumulates per-customer-domain SPF-aligned-pass-rate floor regression at the egress-IP-pool rebalancing boundary. Read the shared-hosting spoke alongside this Workspace SPF deployment guide when AUTHORING per-hosting-provider per-customer-domain composite SPF + DKIM publication discipline with Workspace include coordination, when AUDITING per-customer- domain include-budget against the 10-DNS- lookup-cap, or when PLANNING per-customer- domain DMARC enforcement-mode ramp sequencing against per-hosting-provider per-customer- domain composite Workspace + hosting-provider publication-discipline cadence.
• DKIM troubleshooting
• DKIM-Signature header explained
• DMARC myths and misconceptions
• DMARC for cPanel — the split-sending deployment case for the Workspace SPF directive this page documents. A common shared-hosting topology routes mailboxes through Google Workspace (include:_spf.google.com) while a cPanel/Exim node also sends application mail (web forms, order confirmations) from the same custom domain — so the apex SPF record must authorise BOTH the Workspace envelope-MAIL-FROM leg AND the cPanel server's outbound IP within the single RFC 7208 §4.5 SPF TXT-RR and under the §4.6.4 10-DNS-lookup cap. The cPanel guide documents how cPanel's Email Deliverability tool auto-generates the cPanel-side SPF/DKIM and where the operator must hand-merge the Workspace include: so neither sending path produces a DMARC spf=fail row. Read the cPanel spoke when a Workspace tenant also hosts a cPanel sending node on the same domain.
• DMARC policy modes — the enforcement ramp the Workspace SPF record feeds. A correct include:_spf.google.com -all record under the 10-lookup cap keeps the SPF-aligned-pass leg solid, which is the evidence you need to advance the DMARC policy from p=none through p=quarantine to p=reject; this spoke walks the three modes and the ramp between them.
• MTA-STS vs DANE for SMTP — once your Workspace SPF record holds the SPF-aligned-pass leg, the next hardening layer is the SMTP transport itself. Google Workspace supports MTA-STS for inbound TLS enforcement; this head-to-head reference compares HTTPS-PKI-anchored MTA-STS against DNSSEC-anchored DANE so you can decide which transport-security discipline fits a Workspace tenant whose registrar may or may not support DNSSEC.
• Microsoft SNDS + JMRP monitoring — the Microsoft-side counterpart of Google Postmaster Tools: when the same streams also reach Outlook.com/Hotmail recipients, SNDS is where Microsoft exposes per-IP GREEN/YELLOW/RED filter verdicts and JMRP is its complaint feedback loop.

13. Get started with DMARC Analyzer

Try the free tools first — no signup required:

• Check my Google Workspace SPF setup — paste your Workspace tenants apex domain to see the live SPF posture and realised lookup count.
• Analyze a Google Workspace message header — paste any Authentication-Results header to surface SPF / DKIM / DMARC / ARC verdicts in human-readable form.

When you're ready to ingest your DMARC aggregate reports for ongoing monitoring, create a free account — the free tier covers up to 10 reports per month and surfaces the same per-source SPF pass-rate data the paid tiers do.