Field notes

Email Infrastructure

SPF, DKIM, and DMARC for Google Workspace: A Practical Guide

Configure SPF, DKIM, and DMARC for Google Workspace with safe DNS examples, alignment checks, rollout steps, and troubleshooting guidance.

Shohan Biswas4 topics
Diagram showing sender authentication information being checked by recipient mail systems before delivery.
Email authentication concept diagram by Macquigg, via Wikimedia Commons, licensed CC BY-SA 2.5.



A message can look perfectly legitimate and still fail authentication. The visible From address is only one identity in an SMTP transaction, and receiving systems compare that identity with DNS, the sending server, and cryptographic signatures before deciding how much trust to give the message.

For a Google Workspace domain, SPF, DKIM, and DMARC form a chain. SPF authorizes sending infrastructure, DKIM proves that an authorized system signed the message, and DMARC checks whether at least one of those results aligns with the domain the recipient actually sees in the From header.

This guide uses example.com as a safe placeholder. Replace it with your own domain and use the exact values generated by each provider. Never copy a public key, reporting mailbox, or third-party include from an example without confirming it belongs in your mail flow.

The authentication chain in one minute

  • DNS publishes the public records that receiving mail systems query.
  • SPF asks whether the connecting server is authorized for the envelope-from domain.
  • DKIM verifies a cryptographic signature against a public key stored in DNS.
  • DMARC asks whether SPF or DKIM passed and aligned with the visible From domain.
  • The DMARC policy tells receivers how the domain owner wants failures handled and where aggregate reports should be sent.

Authentication reduces spoofing and removes common technical reasons for rejection, but it does not guarantee inbox placement. Reputation, recipient engagement, complaint rates, message content, list quality, sending volume, PTR records, and TLS still matter.

A practical sending scenario

Assume your team uses support@example.com in Google Workspace. People send normal conversations through Gmail, a website sends contact-form confirmations, and a marketing platform sends a monthly newsletter. All three streams display the same organizational domain, but they may use different return-path domains, IP addresses, and DKIM selectors.

The first task is not writing DNS records. It is inventorying every system that sends as example.com. Include Google Workspace, CRM platforms, ticketing systems, website forms, accounting software, transactional providers, marketing platforms, on-premise relays, and any old service that may still send scheduled mail.

That inventory becomes the source of truth for SPF authorization, DKIM signing, and DMARC report review. Missing one legitimate sender can create failures when enforcement begins.

DNS: the public control plane

Email authentication records are normally TXT records published at specific DNS names. DNS providers label the root of a domain differently: many use @, some expect the complete domain, and some leave the host field blank. Follow the provider's interface rather than blindly copying the host column from another platform.

The three important record names

  • SPF is usually published at the root domain, for example example.com.
  • Google Workspace DKIM normally uses google._domainkey.example.com. The google part is the selector and can be customized.
  • DMARC is always published below _dmarc, for example _dmarc.example.com.

TTL controls caching, not record correctness. Lowering it before a migration can shorten the time old answers remain cached, but it does not make an invalid value propagate correctly. Always inspect the public answer after publishing.

SPF: authorize the systems that may send

SPF evaluates the SMTP envelope identity, commonly called MAIL FROM or return-path, and the connecting IP address. It does not directly validate the visible From address a person sees in Gmail. That distinction is why an SPF pass alone is not enough for DMARC.

For a domain that sends only through Google Workspace, Google's documented starting value is: v=spf1 include:_spf.google.com ~all

If a legitimate marketing service also sends for the domain, merge it into the same policy. For example, Google documents this Google Workspace plus Mailchimp value: v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

How to read the record

  • v=spf1 declares the SPF version.
  • include:_spf.google.com asks receivers to evaluate Google's authorized infrastructure.
  • include:servers.mcsv.net adds Mailchimp when that service is genuinely used.
  • ~all is a soft-fail ending. Google recommends it for its Workspace examples while you maintain an accurate sender inventory.

SPF mistakes that cause real failures

  • Publishing two SPF records at the same hostname. SPF expects one policy, so merge authorized senders into one record.
  • Adding a provider because it might be used later. Every include increases complexity and trust surface.
  • Forgetting a website, CRM, scanner, or ticketing platform that sends with your domain.
  • Exceeding the SPF limit of 10 DNS-query-causing mechanisms and modifiers. RFC 7208 requires a permanent error when evaluation exceeds that limit.
  • Assuming SPF always survives forwarding. A forwarder changes the connecting server, so SPF can fail even when the original message was legitimate.

Review the expanded lookup path, not just the number of include words in the top-level record. Nested includes also contribute to the evaluation limit.

DKIM: sign the message with your domain

DKIM adds a signature to the message headers using a private key held by the sending service. The receiver finds the matching public key in DNS and verifies that the signed parts of the message have not changed. The private key never belongs in public DNS.

A selector allows a domain to publish multiple keys and rotate them without replacing every sender at once. In Google Workspace the recommended default selector is google, producing the DNS name google._domainkey.example.com. Use a different selector when the default name is already occupied by another active key.

Google Workspace DKIM rollout

  1. In the Google Admin console, open Apps, Google Workspace, Gmail, then Authenticate email.
  2. Select the sending domain and generate a 2048-bit key when the DNS provider supports it.
  3. Publish the TXT hostname and value exactly as Google provides them.
  4. Wait until the public DNS answer is visible, then click Start authentication in the Admin console.
  5. Send a message to a separate Gmail or Google Workspace mailbox and inspect Show original for dkim=pass.

DKIM DNS example

Host: google._domainkey.example.com

Value shape: v=DKIM1; k=rsa; p=PUBLIC_KEY_GENERATED_BY_GOOGLE

Do not use the placeholder public key above. Copy the complete key generated for your own domain. Some DNS consoles split a long TXT value into quoted segments; that can be valid as long as the public DNS response reconstructs the full value correctly.

DKIM often survives ordinary forwarding because the signature travels with the message. It can still fail if a gateway rewrites signed headers, changes the body, adds a footer, or otherwise modifies content covered by the signature.

DMARC: alignment, policy, and reporting

DMARC connects authentication to the domain visible to the recipient. A message passes DMARC when SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain. Both may pass, but only one aligned path is required.

Alignment is the part many DNS checklists miss. An SPF result can be pass for a provider-owned return-path while failing DMARC alignment with example.com. A DKIM signature can also be technically valid but use a d= domain unrelated to the visible From domain.

Alignment example

Visible From: support@example.com

SPF passes for bounce.vendor.example, which is not aligned with example.com. DKIM passes with d=example.com, which is aligned. DMARC passes through DKIM.

If DKIM also used d=vendor.example, the message could show SPF pass and DKIM pass in a header while DMARC still failed because neither authenticated domain aligned with the visible From domain.

DMARC policies

  • p=none requests monitoring only. Messages are not quarantined or rejected because of the DMARC policy.
  • p=quarantine asks receivers to treat failing messages as suspicious, commonly by placing them in spam.
  • p=reject asks receivers not to accept messages that fail DMARC.

A safe monitoring record

Host: _dmarc.example.com

Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

The rua address receives aggregate XML reports. Make sure the mailbox or reporting service can receive and process them. Relaxed alignment, represented by r, is the default and allows organizational-domain alignment. Strict alignment is useful in selected environments but should be introduced deliberately.

A staged rollout that avoids surprises

DMARC should not be treated as a single DNS change. Enforcement is the end of an evidence-gathering process. Google recommends having SPF and DKIM in place for at least 48 hours before introducing DMARC, then monitoring representative traffic before increasing enforcement.

  1. Inventory every service that sends mail using the domain or its subdomains.
  2. Publish one accurate SPF policy and confirm it resolves without a permanent error.
  3. Enable DKIM signing for Google Workspace and every third-party platform that supports your domain.
  4. Send tests from every mail stream and confirm authentication plus alignment in the received headers.
  5. Publish DMARC with p=none and review aggregate reports daily for at least one normal business cycle.
  6. Move to p=quarantine with a small percentage, such as pct=10, and increase only after legitimate sources remain aligned.
  7. Move to p=reject when reports show that authorized mail is consistently passing and unknown sources are safe to block.

Example policy progression

Monitor: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Limited quarantine: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com

Full enforcement: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

The pct tag applies to enforcement and is useful during a controlled rollout. Do not move to reject because a DNS checker shows three green records. A syntactically valid record cannot tell you whether every legitimate business system is aligned.

How to verify the setup

Check the public DNS answers

Run the read-only Workspace DNS Checker at https://shohanbiswas.com/tools/workspace-check with your bare domain and the correct DKIM selector. Confirm that the result seen from public resolvers matches the values in your DNS console.

Check for one SPF policy at the root, the complete DKIM key at selector._domainkey, and one DMARC policy at _dmarc. During propagation, compare more than one resolver before assuming a provider saved the change incorrectly.

Inspect a real received message

Send from the system being tested to a mailbox outside the source account. In Gmail, open the message menu and choose Show original. Look for spf=pass, dkim=pass, and dmarc=pass, then inspect the authenticated domains rather than stopping at the word pass.

The DKIM result should show a signing domain aligned with the visible From domain. The SPF result should identify the envelope domain and sending IP. The DMARC result confirms whether an aligned path passed.

Test every sending stream

  • A normal message sent from the Gmail web interface.
  • A website form or application notification.
  • A CRM, help desk, invoicing system, or marketing platform.
  • Messages sent through an SMTP relay or outbound gateway.
  • A forwarded message when forwarding is part of the real workflow.

Read DMARC aggregate reports

Aggregate reports reveal source IPs, message counts, SPF and DKIM outcomes, alignment, and the policy applied. Group the data by known service, investigate unknown volume, and correct legitimate failures before enforcement. A reporting dashboard is often easier to operate than reading raw XML files by hand.

Troubleshooting common failures

SPF returns permerror

Look for multiple SPF TXT records, malformed syntax, recursive includes, or more than 10 query-causing mechanisms and modifiers. Consolidate the policy and remove services that no longer send. SPF flattening can create maintenance risk because provider IP ranges change, so use it only with an update process you trust.

SPF passes but DMARC fails

Compare the SPF-authenticated envelope domain with the visible From domain. A provider-owned bounce domain can pass SPF without aligning. Configure a custom return-path at the provider when available, or rely on aligned DKIM.

The DKIM TXT record exists but messages are unsigned

Publishing the key is only half the setup. In Google Workspace, return to Authenticate email and start authentication after the DNS record resolves. For third-party senders, enable signing inside that platform and confirm it uses your domain in the d= tag.

DKIM fails after a gateway or mailing list

Inspect whether the intermediary adds a footer, rewrites the subject, changes MIME encoding, or modifies signed headers. Adjust the mail flow so signing happens after modifications when you control the path. When forwarding breaks SPF, an intact aligned DKIM signature often preserves DMARC.

DMARC reports show an unknown sender

Do not authorize it immediately. Correlate the source IP, reverse DNS, message volume, business owner, and service documentation. It may be an overlooked legitimate platform, a forwarding artifact, or unauthorized spoofing. Authorization should follow ownership evidence.

Everything passes, but mail still lands in spam

Authentication is not a reputation reset. Review consent, list hygiene, complaint rate, bounce handling, content, links, domain and IP reputation, sending consistency, PTR records, TLS, unsubscribe behavior, and sudden changes in volume. Use Gmail Postmaster Tools when the sending volume provides enough data.

Current Gmail sender expectations

Google's sender guidelines require all senders to Gmail accounts to use SPF or DKIM. Senders delivering more than 5,000 messages per day to personal Gmail accounts must use SPF, DKIM, and DMARC, and direct mail must align the visible From domain with SPF or DKIM. Marketing and subscription mail at that volume also needs one-click unsubscribe.

Google additionally calls for valid forward and reverse DNS for sending infrastructure, TLS, properly formatted messages, and low user-reported spam rates. These requirements show why a DNS-only test is a readiness assessment rather than a guarantee of delivery.

Operational checklist

  • Maintain a named owner and inventory for every sending service.
  • Keep exactly one SPF policy per hostname and stay within the evaluation limit.
  • Use DKIM on every capable platform and prefer 2048-bit keys when supported.
  • Confirm the signing domain and return-path alignment, not only pass or fail.
  • Collect DMARC aggregate reports before enforcement.
  • Increase quarantine or reject gradually and document each change.
  • Retest after migrations, new vendors, domain changes, gateways, or footer rules.
  • Remove retired senders and rotate DKIM keys as part of ongoing maintenance.

A reliable configuration is not the longest DNS record. It is the smallest accurate policy that represents the systems your organization actually operates, paired with evidence from real messages and ongoing reports.

Authoritative references

Continue reading

Related field notes.