Verifying Google Workspace SPF and DKIM Records During Mail Delivery Failures

Verifying your email authentication records is the fastest way to resolve message delivery failures, stop your emails from landing in spam folders, and protect your domain against spoofing. When messages sent from Google Workspace bounce or get rejected by recipient servers, misconfigured or missing DNS authentication entries are usually the primary culprit. Performing a thorough google workspace spf dkim check allows you to pinpoint exact syntax errors, missing hostnames, or conflicting policy rules in your zone file before they disrupt your business operations.

Before diving deep into DNS troubleshooting, ensure your primary web server and mail routing infrastructure are fully operational by running a quick Website Down Checker to rule out broader hosting outages that might impact your inbound mail flow.

Understanding Google Workspace Email Authentication

Google Workspace relies on three core protocols to verify the identity of the sender and protect your domain name from abuse: SPF, DKIM, and DMARC. When you send an email from user@example.com, receiving mail servers look up your domain's public DNS records to confirm that Google has explicit permission to send mail on your behalf and that the message contents have not been tampered with in transit.

The Role of SPF in Google Workspace

Sender Policy Framework (SPF) is a TXT record published in your DNS zone that lists all authorized IP addresses and mail servers permitted to send email for your domain. Google Workspace requires a single, specific SPF record that includes Google's mail servers. If you use third-party marketing tools or help desks, their sending mechanisms must also be integrated into this single record rather than creating multiple SPF entries, which violates RFC standards.

The Role of DKIM in Google Workspace

DomainKeys Identified Mail (DKIM) adds a cryptographic digital signature to the header of every outgoing email. When you enable DKIM within the Google Workspace Admin console, Google generates a unique public key that you publish to your DNS, while keeping the private key secure on their signing servers. Receiving servers use your public DNS key to verify the signature, proving the email genuinely originated from your domain and arrived unaltered.

Step-by-Step Google Workspace SPF DKIM Check

To diagnose mail delivery failures effectively, you must inspect your public DNS records using command-line tools or online utilities. Follow these structured steps to verify your configuration.

Step 1: Locate Your Google Workspace TXT and CNAME Records

First, log into your Google Workspace Admin console and navigate to Apps > Google Workspace > Gmail > Authenticate email. Note the exact hostname (selector) and value provided for DKIM, as well as the recommended SPF string: v=spf1 include:_spf.google.com ~all.

Step 2: Query SPF Records Using Dig or Nslookup

Open your terminal and query the TXT records for your domain to inspect your SPF setup. Run the following command:

dig example.com TXT

For Windows users, use PowerShell or nslookup:

Resolve-DnsName -Name example.com -Type TXT

A correct Google Workspace SPF response will look similar to this:

example.com. 300 IN TXT "v=spf1 include:_spf.google.com ~all"

Step 3: Verify DKIM CNAME Records

Google Workspace uses a CNAME-based DKIM implementation. You must check that your selector points correctly to Google's routing servers. Run a query for your specific DKIM selector (commonly google):

dig google._domainkey.example.com CNAME

Expected output sample:

google._domainkey.example.com. 300 IN CNAME gmr-smtp-in.l.google.com.

Troubleshooting SPF and DKIM Failures

Even minor typos in DNS records can break email authentication. Use this comparison table to identify common symptoms and apply the correct fixes.

Issue Symptom	Root Cause	Corrective Action
SPF PermError	Multiple SPF TXT records published in DNS.	Merge all include statements into a single TXT record.
DKIM Check Failed	Incorrect CNAME target or truncated selector.	Re-copy the exact CNAME host and value from Google Admin.
SoftFail on Google Mail	Using ~all instead of -all or missing IPs.	Update policy to strict -all once third-party senders are verified.
DNS Propagation Delay	Recent changes have not updated globally yet.	Wait up to 24 hours or check global DNS resolvers using dig.

Common Mistakes and How to Fix Them

Avoid these frequent configuration pitfalls when setting up Google Workspace mail security:

• Creating Multiple SPF Records: DNS specifications state that a domain must never have more than one SPF TXT record. If you have two, receiving mail servers return a PermError, causing legitimate emails to fail outright. Always combine multiple services into one string, such as v=spf1 include:_spf.google.com include:spf.mailgun.org ~all.
• Typographically Incorrect Selectors: When adding the DKIM CNAME record, registrars often automatically append your root domain name to the host field. Entering google._domainkey.example.com instead of just google._domainkey results in google._domainkey.example.com.example.com, rendering the record invalid.
• Using A or PTR Mechanisms in SPF: Avoid adding individual IP addresses or a mechanisms unless strictly necessary. Rely on include:_spf.google.com so Google automatically manages IP rotations for you.

Quick Checklist for Email Deliverability

• Confirm you have exactly one SPF TXT record containing include:_spf.google.com.
• Verify that your SPF record ends with either ~all (SoftFail) or -all (Fail).
• Check that DKIM is turned on in the Google Workspace Admin console.
• Ensure the DKIM CNAME selector points precisely to gmr-smtp-in.l.google.com.
• Test inbound and outbound message delivery using an external testing address.