DMARC Analyzer

TL;DR

• Google Workspace senders need three DNS records: SPF with include:_spf.google.com, DKIM at google._domainkey.<your-domain> (generated via Admin Console "Authenticate email"), and DMARC at _dmarc.<your-domain> starting at p=none.
• Google's Feb 2024 bulk-sender requirements demand working SPF and DKIM with at least one of them aligned with the From: header, DMARC at minimum p=none (bulk senders strongly encouraged at p=quarantine or stronger), RFC 8058 one-click List-Unsubscribe, and Google Postmaster Tools spam-complaint rate under 0.3% for any domain sending >5000 messages/day to gmail.com or yahoo.com.
• SPF record: v=spf1 include:_spf.google.com ~all during rollout, harden to -all in production. Add additional include: for every third-party sender (SendGrid, Mailchimp, etc.) — stay under the 10-DNS-lookup limit.
• DKIM workflow: Apps > Google Workspace > Gmail > Authenticate email. Generate a 2048-bit key, publish the TXT record at google._domainkey, wait 24-48h for DNS propagation, click "Start authentication" to enable signing.
• DMARC rollout: v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com first. Ingest reports for 2-6 weeks to inventory every sender. Advance to p=quarantine only after every legitimate sender is aligned. Never skip from p=none to p=reject.
• Aligning SaaS senders (the #1 alignment failure for Workspace admins): enable DKIM with d=your-domain.com in every SaaS provider's settings (most support CNAME-delegated subdomain selectors). SPF alignment usually requires a custom bounce-domain configuration in the SaaS provider.
• Google Postmaster Tools (postmaster.google.com) is the receiver-side reputation + deliverability dashboard for your Workspace tenant's mail to Gmail. Set it up alongside DMARC — they answer complementary questions.
• DMARC Analyzer ingests Google's daily aggregate reports via includes/DmarcParser.php and surfaces the per-sender / per-IP / per-day breakdown that drives the alignment fix-up phase.

1. What this guide covers

This is the operator-implementation walkthrough for deploying SPF, DKIM, and DMARC on a domain whose mail is sent by Google Workspace (formerly G Suite). It assumes you are the administrator of a Workspace tenant and have access to:

• The Google Workspace Admin Console (admin.google.com) — used to generate the DKIM key and enable outbound signing.
• Your domain's DNS provider (Cloudflare, Route 53, GoDaddy, etc.) — used to publish the SPF, DKIM, and DMARC TXT records.
• A working email mailbox on the domain to receive DMARC aggregate reports (or a third-party report-ingestion service — DMARC Analyzer is one option).

The guide is structured as five sequential deployment steps (SPF → DKIM → DMARC at p=none → alignment fix-up → enforcement) that mirror the canonical DMARC rollout with Google-Workspace- specific UI paths, syntax, and gotchas.

What this guide does not cover:

• Hosting DNS at Google Domains specifically — Google Domains was sold to Squarespace in 2023 and is no longer a Google product. Any DNS provider works.
• Receiving inbound mail for non-Workspace domains via Workspace's split delivery — a separate Workspace feature unrelated to outbound DMARC.
• Google's bulk-sender enforcement actions in detail — covered in section 2 and at support.google.com/mail/answer/81126.

2. Why DMARC matters now: the Feb 2024 bulk-sender requirements

In February 2024 Google (jointly with Yahoo) introduced sender requirements that apply to any domain sending more than 5000 messages per day to gmail.com or yahoo.com combined. The Feb 2024 cutover is the single largest DMARC-adoption driver in the industry to date and the proximate reason most Workspace administrators are revisiting email authentication in 2024-2025.

The five Feb 2024 requirements:

1. SPF must be set up and pass for the sending domain (RFC 7208).
2. DKIM must be set up and pass (RFC 6376). The domain in the visible From: header must also align with either the SPF domain or the DKIM domain — that is what DMARC identifier alignment requires; aligning both is good practice.
3. DMARC TXT record published with at minimum p=none — and bulk senders are strongly encouraged to advance to p=quarantine or p=reject over time.
4. RFC 8058 one-click List-Unsubscribe (List-Unsubscribe-Post header + List-Unsubscribe with both a mailto: and an https: URL) on every commercial / marketing message.
5. Spam complaint rate < 0.3% as measured by Google Postmaster Tools (with anything >0.1% as a yellow flag).

Bulk senders that fail one or more requirements have their mail delivered to spam at Gmail and Yahoo, or rejected entirely at the SMTP boundary. The 5000-messages-per-day threshold catches every commercial mailing-list operator, most B2B SaaS senders, and any organisation running marketing automation against the consumer-mailbox segment.

Even non-bulk senders below the 5000 threshold should publish DMARC for two reasons:

• Spoofing protection. Without DMARC, attackers can forge messages with your domain in the From: header from anywhere on the internet. Workspace's own SPF / DKIM on your outbound mail does nothing to stop a different sender at a different IP from spoofing your domain at another receiver. DMARC at enforcement is what closes that gap.
• Threshold drift. The 5000/day cutoff is the threshold today; Google's stated direction is universal enforcement. Deploying DMARC at p=quarantine now means you are not exposed when the threshold drops.

3. Prerequisites

• Google Workspace super-administrator role on the primary domain. DKIM generation lives under Apps > Google Workspace > Gmail > Authenticate email and requires super-admin privileges. A delegated admin with the "Gmail" delegated permission can also access this page.
• DNS edit access for the primary domain. You will publish three TXT records (SPF at apex, DKIM at google._domainkey, DMARC at _dmarc) and potentially more if you have additional sending sources.
• A monitored mailbox on the domain (or a third-party DMARC report ingestion service such as DMARC Analyzer). Reports arrive as gzip-compressed XML attachments — a typical setup uses a dedicated address like dmarc-reports@your-domain.com.
• Inventory of every legitimate sender for the domain. Workspace is the obvious source, but the list usually also includes a marketing platform (Mailchimp, Klaviyo, Customer.io), a transactional relay (SendGrid, Mailgun, Amazon SES, Postmark), a CRM (Salesforce, HubSpot), helpdesk software (Zendesk, Intercom), and potentially shadow-IT senders only the reports will surface.

4. Step 1: Configure SPF with _spf.google.com

Publish a single SPF TXT record at the domain apex (the root of your zone). Google Workspace publishes its sender IPs at _spf.google.com — a nested include that resolves to the union of every Workspace-side mail source (Gmail, Calendar invitations, Apps Script, etc.). Google updates the underlying IPs without operator intervention.

Minimum record for a Workspace-only sender:

your-domain.com.   IN TXT  "v=spf1 include:_spf.google.com ~all"

Production record once SPF passes are clean (note the -all hard fail):

your-domain.com.   IN TXT  "v=spf1 include:_spf.google.com -all"

If you also send via third-party providers, add each provider's include: in the same record (RFC 7208 §3.2 mandates a single SPF record per domain — multiple records cause a permerror):

your-domain.com.   IN TXT  "v=spf1 include:_spf.google.com include:sendgrid.net include:mailgun.org -all"

Watch the 10-DNS-lookup limit (RFC 7208 §4.6.4). Every include:, a:, mx:, exists:, and redirect= counts toward the limit, and nested includes count for their full expansion. The DMARC Analyzer Domain Security Checker reports the live lookup count against any SPF record.

Verify the record with dig +short txt your-domain.com after publication, or via the Domain Security Checker.

5. Step 2: Configure DKIM via the "Authenticate email" feature

1. Sign in to admin.google.com as a super-administrator.
2. Navigate to Apps > Google Workspace > Gmail > Authenticate email. The shortcut URL is admin.google.com/ac/apps/gmail/authenticateemail.
3. Select the primary domain from the domain dropdown. The "Generate new record" button appears.
4. Click Generate new record. Accept the default 2048-bit key (the Admin Console UI also offers 1024-bit; 2048 is what RFC 8301 recommends and the only option that should be selected in production).
5. The Admin Console displays a TXT record to publish:

   Name: google._domainkey
   Type: TXT
   Value: v=DKIM1; k=rsa; p=<long-base64-public-key>

   Copy the entire Value field — public keys for 2048-bit RSA are around 400 bytes of base64 and your DNS provider may need to split it into multiple character-quoted strings (most modern providers handle this automatically).
6. At your DNS provider, publish the record with hostname google._domainkey (the provider may append your domain automatically; the final FQDN is google._domainkey.<your-domain>).
7. Wait 24-48 hours for DNS propagation. Most providers complete the change in minutes to a few hours; the Admin Console's "Start authentication" button will refuse to activate until Google can resolve the public key.
8. Return to the Admin Console "Authenticate email" page and click Start authentication. Workspace begins DKIM-signing all outbound mail under your domain immediately.
9. Verify by sending a test message to a Gmail address you control, opening Show original in Gmail, and confirming the Authentication-Results header shows dkim=pass header.d=your-domain.com.

Key rotation: re-running Generate new record creates a second selector (typically google2._domainkey); publish both selectors during the transition window, then activate the new one and remove the old. Workspace does not currently support Ed25519 (RFC 8463) DKIM keys; RSA-2048 is the production standard.

6. Step 3: Publish DMARC at p=none

With SPF + DKIM working, publish a DMARC TXT record at _dmarc.<your-domain>:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Tags explained:

• v=DMARC1 — protocol version, always first.
• p=none — the reporting-only phase. Receivers will NOT change disposition based on DMARC outcomes; instead they will send daily aggregate reports describing every authentication result.
• rua=mailto:dmarc-reports@... — destination for daily aggregate (RUA) reports.
• fo=1 — request a forensic (RUF) report on any DMARC failure (most major receivers including Google do not send forensic reports — see DMARC aggregate reports deep dive — but publishing fo=1 is the operator signal).

Confirm the record is live with dig +short txt _dmarc.your-domain.com or via DMARC Analyzer's Domain Security Checker.

Reports begin arriving within 24-48 hours. Google's reports arrive daily between 04:00 and 09:00 UTC. Other major receivers (Microsoft, Yahoo, Comcast) send on similar cadences. Forward the rua= mailbox into DMARC Analyzer (via IMAP, Graph, or manual upload through the dashboard) for parsing.

7. Step 4: Inventory legitimate senders and fix alignment

Read aggregate reports for 2-6 weeks. For each unique sending IP / sending domain combination, determine:

• Is this a legitimate sender? Workspace itself is obvious; the marketing platform you set up two years ago may not be.
• Is the sender aligned? Either SPF must pass AND the envelope MAIL FROM domain match your visible From: header (organisational-domain match for relaxed alignment), OR DKIM must pass AND the d= in the signature match your visible From: header.
• If not aligned, what is the gap? Workspace mail aligns natively. SaaS senders almost always need a configuration change.

The #1 alignment failure for Google Workspace senders is the SaaS-sender case: a third-party service (SendGrid, Mailgun, Customer.io, Mailchimp) sends on your behalf with the From: header set to marketing@your-domain.com but the envelope MAIL FROM domain pointing at the SaaS provider's bounce domain (bounces.sendgrid.net, etc.). SPF evaluates the bounce domain (passes) but doesn't align with your visible From: — DMARC fails.

Fix: enable DKIM signing with d=your-domain.com in each SaaS provider's settings. Most providers let you publish a CNAME under a unique subdomain (e.g. em1234._domainkey.your-domain.com CNAME → em1234.sendgrid.net) that delegates the DKIM key to the SaaS provider while the signing domain stays under your control. After CNAME publication and SaaS activation, the next day's reports show dkim=pass aligned with your domain — DMARC passes.

Continue iterating until every legitimate sender shows in reports as DMARC-pass. Note that some senders may take a full week to surface (cron-driven monthly billing emails, one-off campaign sends).

8. Step 5: Advance from p=quarantine to p=reject

Once every legitimate sender is aligned, advance the DMARC record to p=quarantine:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Receivers begin delivering DMARC-failing mail to spam. Continue monitoring reports for unexpected failures. A common pattern: a monthly cron job sends from an unaligned legacy script the operator forgot about — the first month at p=quarantine surfaces it loudly.

After 1-3 months at p=quarantine without unexpected failures, advance to p=reject:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; fo=1"

DMARC-failing mail is now bounced at the SMTP boundary. Spoofing of your domain at DMARC-honouring receivers is no longer possible. You have completed the rollout.

Never skip from p=none to p=reject. The p=quarantine intermediate phase exists specifically so failed mail goes to spam (recoverable) rather than bouncing (unrecoverable). The single most common self-inflicted email outage in DMARC rollouts is skipping this phase. See the DMARC policy rollout deep dive for the full rationale.

For granular ramping, use the pct= tag: p=quarantine; pct=5 applies the quarantine disposition to 5% of failing mail, leaving 95% at p=none. RFC 7489 §6.3 defines the semantics; note that the dmarcbis draft deprecates pct= so this is a transitional feature.

9. Google Workspace-specific gotchas

• Email aliases vs send-as addresses. Workspace lets users configure a send-as address from a different domain (e.g. user alice@your-domain.com sends as alice@your-other-domain.com). The From: header is rewritten but the DKIM signature is anchored to the Workspace-primary domain. If your-other-domain.com has DMARC at p=reject, these messages will fail. Either align both domains' DKIM under the same key, or use a Workspace secondary-domain configuration.
• Multiple Workspace tenants sharing a domain. Only one Workspace tenant can own DKIM for a given domain at a time — the selector google._domainkey is single-instance. If two tenants need to send for the same domain, only one of them can sign with the canonical selector; the other must rely on SPF alignment or a separate non-Workspace DKIM key.
• Workspace Routing rules. If you have Workspace Routing configured to send certain mail through an external smart host, that smart host becomes a new sending source. The Workspace DKIM signature may break if the smart host modifies headers. Add an SPF include: for the smart host, configure DKIM on the smart host, and verify alignment in reports.
• Gmail vacation auto-replies are sent from Workspace and carry the google DKIM signature like any normal message — but the envelope MAIL FROM is a Workspace-internal bounce domain. SPF alignment may fail for these; rely on DKIM alignment which works correctly.
• The default google._domainkey selector is the recommended choice, not the only one — the Admin Console lets you enter a different prefix selector when you generate the key. You need a different prefix when the domain already has a DKIM key under the prefix google, for example from another tenant or a relay.

10. Common Google Workspace + DMARC mistakes

1. Clicking "Start authentication" before DNS propagates. The Admin Console rejects activation with "Authentication unsuccessful" until Google can resolve the published google._domainkey TXT record. Wait 24-48 hours after publication.
2. Publishing the DKIM key as a CNAME instead of a TXT. Google Workspace's DKIM record is a TXT — unlike Microsoft 365 which uses CNAME delegation. Confirm the record type at your DNS provider.
3. Forgetting to advance past p=none. The reporting-only phase does NOT stop spoofing. Advance to enforcement after 2-6 weeks of clean reports.
4. Generating a 1024-bit DKIM key. The Admin Console UI offers 1024 as an option; do not select it unless your DNS host cannot hold a longer record. RFC 8301 (2018) allows 1024 bits only as the minimum and recommends at least 2048.
5. Two SPF records on the same domain. RFC 7208 §3.2 mandates a single SPF record. Merge multiple records into one with concatenated include: directives.
6. SPF over 10 DNS lookups. Nested include: chains commonly blow the limit. Use Domain Security Checker to count lookups and flatten or remove unused providers.
7. Skipping SaaS-sender alignment. The marketing platform that sends from noreply@your-domain.com without DKIM-signing under your domain will fail DMARC even after Workspace is clean. Configure CNAME-delegated DKIM in every SaaS provider's settings.
8. Publishing DMARC at p=reject without alignment fix-up. The fastest path to a self-inflicted email outage. Always ingest reports at p=none for 2-6 weeks first.
9. Ignoring Google Postmaster Tools. Postmaster Tools and DMARC reports answer complementary questions: DMARC reports describe inbound spoofing at OTHER receivers, Postmaster Tools describes Workspace's own deliverability and reputation at Gmail. Both are free; set up both.
10. Treating DMARC as one-time work. New SaaS deployments, partner integrations, and acquired domains constantly surface new senders. Indefinite monitoring is the ongoing cost of DMARC enforcement.

11. Troubleshooting

• "Authentication unsuccessful" error on Start authentication. Google cannot resolve your published google._domainkey TXT record. Cause: DNS hasn't propagated, the record is published at the wrong host (e.g. at the apex instead of google._domainkey), or the Value field was truncated. Wait, verify with dig +short txt google._domainkey.your-domain.com, and republish if needed.
• "My Workspace mail goes to spam at Gmail despite DMARC pass". DMARC pass does not guarantee inbox delivery — Gmail's content-based spam filter operates downstream. Check Google Postmaster Tools for the reputation signal and spam-complaint rate. Anything >0.1% in Postmaster Tools is a warning; >0.3% triggers spam-folder delivery regardless of DMARC.
• "DMARC reports show DKIM pass + SPF pass but DMARC fail". An alignment failure. The SPF-passing domain or DKIM-signing domain does not match the visible From: header. See DMARC alignment explained for the deep dive — the SaaS-sender CNAME delegation pattern is the canonical fix.
• "My SPF record is failing with permerror". Almost always the 10-DNS-lookup limit. Run Domain Security Checker to see the live count.
• "DKIM signature fails on some receivers but passes at Gmail". Usually a canonicalization mismatch or a header-modifying intermediate (mailing-list software, security gateway). Inspect the message at the downstream receiver via the Email Header Analyzer.
• "No DMARC reports arriving". Common causes: the rua= mailbox itself fails DMARC (the records haven't propagated long enough yet, or the mailbox is on a different domain without cross-domain authorisation), the mailbox spam filter is flagging reports as bulk mail, or the report-receiver-side mail-flow is broken. See DMARC aggregate reports deep dive.
• "How do I see my outbound DKIM signature in Workspace?" Send a test message to a Gmail address you control. Open the message, click the three-dot menu, and choose Show original. The Authentication-Results header shows dkim=pass header.d=your-domain.com when signing is working.

12. Frequently asked questions

How do I set up DMARC for Google Workspace?

Five steps. Publish SPF at the domain apex with include:_spf.google.com. Generate a 2048-bit DKIM key via Admin Console > Apps > Google Workspace > Gmail > Authenticate email and publish the resulting TXT record at google._domainkey. Publish DMARC at _dmarc starting at p=none with a rua= mailbox. Ingest reports for 2-6 weeks to align every legitimate sender. Advance through p=quarantine to p=reject.

What is the Google Workspace SPF include?

include:_spf.google.com. Minimum record: v=spf1 include:_spf.google.com ~all; production: v=spf1 include:_spf.google.com -all. Stay under the 10-DNS-lookup limit when adding third-party senders.

What DKIM selector does Google Workspace use?

google. The TXT record lives at google._domainkey.<your-domain>. A different prefix selector can be entered when the key is generated.

What are Google's Feb 2024 bulk sender requirements?

For domains sending >5000 messages/day to gmail.com or yahoo.com: working SPF + DKIM with at least one of them aligned with From:, DMARC at minimum p=none, RFC 8058 one-click List-Unsubscribe, and spam complaint rate < 0.3% in Postmaster Tools. Failure to comply causes spam-folder delivery or SMTP rejection.

How long does Google Workspace DKIM setup take to propagate?

Typically 24-48 hours, though many DNS providers complete the change in minutes to a few hours. The Admin Console "Start authentication" button refuses to activate until Google can resolve the published key.

Why is my DMARC failing despite SPF and DKIM passing on Google Workspace?

Alignment failure. SPF or DKIM passes on a domain different from your visible From: header — typically a SaaS sender using its own bounce domain. Fix by enabling DKIM with d=your-domain.com in the SaaS provider, most commonly via CNAME-delegated subdomain selectors.

Do I need DMARC if I only use Google Workspace?

Yes. Workspace's outbound authentication does not stop attackers from spoofing your domain at other receivers — DMARC at enforcement is what closes that gap. The Feb 2024 bulk-sender requirements additionally demand DMARC for any high-volume Workspace tenant.

Where do I see DMARC reports for Google Workspace mail?

Receivers (Google, Microsoft, Yahoo, and others) send daily aggregate reports to the rua= mailbox in your DMARC record. DMARC Analyzer ingests these via includes/DmarcParser.php and surfaces the per-sender breakdown. Google Postmaster Tools at postmaster.google.com is a separate sender-side dashboard for outbound reputation at Gmail.

13. Related guides

• Email authentication explained — the cluster-intro pillar covering the full ecosystem (SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC).
• DMARC explained — the DMARC primer for the broader ecosystem.
• DMARC myths and misconceptions debunked (the GW-TENANT-MYTH-CLARIFICATION companion to this Workspace deployment guide) — the GW-TENANT-MYTH-CLARIFICATION companion documenting the 18 most common DMARC mental-model ERRORS — with specific emphasis on the Google-Workspace-specific variants of each — that Workspace tenants encounter while executing the deployment workflow THIS page documents. Where THIS page documents the WORKSPACE-SPECIFIC DMARC PUBLICATION WORKFLOW (the canonical include:_spf.google.com SPF record, the Workspace-managed DKIM signing-key at google._domainkey selector, the _dmarc.<domain> TXT publication, the Google Admin Console verification + RUA-mailbox configuration workflow, the third-party-sender catalogue of Workspace-compatible secondary include: tokens), the myths- and-misconceptions spoke documents the Workspace-tenant variants of the 18 recurring DMARC myths: (i) "Google Workspace handles DMARC for me automatically" — partial truth that DOES NOT hold for the _dmarc publication step or the third-party-sender inventory; the Workspace Admin Console DOES NOT publish the _dmarc TXT record, only the google._domainkey CNAME and the receive-side DKIM-verifier config; (ii) "I added spf.protection.outlook.com to my SPF so DMARC works" — Workspace-specific variant: operator migrating FROM M365 to Workspace leaves the Outlook include in place, producing an SPF record with both include:spf.protection.outlook.com AND include:_spf.google.com that burns through the 10-lookup budget before any third-party-sender; (iii) "My SaaS senders are already DMARC- aligned" — Workspace-specific variant: Salesforce email-relay sends From: customer-domain.com via Salesforce-managed SPF/DKIM but the d= domain in the DKIM signature is salesforce.com not the customer domain, producing dkim=pass + aligned=false in every row until the customer enrolls in Salesforce's signed-by-domain feature; (iv) "DMARC blocks all phishing" — Workspace-specific variant: Gmail users see display-name spoofing in their inbox post-p=reject and assume DMARC is broken; the misconception is that Gmail's display-name filtering is the last-line defense, not alignment; (v) "p=none means DMARC is off" — Workspace-tenant variant: Admin Console UI labels the published p=none policy as "Monitoring" which is technically correct but reinforces the misperception that monitoring is optional rather than mandatory for building the sender inventory the Workspace tenant needs BEFORE Phase 4 advancement; (vi) "I'll just go straight to p=reject" — Workspace- tenant variant: tenant migrating from a prior provider's p=reject record assumes the existing policy is still valid for Workspace-routed mail, breaking legitimate-mail until the Workspace- specific include:_spf.google.com + google._domainkey CNAME + DKIM verification cycle is complete. Read THIS Workspace deployment guide WITH the myths-and-misconceptions spoke when authoring the Workspace- tenant deployment runbook: the deployment guide documents the WORKSPACE-SPECIFIC WORKFLOW STEPS, the myths-and-misconceptions spoke documents the 18 Workspace-tenant variant mental-model ERRORS the tenant must clear BEFORE the workflow produces the expected outcome.
• SPF explained — the protocol-level deep dive on Sender Policy Framework (RFC 7208). Covers the 10-lookup limit, mechanisms, qualifiers, and flattening.
• SPF mechanisms explained — the per-mechanism syntax + lookup-cost reference for the include:_spf.google.com mechanism this Workspace deployment authors — the WORKSPACE-SPF-MECHANISM-INSTANCE companion to this Workspace DMARC deployment guide. Where THIS page documents the Workspace-specific DMARC publication workflow (the canonical include:_spf.google.com token, the third-party-sender catalogue's secondary include: tokens, the ~all default-deployment qualifier), the mechanisms-explained spoke documents the eight SPF mechanisms (RFC 7208 §5 — all, include, a, mx, ip4, ip6, ptr, exists) and the per- mechanism lookup-cost / when-to-use / when-NOT-to-use reference the Workspace SPF record instantiates. Read the mechanisms spoke alongside this Workspace deployment guide when extending the Workspace-baseline v=spf1 include:_spf.google.com ~all record with secondary include: tokens for SaaS senders (Mailchimp, SendGrid, HubSpot, Salesforce, Marketo) and you need the per-mechanism reference to verify each addition stays inside the 10-lookup cap, plus the per-mechanism semantics when deciding whether a third-party sender's IPs should enter the record as include: (provider-managed), ip4: (static IP block), a: (A-record-identified host), or mx: (legacy MX-is-also-outbound pattern).
• include: vs ip4: vs a: vs mx — the WORKSPACE-MECHANISM-SELECTION-DECISION companion to this Workspace DMARC deployment guide. Where THIS page documents the Workspace-specific DMARC publication workflow (the canonical v=spf1 include:_spf.google.com ~all baseline that all Workspace tenants publish at TXT @) — i.e. the FIXED ANCHOR mechanism the Workspace provider mandates — the include-vs-ip4-vs-a-vs-mx spoke documents the DECISION-MATRIX an operator faces when EXTENDING the Workspace baseline with secondary third-party-sender tokens: for each new SaaS sender added to the record, the operator must choose between four STRUCTURALLY-DIFFERENT mechanism tokens — include: (delegate the sender's IPs to the sender's own SPF record, costs 1 lookup at minimum but recurses through the sender's include: chain), ip4:<CIDR> (hard-code the sender's IPv4 block, costs 0 lookups but freezes the IP set at the moment of authoring), a:<hostname> (delegate to an A-record lookup, costs 1 lookup but FOLLOWS the host's IP rotation), and mx:<domain> (delegate to the MX-record-resolved hosts, costs 1+N lookups for N MX hosts, useful only for the legacy MX-is-also-outbound pattern). The include-vs-ip4-vs-a-vs-mx spoke documents the per-mechanism TRADE-OFF MATRIX (lookup-cost, freshness, operator-burden, security) plus the canonical mechanism-choice DECISION-TREE for each common SaaS-sender class — ESP-bulk-sender (Mailchimp, SendGrid, HubSpot — typically include:), marketing-automation (Marketo, Pardot — include:), transactional-static-IP (some Postmark / Mailgun customer tiers — ip4:), self-hosted-mailserver (ip4: or a:), legacy-MX-outbound (mx:) — plus the lookup-cost RUNNING-TOTAL accounting that determines whether the record stays under the 10-lookup cap documented in help_spf_lookup_limit.php. Read the include-vs-ip4-vs-a-vs-mx spoke EVERY time you add a token to the Workspace-baseline SPF record — the mechanism-choice is the load-bearing decision that determines whether the new record will produce spf=pass for the new sender, stay under the 10-lookup cap, and avoid the permerror trap.
• SPF 10 DNS lookup limit and SPF flattening — the dedicated deep dive on the permerror-on-overlimit failure class. Google Workspace's _spf.google.com include is relatively lookup-friendly (2 slots), but the moment you add common SaaS senders (Mailchimp, SendGrid, HubSpot, Salesforce Marketing Cloud, Klaviyo), the cumulative DNS-lookup cost passes 10 and your SPF record breaks silently with permerror. Covers the per- provider include-cost table, the flattening tradeoff, and the recommended remediation sequence.
• SPF permerror vs temperror — the WORKSPACE-TENANT-RECURSIVE-INCLUDE- CASCADE-AS-CANONICAL-PERMERROR-TRIGGER- AND-AUTHORITATIVE-NS-SERVFAIL-AS-CANONICAL- TEMPERROR-TRIGGER companion documenting how the Workspace-baseline SPF deployment pattern this page's third-party-sender catalogue documents (the canonical include:_spf.google.com anchor + per-ESP recursive include cascade) operationally produces both SPF permerror AND temperror verdict classes at receiver-side evaluation, each requiring distinct operator-side root-cause analysis. Where THIS page documents the Workspace-specific SPF deployment baseline (the v=spf1 include:_spf.google.com ~all canonical anchor + per-ESP cooperative include extension), the SPF- permerror-vs-temperror spoke is the SPF- ERROR-CLASS REFERENCE documenting how each Workspace-tenant operational pattern produces a specific error-class verdict at receiver-side evaluation. The four- axis WORKSPACE-TENANT-VS-SPF-ERROR-CLASS- TAXONOMY mapping exposes the structurally- distinct Workspace-operational-pattern-to- error-class resolutions: (i) per- tenant recursive-include-cascade DNS- lookup-budget exhaustion → canonical permerror verdict at receiver evaluation — the Workspace baseline's include:_spf.google.com (which itself recursively includes _netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com at 2-3 sub-include depth, consuming 4-5 DNS lookups against the RFC 7208 §4.6.4 10-lookup ceiling) + the per-ESP cooperative includes this page enumerates (Mailchimp 5 lookups, SendGrid 4 lookups, HubSpot 3 lookups, Salesforce MC 3 lookups, Klaviyo 2 lookups) trivially push the recursive cascade beyond the 10-lookup ceiling at the canonical Workspace-tenant 4-7 cooperatively- extending-ESP deployment pattern; the spoke documents the RFC 7208 §5.1 receiver-side permerror emission contract whose verdict the Workspace operator sees in the daily RUA aggregate-report row stream when the lookup-budget exhaustion fires; (ii) per-tenant SPF-record byte-syntax publication bug at Google Admin Console- emitted SPF record → canonical permerror verdict from publication-time grammar violation — the Workspace tenant's SPF record publication at the customer's apex DNS zone (typical pattern: copy-paste from Google Workspace Admin Console SPF wizard into Cloudflare / Route 53 / GoDaddy TXT-record-editor) is the canonical publication-bug surface this page's Workspace-deployment baseline documents; when the copy-paste path corrupts the record (typical defects: extra whitespace inside mechanism token, truncated record at 255-byte string- segment boundary if the cooperatively- extended ESP includes push the record beyond the single-string boundary, missing ~all qualifier terminator), the spoke documents the RFC 7208 §5.1 receiver-side permerror emission for grammar-violation operational classes; (iii) per-tenant authoritative- NS SERVFAIL or recursive-resolver-cache- eviction during peak Workspace deployment traffic → canonical temperror verdict — at peak send-traffic windows for the Workspace tenant (typical pattern: post-mass-mail-blast spike from a Workspace-hosted marketing platform co-deployed with the customer-apex domain), the canonical-include-cascade recursive resolution can encounter transient SERVFAIL from any one of the 4-7 cooperatively-extending include targets; the spoke documents the RFC 7208 §5.1 receiver-side temperror emission contract (receiver-side retry-deferred behavior) whose verdict the Workspace operator sees as a spike in the daily RUA aggregate-report spf=temperror row count during traffic-spike windows; (iv) per-tenant rua-aggregate- report per-row spf=permerror- rate + per-row spf=temperror- rate as canonical-tenant SPF-record- health KPI → operator-side daily triage observability — the Workspace-tenant operator's daily per-domain RUA aggregate-report row stream surfaces per-day spf=permerror-rate and spf=temperror-rate as the canonical SPF-record-health KPI pair the operator monitors; the spoke documents the per-error-class root- cause taxonomy operators consume during triage, the per-error-class remediation- cadence contract (permerror = same-day publication-fix-and-redeploy because the record is structurally broken; temperror = monitor-and-defer because the upstream DNS authority is transiently degraded and the verdict will self-clear on retry), and the per-error-class Workspace-Admin-Console-side workflow (Workspace Admin Console SPF wizard re-verification for permerror, no-action- required-but-monitor for temperror). Read the SPF-permerror-vs-temperror spoke when the Workspace-tenant SPF record has just regressed to permerror or temperror in the daily RUA aggregate-report row stream and the operator needs the per-error-class root-cause taxonomy to triage whether the Workspace-tenant SPF record requires immediate republication or whether the verdict is upstream-DNS-authority transient.
• SPF for Google Workspace — the Workspace-specific SPF deep dive that complements this DMARC deployment guide. Covers the canonical v=spf1 include:_spf.google.com ~all record, the third-party-sender catalogue (Mailchimp, SendGrid, Mailgun, HubSpot, Salesforce, Amazon SES, Marketo, Zendesk) with their canonical include: tokens, the Inbound Gateway / default-routing failure modes, and the secondary-domain & gmail.com-alias edge cases. Read alongside this guide when authoring the SPF record half of the Workspace DMARC deployment.
• SPF forwarding issues (the second-hop break) — the WORKSPACE-GROUPS-AND-PER-USER- AUTO-FORWARD-AND-EXTERNAL-MAILING- LIST-SUBSCRIPTION-INDUCED-SPF-BREAK- AT-WORKSPACE-USER-MAILBOX companion to this Workspace-tenant DMARC deployment guide. Where THIS page documents the Workspace-tenant DMARC publication workflow (admin-console DKIM authentication, Mail Authentication Settings DMARC record, per-tenant p=-tier-progression ramp, Postmaster Tools aggregate-report observation, Google Workspace Routing rules), the SPF-forwarding-issues spoke documents the WORKSPACE- TENANT-FORWARDER-TOPOLOGY-INDUCED SECOND-HOP SPF-BREAK PATTERNS the Workspace tenant's OWN forwarder infrastructure produces at the tenant's receiver-side aggregate- report stream. FIVE structurally- distinct WORKSPACE-FORWARDER-VS- FORWARDER-INDUCED-SPF-BREAK operational classes the spoke catalogues that THIS Workspace- tenant DMARC reference cross- references but does not enumerate: (i) Workspace Groups distribution-list-MTA second-hop SPF break — when a Workspace-hosted Group at group@tenant.com receives a message and re-distributes it to subscriber addresses, the Workspace Groups MTA at groups.google.com re- emits the message from a Workspace- Groups-controlled IP-pool whose envelope MAIL FROM is the original sender's address — producing per- message spf=fail at external-subscriber receivers because the original sender's SPF record does not authorise the Workspace-Groups MTA IP-pool; (ii) per-user Gmail Settings → Forwarding-and-POP/IMAP auto-forward SPF break at user-mailbox layer — when a Workspace user configures Gmail Settings → Forwarding-and-POP/IMAP to auto-forward all inbound mail to an external address, the per-user forward-MTA re-emits the message from a Gmail-forwarder IP-pool whose envelope MAIL FROM is the ORIGINAL external sender's address — producing per-message spf=fail at the downstream external receiver; (iii) external mailing-list subscription-induced SPF break at Workspace user mailbox — when a Workspace user subscribes to an external Mailman / Listserv / sympa mailing list, the external list-MTA forwards messages to the Workspace user from the list-MTA's IP, producing per-message spf=fail rows in the Workspace tenant's aggregate-report stream attributed to the external list-MTA's IP set; (iv) Workspace Routing rules dual-delivery to legacy on-prem MX SPF break — Workspace deployments with Routing rules configured for dual-delivery (cloud mailbox + legacy on-prem MX) relay messages from the on-prem MX back to Workspace producing forwarder- hop spf=fail rows the Workspace receiver-side authentication- results header surfaces; (v) SRS / rewritten-MAIL-FROM as Workspace-side structural remediation for Groups-forwarder-induced SPF- fail rows — Workspace Groups implements Sender Rewriting Scheme by default for external sender → external subscriber delivery paths, rewriting the envelope MAIL FROM to a SRS0=...@tenant.com address whose SPF record DOES authorise the Workspace-Groups MTA, restoring SPF-aligned-pass at the downstream subscriber receiver. Read the SPF-forwarding-issues spoke alongside this Workspace- tenant DMARC deployment guide when the tenant's aggregate-report stream shows persistent background spf=fail rows whose source-IP attribution maps to Workspace-Groups / Gmail-forwarder / external-list-MTA infrastructure — the spoke's forwarder-topology catalogue is the diagnostic reference that disambiguates Workspace-side forwarder-relay-MTA fan-out (Workspace-Groups-default SRS rewriting + ARC re-sealing as the remediation) from actual external- spoofing-attempt-attack fan-out (DMARC-policy-enforcement as the remediation).
• SPF DNS TXT-record byte syntax — the WORKSPACE-TENANT-SPF-RECORD- PUBLICATION-AT-GOOGLE-ADMIN-CONSOLE-AND- EXTERNAL-DNS-CONSUMER-OF-SPF-TXT-RECORD- BYTE-LAYOUT companion to THIS Workspace DMARC deployment guide. Where THIS page documents the Workspace-tenant DMARC deployment workflow (provision the customer-domain at admin.google.com, verify the customer-domain via TXT challenge, configure MX records to the aspmx.l.google.com family, publish DKIM via the Workspace admin console's "Authenticate Email" flow, publish DMARC at _dmarc.<customer-domain>), the SPF-DNS-syntax spoke is the BYTE- LAYOUT REFERENCE the Workspace tenant operator consults when authoring the SPF record at the customer-domain's external DNS provider (Google Domains / Cloudflare / Route 53 / Namecheap / GoDaddy / Squarespace), since Workspace does NOT host the customer-domain's SPF record (only the MX RR-set target, the DKIM TXT publication, and the receive-side mail flow are Workspace-managed). The four-axis WORKSPACE-DEPLOYMENT-VS-SPF-BYTE-SYNTAX comparison exposes the structurally- distinct WORKSPACE-TENANT-SPF-EDITING- CONTEXTS: (i) customer-domain first-publication of the canonical Workspace SPF — the v=spf1 include:_spf.google.com ~all record's byte-layout conforms to RFC 7208 §4 grammar; the SPF-DNS-syntax spoke documents the v=spf1 version-tag precedence, the include: mechanism's 1+N DNS-lookup expansion cost against the 10-lookup budget, and the trailing ~all terminating qualifier's SoftFail semantics; (ii) multi-ESP include-chain editing — when the Workspace tenant adds Mailchimp / SendGrid / Mailgun / Salesforce / HubSpot ESP includes, the SPF-DNS-syntax spoke is the byte-syntax reference for the multi-mechanism record byte-layout + the 255-byte single-string DNS TXT limit + the §3.3 multi-string concatenation form (("…" "…")) when the record byte-length exceeds the limit; (iii) secondary-domain SPF authoring — Workspace tenants with secondary domains (acquired-brand domains, regional ccTLDs, marketing-only domains) publish SPF records at EACH secondary domain; the SPF-DNS-syntax spoke is the byte-layout reference for the per-secondary-domain v=spf1 record structure; (iv) gmail.com alias SPF edge-case — Workspace tenants who configure gmail.com-aliased send-as addresses surface a known SPF evaluation edge-case (the gmail.com domain's public SPF record applies to alias- send-as scenarios); the SPF-DNS-syntax spoke documents the byte-grammar for the gmail.com-side SPF record's published structure operators cross-reference when debugging the edge-case. Read the SPF-DNS-syntax spoke alongside this Workspace deployment guide when manually editing the SPF TXT-record at the external DNS provider's UI — the byte-syntax spoke is the authoritative byte-grammar reference Workspace tenants consult when the SPF record byte-layout matters more than the admin.google.com UI semantics (which never surfaces the SPF record because Workspace does not host the customer-domain's SPF publication).
• MX records explained — the DNS-RR foundation whose aspmx.l.google.com family routes inbound mail to the Workspace MTA fan-out — the WORKSPACE-MX-FOUNDATIONAL-DELIVERY companion to this Workspace DMARC deployment guide. Where THIS page documents the Workspace-specific DMARC publication workflow (Admin Console DKIM enablement, the include:_spf.google.com SPF token, the DMARC TXT record under _dmarc.<domain>), the MX-records spoke documents the DNS-RR-MECHANICS-LAYER reference the Workspace MX deployment instantiates: the canonical aspmx.l.google.com / alt1.aspmx.l.google.com / alt2.aspmx.l.google.com / alt3.aspmx.l.google.com / alt4.aspmx.l.google.com five-MX priority ladder, the <preference> <target> wire-format (RFC 1035 §3.3.9), the per-MX preference-value semantics (lower = preferred, ties = round-robin across A/AAAA), the 0 . "null MX" RFC 7505 convention for non-mail-receiving zones, and the dig +short MX example.com authoritative-vs-cached diagnostic workflow for verifying publication state when an inbound delivery to a Workspace tenant fails and the operator must distinguish an authoritative-zone misconfiguration from a stale recursive-resolver cache during the post-cutover propagation window. Read the MX-records spoke alongside this Workspace deployment guide when the Workspace Admin-Console MX setup produces an inbound-delivery failure and you need the DNS-RR-mechanics reference to diagnose the failure layer.
• DKIM explained — the protocol-level deep dive on DomainKeys Identified Mail (RFC 6376). Covers selectors, canonicalization, key rotation, and CNAME delegation.
• DKIM cryptography basics — the WORKSPACE-MANAGED-DKIM-CRYPTOGRAPHIC- PRIMITIVE companion to this Workspace DMARC deployment guide. Where THIS page references the Workspace-managed 2048-bit RSA keypair generated by the Admin Console Authenticate-email wizard at google._domainkey.<domain> and treats the per-message DKIM signature as an OPAQUE PRIMITIVE the per-Workspace- tenant DMARC ramp consumes, the cryptography-basics spoke documents WHAT the cryptographic primitive ACTUALLY IS at FOUR per-Workspace-tenant cryptographic- foundation dimensions: (i) per- Workspace-tenant google._domainkey RSA-2048 keypair as the load-bearing cryptographic primitive upstream of every per-message DKIM signature — the Admin Console Authenticate-email wizard provisions a 2048-bit RSA keypair (private key held by Workspace's signing infrastructure, public key published as the p=<base64-pubkey> tag in the google._domainkey.<domain> TXT-RR) whose RFC 8301 compliance (RSA-2048 recommended and RSA-1024 the required minimum since 2018, superseding RFC 6376's RSA-1024 originally- sufficient floor) IS the LOAD-BEARING cryptographic primitive whose receiver- side verification produces the dkim=pass verdict every per- Workspace-tenant per-message DMARC-aligned- pass evaluation downstream depends on; (ii) RFC 8463 Ed25519 emerging algorithm vs RSA-2048 default cryptographic algorithm choice — the spoke documents the per-publisher cryptographic algorithm choice (Workspace defaults to RSA-2048; Ed25519 RFC 8463 offers 128-bit security level with substantially smaller signatures and faster verification but receiver-side support remains uneven in 2026 across major mailbox providers), the per-tenant publication discipline (k=rsa vs k=ed25519 in the TXT-RR), and the operator decision-matrix for when to enable Ed25519 alongside RSA-2048 via dual- selector publication (RFC 8463 §3 dual- algorithm coexistence) — the per- Workspace-tenant operator must understand the cryptographic-algorithm-choice discipline before consuming the rotation-playbook companion's dual- selector procedure for any algorithm- migration cutover; (iii) SHA-256 hash function role in per-message DKIM signing operation — the spoke documents the per-message DKIM signing operation (canonicalize body per c=relaxed/relaxed default → compute SHA-256 body hash → emit bh=<base64-sha256-body-hash> tag → build signed-headers blob over operator-chosen h=-tag header list → SHA-256 hash the signed-headers blob → sign with RSA-2048 private key → base64 encode → emit b=<base64-rsa-signature> tag → attach DKIM-Signature header) whose cryptographic-correctness chain is the LOAD-BEARING per-Workspace-tenant per- message DKIM-pass prerequisite the per- tenant DMARC deployment ramp THIS page documents PRESUPPOSES is operating cleanly underneath the policy-publication layer (any signing-engine cryptographic- misconfiguration at the per-Workspace- tenant google-managed signing infrastructure produces receiver-side dkim=fail verdicts cascading to per-message DMARC-aligned-fail verdicts under p=quarantine / p=reject enforcement); (iv) per-Workspace-tenant per-key- lifetime cryptographic-strength budget cross-attribution to rotation-cadence discipline — the spoke documents the cryptographic-strength-budget chain (RSA-2048 ≈ 112-bit security level vs Ed25519 128-bit security level vs deprecated RSA-1024 ≈ 80-bit security level) whose per-key-lifetime budget directly constrains the half-yearly-or- faster rotation cadence the Workspace Admin Console Authenticate-email "Generate new record" workflow operates underneath — the per-Workspace-tenant operator must understand the cryptographic- strength budget before consuming the rotation-playbook companion's dual- selector zero-downtime rotation procedure at the per-tenant DKIM-aligned-pass-rate floor preservation boundary. The operator landing here for the Workspace DMARC posture needs the cryptography-basics spoke's RSA-2048-vs-Ed25519-vs-RSA-1024- deprecated cryptographic-primitive foundation reference to safely consume both the DKIM-explained protocol-level intro AND the DKIM-key-rotation operational rotation playbook without treating the cryptographic primitive as an opaque load-bearing black box underneath the per-tenant DMARC ramp.
• DKIM key rotation playbook — the WORKSPACE-MANAGED-DKIM-KEYPAIR- HALF-YEARLY-ROTATION companion to this Workspace DMARC deployment guide. Where THIS page references the Workspace-managed DKIM keypair (Apps → Google Workspace → Gmail → Authenticate email; the 2048-bit keypair generated by Workspace; the google._domainkey.<domain> TXT publication; the half-yearly key rotation that Workspace's Admin console prompts the operator to perform), the key-rotation spoke documents the OPERATOR-SIDE PROCEDURE for the Workspace-managed rotation: how the Admin console's "Rotate DKIM keys" affordance publishes a SECOND google._domainkey TXT record alongside the first while keeping the OLD selector active for signing, the TTL-bounded propagation gate the operator must observe before flipping the active-signing selector, the per-receiver cache-aging window (Gmail, Microsoft 365, Yahoo, Mail.ru) the operator monitors in aggregate reports BEFORE retiring the old selector, and the gappssmtp.com default-signing identity trap this page documents (Workspace's default per-message DKIM signature uses d=<domain>.gappssmtp.com which produces dkim=pass but does not align with the From: organisational domain under DMARC — every Workspace rotation playbook must verify the post-rotation d=<domain> signing identity on the publisher's own apex domain, NOT on gappssmtp.com, to keep the alignment contract intact). The operator landing here for the Workspace DMARC posture needs the key-rotation spoke's dual-selector zero-downtime procedure to safely advance the half-yearly rotation step without an enforcement-window regression.
• DKIM replay attacks (RFC 6376 §8.6) — the WORKSPACE-DKIM-REPLAY-ATTACK- DEFENSE companion to this Workspace DMARC deployment guide. Where THIS page documents the p=none → p=quarantine → p=reject ramp at the policy- publication layer, the replay-attacks spoke documents the RFC 6376 §8.6 REPLAY-ATTACK structural bypass-vector whose captured-and-re-injected legitimate Workspace-signed message replayed by an attacker from a different sending IP STILL produces a receiver-side dkim=pass verdict (because the cryptographic signature validates) AND dkim-alignment=pass verdict (because the per-Workspace- tenant google._domainkey d= tag is preserved verbatim from the original Workspace- signed emission) AND DMARC-pass verdict (via the DKIM-side alignment leg the Workspace signing satisfies) — the per-message DMARC evaluation cannot distinguish replay from origin emission. The replay-attacks spoke documents the Workspace-tenant structural defenses at FOUR Workspace- tenant-DKIM-replay-defense dimensions: (i) per-Workspace-tenant operator-managed manual rotation cadence shortens the per-key replay window — the Workspace Admin Console Authenticate-email "Generate new record" workflow executed on an operator-defined cadence is the canonical per-key-lifetime structural defense every Workspace operator must apply as the Workspace- tenant per-key-lifetime closure of the attacker's replay-window exploitation; the spoke documents the operator- recommended quarterly-or-faster rotation cadence; (ii) RFC 6376 x= tag signature- expiration discipline — operators publish per-message signature-expiration timestamps in the DKIM-Signature header limiting the replay-window attackers can exploit on captured legitimate Workspace- egress mail; (iii) narrow per- Workspace-tenant signing scope discipline — operators constrain the per-message signed- header scope (signed List-Unsubscribe URIs, signed Content-Type, signed Subject:) so replayed messages diverge from the originals in ways that break signature validity; (iv) receiver-side replay-detection signals — sophisticated receivers correlate per-Message-ID replay counts and downgrade-or- reject the replayed variants even when the per-Workspace-tenant DKIM- pass + DKIM-alignment=pass evaluation otherwise validates. Pair this Workspace DMARC deployment guide (the per-policy-publication ramp reference) with the replay- attacks spoke (the per-key-lifetime structural defense reference) for the complete picture of when Workspace- tenant DKIM-pass + DKIM-alignment=pass + DMARC-pass actually means a legitimate Workspace-origin-emitted message vs a replayed attacker- injected variant.
• DKIM for Google Workspace — the Workspace-specific DKIM deep dive that complements this DMARC deployment guide. The DMARC deployment guide on this page covers the _dmarc.<domain> TXT publication and the p=none → p=quarantine → p=reject ramp at the policy level; the DKIM-for-Workspace spoke covers the upstream DKIM signing posture WITHOUT WHICH the DMARC enforcement cannot pass. Specifically: the Admin console workflow (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 Verify-with-mail-tester workflow, the half-yearly key-rotation procedure, the seven common Workspace DKIM mistakes, and the gappssmtp.com signing-identity gotcha — Workspace's default 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, therefore FAILS DMARC alignment despite a green DKIM verdict in Authentication-Results. The gappssmtp.com trap is the SINGLE most common reason a Workspace tenant's p=reject rollout breaks legitimate mail: operators see dkim=pass in headers, assume alignment is satisfied, then discover post-enforcement that d=domain.gappssmtp.com does NOT align with From: user@domain.com under the organisational-domain rule. This is the FIRST Workspace cross-protocol bridge from this DMARC-policy guide to the DKIM-side procedural sibling — operators landing here for DMARC enforcement need the DKIM-side procedural deep dive to complete the upstream signing-posture work BEFORE advancing p=none → p=quarantine.
• DKIM for Microsoft 365 — the PEER-CLOUD-MAILBOX-PROVIDER-M365- TENANT-DKIM-PUBLICATION-AS-LOAD-BEARING- DKIM-AUTHENTICATION-EVIDENCE-AND-CROSS- CLOUD-PARALLEL-DEPLOYMENT-REFERENCE companion to this Workspace-tenant DMARC deployment reference. Where THIS page documents the Workspace-tenant DMARC deployment workflow (Admin Console DKIM enablement at google._domainkey.< domain> TXT-publication + _dmarc.<domain> TXT publication + per-tenant policy ramp p=none → p=quarantine → p=reject), the dkim_for_microsoft_365 spoke is the M365- TENANT-DKIM-PUBLICATION canonical reference documenting the FOUR cross-cloud- M365-vs-Workspace-DKIM-publication- discipline coupling dimensions: (i) M365 selector1/selector2 dual- selector CNAME publication vs Workspace google._domainkey TXT publication topology asymmetry — M365 publishes DKIM keys via per-tenant CNAMEs (selector1-<tenant>._domainkey + selector2-<tenant>._domainkey) pointing at Microsoft-managed onmicrosoft.com hostnames; Workspace publishes the DKIM public-key directly via a TXT-record at google._domainkey.<domain> with the Workspace-tenant operator inserting the Admin-Console- generated base64-encoded RSA / Ed25519 public-key bytes — the cross-cloud publication-topology asymmetry is the per-publisher per-domain DKIM- publication discipline difference the Workspace operator must understand when consuming receiver-side DMARC aggregate reports from M365-receiver endpoints; (ii) M365 default d=<tenant>.onmicrosoft.com emission vs Workspace default d=<workspace-domain> emission cross-cloud emission-default asymmetry — M365's out-of-box DKIM-Signature emission defaults to the <tenant>.onmicrosoft.com sub-tenant domain (NOT the protected vanity domain), requiring the M365-tenant operator to execute the Defender portal DKIM-enablement workflow BEFORE the protected vanity domain produces aligned-pass; Workspace's out- of-box DKIM-Signature emission defaults to the Workspace-tenant primary domain as the d=-tag value — the Workspace operator's deployment workflow THIS page documents is structurally simpler because the default emission already produces the alignment-pass- eligible d=-tag; (iii) M365 2048-bit RSA Rotate- DkimSigningConfig PowerShell upgrade- from-1024-bit-default vs Workspace 2048-bit RSA Admin-Console-default cross-cloud cryptographic-foundation asymmetry — M365's legacy default DKIM key-strength is 1024-bit RSA (deprecated per RFC 8301 §3), requiring the M365-tenant operator to execute the Rotate-DkimSigningConfig -KeySize 2048 PowerShell sequence; Workspace's Admin-Console DKIM- generation panel defaults to 2048-bit RSA at panel-emission time — the cross- cloud cryptographic-foundation operational asymmetry favours Workspace operators with modern out-of-box cryptographic discipline; (iv) M365 Rotate-DkimSigningConfig PowerShell-orchestrated rotation vs Workspace Admin-Console-orchestrated rotation cross-cloud rotation-tooling asymmetry — M365 orchestrates DKIM rotation via the PowerShell Rotate-DkimSigningConfig cmdlet at the per-tenant selector1-to-selector2 cutover; Workspace orchestrates DKIM rotation via the Admin-Console panel with single-selector retirement + replacement (or operator-side dual- selector publication discipline) — the cross-cloud rotation-tooling operational asymmetry is the per-cloud DKIM-key-lifecycle discipline difference the Workspace operator must understand when designing the per-Workspace-tenant rotation cadence THIS page documents. Read the dkim_for_microsoft_365 spoke as the cross-cloud parallel deployment reference when the Workspace-tenant DMARC deployment workflow THIS page documents needs context for the peer M365-cloud DKIM-publication discipline in multi-cloud / migration / cross- cloud-coordination scenarios.
• DMARC deployment checklist — the PROVIDER-AGNOSTIC GREEN-PATH companion to this Workspace-specific DMARC deployment guide. Where THIS page documents the WORKSPACE-SPECIFIC concrete operator workflow (Admin Console navigation paths, the Workspace Authenticate-email flow, _spf.google.com include canonical record, google._domainkey TXT publication, the gappssmtp.com alignment gotcha, the Workspace-side Defender- equivalent telemetry workflow), the deployment-checklist spoke is the PROVIDER-AGNOSTIC abstract reference cataloguing the SAME phases this Workspace guide instantiates: (a) Phase 0 sender-inventory enumeration (which Workspace tenants + secondary domains + third-party SaaS senders ride the deployment); (b) Phase 1 SPF + DKIM prerequisite verification (the SPF record with _spf.google.com + custom DKIM PUBLISHED-and-aligned BEFORE DMARC publication); (c) Phase 2 DMARC record publication with p=none + a working rua= mailbox; (d) Phase 3 baseline RUA-stream instrumentation (the operator-side inbound mailbox / ingestion-pipeline activation that turns the receiver-side aggregate-report generator output into operator-readable dashboards); (e) Phase 4 post-publication monitoring cadence (the Workspace-specific rua-stream observation cadence that establishes steady-state alignment-rate baseline BEFORE advancing the policy ramp). Read the deployment-checklist spoke alongside this Workspace-specific page when an operator deploying DMARC on a Workspace tenant needs the PROVIDER-AGNOSTIC checkbox roster to ensure ALL deployment phases are complete — the Workspace-specific page documents the WHAT (concrete Workspace Admin Console clicks and record content) and the deployment-checklist spoke documents the WHEN (phase-by-phase exit-criteria roster) and the WHY (operational consequences of skipping each phase).
• DMARC record tags explained — every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment explained — identifier alignment (the SPF-or-DKIM-domain-matches-From: rule). The single concept that makes SaaS senders fail until they CNAME-delegate DKIM under your domain.
• DKIM alignment with DMARC — the PER-WORKSPACE-TENANT-google._ domainkey-SIGNING-DOMAIN-AS-LOAD- BEARING-UPSTREAM-PRODUCER-OF-PER- MESSAGE-DKIM-ALIGNMENT-EVALUATION companion to this Workspace-tenant DMARC deployment guide. Where THIS page documents the per-Workspace- tenant Authenticate-Email-driven DKIM activation that creates the google._domainkey.<Workspace- author-domain> publisher- side DNS publication directive, the DKIM-alignment-with-DMARC spoke documents the per-Workspace-tenant per-message receiver-side EVALUATION of that signing-domain identity at every per-message DMARC verdict: (i) the per-message comparison between the Workspace-tenant DKIM-Signature header's d=<Workspace-author- domain> tag and the RFC 5322 From: header's organisational-domain — the comparison the per-Workspace- tenant DKIM activation makes organisationally-aligned by design (Workspace's Authenticate Email feature signs the per-message DKIM with the Workspace-tenant author- domain as the d= tag, directly producing per-message dkim=aligned=true); (ii) the strict-vs-relaxed alignment mode the Workspace-tenant publisher selects via the adkim=s / adkim=r DMARC-record tag-value — Workspace-tenant best practice is adkim=r per RFC 7489 default, accommodating organisational-domain-aligned delegated subdomain signing for third-party ESPs; (iii) the canonical Workspace-tenant defect class — per- message dkim=pass with aligned=false — that emerges when third-party ESPs sign for the Workspace-tenant author- domain using the ESP's signing- domain (d=sendgrid.net, d=mandrillapp.com, d=amazonses.com) without CNAME-delegation, producing per- message dkim=pass + aligned= false aggregate-report evidence rows at every legitimate- mail message; and (iv) the canonical Workspace-tenant remediation pattern — CNAME-delegate the ESP's signing- selector under the Workspace-tenant author-domain so the per-message DKIM-Signature header's d= <esp-selector>.<Workspace- author-domain> tag-value organisationally aligns with the From: header at receiver-side evaluation, restoring per-message dkim=aligned=true. Read this WITH the Workspace-tenant DMARC deployment guide when the operator's Phase 1 RUA sender-inventory step surfaces third-party-ESP-signed legitimate-mail rows showing dkim=aligned=false: THIS page documents the Workspace-tenant deployment WORKFLOW, the DKIM- alignment-with-DMARC spoke documents the BYTE-LEVEL ALIGNMENT-EVALUATION DISCIPLINE that turns Workspace- tenant signing into per-message DMARC- aligned-pass.
• DMARC policy rollout — the operational migration from p=none through p=quarantine to p=reject with a worked Week 0 → Week 26 timeline.
• DMARC aggregate (RUA) reports — the daily XML stream receivers send back. The data behind every rollout decision.
• Business Email Compromise (BEC) — the WORKSPACE-TENANT-AS-BEC-PRIMARY- TARGET-PLATFORM companion to THIS Workspace- specific DMARC deployment guide. Where THIS page documents the Workspace-tenant DMARC publish-and-ramp deployment (the include:_spf.google.com SPF record, the google._domainkey DKIM TXT selector, the _dmarc TXT record with the Workspace-tenant-specific p=none → quarantine → reject ramp), the business_email_compromise spoke documents the FINANCIAL-FRAUD-THREAT- SCENARIO whose six canonical variants (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, VEC) the Workspace-tenant deployment THIS guide documents is the canonical application-layer defense against. Four structurally-distinct Workspace-tenant-BEC-defense operational classes the spoke covers that THIS Workspace deployment guide intentionally elides: (i) Workspace as the canonical BEC-target platform — Workspace tenants are disproportionately targeted by BEC campaigns because the platform's defaults make spoofing the executive / finance / HR / payroll identity high-impact AND because the gappssmtp.com default signing-domain produces the DMARC-aligned-pass-but-org-unaligned outcome the BEC spoke's spoofing catalogue documents; (ii) Workspace- tenant-specific BEC-incident-response playbook — the BEC spoke's FBI Financial Fraud Kill Chain playbook has Workspace-tenant-specific evidence-collection steps (Workspace Admin audit log, Vault hold, Investigation Tool message search) that the provider-agnostic incident-response playbook does not surface; (iii) Workspace-tenant DMARC p=reject as the BEC defense- in-depth application-layer anchor — the BEC spoke documents a SIX-LAYER PROACTIVE defense stack where DMARC p=reject is the application-layer foundation; this Workspace deployment guide is the provider-specific deployment playbook that ACTUALISES that defense-in-depth layer on the Workspace platform; (iv) Workspace-tenant-specific BEC defense-readiness-validation checklist — the BEC spoke documents the per-tenant defense- readiness checklist (executive education, finance-process out-of-band confirmation, secure-email-gateway integration, DMARC p=reject enforced); the Workspace-tenant deployment THIS page documents is the per-platform actualisation of the DMARC-enforcement checklist item. Required reading once a Workspace-tenant operator advances to p=quarantine / p=reject per the rollout- spoke timeline AND needs to cross- reference the BEC threat-scenario catalogue for executive-sponsorship and incident-response readiness validation.
• ARC (Authenticated Received Chain) explained — RFC 8617: preserves SPF / DKIM / DMARC results across forwarding hops (mailing lists, .forward redirects). Google (Gmail / Workspace) was the first major implementer and signs every forwarded message.
• DMARC for Microsoft 365 — the sibling per-mailbox-provider deployment guide. Compare the TXT-publication DKIM model (Workspace) with the CNAME-delegation DKIM model (M365) side by side, including the selector1 / selector2 dual-selector rotation and the Defender for Office 365 Trusted ARC Sealers feature.
• Multi-domain DMARC strategy — the operational playbook for Workspace tenants running mail for multiple distinct sending domains. Workspace's domain model — a primary domain plus any number of secondary domains and user aliases, all governed under the Admin Console's Domains panel — is the single most common multi-brand topology in the Workspace ecosystem. The multi-domain page documents the four- pattern decision framework that maps directly onto the Workspace primary- and-secondary domain model: single-org- many-brands (each brand a secondary domain in one tenant), many-orgs-one- tenant (MSP / IT-services pattern with per-customer domain segregation), acquired-domain wind-down (the post-merger consolidation pattern), and parked-domain enforcement ( p=reject; sp=reject; aspf=s; adkim=s on every never-sending Workspace alias domain to prevent attacker abuse). Each Workspace-managed sending domain needs its own _dmarc.<domain> TXT record — Workspace does NOT automatically propagate the primary- domain DMARC to secondary domains, and the Public Suffix List (PSL) organizational-domain boundary stops at each registrable domain. The page also covers brand-aware RUA aggregator configuration (each Workspace secondary domain's rua= can route to a distinct brand-team inbox via the external-domain authorisation pattern), and the per-domain google._domainkey.brand-a.com DKIM selector inventory pattern.
• DMARC for cPanel & Shared Hosting — the SMB / shared-hosting sibling deployment guide. Compare Workspace's enterprise mailbox-provider model with the cPanel shared-hosting model: provider-specific SPF includes (vs Workspace's single _spf.google.com), the default._domainkey DKIM selector (vs Workspace's google._domainkey), manual key rotation (vs Workspace's Admin Console regeneration), shared-IP reputation as a deliverability ceiling (no equivalent at Workspace), and the end-user-cPanel vs WHM-administrator persona split.
• DMARC for Shared Hosting: Plesk, DirectAdmin, ISPConfig — the shared-hosting deployment guide for platforms OTHER than cPanel. Covers Plesk (Postfix backend, DKIM toggle at Mail Settings > DKIM spam protection, default selector), DirectAdmin (Exim backend, DKIM at Email Manager > DKIM, single- character x selector), ISPConfig (Postfix + Dovecot), Webmin / Virtualmin, CentOS Web Panel, and the generic-no-control-panel population with a SaaS-relay CNAME-delegated DKIM escape hatch. Useful for evaluating whether to migrate auxiliary domains (marketing landing pages, support portals) from Workspace to shared hosting while keeping DMARC alignment intact.
• MTA-STS vs DANE for SMTP — the head-to-head COMPARISON of the two SMTP transport-security standards (RFC 8461 MTA-STS vs RFC 7672 DANE for SMTP). Read once authentication (SPF + DKIM + DMARC) is running and you turn to transport security: Google Workspace inbound supports MTA-STS and TLS-RPT and (per Google's 2024 announcement) DANE inbound on aspmx.l.google.com, making Workspace one of the few major providers where both standards genuinely deploy. The comparison page documents the trust-model asymmetry (web-PKI vs DNSSEC), the RFC 7672 §1.3 coexistence rule, and the per-provider support matrix so Workspace operators can decide whether to deploy MTA-STS alone, add DANE for DNSSEC-signed zones, or take advantage of the dual-stack receiver support to harden both inbound and outbound transport.
• MTA-STS for Google Workspace — the same-provider companion that operationalises the MTA-STS half of the Workspace transport-security deployment. Where THIS page deploys SPF + DKIM + DMARC for Workspace, the MTA-STS-for-Workspace page deploys the orthogonal transport-encryption layer (RFC 8461). Read the two pages together when planning a complete Workspace email- security rollout: DMARC stops spoofers from forging your From:; MTA-STS stops downgrade attackers from intercepting your mail in flight. Covers the Workspace-specific policy-file shape (mx: aspmx.l.google.com plus the four secondary backup MXes alt1..alt4.aspmx.l.google.com), the policy-file hosting options for Workspace tenants (Google Sites, Cloudflare Pages, GitHub Pages with custom domain), the testing → enforce burn-in workflow paired with TLS-RPT for Workspace, and the joint Workspace TLS-RPT + MTA-STS rollout sequence.
• BIMI explained — the BIMI-PROTOCOL-OVERVIEW-AS-WORKSPACE- TENANT-DMARC-ENFORCEMENT-DOWNSTREAM- CONSUMER companion to this Workspace DMARC deployment reference. Where THIS page documents the Workspace-tenant DMARC deployment playbook (the canonical v=spf1 include:_spf.google.com ~all baseline + DKIM-via-Google-default-or- per-custom-domain selector + DMARC record publication + Workspace admin console verification + Gmail recipient-side rendering observability), the BIMI-explained pillar is the PROTOCOL-OVERVIEW companion documenting the four operationally-distinct Workspace-tenant BIMI-deployment dimensions every Workspace operator reaching DMARC enforcement encounters when activating the brand-indicator downstream consumer: (i) Gmail is the canonical BIMI-displaying inbox — it was the first major mailbox provider to launch BIMI logo rendering in production (Jul 2021 GA) and remains the load-bearing receiver for Workspace- tenant outbound brand-indicator display among consumer Gmail recipients + Workspace-tenant cross-organizational recipients — the BIMI-explained pillar documents the receiver-side rendering model (the BIMI selector + the SVG Tiny PS asset publication + the VMC vs CMC chain-of-trust + the per- receiver allowlist + the on-rendering side-effects) that determines whether a Workspace tenant's brand-indicator actually displays at the load-bearing Gmail-recipient cohort; (ii) BIMI display gating at every BIMI-aware mailbox provider REQUIRES DMARC at p=quarantine pct=100 or p=reject at the organizational domain — the BIMI-explained pillar documents the receiver-side DMARC-policy-gate eligibility contract that promotes this Workspace DMARC deployment's Phase 4 enforcement transition from "DMARC compliance milestone" to "operationally-visible brand-display reward" — making BIMI the load-bearing operational justification many Workspace tenants reach p=reject for; (iii) BIMI per-domain-and-per- subdomain selector publication discipline at Workspace tenants requires the default._bimi.<domain> TXT record AND the SVG-Tiny-PS asset AND (for VMC display) the X.509-VMC certificate chain pinning that Workspace-tenant operators must coordinate with their existing DMARC publication — the BIMI- explained pillar documents the per- domain selector authoring discipline that operationally extends this Workspace DMARC deployment to per- brand display eligibility; and (iv) Workspace-tenant operators debugging BIMI display failures at Gmail use the Authentication-Results-side bimi= result-code taxonomy (bimi=pass / skipped / fail / temperror / permerror) AND the per-message Gmail delivery-headers BIMI-trace fields to diagnose the root cause — the BIMI-explained pillar documents the receiver-side diagnostic taxonomy that operationally extends this Workspace DMARC deployment's per-message Authentication-Results consumption discipline. Read the BIMI-explained pillar after completing this Workspace DMARC deployment to p=quarantine or p=reject — the BIMI pillar is the AUTHORITATIVE downstream-consumer reference for the brand-indicator reward this DMARC enforcement transition operationally unlocks at the Workspace-tenant cohort.
• BIMI SVG file requirements (SVG Tiny PS profile) — the brand-logo-asset reference operators reach for once this Workspace DMARC deployment reaches p=quarantine or p=reject. Gmail is the canonical BIMI-displaying inbox — it was the first major mailbox provider to launch BIMI logo rendering in production (Jul 2021 GA) and remains the only major inbox that honours BOTH the Verified Mark Certificate AND the unregistered-trademark Common Mark Certificate. For a Workspace sender with DMARC at enforce, BIMI is the single highest-leverage commercial-value milestone after the rollout: the brand logo renders in the Gmail sender column in place of the placeholder initial. The BIMI record carries two file URLs — a= for the VMC/CMC and l= for the SVG logo file — and Gmail validates BOTH server-side before rendering. This page documents the SVG side: the baseProfile="tiny-ps" root attribute that gates conformance (its omission is the #1 silent-rejection cause on Gmail), the permitted/forbidden element whitelist (no <script>, no <animate>, no external raster <image> references — even though all three parse as valid SVG), the 1:1 square aspect ratio with safe central crop circle that survives Gmail's downstream circular cropping in the sender column, the HTTPS-only fetch contract with public-PKI trust chain, the < 32 KB recommended file-size ceiling for Gmail render latency, and the SVG-validator tooling published by the BIMI Group to pre-flight conformance before publication.
• BIMI Verified Mark Certificates (VMC and CMC) — the certificate-acquisition companion to the SVG-requirements page above, equally required by Gmail before the brand logo renders. Gmail is uniquely permissive here: it is the only major BIMI-displaying inbox that honours BOTH the Verified Mark Certificate (registered trademark required, two issuing CAs — DigiCert and Entrust) AND the Common Mark Certificate (unregistered marks accepted, lower documentation burden, but still ~12-month validity and public-PKI chain). Read once the SVG asset on the page above conforms to the Tiny PS profile and the brand team is deciding which certificate path to pursue: VMC for legal trademark protection and cross-provider rendering (Outlook, Apple Mail, Yahoo, Fastmail only accept VMC); CMC for Gmail-only rendering when a registered trademark is not yet available or is in flight.
• DMARC for transactional email — the WORKSPACE-TENANT-PLUS-THIRD-PARTY- TRANSACTIONAL-ESP-DUAL-EGRESS-PUBLISHER- IDENTITY-ALIGNMENT-COORDINATION- COMPANION-AT-FOUR-PER-WORKSPACE-TENANT- PLUS-PER-ESP-STREAM-ALIGNMENT- COORDINATION-DIMENSIONS companion to this DMARC-for-Google-Workspace reference. Where THIS page documents the per-Workspace-tenant DMARC deployment discipline at the per- tenant Workspace cloud-egress IP-pool boundary (per-tenant DMARC _dmarc.<workspace-tenant- domain> TXT-RR publication + per-tenant DKIM google._domainkey.<workspace- tenant-domain> TXT-RR publication with Google-Workspace- operated per-tenant DKIM-signing-key custody + per-tenant SPF apex-domain include:_spf.google.com publication), the transactional-email spoke is the structural-parallel cross- cloud companion documenting the per- Workspace-tenant per-transactional-ESP- stream DMARC alignment coordination discipline that runs ALONGSIDE the per-Workspace-tenant cloud-egress at four per-Workspace-tenant per-stream alignment-coordination dimensions: (i) per-Workspace-tenant per- ESP-stream DKIM-signing-key custody coordination — Workspace tenants commonly integrate per- customer-stream transactional ESPs (SendGrid / Mailgun / Postmark / Amazon SES / SparkPost) for transactional traffic ALONGSIDE Workspace cloud-egress for staff traffic; each per-ESP-stream signs per-message DKIM headers via an ESP- managed <esp-selector>.<d-domain>. <esp-platform>.com CNAME-delegated key-publication target DISTINCT from the per- Workspace-tenant google._domainkey.<workspace- tenant-domain> key-custody THIS page documents; (ii) per- Workspace-tenant SPF authority-list include-cascade vs 10-mechanism RFC 7208 §4.6.4 lookup-limit ceiling coordination — per-Workspace- tenant SPF records expanding include:_spf.google.com (Workspace cloud-egress) + include:sendgrid.net / include:mailgun.org / include:_spf.salesforce.com (per-customer-stream transactional ESP egress) face the SAME RFC 7208 §4.6.4 permerror ceiling — the per- Workspace-tenant per-ESP-stream SPF- flattening / authoritative-delegation remediation pattern the transactional- email spoke documents is the cross- protocol per-publisher SPF-authority- list publication-discipline coordination ladder Workspace tenants deploying multi-stream egress topology encounter; (iii) per-Workspace- tenant per-stream DMARC-aligned-pass- rate observability via rua aggregate- XML per-source-IP attribution coordination — per-Workspace- tenant rua aggregate-XML evidence streams must distinguish Workspace cloud-egress shared-IP-pool members from per-customer-stream transactional- ESP egress shared-IP-pool members at the per-source-IP per-message DMARC- aligned-pass-rate-attribution boundary — the per-publisher per-stream attribution discipline the transactional-email spoke documents is the LOAD-BEARING per-Workspace-tenant per-stream observability discipline every per-Workspace-tenant deployment with multi-stream egress topology depends on at the per-tenant rua aggregate-XML record-level boundary; (iv) per-Workspace-tenant ARC-trusted-sealer-vs-transactional- ESP-relay-rewriting alignment-survival coordination — when a Workspace tenant routes transactional traffic through a per-customer-stream transactional ESP that REWRITES message bodies (footers, unsubscribe links, ESP-tracking pixel injection), the per-ESP-stream DKIM-Signature publication must precede the body- rewriting boundary OR the per-ESP- stream must re-sign the rewritten message body; Workspace's per-tenant ARC-Authentication-Results sealing at the cloud-receiver boundary preserves the per-stream upstream DKIM verdict across the per-forwarder body- rewriting boundary — the per- Workspace-tenant per-stream body- modification-survival coordination discipline the transactional-email spoke documents is the cross-publisher DKIM-Signature-survival contract every per-Workspace-tenant deployment integrating with body-rewriting transactional ESPs encounters at the per-tenant per-stream DKIM-Signature- publication boundary. Read the transactional-email spoke ALONGSIDE this DMARC-for-Google-Workspace reference whenever a per-Workspace- tenant per-stream alignment- coordination discipline question emerges that crosses publisher- identity boundaries between Workspace cloud-egress and per-customer-stream transactional ESP egress — THIS page gives the per-Workspace-tenant cloud- egress deployment discipline, the transactional-email spoke gives the per-publisher per-stream alignment- coordination reference the per- Workspace-tenant multi-stream egress topology deployment ladder bottoms out on at the per-tenant per-stream DMARC-aligned-pass-rate-attribution boundary.
• Google Workspace Admin Console — the operator entry point for DKIM generation and "Authenticate email" activation.
• Google Postmaster Tools — sender-side reputation and deliverability dashboard for your outbound Workspace mail to Gmail.
• Google: Email sender guidelines — the canonical Feb 2024 bulk-sender requirements document.
• DMARC for SaaS senders — the TENANT-WORKSPACE-PLATFORM-WITH- SAAS-SENDER-INTEGRATION companion to this Google Workspace DMARC deployment guide. Where THIS page documents the Workspace-native DMARC publication workflow (the canonical include:_spf.google.com SPF mechanism, the Workspace-managed google._domainkey DKIM selector via Admin Console "Authenticate email", the _dmarc.<domain> TXT publication), the SaaS-senders spoke documents the SIBLING third-party-sender integration pattern that Workspace tenants almost universally co-deploy: the marketing-automation / sales-enablement / customer-success SaaS platforms (HubSpot, Mailchimp, Marketo, Pardot, Salesforce Marketing Cloud, Outreach.io, SalesLoft, Klaviyo, Iterable, Braze, Intercom) that each consume a second SPF include token (include:_spf.hubspot.com, include:servers.mcsv.net, include:mktomail.com, etc.) AND a tenant-specific DKIM CNAME selector (e.g. hs1._domainkey, k1._domainkey, mte1._domainkey) that the Workspace tenant must publish in their DNS zone alongside the Workspace-native records. The SaaS-senders spoke documents the per-platform integration cookbook (the SPF-lookup budget the Workspace tenant must reserve for each SaaS-sender include, the CNAME-delegated DKIM selector publication pattern, the SaaS- platform per-tenant authentication verification UI, the dkim=pass + aligned=false failure mode when the SaaS platform signs with the platform's d= instead of the customer's, the RUA-report attribution workflow that surfaces each SaaS-sender's per-day send- volume + alignment-pass-rate from Workspace-routed outbound mail). Read the SaaS-senders spoke alongside this page when the Workspace tenant's third-party- sender catalogue documented in section 6 includes any of the marketing-automation / sales- enablement / customer-success SaaS platforms above, and the operator needs the per-platform SPF-include + DKIM-CNAME publication reference to author the Workspace DNS zone changes.
• Phishing protection — the WORKSPACE-TENANT-PHISHING-DEFENSE- DEPLOYMENT-PILLAR companion to this Workspace DMARC deployment reference. Where THIS page documents the Workspace-tenant DEPLOYMENT mechanics (the Workspace Admin Console DKIM enablement workflow, the include:_spf.google.com SPF baseline, the google._domainkey selector, the _dmarc.<domain> TXT record authoring discipline, the Postmaster Tools enrolment), the phishing-protection spoke documents the cross-cluster DEFENSE-IN-DEPTH stack the Workspace deployment slots into as the application-layer foundation — a threat-catalogue dimension structurally DOWNSTREAM of this Workspace deployment guide because (i) Workspace tenants are the SINGLE most operationally-load- bearing production phishing-defense deployment surface for the small-to-mid-market segment — Workspace is the protected-domain authority for every customer-facing communication whose phishing-risk profile this deployment defends, (ii) the defense-in-depth stack the phishing-protection spoke synthesises (DMARC + DKIM + SPF + BIMI + MTA-STS + secure-email-gateway anti-impersonation + user-awareness training) is the canonical reference for how each defense layer the Workspace deployment provisions (DMARC enforce, Workspace DKIM at google._domainkey, Workspace SPF via include:_spf.google.com) contributes its specific defense-layer coverage against specific phishing attack-class variants (header-From forgery, display-name spoofing, cousin-domain typosquatting, transport- layer downgrade, brand-logo absence), (iii) the Workspace post-deployment steady-state operator-attention budget is dominated by phishing-protection incident response — the phishing-protection spoke is the Workspace operator's canonical incident-response runbook for the moment a phishing campaign against the protected domain surfaces in Postmaster Tools, in the DMARC aggregate-report ingest pipeline, or in the user-reported phishing-quarantine review queue. Read the phishing-protection spoke once this Workspace deployment guide's per-phase checklist is complete and the operator is moving from the deployment phase into the steady-state phishing-protection operational discipline the Workspace tenant must sustain post-launch.
• TLS-RPT record syntax deep dive — the WORKSPACE-TENANT- TRANSPORT-LAYER-HARDENING- PUBLISHER-SIDE-DEPLOYMENT-PAIR companion reference. Where THIS page documents the Google Workspace tenant's DMARC publication and SPF / DKIM / Gmail-receive-boundary configuration that protects message-layer sender identity-alignment for the tenant's mail-flow, the TLS-RPT record-syntax spoke is the authoritative reference for the publisher-side authoring step that produces receiver-side reports of the SMTP TLS handshake failures and MTA-STS policy-compliance outcomes a Workspace tenant otherwise has ZERO visibility into. Workspace tenant publishers SHOULD deploy TLS-RPT alongside MTA-STS as the transport-layer-hardening publisher-side observability pair — mta-sts.<domain> policy file at /.well-known/mta-sts.txt with version: STSv1 + mode: enforce|testing|none + mx: Gmail- smtp-allow-list (typically aspmx.l.google.com + alt[1-4].aspmx.l.google.com) + max_age:, plus the _mta-sts.<domain> TXT-record with v=STSv1 + id=, plus the _smtp._tls.<domain> TXT-record with v=TLSRPTv1 + rua=mailto:/ rua=https: report-endpoint declaration. The TLS-RPT record-syntax spoke documents the publisher- side authoring step (the v=TLSRPTv1 version-tag mandatory-first, the rua=mailto: and rua=https: endpoint forms with multiple- comma-separated semantics, the trailing-; terminator-not-separator semantics per RFC 8460 §3.2, the canonical publication- pre-MTA-STS-deployment ordering — publish TLS-RPT FIRST as a 1-week baseline observability tier BEFORE publishing the MTA-STS policy file with mode: testing → mode: enforce transition) that gives the Workspace tenant publisher SILENT-TRANSPORT-FAILURE OBSERVABILITY the Workspace admin console alone does not provide — receiver-side failure-class JSON reports arrive daily at the publisher's rua= endpoint cataloguing per- receiver SMTP TLS handshake failures (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid), each of which the Workspace admin would otherwise NEVER SEE (failed-TLS messages get bounced or downgraded silently without surfacing in the tenant Admin Console's message-log UI). Read the TLS-RPT record-syntax spoke alongside this Workspace DMARC deployment page when authoring the tenant's full DNS-record inventory and publisher-side observability runbook — DMARC publication on _dmarc.<domain> gives message-layer alignment observability, TLS-RPT publication on _smtp._tls.<domain> gives transport-layer encryption-and-policy observability, and joint deployment is the defensible defense-in-depth posture for any Workspace tenant whose threat model includes silent- downgrade or man-in-the- middle attacker scenarios at the SMTP transport layer below the message- authentication layer this page configures.
• Email deliverability — the WORKSPACE-POSTMASTER-TOOLS- DELIVERABILITY-OUTCOME-INDICATOR companion. Where THIS page documents Workspace-tenant-side DMARC posture (per-domain SPF includes via _spf.google.com, per- selector Workspace DKIM signing, per-domain DMARC TXT publication through Google Admin Console), the deliverability spoke documents the UMBRELLA RECEIVER-SIDE INBOX- PLACEMENT OUTCOME the Workspace tenant's authentication-posture decisions ultimately determine. The deliverability spoke is the canonical reference for the EIGHT RECEIVER-SIDE INBOX-PLACEMENT SIGNAL DIMENSIONS Workspace tenants measure via Postmaster Tools (postmaster.google.com): (i) Sender Reputation (per-domain rolling 30-day score Bad / Low / Medium / High); (ii) Domain Reputation (the From: header organisational-domain reputation); (iii) IP Reputation (per-sending-IP reputation including the Workspace SMTP relay pool); (iv) Spam Rate (the Workspace-tenant-reported spam-mark rate at recipient Gmail / Workspace mailboxes); (v) Authentication Pass Rate (the SPF-alignment + DKIM- alignment + DMARC-evaluation pass percentage Google's receiver-side evaluation reports); (vi) Encryption (the percentage of inbound TLS- encrypted SMTP connections from the Workspace tenant's send-population); (vii) Delivery Errors (per-error-code breakdown of 421/450/500-class SMTP-reject responses); (viii) Feedback Loop (post-delivery recipient-marked-as-spam events). Each Workspace-side authentication decision documented on THIS page translates to one or more Postmaster-Tools signal-dimension readings the deliverability spoke anchors against the umbrella outcome. Read THIS Workspace-DMARC page WITH the deliverability spoke when designing a per-tenant authentication-posture-and- deliverability-outcome closed-loop operational discipline.
• Reverse DNS and PTR records explained — the WORKSPACE-TENANT-OUTBOUND-SMTP- RELAY-PER-CONNECTING-IP-PTR-FCRDNS- RECEIVER-SIDE-CONNECTION-FILTERING-GATE companion to this Workspace DMARC deployment guide. Where THIS page documents the Workspace-tenant-side message-layer authentication posture (per-domain SPF v=spf1 include:_spf.google.com ~all publication, per-selector Workspace- managed DKIM key publication at google._domainkey.<d=>, per-organisational-domain DMARC TXT publication via Google Admin Console), the reverse-DNS / PTR spoke is the TRANSPORT-LAYER-CONNECTION-FILTERING receiver-side gate Gmail enforces against every connecting SMTP client from the Workspace outbound relay pool (*.google.com / aspmx.l.google.com) — and against every third-party-ESP outbound IP a Workspace tenant delegates to via the SPF include: cascade. The four-axis WORKSPACE-DMARC-VS-REVERSE- DNS-PTR coordination model exposes the structurally-distinct deployment responsibilities: (i) Feb 2024 Gmail bulk-sender published requirement at support.google.com/mail/answer/81126 EXPLICITLY mandates valid forward-and- reverse DNS records (FCrDNS) for the sending IP for any sender exceeding 5 000 messages per day to Gmail consumer or Workspace recipients — making PTR / FCrDNS publication a LOAD-BEARING DELIVERABILITY PREREQUISITE that runs at the SMTP- connection-establishment phase BEFORE the per-message DMARC evaluation this page documents — the reverse- DNS / PTR spoke documents the canonical IPv4 <reversed-octets>.in-addr.arpa / IPv6 ip6.arpa nibble-reversed PTR publication mechanics every bulk-sending Workspace tenant must publish at the per-connecting-IP boundary, AND the per-sending-IP PTR-hostname-matches-DKIM- d=-domain alignment Gmail receiver-side reputation engines score against; (ii) Workspace- managed outbound SMTP relay (aspmx.l.google.com / *.google.com / smtp.gmail.com) publishes Google-managed PTR records out-of-the- box, so direct-MX Workspace sending inherits FCrDNS-pass at no operator action — but tenant-side include: cascade delegation to a third-party-ESP outbound IP (Mailchimp / SendGrid / Postmark / Mailgun) REQUIRES the operator to confirm the third-party- ESP outbound IP's PTR publication BEFORE the Workspace tenant's per- message SPF-aligned-pass via the third-party-ESP egress can materialise a Gmail-delivered-to-inbox outcome — the reverse-DNS / PTR spoke documents the per-ESP- outbound-pool PTR-audit operational discipline every Workspace tenant deferring outbound sending via include: delegation must execute against the per-tenant ESP- relationship boundary; (iii) per-Workspace-tenant on- premises hybrid Exchange / dedicated outbound-relay deployment publishing its own egress IP (custom outbound SMTP relay, e.g. mta1.<d=> on a tenant-owned IP) MUST coordinate the PTR publication at the IP-owner's registrar / hosting-provider control plane (AWS PTR submission form, Hetzner Robot rDNS UI, Azure VM portal-side rDNS) and ALIGN that PTR hostname with the DKIM d= signing-identity domain — a Workspace tenant publishing ec2-<ip>.compute-1.amazonaws.com as the PTR while signing with d=<tenant>.com produces a Gmail iprev=pass + dkim=pass that the reputation-scoring layer scores LOWER than the aligned-PTR-with- signing-domain alternative — the reverse-DNS / PTR spoke documents the per-tenant custom-PTR- request escalation path every Workspace tenant maintaining a dedicated outbound-relay IP must complete BEFORE the Feb 2024 bulk- sender deadline window; and (iv) per-Workspace-tenant iprev=fail Authentication- Results verdict observable in the message header of any inbound test message routed via Workspace inbound SMTP flags PTR / FCrDNS misconfiguration AT THE SAME DIAGNOSTIC SURFACE as the SPF / DKIM / DMARC verdicts the operator already inspects via Postmaster Tools — making the iprev= verdict the canonical receiver-side PTR / FCrDNS diagnostic primitive every Workspace tenant should include in the per-tenant authentication- posture audit checklist alongside the spf= / dkim= / dmarc= verdicts this page's deployment guide produces — the reverse- DNS / PTR spoke documents the receiver-side iprev=-verdict-as- FCrDNS-diagnostic operational discipline every Workspace tenant verifying Feb 2024 bulk-sender compliance must execute against the per-tenant outbound-IP boundary. Read the reverse-DNS / PTR spoke BEFORE the Feb 2024 Gmail bulk-sender deadline when commissioning a new Workspace- tenant outbound-sending IP (audit the PTR publication AS PART OF the same change-set as the SPF + DKIM + DMARC publication), when adding a new third-party ESP via the SPF include: cascade (audit the ESP outbound- IP-pool PTR-publication discipline BEFORE the SPF-include goes live), and when diagnosing a Gmail- Postmaster-Tools "Sender Reputation" downgrade that correlates with a Workspace- tenant outbound-IP change.
• SPF for Microsoft 365 — the PEER-CLOUD-MAILBOX-PROVIDER-M365- TENANT-SPF-PUBLICATION-AS-WORKSPACE-INBOUND- AUTHENTICATION-EVIDENCE companion to this DMARC-for-Google-Workspace reference. Where THIS page documents the per- Workspace-tenant deployment topology (per- tenant DMARC publication, per-tenant include:_spf.google.com cascade, per-tenant DKIM key publication, per-tenant outbound-IP topology, Workspace- inbound EOP-equivalent spam-filtering for per-tenant inbound flows), the SPF-for- Microsoft-365 spoke is the PEER-CLOUD- MAILBOX-PROVIDER PER-M365-TENANT-SPF- PUBLICATION reference whose per-tenant publication discipline the Workspace- inbound spam-filter consumes for mail- from-M365-tenant senders at FOUR cross- cloud M365-to-Workspace mail-flow-leg authentication-publication coupling dimensions: (i) per-M365-tenant include:spf.protection.outlook.com as authentication-record Workspace inbound consumes for mail-from-M365- senders — the per-M365-tenant SPF cascade publication directly determines whether Workspace inbound spam-filter produces SPF-pass against mail-from-M365- tenant senders, which becomes the per- tenant message-layer authentication input to the Workspace-side DMARC-evaluation verdict the per-Workspace-tenant deployment topology on THIS page consumes; (ii) per-M365-tenant outbound- smarthost / mail-flow-connector gateway IP-list as source-IP topology Workspace inbound authenticates against published M365 SPF — every per-M365-tenant outbound smarthost or mail-flow-connector IP is the load-bearing source-IP topology Workspace inbound must authenticate against the per-tenant published M365 SPF record, which the per-Workspace-tenant deployment topology on THIS page consumes as the per-tenant per-mail-flow-leg authentication evidence; (iii) per-M365-tenant SPF-alignment with Header- From as load-bearing DMARC-verdict input Workspace inbound records — every per-M365-tenant SPF record whose per-tenant publication scope aligns organisationally with the per-tenant Header-From is the load-bearing per- tenant SPF-alignment-pass input the Workspace-inbound DMARC evaluator on the Workspace-side consumes for cross-cloud mail-from-M365-tenant deliverability; (iv) Workspace-inbound per-tenant DKIM verification + M365-sender SPF as COMPLEMENTARY message-layer-authentication disciplines for the M365-to-Workspace mail-flow leg — the per-M365- tenant outbound DKIM-signing publication plus per-tenant SPF-publication produces the COMPLEMENTARY message-layer cross- cloud authentication evidence stack the Workspace-inbound DMARC evaluator on the Workspace-side consumes for the cross- cloud M365-to-Workspace mail-flow leg the per-Workspace-tenant deployment topology on THIS page consumes. Read the SPF-for-Microsoft-365 spoke alongside this DMARC-for-Google-Workspace reference when scoping the per-M365-tenant SPF publication discipline the Workspace- inbound DMARC-evaluator structurally consumes for cross-cloud M365-to- Workspace mail-flow-leg deliverability.
• DMARC for Office 365 Hybrid — the peer enterprise-mailbox-provider DMARC-deployment-topology companion to this Google-Workspace-specific deployment reference. Where THIS page documents the WORKSPACE-TENANT-AS-SINGLE-CLOUD-PROVIDER deployment topology (the canonical include:_spf.google.com SPF mechanism + the Workspace-managed google._domainkey DKIM selector + the Admin Console-driven _dmarc publication + verification workflow), the Office-365- hybrid spoke documents the structurally- distinct HYBRID-EXCHANGE-AS-DUAL-MAIL-FLOW deployment topology in which the per- tenant outbound stream is split across on-prem Exchange + Exchange Online via the per-tenant mail-flow connector + on-prem Edge Transport role, producing TWO independent source-IP topologies the per-tenant SPF must authorize (include:spf.protection.outlook.com for the cloud leg + per-tenant on-prem IP literals or mx mechanism for the on-prem leg) and TWO independent DKIM signing surfaces (Exchange-Online- managed selector1._domainkey + on-prem-Exchange-managed selector for legacy on-prem signed mail). Read the Office-365-hybrid spoke alongside this Workspace deployment reference when scoping the per-tenant DMARC-deployment- topology decision tree across the two dominant enterprise mailbox-provider platforms — the Workspace-tenant deployment THIS page documents is the single-cloud-provider baseline against which the Office-365-hybrid spoke's dual-mail-flow topology contrasts at every per-tenant SPF / DKIM / DMARC publication-discipline coupling dimension.
• DMARC forensic / failure reports — the per-Workspace-tenant RUF forensic-evidence as load-bearing per- message diagnostic complement to per- tenant RUA aggregate evidence companion to this Google-Workspace-specific deployment reference. Where THIS page documents the WORKSPACE-TENANT-AS- SINGLE-CLOUD-PROVIDER deployment topology + per-tenant include:_spf.google.com SPF cascade + per-tenant Workspace- managed google._domainkey DKIM selector + per-tenant _dmarc publication + per-tenant Admin Console-driven verification + per-tenant rua=mailto:<mailbox> aggregate-mailbox configuration, the forensic-reports spoke documents the structurally-distinct PER-MESSAGE AFRF (Abuse Feedback Report Format, RFC 6591) forensic-evidence-capture publication-discipline whose per- Workspace-tenant RUF emission pattern is the load-bearing per-message diagnostic complement to the per- tenant RUA aggregate per-row evidence-stream this Workspace deployment reference's per-tenant verification workflow produces. Four PER-WORKSPACE-TENANT-RUF-FORENSIC- EVIDENCE coupling dimensions the forensic-reports spoke documents that THIS Workspace deployment reference is the upstream per- tenant configuration foundation for: (i) per-Workspace-tenant ruf=mailto:<mailbox> publication discipline as the per- tenant AFRF delivery endpoint — every per-receiver AFRF forensic- evidence emission against per- Workspace-tenant outbound mail traverses the per-tenant ruf= mailbox the per- tenant DMARC TXT publication THIS Workspace deployment reference's Admin Console workflow produces; (ii) per-Workspace-tenant Gmail-as-non-RUF-emitter receiver coverage gap — Gmail (the Workspace receiver) does NOT emit RUF AFRF forensic-evidence for Workspace-tenant outbound mail (Google's per-tenant privacy policy), so the per-Workspace- tenant RUF stream consumes ONLY per-receiver-from-non-Google receivers (Microsoft / Yahoo / ProtonMail / per-ESP private receivers) the forensic-reports spoke's per-receiver-coverage- matrix catalogues; (iii) per-Workspace-tenant fo=0|1|d|s failure- option publication discipline as the per-tenant AFRF trigger criterion — the per- Workspace-tenant per-failure-options token choice (fo=1 for full per-mechanism visibility into per-tenant include:_spf.google.com cascade plus per-tenant google._domainkey signing failures, fo=0 for only complete-alignment-fail) directly determines per-receiver AFRF emission scope; (iv) per-Workspace-tenant transactional- ESP / Marketing-ESP per-customer- signed-mail per-message forensic- attribution discipline — when per-Workspace-tenant outbound mail flows through external SaaS senders (Mailchimp / SendGrid / Klaviyo / per-customer-CNAME- delegated DKIM signing), the per- receiver AFRF stream gives per- message attribution distinguishing Workspace-direct mail from per- SaaS-platform-relayed mail at the per-message identifiers block. Read the forensic-reports spoke alongside this Workspace deployment reference when authoring the per-Workspace-tenant ruf= + fo= + rf= per-tag subset of the per-tenant DMARC TXT publication — the per-Workspace- tenant Admin Console DOES NOT publish these per-tag values (Admin Console manages p=, rua=, and the canonical _dmarc record skeleton, but per-tenant per-tag ruf= + fo= + rf= publication requires per-tenant DNS-edit-direct intervention).
• DANE for SMTP — the WORKSPACE-TENANT-INBOUND-MX- AT-aspmx.l.google.com-AS-LOAD-BEARING- DANE-DEPLOYMENT-CONSIDERATION-FOR- EVERY-DMARC-PROTECTED-WORKSPACE-DOMAIN companion documenting how the per- Workspace-tenant inbound-MX host set (the canonical aspmx.l.google.com at preference 1 + the four alt[1-4].aspmx.l.google.com backup hosts) is the per-publisher transport-layer receiving-MX infrastructure whose RFC 7672 DANE- for-SMTP TLSA-RR publication posture the per-Workspace-tenant operator must consider when scoping the per- domain complete cross-layer publication discipline this DMARC deployment guide documents the message-layer publication of. Where THIS page documents the per- Workspace-tenant DMARC message-layer publication discipline (the canonical include:_spf.google.com SPF record, the Workspace-managed DKIM signing-key at google._domainkey selector, the per-tenant _dmarc.<domain> TXT-RR publication, the per-tenant Admin Console verification workflow + RUA-mailbox configuration), the DANE-for-SMTP spoke is the per- Workspace-tenant cross-layer transport-layer DANE deployment reference at four per-Workspace- tenant inbound-MX-DANE-deployment-vs- DMARC-message-layer-publication coupling dimensions: (i) per- Workspace-tenant inbound-MX host set as load-bearing transport-layer receiving-MX infrastructure whose DANE deployment posture is per-MX- host-published not per-Workspace- tenant-published — every per- Workspace-tenant operator's aspmx.l.google.com + alt[1-4].aspmx.l.google.com inbound-MX host set is Google- operated infrastructure whose per-MX- host TLSA-RR publication posture belongs to Google's per-MX-host publication discipline (NOT the per- Workspace-tenant's per-domain publication discipline) — the per- Workspace-tenant operator does NOT publish per-MX TLSA-RRs for Google-operated inbound MX hosts; every per-Workspace-tenant operator is a DANE deployment-posture CONSUMER of Google's per-MX-host publication discipline at the Workspace inbound boundary, not a DANE publication- discipline PRODUCER for those MX hosts; (ii) per-Workspace- tenant DNSSEC-on-publishing-zone commitment as load-bearing per- domain DANE-publication-discipline prerequisite for per-tenant subdomain MX deployments — when a per-Workspace-tenant operator deploys a per-tenant subdomain (e.g. news.<tenant>, billing.<tenant>) with per-tenant-operated MX hosts (not Google-operated), the per- tenant per-domain DANE-publication discipline structurally REQUIRES DNSSEC validation of the per- subdomain TLSA-RRs per RFC 7672 §1.3.4 (any non-DNSSEC-validated TLSA-RR is treated as absent); the per-Workspace-tenant operator's DNSSEC-on-publishing-zone commitment is the load-bearing prerequisite for any per-tenant- operated-MX DANE deployment discipline; (iii) per- Workspace-tenant TLS-RPT publication as load-bearing transport-layer- observability complement to DMARC message-layer-observability for per-tenant outbound-from-Workspace mail-stream transport-failure detection — when a per- Workspace-tenant operator publishes the per-tenant _smtp._tls.<tenant> TXT-RR per RFC 8460, the per-tenant TLS-RPT JSON-failure-report stream becomes the transport-layer observability complement to the per-tenant rua-aggregate-XML stream this DMARC deployment guide documents — together producing per-tenant cross-layer observability for both message-layer DMARC-alignment failures AND transport-layer DANE/ MTA-STS/STARTTLS-negotiation failures on outbound-from-Workspace mail- streams (e.g. STARTTLS-not-supported at recipient MX, TLSA-RR validation failures at DANE-enforcing recipients, MTA-STS policy-fetch failures); (iv) per- Workspace-tenant cross-layer publication-discipline stack — message-layer DMARC + transport- layer DANE/MTA-STS/TLS-RPT — as per-Workspace-tenant per-domain complete publication-discipline scope — every per-Workspace- tenant per-domain publication- discipline catalogue (SPF + DKIM + DMARC at message-layer + MTA-STS + DANE at transport-layer + TLS-RPT at transport-layer-observability + BIMI VMC at display-layer) composes into a per-Workspace-tenant complete per-domain cross-layer publication-discipline scope; the DANE-explained spoke is the canonical per-publisher transport-layer-DNSSEC- anchored-cryptographic-publication reference per-Workspace-tenant operators consume alongside this Workspace-DMARC deployment guide when scoping the per-tenant per- domain cross-layer publication discipline the per-tenant message- layer DMARC publication this page documents is one layer of, alongside the per-tenant transport-layer DANE TLS-cert-attestation the DANE- explained spoke documents.
• MTA-STS for Microsoft 365 — the CROSS-CLOUD-PEER-MAILBOX-PROVIDER- M365-MTA-STS-AT-mta-sts-PERIOD-DOMAIN-HTTPS- POLICY-PUBLICATION-VS-WORKSPACE-MTA-STS-AT- mta-sts-PERIOD-DOMAIN-HTTPS-POLICY-PUBLICATION- CROSS-CLOUD-TRANSPORT-LAYER-PUBLICATION- TOPOLOGY-PARALLEL companion reference. Where THIS page documents the Google Workspace cloud tenant DMARC deployment topology (per-tenant google._domainkey.<d> DKIM publication, Workspace inbound MX at aspmx.l.google.com, per-tenant Admin Console operator-discipline, per- tenant Gmail outbound DKIM signing pipeline), the mta-sts-for-microsoft-365 spoke is the STRUCTURALLY-PARALLEL cross-cloud transport- layer publication-topology reference whose per-M365-tenant transport-layer per-MX-host MTA-STS-policy-file publication discipline is the STRUCTURAL ANALOGUE to the per- Workspace-tenant transport-layer per-MX- host MTA-STS-policy-file publication discipline operators commonly deploy in parallel across cross-cloud multi-tenant portfolios, at four cross-cloud MTA-STS- deployment-topology coupling dimensions: (i) Cross-cloud per-tenant per-MX- host MTA-STS-policy-file-content asymmetry — M365 EOP per-tenant per-domain MX targets vs Workspace per-tenant inbound MX at aspmx.l.google.com — the per- M365-tenant MTA-STS-policy-file enumerates the per-tenant per-domain Exchange Online Protection MX hostnames (typically <tenant>-com.mail.protection.outlook.com + *.mail.protection.outlook.com SAN-pattern); the per-Workspace-tenant MTA-STS-policy-file enumerates the per- tenant per-domain Workspace inbound MX hostnames (typically aspmx.l.google.com + alt[1234].aspmx.l.google.com); the per-MX-host enumeration discipline is STRUCTURALLY DIFFERENT across the two clouds (M365 single-cloud-managed cert infrastructure vs Workspace single-cloud- managed cert infrastructure with different per-domain mx-routing topology); (ii) Cross-cloud per-tenant per-domain MTA-STS-policy-mode-and-max_age operator- discipline parallel — both M365 and Workspace tenants follow the STRUCTURALLY-IDENTICAL per-tenant per- domain MTA-STS policy-mode publication discipline (testing → enforce stage gates per RFC 8461 §5, 24-hour-minimum-to-1-year- recommended max_age: publication-discipline, per-policy-file- rotation cadence); the operator-skillset overlap is the per-tenant per-domain MTA-STS-policy-mode-and-max_age-gate progression discipline both clouds share; (iii) Cross-cloud per-tenant per- domain MTA-STS-host HTTPS-cert-procurement operator-discipline parallel — both M365 and Workspace tenants must operator-side procure a per-domain HTTPS- cert for the per-tenant mta-sts.<d> well-known- path host (from a per-publisher public-CA- issuance-restriction respected at the per-domain CAA-RR boundary); the per- tenant per-domain HTTPS-cert-procurement- and-renewal lifecycle is STRUCTURALLY- IDENTICAL across the two clouds (Let's Encrypt per-90-day renewal at the per- tenant per-domain DNS-zone-management + HTTPS-host-management operator-surface boundary); (iv) Cross-cloud per- tenant per-domain cross-layer publication- discipline-stack composition parallel — Workspace DKIM + DMARC + MTA-STS + TLS-RPT vs M365 DKIM + DMARC + MTA-STS + TLS-RPT — both M365 and Workspace tenants compose the per-tenant per-domain complete cross- layer publication-discipline-stack (message-layer DKIM + DMARC + transport- layer MTA-STS + TLS-RPT) into the per- tenant per-domain Bulk Sender Requirements 2024 compliance-coverage; the cross-cloud operator-skillset overlap is the per- tenant per-domain cross-layer publication- discipline-stack-completion discipline both clouds require — the mta-sts-for-microsoft- 365 spoke documents the M365-tenant instantiation of THIS Workspace-tenant deployment reference's transport-layer publication-discipline structural-parallel. Read the mta-sts-for-microsoft-365 spoke ALONGSIDE this Workspace-tenant DMARC deployment reference whenever the cross- cloud per-tenant per-domain MTA-STS deployment architecture must coordinate per-tenant per-cloud transport-layer publication-discipline choices — most commonly when a protected vanity domain has BOTH M365 Exchange Online and Google Workspace tenants serving inbound and outbound mail at the per-tenant per-domain MX-target boundary.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, and ARC results.
• Domain Security Checker — live DNS lookups for every email- authentication record on a domain. Surfaces the live SPF lookup count, the published DKIM selectors, and the DMARC policy state.
• DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• DMARC Analyzer Dashboard — ingests Workspace-receiver aggregate reports and surfaces the per-sender / per-IP / per-day breakdown via includes/DmarcParser.php.
• DMARC troubleshooting — the WORKSPACE-TENANT-DMARC-FAILURE- PATTERN-DIAGNOSTIC-LADDER-CONSUMER companion to this Workspace-tenant deployment reference. Where THIS page documents the per-Workspace-tenant deployment workflow (google._domainkey.<d> direct TXT-RR DKIM publication discipline + Admin Console "Generate new record" workflow + Workspace per-tenant SPF include:_spf.google.com publication + per-tenant _dmarc.<d> record with rua= + adkim/aspf tag publication + the five-host aspmx-tier MX inventory at aspmx.l.google.com + alt1..alt4.aspmx.l.google.com), the dmarc-troubleshooting spoke is the OPERATOR-FACING DIAGNOSTIC-LADDER reference whose four canonical Pattern-1-through- Pattern-4 ladders intersect with Workspace- tenant-specific deployment surfaces at four diagnostic-ladder-intersection dimensions: (i) Pattern 1 SPF-aligned-pass- regression diagnostic ladder × Workspace- tenant _spf.google.com include cascade — when a per-Workspace-tenant per-domain rua aggregate-XML stream surfaces a per- source-IP cohort with policy_evaluated.spf=fail, the Pattern-1 ladder walks the Workspace operator through the include:_spf.google.com cascade evaluation, the 10-lookup budget consumed by the Google-published include cascade, and the per-tenant SPF record's residual budget for vendor includes (the Workspace-tenant-specific cascade depth differs from M365 + spf.protection.outlook.com cascade depth and requires the operator to scope the SPF flattening discipline accordingly); (ii) Pattern 2 forwarder-hop-alignment-loss diagnostic ladder × Workspace-tenant inbound Gmail ARC trust posture — when the Pattern-2 ladder surfaces a per-forwarder- hop alignment-loss, the Gmail-side ARC- trust posture (Gmail is one of the canonical ARC trusted sealers in the industry) is the receiver-side remedy primitive Workspace senders rely on for forwarder-hop alignment recovery; the troubleshooting spoke walks the operator through the per-forwarder-class catalogue (Workspace Groups mediator, Workspace alias rewriting, .forward / Sieve forwarders, MLM expanders) and the per-class ARC-trust-list-extension decision; (iii) Pattern 3 DKIM-alignment-pass- failure diagnostic ladder × Workspace- tenant google._domainkey direct TXT-RR publication — when the Pattern-3 ladder walks the operator through the DKIM- alignment-failure root cause catalogue (selector-publication gap, Admin-Console- not-yet-generated, key-rotation-mid-flight cutover gap at google → google2 → google3 selector-namespace progression, d=-tag emission-default-onmicrosoft-vs-vanity-domain divergence), the diagnostic-ladder reference cross-links back to THIS page's google._domainkey.<d> direct TXT-RR publication + Admin Console "Generate new record" workflow + 2048-bit RSA upgrade discipline as the per-Workspace- tenant DKIM-publication primitives the diagnostic ladder evaluates against; (iv) Pattern 4 per-source-IP-cohort- attribution diagnostic ladder × Workspace- tenant Gmail-24-hour-UTC-aligned-batch rua- emission cadence — when the Pattern-4 ladder walks the operator through the per- source-IP-cohort attribution boundaries, the Workspace-tenant-specific Gmail 24-hour UTC- aligned batch rua-emission cadence (distinct from M365 EOP's hourly rolling-window cadence) is the cadence-disambiguator the operator consumes when scoping per-day evidence-row attribution windows for per-Workspace-tenant per-source-IP cohort attribution. Read the troubleshooting spoke ALONGSIDE this Workspace- tenant deployment reference whenever the per- Workspace-tenant rua aggregate-XML stream surfaces an unexpected per-source-IP-cohort disposition shift — the Workspace-tenant deployment surfaces THIS page documents are the publication primitives, the diagnostic ladders the troubleshooting spoke documents are the operator-facing ladders that walk from observed regression to publication- primitive root cause in this Workspace-tenant deployment reference. Together with the parallel M365 DMARC-deployment entry above, the two Workspace + M365 troubleshooting diagnostic-ladder entries form the cross- cloud enterprise-mailbox-provider DMARC- diagnostic-ladder pair operators consult when DMARC-troubleshooting investigations span mixed-cloud sender inventories.
• DMARC reporting pipeline (RUA / RUF ingestion, parsing, delivery) — the canonical end-to-end pipeline reference documenting how the per- Workspace-tenant per-domain DMARC deployment THIS page architectures becomes the publisher-side entry-point into the five-stage receiver-to-operator infrastructure path that serialises every per-Workspace-tenant per-domain aggregate-report into operator- consumable per-row evidence: (1) Gmail 24-hour UTC-aligned aggregate-XML generation cadence (the Workspace- tenant-specific receiver-side cadence distinct from M365 EOP's hourly rolling- window cadence), (2) per-Workspace- tenant rua= publication at the apex _dmarc.<d> TXT-RR with external-domain delegation requirement at _report._dmarc.<d> per RFC 7489 §7.1, (3) per-Workspace- tenant Gmail consumer-mailbox IMAP / Gmail-API ingestion (Workspace tenants can ALSO consume rua at a Gmail-hosted mailbox — the dogfooded receive path most Workspace operators choose), (4) parser-side XML-to-row decomposition via DmarcParser minting dmarc_records rows with the per-Workspace-tenant per-Gmail- recipient policy_evaluated.dkim/ spf verdicts, and (5) dashboard delivery surfacing the per-Workspace- tenant per-source-IP per-disposition evidence the Workspace-tenant rollout decisions THIS page documents structurally depend on. Read the reporting-pipeline spoke ALONGSIDE this Workspace-tenant deployment reference whenever a Workspace operator asks "where does my rua go and how do I consume it" — the answer is FIVE-LAYERED: THIS page documents the Workspace-tenant publisher-side rua- publication-discipline, the reporting- pipeline spoke documents the five-stage receiver-to-operator infrastructure path the Workspace-tenant rua evidence traverses end-to-end.
• MTA-STS policy file syntax — the PER-WORKSPACE-TENANT- mta-sts.txt-POLICY-FILE-BYTE-LEVEL- PUBLICATION-REFERENCE companion to this Workspace-tenant DMARC deployment-discipline reference. Where THIS page documents the per-Workspace-tenant SPF / DKIM / DMARC message-authentication publication discipline, the mta_sts_policy_syntax spoke documents the per-Workspace-tenant MTA-STS POLICY-FILE BYTE-LEVEL PUBLICATION the per-tenant operator publishes at https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt per RFC 8461 §3.2: the four mandatory fields (version: STSv1, mode: enforce|testing|none, mx: <hostname-pattern>, max_age: <seconds>), the per-mode receiver-side enforcement outcomes the per-Workspace-tenant operator commits to, and the per-tenant _mta-sts.<tenant-domain> TXT-record discovery primitive whose v=STSv1; id=<policy-id> format every receiver fetches before retrieving the policy file. FOUR structurally-distinct PER-WORKSPACE- TENANT-MTA-STS-POLICY-FILE-PUBLICATION dimensions the Workspace-tenant DMARC deployment THIS page documents operationally consumes: (i) per-Workspace-tenant mx: aspmx.l.google.com + mx: *.googlemail.com mx-pattern publication AS LOAD- BEARING-PER-TENANT-INBOUND-TRANSPORT- SECURITY-AUTHORIZATION-INVARIANT — every Workspace tenant's inbound mail-flow terminates at the Google- managed aspmx.l.google.com + alt[1-4].aspmx.l.google.com + *.googlemail.com MX-hostname pattern; the per-tenant mta-sts.txt mx:-field publication the policy-syntax spoke documents is the canonical per-tenant MX-pattern publication the per-receiver-side MTA-STS-aware sending MTA validates the negotiated-TLS-certificate against during inbound mail-flow, directly mirroring the per-tenant SPF-include and DKIM-CNAME- delegation publications THIS page catalogues; (ii) per- Workspace-tenant mode: testing → mode: enforce progression AS LOAD-BEARING-PARALLEL- TO-DMARC-p=none-→-p=quarantine-→- p=reject-ROLLOUT DISCIPLINE — the per-tenant mta-sts.txt mode:-field testing-to- enforce progression the policy- syntax spoke documents IS the structural transport-layer parallel to the per-tenant DMARC p=none-to- p=quarantine-to- p=reject progression THIS page's Workspace-tenant rollout sections catalogue: both the per-tenant message- authentication enforcement-policy and per-tenant transport-security enforcement-policy advance through a baseline-observability → partial- enforcement → full-enforcement ladder coordinated against per- tenant aggregate-report and per- tenant TLS-RPT empirical evidence; (iii) per-Workspace-tenant _mta-sts.<tenant-domain> TXT-record + Postmaster-Tools per-receiver TLS-handshake-rate observability AS LOAD-BEARING-PER- TENANT TLS-RPT-CONSUMER COUPLING — the per-tenant mta-sts.txt publication the policy-syntax spoke documents structurally co-publishes with the per-tenant _smtp._tls.<tenant-domain> TLS-RPT TXT-record whose per- receiver per-day per-publisher RFC 8460 JSON aggregate stream surfaces every per-tenant per- receiver-side mta-sts.txt-policy- violation (mx-mismatch, certificate- host-mismatch, expired-certificate, STS-NXDOMAIN) via the Postmaster- Tools-observable empirical evidence stream the Workspace-tenant operator consumes; (iv) per- Workspace-tenant max_age:-field publication-cadence AS LOAD- BEARING-PER-TENANT POLICY-ROTATION-CADENCE-DISCIPLINE — the per-tenant mta-sts.txt max_age:-field publication the policy-syntax spoke documents (typical Workspace-tenant value: max_age: 604800 for 7-day cache, ramping to max_age: 2592000 at 30-day cache after Workspace-tenant operator confidence per-receiver per-day TLS-handshake-rate baseline) is the canonical per- tenant policy-rotation-cadence discipline that mirrors the per- tenant DMARC-record TTL discipline and DKIM-CNAME-delegation TTL discipline THIS page's per- Workspace-tenant zone-publication sections catalogue. Read the mta_sts_policy_syntax spoke ALONGSIDE this Workspace-tenant DMARC deployment reference when the per-tenant operator extends the message-authentication deployment discipline THIS page documents WITH the per-tenant transport-security deployment discipline the spoke catalogues — the spoke is the canonical PER- WORKSPACE-TENANT-mta-sts.txt- POLICY-FILE-BYTE-LEVEL- PUBLICATION REFERENCE the per- tenant inbound mail-flow transport-security depends on at the per-tenant mta-sts.<tenant-domain> HTTPS-fetched policy-file publication level.
• DKIM-Signature header tag anatomy — the per-message HEADER companion to this Workspace-tenant DKIM TXT-record signing deployment guide. Where THIS page documents the per-tenant DKIM TXT-record publication discipline (google._domainkey at the customer-domain holding the Workspace- generated RSA-2048 public key plus per-tenant additional selectors for partner-sender segregation), the DKIM-Signature-header anatomy reference documents the per-message header Google's signing infrastructure actually emits at send-time — the v= / a= / c= / d= / s= / h= / bh= / b= tag layout, the canonicalization choice Google's mail-emission pipeline applies (relaxed/relaxed), and the signed-header-list Google commits to. Read the DKIM-Signature-header anatomy reference whenever a per- Workspace-tenant administrator needs to decode a specific message's DKIM-Signature header from the Authentication-Results stack or a captured forensic-report payload — the per-tenant TXT-record-publication workflow THIS page documents IS the upstream key-publication discipline that produces the per-message DKIM- Signature headers the anatomy reference decodes.
• DKIM troubleshooting — the PER-WORKSPACE-TENANT PER- SELECTOR DKIM-VERIFICATION-FAILURE- DIAGNOSTIC-PLAYBOOK companion to this Workspace-tenant DMARC deployment reference. Where THIS page documents the per-Workspace-tenant DKIM-key publication discipline at google._domainkey.<tenant-domain> via the Google Admin Console Apps → Gmail → Authenticate Email workflow (Workspace-generated RSA-2048 public-key CNAME-delegated to Google's signing infrastructure, per-tenant additional selector provisioning for partner-sender segregation, per-tenant k=rsa p=<base64-public-key> TXT-record publication at the customer-domain authoritative nameserver), the DKIM-troubleshooting spoke is the per-Workspace-tenant per-selector failure-mode investigation playbook documenting the FIVE per- receiver DKIM-verifier verdict states a per-Workspace-tenant administrator encounters when reading the per- receiver Authentication-Results evidence stream or per-publisher RUA aggregate-report payload: (i) dkim=none at the per- receiver verdict line indicating the per-Workspace-tenant outbound message carried NO DKIM-Signature header at all — per-Workspace-tenant failure mode where the Admin Console DKIM- signing toggle is disabled or the per-tenant CNAME-delegation to Google's signing infrastructure has not yet been activated; (ii) dkim=temperror indicating the per-receiver verifier could not complete the per-selector public-key DNS-lookup within the per-receiver evaluation-budget window — per- Workspace-tenant failure mode where the per-tenant google._domainkey.<tenant-domain> CNAME is suffering per-RR-TTL propagation lag at the customer- domain authoritative nameserver, or the Google-side signing-infrastructure TXT-record-publication endpoint SERVFAILs under per-receiver query load; (iii) dkim=permerror indicating the per-receiver verifier successfully retrieved the per- selector public-key TXT-record but could not parse it — per-Workspace- tenant failure mode where the customer-domain CNAME points at the wrong Google selector hostname (typo-introduced google._domainkey.google.com instead of the per-tenant Workspace-issued canonical target), the CNAME flattening at the customer- domain authoritative nameserver truncated the upstream public-key TXT past the 255-byte single-string boundary, or the Workspace-side signing TXT carries the p=-revocation marker without the corresponding key material; (iv) dkim=fail indicating the per-receiver verifier retrieved a parseable per-selector public-key but the per-message body- hash or signature-hash did NOT verify — per-Workspace-tenant failure mode where the per-tenant outbound mail-flow post-signature modification (Google-Groups list-header injection, Workspace-side Smart-Compose signature-tagline append, per-tenant admin-mandated banner-injection on external-origin inbound mail being re-emitted via a Google-Groups forward) invalidates the canonicalized body-or-header hash the DKIM-signature committed to; (v) dkim=pass + aligned=false at the DMARC-alignment-evaluator line indicating the DKIM signature itself verified BUT the d=-tag value of the DKIM-Signature header does NOT match the per-Workspace-tenant From: header organizational domain under the per-publisher adkim= alignment- strictness setting — per-Workspace- tenant failure mode where a third- party-sender (Salesforce relay, Mailchimp campaign, HubSpot marketing-email) signs with the ESP's own d=-domain rather than the per-Workspace-tenant customer domain. Read THIS page when PUBLISHING the per-Workspace-tenant DKIM CNAME via the Google Admin Console; read the DKIM-troubleshooting spoke when INVESTIGATING per-tenant per-selector DKIM-verification failures surfaced in per-receiver Authentication-Results headers or per-publisher RUA aggregate-report rows.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the PER-WORKSPACE-TENANT-PER-DOMAIN-DMARC- DISPOSITION-DECISION companion to this Workspace deployment guide. Where THIS page documents the per-Workspace-tenant _dmarc.<domain> TXT-record publication workflow via the Google Admin Console DNS-zone integration AND the per-tenant third-party-sender authentication-coverage build-out (Salesforce relay, Mailchimp campaigns, HubSpot marketing email), the policy-modes spoke is the per-receiver DMARC-disposition-action reference documenting what each p=-tag value actually instructs the per-receiver to DO with per-message DMARC-failed mail: p=none (monitor-only — receivers deliver normally and emit only the per-row RUA aggregate-report entry), p=quarantine (per-receiver Junk-folder routing), and p=reject (per-receiver SMTP-time 550 rejection). Workspace tenants typically progress through the three modes in lock-step with the per-tenant third-party-sender inventory authentication-coverage build-out: launch at p=none for at least 30 days to capture the Workspace egress + Salesforce-relay + Mailchimp-campaign + HubSpot-marketing-email per-source authentication-row inventory in the RUA aggregate-report evidence stream, tighten to p=quarantine once each third-party sender's per-publisher SPF + DKIM alignment-pass rate is at steady-state on the per-receiver per-day rolling window, then promote to p=reject after sustained Workspace-tenant egress + third-party-sender alignment-pass health. Read THIS page when PUBLISHING the per- Workspace-tenant _dmarc TXT record via the Google Admin Console; read the policy-modes spoke when CHOOSING which p=-tag value to publish at each ramp step of the Workspace-tenant DMARC-enforcement-mode progression.
• DKIM selectors explained (RFC 6376 §3.1) — the PER-WORKSPACE-TENANT-DKIM-SELECTOR- IDENTIFIER companion to this Workspace deployment guide. Where THIS page documents the per-Workspace-tenant DKIM publication workflow (the Google Admin Console DKIM activation step that surfaces a per- tenant CNAME target like google._domainkey.<domain> → <tenant-id>.dkim.google.com, the customer-domain authoritative-nameserver CNAME RR publication step, and the Workspace-managed upstream public-key TXT-RR at the canonical Google selector hostname), the DKIM-selectors-explained spoke is the per-publisher per-selector identifier-scheme reference documenting the RFC 6376 §3.1 selector._domainkey. <domain> naming convention, the per-selector public-key TXT-RR byte format with v=DKIM1 + k=rsa + p=<base64> tag-value structure, the canonical per-vendor selector-naming convention (Google's google selector, M365's selector1 / selector2 pair, Mailchimp's k1 selector, SendGrid's s1 / s2 per- sub-user selectors), and the per-selector key-revocation marker (p= with empty value) signalling the selector has been deprecated. Read THIS page when ACTIVATING per-Workspace-tenant DKIM via the Google Admin Console; read the DKIM-selectors-explained spoke when UNDERSTANDING the per-selector identifier scheme that allows multiple per-Workspace- tenant DKIM keys (per-Workspace-tenant primary google._domainkey selector PLUS per-third-party-sender per-vendor selectors like k1._domainkey for Mailchimp or scph0<N>._domainkey for SparkPost) to coexist at the per-customer- domain authoritative DNS zone publication boundary.
• DKIM canonicalization — the per-Workspace-tenant default canonicalization-mode publication discipline as load-bearing per-tenant per- message DKIM-signing-engine fixed canonicalization-mode reference companion to this DMARC-for-Google-Workspace deployment guide. Where THIS page documents the per-Workspace-tenant DMARC publication flow (per-tenant Admin Console configuration, per-tenant primary google._domainkey selector, per-tenant third-party-sender selector coexistence at the per-customer-domain authoritative DNS zone), the DKIM canonicalization spoke documents the per- message RFC 6376 §3.4 simple-vs-relaxed body-and-header canonicalization-mode byte-normalization grammar whose per- Workspace-tenant default c=relaxed/relaxed publication discipline is the LOAD-BEARING per-tenant per-message DKIM-signing-engine fixed canonicalization-mode reference every per-tenant per-domain DMARC deployment STRUCTURALLY DEPENDS on. Four DKIM- CANONICALIZATION-VS-WORKSPACE-TENANT- PUBLICATION cross-correlation axes the canonicalization spoke documents: (i) per-Workspace-tenant default c=relaxed/relaxed canonicalization-mode publication STRUCTURALLY DETERMINES per-tenant per- message body-hash recomputation consistency — every per- Workspace-tenant per-domain primary google._domainkey selector signs per-message DKIM-Signature headers with c=relaxed/relaxed by default; the per-receiver per-message bh= body-hash recomputation normalizes per-line whitespace and strips trailing empty lines BEFORE the SHA-256 body-hash recomputation, preserving the per-message body-hash through per- intermediary whitespace mutation but NOT through per-intermediary footer-injection content-mutation; (ii) per- Workspace-tenant DKIM-signing-engine canonicalization-mode is fixed and operator-cannot-override — the per-Workspace-tenant signing engine applies c=relaxed/relaxed for the per-tenant primary google._domainkey selector without per-tenant operator-side override capability; per-Workspace-tenant operators MUST design their per-publisher per-domain DMARC-rollout against the fixed per-tenant canonicalization-mode floor rather than attempting to tune the per-tenant signing- engine canonicalization-mode publication discipline; (iii) per-Workspace- tenant Workspace-routing intermediary mutation footprint operationally precludes c=simple body canonicalization for cross-tenant message routing — per-Workspace-tenant outbound mail routed through Google's outbound mail- relay infrastructure undergoes per- intermediary trailing-newline normalization and per-intermediary CRLF-to-LF conversion that would break c=simple body-hash recomputation; the per-tenant DKIM-signing-engine c=relaxed/relaxed default publication discipline is operationally forced by the per-Workspace-tenant outbound-routing intermediary mutation footprint; (iv) per-Workspace- tenant third-party-vendor selector canonicalization-mode divergence vs primary google._domainkey — per-Workspace-tenant third-party-sender selectors (Mailchimp k1._domainkey, SparkPost scph0<N>._domainkey, SendGrid s1._domainkey) MAY publish per-vendor-engine-specific canonicalization-mode defaults that diverge from the per-Workspace-tenant primary google._domainkey c=relaxed/relaxed; per- Workspace-tenant operators MUST audit per-third-party-selector canonicalization- mode publication discipline as part of the per-Workspace-tenant per-domain DKIM- aligned-pass coverage-rate baseline. Read THIS page when DEPLOYING per-Workspace- tenant per-domain DMARC publication infrastructure; read the DKIM canonicalization spoke when AUDITING the per-Workspace-tenant per-domain DKIM- signing-engine fixed canonicalization- mode publication-discipline floor whose per-tenant per-message body-hash recomputation reference is the LOAD- BEARING per-tenant per-message DKIM- signing-engine canonicalization-mode prerequisite every per-Workspace-tenant per-domain DMARC deployment STRUCTURALLY DEPENDS on.
• DMARC monitoring — the per-Workspace-tenant per-domain DMARC-monitoring KPI dashboard as operator-console for per-tenant per- domain authentication-and-enforcement- discipline companion to this Google Workspace DMARC deployment reference. Where THIS page documents the per- Workspace-tenant deployment workflow (the Admin-Console-issued google._domainkey selector publication, the include:_spf.google.com canonical SPF-include, the per-tenant Workspace-Admin-Console zone-editor commit cadence, the per-tenant supplemental-third-party-ESP include- cascade composition), the DMARC- monitoring spoke is the OPERATOR- CONSOLE REFERENCE documenting the per- Workspace-tenant per-domain KPI dashboard whose per-day per-receiver per-source-IP DMARC-disposition pass- rate telemetry the per-tenant operator MUST track to detect per-tenant authentication-and-enforcement- discipline regression BEFORE it propagates into per-receiver per-day per-source-IP DMARC-disposition cliffs. Four WORKSPACE-TENANT-DMARC-MONITORING- KPI-DASHBOARD cross-correlation dimensions the monitoring spoke documents: (i) per-Workspace- tenant Google-outbound-IP-range attribution as upstream input to monitoring-KPI per-source-IP DMARC- disposition pass-rate baseline — the per-Workspace-tenant outbound mail traverses the Google-published IP ranges (_spf.google.com sub-include expansion); the DMARC- monitoring spoke documents the per-day per-receiver per-source-IP DMARC- disposition pass-rate KPI panel whose per-Google-IP-range-attribution baseline lets the per-tenant operator distinguish a per-tenant publication- discipline regression from a per-Google- IP-range reputation-shift the Google operations team must escalate; (ii) per-Workspace-tenant supplemental-third-party-ESP include- cascade SPF-aligned-pass coverage-rate as upstream determinant of monitoring- KPI sustained SPF-aligned-pass baseline — the per-tenant supplemental-third-party-ESP include- cascade (SendGrid include:sendgrid.net, Mailgun include:mailgun.org, Amazon SES include:amazonses.com, Mailchimp include:servers.mcsv.net) publication-discipline-correctness is the LOAD-BEARING upstream determinant of the monitoring-KPI sustained SPF- aligned-pass coverage-rate baseline; the DMARC-monitoring spoke documents the per-day per-receiver per-ESP- include-cascade-attribution rule the per-tenant operator applies to distinguish per-ESP-include-cascade publication-discipline regression from per-day per-receiver per-source-IP legitimate-traffic-pattern shift; (iii) per-Workspace-tenant per-quarter manual DKIM-selector- rotation overlap-window discipline as upstream cause of monitoring-KPI DKIM- aligned-pass coverage-rate cliff — the per-Workspace-tenant google._domainkey selector rotation MUST be performed manually from the Workspace Admin Console (Google publishes no automatic rotation pipeline) — a per-tenant manual rotation-without-overlap-window misstep emits per-day per-receiver per-source-IP DKIM-aligned-pass coverage-rate cliffs the monitoring- KPI dashboard surfaces as the per- tenant operator-side discipline- regression alarm; (iv) per-Workspace-tenant p=quarantine-to- p=reject ramp-advancement readiness as function of monitoring- KPI sustained pass-rate baseline stability — the per-tenant per-domain ramp-advancement from p=quarantine to p=reject structurally depends on per-day per-receiver per- source-IP DMARC-pass-rate baseline stability the monitoring-KPI dashboard publishes; the DMARC-monitoring spoke documents the per-tenant per-domain pass-rate-baseline-vs-ramp-advancement readiness gate the per-Workspace- tenant operator applies BEFORE advancing the per-domain DMARC policy- mode against the per-tenant authentication-and-enforcement- discipline regression budget. Pair this page (the per-Workspace-tenant per- domain DMARC deployment reference) with the DMARC-monitoring spoke (the operator-side per-tenant per-domain KPI dashboard reference) when designing the per-Workspace-tenant per-domain DMARC-deployment-to-monitoring-KPI feedback loop — the spoke documents the per-day per-receiver per-source-IP DMARC-disposition pass-rate KPI panel whose telemetry is the operationally- grounded discipline-regression- detection stream every per-Workspace- tenant per-domain DMARC deployment STRUCTURALLY DEPENDS on as the operator-side per-tenant-per-domain authentication-and-enforcement- discipline regression-detection feedback channel.
• DKIM DNS-record byte syntax — the WORKSPACE-DKIM-DNS-PUBLICATION- DISCIPLINE companion to this Workspace deployment guide. Where THIS page documents the Workspace-managed DKIM signing-key CNAME publication workflow (the google._domainkey selector that the Workspace Admin Console requires the tenant publish as a CNAME pointing at the Google-managed key-material rotation chain), the DKIM DNS-syntax spoke documents the RFC 6376 §3.6.1 per-tag byte-grammar reference every receiver-side DKIM verifier consumes when validating the Workspace-signed outbound message — the v=DKIM1 version tag, the k=rsa key-type tag, the p=<base64-pubkey> public-key bytes, the optional h= hash-algorithm constraint, the s=email service-type tag, the t= flags tag, and the 255-octet character-string-fragmentation rule. Pair this Workspace deployment guide with the DKIM-DNS-syntax spoke when verifying that the Workspace-managed CNAME chain at google._domainkey.<tenant-domain> resolves to a Google-published TXT record whose byte grammar matches the RFC 6376 §3.6.1 contract — the per-tenant per-selector CNAME-chain terminal TXT-record byte-grammar compliance is the STRUCTURAL receiver-side verification PREREQUISITE every Workspace-signed outbound message depends on for the dkim=pass verdict that gates the per-message per-receiver DMARC-aligned-pass-rate floor this Workspace deployment guide's per-tenant per-domain DMARC enforcement ramp STRUCTURALLY DEPENDS on.
• TLS-RPT report format — the WORKSPACE-TENANT-TRANSPORT-LAYER- JSON-AGGREGATE-REPORT-FORMAT companion to this Workspace DMARC deployment guide. Where THIS page documents the Workspace-tenant publication workflow for the message-layer authentication triad (SPF include:_spf.google.com, Workspace-managed DKIM at google._domainkey, DMARC TXT at _dmarc.<domain>) and surfaces the receiver-side per-day per-source-IP DMARC-aligned-pass evidence the operator consumes from the per-tenant rua= XML aggregate stream, the TLS-RPT report- format spoke documents the STRUCTURALLY-PARALLEL per-receiver per- publisher per-day RFC 8460 §4 JSON aggregate-report byte-grammar the Workspace tenant's rua= endpoint receives at _smtp._tls.<domain> whose per-failure result-type enum (starttls-not-supported, certificate-host-mismatch, certificate-expired, sts-policy-fetch-error, sts-webpki-invalid) is the receiver-side transport-layer observability primitive Gmail's aspmx.l.google.com inbound STARTTLS handshake outcomes and the Workspace outbound-SMTP STARTTLS handshake outcomes both surface to. Pair this Workspace-DMARC deployment guide with the TLS-RPT-report-format spoke at FOUR per-Workspace-tenant per-domain TLS-RPT-JSON-consumer dimensions: (i) per-tenant per-receiver per- day JSON-report ingestion as transport-layer-observability stream parallel to the per-tenant DMARC aggregate-XML stream — the Workspace tenant's _smtp._tls.<domain> published rua=mailto: endpoint receives per-day JSON aggregate-reports from every receiver that processed Workspace-outbound mail under MTA-STS or DANE policy and the report-format spoke's byte-grammar reference enables per-receiver per-day per-policy-evaluation parsing without which the per-tenant transport-layer evidence stream remains opaque; (ii) per-failure result-type enumeration as per-Workspace-tenant per-domain per- receiver per-day silent-failure attribution catalogue — the spoke's result-type enum (eight standardised values per RFC 8460 §4.3) lets the Workspace tenant distinguish starttls-not-supported (receiver lacks STARTTLS) from certificate-host-mismatch (receiver MX presents a certificate for a different hostname) from sts-policy-fetch-error (Workspace tenant's MTA-STS policy file unreachable) without which every transport-failure attribution would collapse to a single opaque "STARTTLS failed" signal; (iii) per-tenant per-domain per-day summary.total-successful-session-count / total-failure-session-count as MTA-STS-mode-progression-readiness empirical input — the spoke's per-day per-MX-host successful-vs- failed STARTTLS session-count aggregation is the LOAD-BEARING empirical-readiness gate the Workspace tenant uses to advance the per-domain MTA-STS policy mode from testing to enforce (publisher must observe sustained-low total-failure-session-count baseline at the per-receiver-per-day level before flipping to enforce — without that evidence stream the mode-progression decision is uninformed); and (iv) per-failure sending-mta-ip / receiving-mx-hostname / failure-reason-code attribution as per-tenant per-domain per-receiver per-day cross-receiver consistency-deviation incident triage primitive — when one receiver (e.g. outlook.com or yahoo.com) shows sustained certificate-host-mismatch failures while peer receivers show clean STARTTLS, the per-failure attribution lets the Workspace tenant attribute the failure to a specific receiving-MX-hostname vs a per-publisher certificate misconfiguration. Pair THIS Workspace-DMARC deployment guide with the TLS-RPT-report-format spoke when designing the per-Workspace-tenant per- domain cross-protocol-pillar observability discipline that fuses the per-tenant DMARC RUA-XML message-layer evidence stream with the per-tenant TLS-RPT-JSON transport-layer evidence stream into the unified per-tenant per- domain authentication-and-encryption- posture observability surface every production-grade Workspace tenant STRUCTURALLY DEPENDS on for end-to-end Workspace-outbound and Gmail-inbound defensible-posture closure.
• SPF qualifiers (+ Four per-Workspace-tenant qualifier-ramp coupling dimensions: (i) per-Workspace-tenant SPF Phase 1 monitoring publication with ~all-soft terminal qualifier as DMARC p=none observation-only coordination — the per-Workspace-tenant operator publishes v=spf1 include:_spf.google.com ~all as the Phase 1 soft per-message envelope-authorization declaration during the rua=mailto:/p=none observability window; (ii) per-Workspace-tenant SPF Phase 3 partial-enforcement with ~all-soft retained during DMARC p=quarantine pct=10/25 ramp — through Phase 3 the per-Workspace-tenant SPF terminal qualifier remains ~all-soft to avoid pre-DMARC SPF-fail-strict hard-rejection at receivers that pre-evaluate SPF before consulting per-message DMARC composite; (iii) per-Workspace-tenant SPF Phase 5 terminal upgrade from ~all-soft to -all-strict concurrent with DMARC p=reject pct=100 — the per-Workspace-tenant operator coordinates per-message envelope-authorization terminal upgrade from SoftFail to Fail concurrent with per-publisher per-domain DMARC terminal p=reject pct=100, declaring per-tenant per-custom-domain terminal strictness at both per-protocol enforcement boundaries simultaneously; (iv) per-Workspace-tenant gappssmtp.com default-signing-identity SPF posture vs per-custom-domain SPF qualifier-strictness divergence — when the per-Workspace-tenant operator retains the Workspace default-egress posture without per-custom-domain DKIM activation, outbound mail signs with the gappssmtp.com-default identity and the per-tenant SPF qualifier strictness at the per-custom-domain apex must coordinate with the per-Workspace-tenant Authenticate-email-Start activation status — the per-tenant operator must coordinate per-custom-domain qualifier-strictness ramp to align with per-tenant DMARC enforcement-posture against the per-Workspace-tenant Authenticate-email-Start activation floor. Read the SPF-qualifiers spoke alongside this DMARC-for-Workspace reference when planning the per-Workspace-tenant SPF qualifier-strictness ramp progression concurrent with the per-Workspace-tenant DMARC policy ramp, when authoring per-Workspace-tenant runbooks coordinating per-custom-domain SPF qualifier strictness with per-custom-domain DMARC p=/pct= settings, or when investigating per-Workspace-tenant per-custom-domain authentication-publication strictness divergence between per-tenant gappssmtp.com-default-egress posture and per-custom-domain user-published posture.
• DKIM failures explained — the PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN- DKIM-FAILURE-ROOT-CAUSE companion to this Workspace DMARC deployment reference. Where THIS page documents the per-Workspace-tenant per-custom-domain Admin Console "Authenticate email" wizard activation, the google._domainkey.<customer-domain> TXT-record publication at the per-tenant external DNS zone, the per-tenant DMARC policy ramp coordination, and the February 2024 bulk-sender requirements compliance, the DKIM-failures-explained spoke is the RECEIVER-SIDE-DOWNSTREAM-CONSUMER whose per- message DKIM-verification verdict class is the load-bearing per-message authentication outcome the per-Workspace-tenant per-custom- domain DMARC ramp gates on. FOUR per- Workspace-tenant per-custom-domain DKIM- failure root-cause dimensions: (i) per-Workspace-tenant per-custom- domain Authenticate-email wizard "Start authentication" not-yet-engaged producing per-receiver dkim=none verdicts on Workspace- signed mail attributing to gappssmtp.com — until the per-tenant operator clicks "Start authentication" in the Admin Console Authenticate-email panel, Workspace outbound mail is signed with the Workspace default 20230601._domainkey.gappssmtp.com identity (per-message d=<tenant-id>.<customer-domain>.20230601.gappssmtp.com signing-identity), producing per-receiver dkim=pass + aligned=false verdicts the per-Workspace-tenant per-custom- domain DMARC composite evaluates as DMARC- aligned-fail under adkim=r relaxed alignment — a per-tenant per-domain operator-discipline-gap defect class the DKIM-failures spoke catalogues as the Workspace-tenant canonical first-time deployment defect; (ii) per-Workspace-tenant per-custom- domain post-rotation google._domainkey TXT-record propagation tail as load-bearing root cause of transient per-receiver dkim=permerror verdicts during the per-tenant Admin Console rotation commit — per-Workspace-tenant operators rotating their google._domainkey selector via the Admin Console rotation flow MUST keep the old selector live across the per-receiver per-resolver cache-eviction window the per- tenant external-DNS TTL discipline bounds; the per-Workspace-tenant per-custom-domain rotation defect class the DKIM-failures spoke catalogues surfaces as receiver-side dkim=permerror verdicts during the TTL-bounded propagation tail; (iii) per-Workspace-tenant per-custom- domain external-ESP-signed legitimate mail arriving with dkim=pass + aligned=false as canonical d=<esp-domain> vs RFC 5322 From-header organisational-domain mismatch defect — per-Workspace-tenant operators routing transactional mail through SendGrid / Mailgun / Mailchimp / Salesforce Marketing Cloud / HubSpot without per-ESP CNAME-delegated DKIM publication observe per- receiver dkim=pass + aligned=false verdicts (per-message d=<esp-domain> mis-aligns with the per-tenant per-custom-domain header From) producing per-tenant per-custom-domain DMARC-aligned-fail evidence rows in the per-tenant RUA stream — a per-Workspace- tenant per-custom-domain alignment-class defect the DKIM-failures spoke catalogues whose per-ESP CNAME-delegation remediation the per-tenant operator authors per-ESP at the per-custom-domain external DNS zone; (iv) per-Workspace-tenant per-custom- domain external-DNS TXT-record-publication defect (CNAME-instead-of-TXT, malformed- tag-list, value-truncated-at-DNS-provider- char-limit) producing per-receiver dkim=permerror verdicts — per-Workspace-tenant operators publishing the Admin Console-generated google._domainkey TXT record at external DNS providers (Cloudflare / Route 53 / GoDaddy / Namecheap / SiteGround) routinely encounter per-provider TXT-record-value char- limit truncation (publishing as a SINGLE long string instead of the multi-string concatenation RFC 6376 §3.6.2.1 mandates), producing per-receiver dkim=permerror verdicts the DKIM-failures spoke catalogues as the canonical external-DNS publication-discipline defect class. Read the DKIM-failures-explained spoke alongside this DMARC-for-Workspace reference when DIAGNOSING per-receiver per-day per- Workspace-tenant per-custom-domain dkim=permerror / dkim=fail / dkim=pass + aligned=false RUA- attributed evidence rows correlating with a per-tenant Admin Console Authenticate-email rotation commit or per-tenant external DNS zone TXT-record publication event, when PLANNING per-Workspace-tenant per-custom- domain DKIM rotation cadence with explicit per-receiver propagation-window-floor coordination, or when AUTHORING per- Workspace-tenant per-ESP CNAME-delegated DKIM publication runbooks whose per-ESP alignment-class defect remediation the DKIM-failures spoke catalogues.
• TLS-RPT (SMTP TLS Reporting RFC 8460) explained — the PER-WORKSPACE-TENANT-PER- CUSTOM-DOMAIN-TRANSPORT-LAYER- OBSERVABILITY-PUBLICATION companion to THIS Workspace tenant DMARC deployment reference. Where THIS page documents the per-Workspace-tenant per-custom-domain DMARC + SPF + DKIM publication discipline (per-Workspace-tenant per-custom-domain _dmarc.<d-domain> publication, per-Workspace-tenant per- custom-domain v=spf1 include: _spf.google.com -all envelope-MAIL- FROM publication, per-Workspace-tenant per- custom-domain Workspace-managed DKIM selector publication, per-Workspace-tenant per-custom-domain RUA aggregate-report consumption pipeline), the TLS-RPT spoke is the PER-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-TRANSPORT-LAYER-OBSERVABILITY- PUBLICATION sibling at FOUR per-Workspace- tenant observability-stream coordination dimensions: (i) per-Workspace- tenant per-custom-domain TLS-RPT _smtp._tls.<d-domain> publication AS structurally-parallel transport-layer-observability-stream counterpart to per-Workspace-tenant per- custom-domain DMARC _dmarc.<d-domain> application-layer-observability-stream publication — the per- Workspace-tenant per-custom-domain TLS- RPT publication the TLS-RPT spoke documents (per-Workspace-tenant per- custom-domain _smtp._tls.<d- domain> TXT-RR v=TLSRPTv1; rua=mailto:tls-rpt@ <d-domain> publication committing to per-Workspace-tenant per- custom-domain per-MX-host per-day JSON- aggregate-report consumption pipeline) IS the structurally-parallel transport- layer-observability-stream counterpart to the per-Workspace-tenant per-custom- domain DMARC _dmarc.<d-domain> RUA publication THIS page documents the application-layer-observability-stream counterpart of; per-Workspace-tenant operators publish BOTH per-Workspace- tenant per-custom-domain DMARC application-layer-observability and per- Workspace-tenant per-custom-domain TLS- RPT transport-layer-observability publications coordinated at the per- Workspace-tenant per-custom-domain unified-observability-publication-floor boundary; (ii) per-Workspace- tenant per-custom-domain TLS-RPT per-MX- host per-day JSON-aggregate-report observability ingestion pipeline AS load- bearing per-Workspace-tenant per-custom- domain transport-layer mail-flow- anomaly-detection input pairing with per- Workspace-tenant per-custom-domain DMARC RUA application-layer mail-flow-anomaly- detection input — the per- Workspace-tenant per-custom-domain TLS- RPT JSON-aggregate-report ingestion pipeline the TLS-RPT spoke documents (per-Workspace-tenant per-custom-domain per-MX-host per-day per-organisation per- failure-type-bucket evidence-row ingestion, per-Workspace-tenant per- custom-domain transport-layer-failure- bucket per-failure-bucket-class attribution discipline) pairs operationally with the per-Workspace-tenant per-custom- domain DMARC RUA aggregate-report ingestion pipeline THIS page documents the per-tenant per-custom-domain consumption discipline of; per-Workspace- tenant operators cross-reference BOTH per-Workspace-tenant per-custom-domain observability streams at the per- Workspace-tenant per-custom-domain mail- flow-anomaly-detection cross-protocol- layer attribution boundary; (iii) per-Workspace-tenant per-custom- domain MTA-STS transport-layer- enforcement-publication-floor commitment IS verifiable via per-Workspace-tenant per-custom-domain TLS-RPT per-MX-host per-day enforcement-failure-rate-floor observability — per- Workspace-tenant per-custom-domain MTA- STS mode=enforce transport- layer-enforcement-publication-floor commitment is verifiable per-Workspace- tenant per-custom-domain operationally via the per-Workspace-tenant per-custom- domain TLS-RPT JSON-aggregate-report per-MX-host per-day per-failure-type- bucket evidence-row stream the TLS-RPT spoke documents the per-publisher per- domain transport-layer observability ingestion discipline of; per-Workspace- tenant operators measure per-Workspace- tenant per-custom-domain MTA-STS- enforcement-failure-rate-floor before- and-after per-Workspace-tenant per- custom-domain MTA-STS mode-enforce deployment as per-Workspace-tenant per- custom-domain MTA-STS-publication- readiness-evidence at the per-Workspace- tenant per-custom-domain transport- layer-enforcement-readiness operational- validation boundary; (iv) per- Workspace-tenant per-custom-domain composite DMARC + SPF + DKIM + MTA-STS + TLS-RPT publication-floor coordination AS load-bearing per-Workspace-tenant per- custom-domain operator-side unified-trust- signal-publication-discipline-floor — the per-Workspace-tenant per- custom-domain TLS-RPT transport-layer- observability publication discipline the TLS-RPT spoke documents IS the load- bearing transport-layer-observability leg of the per-Workspace-tenant per- custom-domain composite DMARC + SPF + DKIM + MTA-STS + TLS-RPT publication- floor coordination posture the per- Workspace-tenant per-custom-domain DMARC + SPF + DKIM publication discipline THIS page documents the application-layer-and- envelope-MAIL-FROM-layer legs of; per- Workspace-tenant operators publish ALL FIVE per-Workspace-tenant per-custom- domain protocol-layer publications coordinated at the per-Workspace-tenant per-custom-domain unified-trust-signal- floor publication-readiness boundary. Read THIS page when DEPLOYING the per- Workspace-tenant per-custom-domain DMARC + SPF + DKIM application-layer + envelope- MAIL-FROM-layer publication discipline; read the TLS-RPT spoke when AUDITING the per-Workspace-tenant per-custom-domain per-MX-host per-day transport-layer- observability stream whose per-publisher per-domain RFC 8460 JSON-aggregate-report ingestion discipline IS the load-bearing sibling per-Workspace-tenant per-custom- domain transport-layer-observability- publication discipline coordinated with the per-Workspace-tenant per-custom- domain DMARC application-layer- observability-publication discipline THIS page documents.
• DKIM best practices — the per-publisher per-selector DKIM operational-hygiene pre-flight checklist companion to this Workspace-tenant DMARC deployment reference.
• Email security glossary — the threat-actor / OSINT / defense-in-depth / incident-response / threat-modeling cybersecurity-vocabulary registry — per-Workspace-tenant per-custom-domain DMARC publication-discipline THIS page documents materially depends on canonical operator-side terminology for BEC (business email compromise) threat-class, lookalike- domain / cousin-domain / IDN-homograph impersonation-tactics vocabulary, and the per-tenant security-operations IR-playbook vocabulary the security-glossary catalogues alongside the broader phishing-taxonomy and threat-modeling framework registry every per-Workspace-tenant per-custom-domain DMARC operator consumes for cross-protocol threat-and-defense terminology- disambiguation.
• MTA-STS explained
• CAA records explained — the PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN-CAA-RR-PKI-LAYER-PER-CA-ALLOWLIST-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-PKI-LAYER-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN-DMARC-APPLICATION-LAYER-COMPOSITE-VERDICT-PUBLICATION-DISCIPLINE companion at four per-Workspace-tenant per-custom-domain CAA-RR-PKI-layer-vs-DMARC-application-layer publication-discipline coupling dimensions: (i) per-Workspace-tenant per-custom-domain CAA-RR 0 issue "<ca-domain>" + 0 issuewild "<ca-domain>" property-tag publication-discipline at apex-<tenant-domain> per RFC 8659 §4.2 IS structurally parallel per-Workspace-tenant per-custom-domain underscore-prefixed-or-apex DNS-publication-discipline to per-Workspace-tenant per-custom-domain DMARC _dmarc.<tenant-domain> underscore-prefixed-TXT-RR publication-discipline per RFC 7489 §6.1 THIS page documents the per-Workspace-tenant per-custom-domain DMARC composite-verdict publication-discipline of — both per-Workspace-tenant per-custom-domain operator-side per-domain DNS-published per-tenant per-domain trust-anchor-and-policy publication-discipline references coordinate at the per-Workspace-tenant per-custom-domain composite cross-layer SMTP-application-and-PKI publication-discipline coordination boundary; (ii) per-Workspace-tenant per-custom-domain CAA-RR 0 iodef "mailto:abuse@<tenant-domain>" incident-attribution-mailbox publication-discipline per RFC 8659 §4.4 IS structurally parallel per-Workspace-tenant per-custom-domain operator-side per-event-class incident-attribution-mailbox publication primitive to per-Workspace-tenant per-custom-domain DMARC rua=mailto:dmarc-reports@<tenant-domain> aggregate-report-URI + ruf=mailto:dmarc-forensic@<tenant-domain> forensic-report-URI publication-discipline per RFC 7489 §6.2 the per-Workspace-tenant per-custom-domain DMARC composite-verdict publication-discipline THIS page documents the per-tenant per-custom-domain operator-side per-aggregate-event attribution workflow of materially consumes — both per-tenant per-custom-domain operator-side per-event-class attribution-mailbox publication primitives whose per-tenant per-custom-domain operator-side per-event-class mitigation-discipline depends on; (iii) per-Workspace-tenant per-custom-domain CAA-RR per-CA-allowlist publication-discipline closes per-attacker per-Workspace-tenant-acquired-lookalike-domain + per-attacker per-Workspace-tenant-acquired-cousin-domain PKI-layer cert-mis-issuance attack-class subset whose per-attacker per-Workspace-tenant-acquired-domain HTTPS-enabled credential-harvesting + spear-phishing message-source infrastructure-provisioning attack-class depends on per-attacker per-domain TLS-cert acquisition per RFC 8659 §3 BLOCKS — structurally parallel per-tenant per-custom-domain composite-verdict-and-anti-spoofing publication-discipline to per-Workspace-tenant per-custom-domain DMARC p=reject + adkim=s + aspf=s + sp=reject publication-discipline closing per-attacker per-target-domain direct-domain-spoof + lookalike-domain + cousin-domain + subdomain-takeover spoofing attack-classes; (iv) per-Workspace-tenant per-custom-domain CAA-RR publication-discipline drift (missing CAA-RR at apex / overly-permissive `0 issue ";"` deny-all-but-self mis-publication / missing `iodef` incident-mailbox / CAA-RR DNSSEC-unsigned-zone exposing per-attacker per-zone CAA-RR DNS-cache-poisoning attack-class) directly opens per-Workspace-tenant per-custom-domain PKI-layer per-attacker per-tenant-acquired-domain rogue-CA cert-issuance attack-window structurally parallel to per-Workspace-tenant per-custom-domain DMARC publication-discipline drift (`_dmarc.<tenant-domain>` TXT-RR missing / p=none permissive-mis-publication / missing `rua=mailto:` aggregate-URI / unreachable `rua=mailto:` mailbox) the per-Workspace-tenant per-custom-domain DMARC-for-Workspace spoke THIS page documents the per-Workspace-tenant per-custom-domain composite-verdict-publication-discipline of catalogues against — together the per-Workspace-tenant per-custom-domain DMARC composite-verdict application-layer publication-discipline THIS page documents AND the per-Workspace-tenant per-custom-domain CAA-RR PKI-layer per-CA-allowlist publication-discipline compose the per-Workspace-tenant per-custom-domain composite SMTP-application-and-PKI cross-layer authentication-and-PKI publication-discipline-floor coordination boundary.
• DNS propagation — the DNS-timing companion to this Workspace DMARC deployment guide. Where this page documents the per-tenant per-custom-domain record publication steps (the v=spf1 include:_spf.google.com ~all SPF record, the google._domainkey DKIM TXT-RR Google generates in the Admin console, the _dmarc.<tenant-domain> policy record), the DNS-propagation spoke documents the timing reality that gates when those records take effect: a freshly-published or edited TXT record is not visible to every receiver's recursive resolver until the prior record's TTL and any negative-cache window expire, so an operator who enables DKIM in the Admin console and immediately advances DMARC enforcement can see transient dkim=temperror / spf=temperror rows in the RUA stream while propagation completes. Read the DNS-propagation spoke when sequencing a Workspace rollout — publish records, wait out the propagation window verified against the RUA aggregate stream, then advance the DMARC policy — so the TTL timing this spoke documents does not get misread as a Workspace misconfiguration on this page.
• Why SPF alone is insufficient — the protocol-layer rebuttal of the “Workspace publishes SPF for us, so we are covered” mental model. SPF authorises only the envelope MAIL FROM and breaks under forwarding, which is exactly why this Workspace deployment also requires the google-selector DKIM signature and a _dmarc policy — the full stack the why-SPF-alone spoke motivates.
• Email spoofing explained — the threat-class reference enumerating the seven spoofing techniques the Workspace SPF + DKIM + DMARC stack this page deploys is meant to stop; read it to see which direct-domain-spoof and display-name variants a p=reject policy on your Workspace custom domain actually eliminates, and which still need additional controls.
• RFC 7489 — DMARC
• RFC 7208 — SPF
• RFC 6376 — DKIM
• RFC 8058 — One-Click List-Unsubscribe — required by the Feb 2024 bulk-sender rules.
• 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.

Deploy DMARC for your Google Workspace tenant now

DMARC Analyzer parses the daily aggregate reports Google and other receivers send to your rua= mailbox, deduplicates by report_id + org_name, and surfaces the per-sender / per-IP / per-day breakdown needed to drive the alignment fix-up phase. Live DNS verification for every SPF / DKIM / DMARC record on your domain runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual message failures by parsing the full Authentication-Results stack via includes/EmailHeaderParser.php.

Sign up — Free plan Check my Workspace domain