Google Workspace DMARC setup has four connected stages: confirm who sends for the domain, publish the applicable SPF and DKIM records, start DKIM signing for the selected domain, and verify the resulting messages before relying on a DMARC policy.
DNS publication and signing are separate observations. A DKIM key can be visible while the service is not yet signing, and employee mail can authenticate correctly while a website or billing application uses a different provider. Follow the complete route for each important service.
Check the selected domain and existing configuration
Confirm the selected domain, its authoritative DNS host, current records and the Google administration permissions needed for the task. Save the existing configuration.
Check whether a valid SPF policy and working custom-domain DKIM signing already exist. Do not regenerate a working key or replace an established policy just to follow a new guide from its first step.
Create a route list for employee mail, aliases or secondary domains, gateways and outside applications. For each important identity, plan a separate received-message test.
Include the services that send outside Workspace
Google Workspace may handle employee mail while the website, accounting system and support platform use other providers. A Workspace setup cannot automatically establish ownership or alignment for those services.
Ask the team to name each customer-facing sender and its business owner. Include low-volume but important mail such as login links and payment receipts. Then ask for a verification result from the actual application, rather than assuming that a successful Gmail test covers it.
Make sure someone owns the domain's DNS account and the report destination. Authentication becomes difficult to maintain when a former contractor controls the records or reports arrive in a mailbox nobody reads.
Publish the appropriate SPF policy
Google's current documented example for a domain sending **only through Google Workspace** is:
v=spf1 include:_spf.google.com ~allUse it only when the assumption fits. For a mixed-service domain, review the existing permissions and the actual envelope identities before changing its single SPF policy. A separate application using its provider's own envelope domain may require a different supported alignment approach.
The ~all qualifier produces an SPF softfail for an otherwise unmatched source. Softfail is not a passing SPF result for DMARC, and it does not force every receiver to put the message in spam. Receiver handling and the separate DMARC decision remain relevant.
Check the SPF evaluation path, including nested dependencies. Counting the includes visible in the top-level record is insufficient.
Generate and publish the selected domain’s DKIM key
In the Google Admin console, navigate to Apps, Google Workspace, Gmail, then Authenticate email. Select the correct domain. If it is a new signing setup, use Generate New Record and the supported key settings.
Google offers a 2048-bit key where the DNS provider supports it. The default selector is google; an existing selector collision needs a supported different selector rather than an overwrite.
Copy the generated DNS host name and public-key value from the console. Publish that **TXT** record in the authoritative DNS zone. A common relative owner name is google._domainkey, but use the selected domain's generated values and the DNS editor's naming model.
The private key is not published in DNS. Do not paste a shortened sample key from an article, reuse another domain's key or silently replace another service's selector.
Check the public answer at the resulting full name:
dig TXT google._domainkey.example.com +shortThis command is illustrative: replace the domain and, where applicable, the selector. A public TXT answer demonstrates key publication, not that Workspace has started signing.
Start signing and inspect a received message
After publishing and checking the key, return to the selected domain's Authenticate email settings and start authentication. Review the resulting status.
Google's instructions describe testing with another Gmail or Google Workspace recipient, rather than sending yourself a message. Open the original message at the recipient and inspect the trusted authentication results and DKIM-Signature.
Verify the signing domain, selector and alignment with the visible From domain. A pass for a different domain does not establish your domain's aligned path. Repeat the test for relevant aliases, secondary domains, gateways and application routes.
- Layer: DNS; Question to answer: Is the generated public key published at the intended name?
- Layer: Workspace; Question to answer: Is signing enabled for the selected domain?
- Layer: Received mail; Question to answer: Does a relevant signature verify and align after the full route?
- Layer: Business workflow; Question to answer: Was the message sent by the service users actually depend on?
- ovider setup and DNS caching can take time. Google also documents a preparation delay before key generation for newly enabled Gmail services. Use the actual state and current guidance; do not promise one universal completion time.
Publish and verify the DMARC policy
For a newly monitored domain, a same-domain reporting example is:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comPublish it at the applicable _dmarc name, use a working approved collection address and confirm report arrival and processing. Google currently advises allowing at least 48 hours of SPF/DKIM operation before its DMARC setup step. That preparation period does not, on its own, establish readiness to enforce a stronger policy.
If the domain already has a policy, assess it instead of automatically replacing it with monitoring. The DMARC record workflow explains how to join DNS verification to real-message evidence.
Maintain coverage as services change
Review the implementation against the sender inventory and its critical-flow tests. A setting for one domain does not prove the state of every secondary domain or external notification service.
Require clear access to the Workspace and DNS administration accounts, a record of approved changes, a maintained list of selectors and an accountable report-review process. Define how the team handles a newly introduced application or an abandoned service.
Retain the distinction between domain authentication and account security. A compromised authorised account can send an authenticated message. A DMARC pass also does not guarantee inbox placement or establish that a business request is legitimate.
The practical takeaway
Keep DNS evidence, signing status and received-message results in the same acceptance record. That makes it possible to distinguish a publishing problem from a signing problem or a separate application that still needs configuration.
Keep a partial success from closing the project
In written case GW-01, assume user@example.com has a passing signature d=example.com with s=google. That stipulated message has an aligned DKIM path. An invoice application using the same From domain has no trusted received-message evidence yet. Its DKIM and SPF results remain unknown. Mark employee mail conditionally evidenced only within the assumed case, and leave the invoice route unresolved with its application owner. No Google tenant, message, DNS record or signing operation was tested for this guide.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.