Google Workspace SPF, DKIM and DMARC setup, step by step

To authenticate a custom domain sending through Google Workspace, publish the appropriate SPF TXT record, generate the domain’s DKIM record in Google Admin, add it to DNS, and start authentication. Then check a delivered message. A published key alone does not prove Google is signing. Google’s setup instructions.

This guide covers Workspace Gmail custom-domain sending, including the service formerly called G Suite. It does not establish authentication for consumer gmail.com addresses, every Google product, or a third-party application merely connected to a Google account. Treat Google Calendar invitations and other application-generated messages as separate test cases rather than assuming an employee-mail result covers them.

Before changing DNS, identify what actually sends

Build a short sending inventory: employee Gmail, website forms, CRM notifications, billing messages, recruitment tools, and any outgoing gateway. For each, record the visible From domain, transport provider, owner, and a sample delivered message. Mark unknown routes explicitly. A website hosted alongside your domain may still send through a different company.

Also identify the authoritative DNS host. It may differ from your registrar or website host. Export the current zone or save the relevant records before editing. Record the existing SPF value, DKIM selector names, DMARC policy, and TTLs. Agree on who can restore a mistaken change. These preparation steps keep a narrow authentication update from becoming an avoidable mail outage.

SPF settings belong in public DNS, not a Google Admin SPF switch. Google’s Workspace-only example applies when Google is the sole sender for that domain. Other active sending services must be assessed before replacing a policy. Google SPF setup.

What is the Google Workspace SPF record?

For a domain sending only through Google Workspace, Google documents this TXT value:

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

Publish it at the domain being authenticated. The DNS host may represent the zone apex as @, a blank field, or the full domain. Follow that host’s naming convention. If an SPF record already exists, edit the existing policy rather than adding a second one. Do not overwrite unrelated verification TXT records. Google SPF setup.

SPF authorizes sending infrastructure for the SMTP MAIL FROM identity (or HELO in applicable cases), commonly exposed as the Return-Path after delivery. It does not directly authenticate the visible From address. Multiple SPF policies at one name cause an error. The evaluation limit is ten DNS-querying mechanisms/modifiers, including nested processing, not simply ten visible includes. Preserve existing qualifiers and legitimate authorizations when merging. redirect is ignored when an all mechanism is present. ~all produces softfail for unmatched sources, not a universal instruction forcing every receiver to put mail in spam. SPF specification, RFC 7208.

For a mixed-provider domain, ask each service which envelope domain it uses and which DNS records your account requires. A service using its own bounce domain may not benefit from an include on your root domain. Do not add an include just because the company appears on an application inventory. The objective is accurate authorization for actual traffic, with no obsolete permissions left behind.

Generate and activate the Workspace DKIM key

First check whether DKIM is already configured, including records added automatically by a domain partner. Avoid replacing a working setup. Google notes a Squarespace automatic-record path. Key generation requires a super administrator; the Gmail settings workflow also identifies the Gmail Settings administrator privilege. In Google Admin, open Apps → Google Workspace → Gmail → Authenticate email, then select the correct domain. Click Generate New Record, choose a 2048-bit key where supported and the intended selector, then click Generate. Google’s default selector is google; choose another if that name is already in use. Newly enabled Gmail organizations may need to wait 24–72 hours before key generation is available. Google DKIM setup.

Copy both generated fields into DNS: the TXT hostname and the entire TXT value. These are account-derived values. This worksheet deliberately does not supply a reusable public key:

• Record type: TXT.
• Name: the exact generated selector hostname, interpreted using your DNS host’s naming rules.
• Value: the complete generated DKIM TXT value, including its public-key data.
• Domain: the same domain selected in Google Admin.

Do not generate a replacement key repeatedly while diagnosing publication. That can make it harder to tell which value is supposed to be live. Keep the console output and the DNS result side by side, and compare their full strings rather than just the beginning.

After publication, return to Authenticate email and select Start authentication. If the status remains “Not authenticating,” confirm activation was completed and verify the hostname and key. Google documents DNS value and TXT-length issues among the checks to perform. Google DKIM troubleshooting.

If the DNS interface rejects a long key, ask the host how to enter one TXT record using multiple character strings of at most 255 characters. Do not create multiple independent key records or truncate the key. If the host cannot support the recommended key, follow Google’s documented shorter-key fallback rather than modifying the public-key data. Google TXT-length troubleshooting.

Map owners across DNS delegations

These are naming examples, not provider-issued records. Suppose the signing domain is news.example.com and the issued selector is SELECTOR. Its full DKIM owner is SELECTOR._domainkey.news.example.com:

Publish in the zone served by the existing delegation's authoritative nameservers, not an inactive parent-zone copy. A DNS editor accepting full names must produce that same full owner, without repeating a zone suffix. For a visible From domain news.example.com, DMARC's full owner is _dmarc.news.example.com: relative _dmarc.news in the parent zone or _dmarc in the delegated child. A _domainkey delegation does not contain the DMARC owner. SPF belongs at the actual evaluated envelope domain, not automatically any of these DKIM or DMARC names.

Preserve NS delegations, existing selectors and shared services. Do not change parent nameservers, MX, DNSSEC or forwarding to make a tutorial fit. If authority or an owner collision is unclear, stop and involve the zone owner rather than deleting records. DNS zones and delegation

Check public DNS before sending the test

Use a public DNS lookup tool, or run these read-only examples after replacing the domain and selector:

dig TXT example.com
dig TXT SELECTOR._domainkey.example.com

example.com and SELECTOR are placeholders, not records to publish. Look up the selector actually generated for this domain. Save the returned answer, resolver, and time in your change record. If the authoritative DNS answer is correct but another resolver still returns old data, compare TTLs before editing again.

For SPF, confirm exactly one applicable policy and evaluate its nested lookup count. Google specifically warns that nested includes count and recommends removing duplicate or unused authorizations. For DKIM, compare the complete logical TXT value; some tools display one TXT record as several quoted character strings. Google SPF troubleshooting; DKIM DNS key format.

Verify a real delivered message, including alignment

Send a new message through the intended production Workspace route from the configured domain to a separate external Gmail or Workspace recipient mailbox you control, not back to the sending mailbox itself. Use a simple subject that identifies the test time and route, without confidential content. In Gmail, open the received message, choose More beside Reply, then Show original to inspect its full headers. Google header instructions.

Use only results generated inside the actual receiving service's known processing boundary. Ask its administrator or consult its receiving-system documentation to identify the authentication component and how externally supplied Authentication-Results fields are removed or isolated from trusted results at ingress. Correlate the field with that service's original-message view or authenticated message trace. A familiar authserv-id, a topmost header, or text claiming to be from the receiver is not proof. Ignore externally supplied or otherwise untrusted fields; if the boundary cannot be established, leave acceptance unresolved and obtain the receiver's trace. Authentication-results trust and forged fields, RFC 8601 section 7.1

Record these observations from the receiving system’s authentication results:

• SPF result and the domain evaluated, often labelled smtp.mailfrom.
• DKIM result, signing domain d=, and selector s=.
• The visible From domain.
• DMARC result and which authenticated identity aligns.
• Whether a forwarding service, gateway, or footer service handled the message.

A valid DKIM signature identifies a signing domain and protects signed message content. Query its key at the name assembled from s= and d=. Finding any Google-related signature is insufficient evidence that your custom domain signed the message. DKIM specification.

DMARC passes when a passing SPF or DKIM identity aligns with the visible From domain. Strict alignment requires identical domains; relaxed alignment uses the same organizational domain. Authentication is not a guarantee that a message is safe or belongs in the inbox. Current DMARC specification, RFC 9989.

Completion of this branded DKIM configuration requires the intended Workspace DKIM signature to pass and align with the intended visible From domain under the current adkim policy, plus the trusted receiver's dmarc=pass for that From domain. Check the selected domain's actual selector, not any incidental Google signature. An SPF-only DMARC pass does not prove DKIM activation. A rewritten provider-domain From does not authenticate your intended brand. For example, d=news.example.com and From example.com can align relaxed, but not strict; the same distinction applies to an SPF envelope child under aspf. Never assume a universal Return-Path.

Add DMARC without weakening an existing policy

Inspect TXT at _dmarc.YOUR-FROM-DOMAIN first, and check whether a parent policy applies when no exact-domain record exists. Preserve existing enforcement and report destinations. Do not add a monitoring override that silently weakens an inherited policy. Google publishes DMARC through DNS, separately from Gmail signing. Google DMARC setup.

Publish one DMARC policy as a TXT record at _dmarc of the exact visible From domain. Use the DNS host’s relative-name or fully qualified-name convention, without duplicating the domain. If a record already exists, edit only the approved policy rather than adding a second.

Only for a domain with no established applicable policy, with a domain-owner-approved monitoring plan, an approved initial monitoring template is v=DMARC1; p=none; rua=mailto:APPROVED-REPORT-ADDRESS. Replace APPROVED-REPORT-ADDRESS with an authorized, functioning mailbox address only, not another mailto: URI, before publication. This is a template, not a record to copy unchanged. Monitoring does not request quarantine or rejection. DMARC policy specification.

For aggregate reports, a destination in a different Organizational Domain from the domain publishing the DMARC policy requires the report-generating receiver to check DNS authorization at the destination. A destination within the same Organizational Domain is excepted; a different hostname alone is not enough to trigger this requirement. Have an external reporting operator provide and confirm the authorization for your actual policy domain. RFC 9990 section 4 DNS authorization is separate from the domain owner's approval to share reporting data. Approve the destination, access and retention before adding it; a functioning mailbox alone is not authorization. Do not copy obsolete pct examples from older guidance. Failure reporting is separate and may disclose message content; do not enable it without an explicit privacy decision. Failure-report privacy

Google advises at least 48 hours of SPF/DKIM operation before its new-DMARC setup step; elapsed time alone does not establish readiness for enforcement or authorize downgrading an existing policy. Repeat relevant tests for secondary domains, aliases, gateways and application routes.

After publication, run dig TXT _dmarc.example.com, replacing the domain, and save the returned policy. Confirm a fresh external message’s DMARC result, then review reports across the sending inventory before changing enforcement.

Troubleshooting by the failed observation

DNS is correct, but DKIM is absent: check the selected domain and activation status, then confirm the message actually traversed Workspace. Do not regenerate a key to fix mail sent by an unrelated CRM.

DKIM fails after a gateway: compare a direct-path test with the gateway path. A footer or other alteration of signed content can invalidate the signature. Google flags outgoing gateways as a specific consideration in DKIM deployment. Google DKIM troubleshooting.

SPF fails for only one application: collect that message’s envelope domain and sending IP before changing DNS. Check whether a new sender was missed, an old route remains in use, or forwarding changed the connecting server. Google’s troubleshooting guidance separates missing senders from lookup-limit and forwarding problems. Google SPF troubleshooting.

SPF reports an error while DKIM passes: still diagnose it. For fail, compare the actual evaluated domain and connecting IP with approved authorizations and consider forwarding. For temperror, investigate temporary DNS timeouts or server failures and retest after recovery. For permerror, check duplicate policies, syntax and the complete evaluated DNS-dependent term budget. Do not confuse a transient lookup failure with a permanent invalid policy or hide either behind DKIM's DMARC pass. SPF result meanings

Employee mail passes, but an invitation fails: retain two separate outcomes. Investigate that invitation’s actual identities and route. A successful mailbox test is not evidence for all Calendar or automated traffic.

For duplicate policies, use the multiple SPF records diagnosis. If a change breaks existing sending, pause and have the named owner restore the approved previous DNS and sender configuration from the saved record, preserving unrelated selectors and DMARC protection.