Why does G-Suite Check MX toolbox say DKIM is not set up when email headers show DKIM and SPF pass?
Michael Ko
Co-founder & CEO, Suped
Published 31 May 2025
Updated 19 Aug 2025
7 min read
It can be confusing when an email authentication tool like Google Workspace's Check MX toolbox reports that DKIM is not set up, yet the actual email headers show DKIM and SPF passing. This discrepancy is a common source of frustration for domain owners and email senders alike. Understanding why this happens requires a deeper look into how these tools operate versus how email authentication standards like DKIM (DomainKeys Identified Mail) and SPF (Sender Policy Framework) are actually implemented and verified.
I've encountered this situation many times. The core of the issue often lies in the different perspectives that DNS (Domain Name System) lookup tools and receiving mail servers have when evaluating email authentication. A DNS checker primarily looks for the presence and correctness of specific DNS records, while a mail server validates the authenticity of an incoming email based on its actual headers and the policies defined by those DNS records.
When you send an email, various systems might add DKIM signatures. For example, if you use a third-party email service provider (ESP) like Dotdigital (which we saw in the example), they will likely sign your outgoing emails with their own DKIM key, and potentially with your domain's DKIM key if you have configured it with them. Both of these signatures can be valid. An email successfully passes DKIM if at least one valid DKIM signature aligns with the sending domain, according to your DMARC policy.
The Authentication-Results header in your email provides the definitive verdict from the receiving mail server. Here's a typical example:
This header clearly shows two DKIM signatures, both passing authentication. One is for your domain (@comms.uwe.ac.uk) and the other is for your ESP's domain (@dkim.dotmailer.com). The spf=pass also confirms your SPF record is configured to allow emails from the sending IP.
Why MX toolbox reports don't always match email headers
The main reason for this discrepancy is that online MX lookup tools, including G-Suite Check MX toolbox, typically perform a static DNS query for the presence of a DKIM record. They look for a specific selector (e.g., google._domainkey) or a general DKIM record for your primary domain.
If you are using a third-party email service to send emails, the DKIM signature that actually passes in the email header might be generated by your ESP, using a different selector or even their own signing domain. The MX toolbox might not be designed to check for these ESP-specific DKIM setups or may only be looking for the standard google._domainkey record which is used when sending directly through Google Workspace. If that record isn't present or correctly configured for direct Google sending, the tool will flag it, even if your actual email flow is authenticated via another service.
Another factor can be DNS propagation delays. Even if you've recently set up or updated your DKIM records, it can take time for these changes to fully propagate across the internet. A DNS checker might query a server that hasn't received the updated information yet, leading to a false negative. However, if your email headers show DKIM=PASS, it indicates that the receiving server was able to validate at least one of the DKIM signatures at the time of receipt.
The SPF warning in the MX Toolbox, even with spf=pass in the headers, often points to an incomplete SPF record. If you are sending emails directly through Google Workspace (G-Suite) in addition to your ESP, your SPF record must include both your ESP's sending mechanisms and Google's SPF record (include:_spf.google.com). If Google's include is missing, the toolbox will flag it, as it expects Google to be a sender for a G-Suite domain, regardless of other services you use.
Troubleshooting and verification steps
To properly troubleshoot and ensure consistent authentication across all your sending sources, consider the following:
Review all sending services: List every service that sends email on behalf of your domain, including your ESP, Google Workspace, CRM systems, transactional email providers, and marketing automation platforms.
Check DKIM setup for each: Ensure DKIM is correctly configured for each sender. This often involves adding a CNAME record provided by your ESP or Google to your DNS.
Update your SPF record: Consolidate all authorized sending IP addresses and include mechanisms into a single SPF record. Remember the 10-lookup limit for SPF. If you exceed this, it will result in SPF PermError (permanent failure).
Verify DMARC alignment: Even if SPF and DKIM pass, DMARC (Domain-based Message Authentication, Reporting, and Conformance) requires at least one of them to align with the From: domain shown to the recipient. The p=NONE policy in your DMARC record means that failing emails are still delivered, but you still get reports.
Checking your SPF record for multiple senders
If you use both Dotdigital (like in the example) and Google Workspace to send emails from the same domain, your SPF record needs to include mechanisms for both. An SPF record like "v=spf1 include:spf.dotmailer.com -all" will only authorize Dotdigital's servers. If Google sends an email, it will fail SPF, and the MX toolbox will likely report this deficiency.
This revised SPF record allows both Google Workspace and Dotdigital to send emails on behalf of your domain.
Regularly checking your authentication status is crucial for maintain good email deliverability. While checking email headers is the ultimate proof of authentication for a specific email, using diagnostic tools like G-Suite Check MX toolbox can provide an overview of your DNS setup. Just remember to interpret their findings with an understanding of your specific email sending architecture and DNS records. If the tool reports an issue, it highlights a configuration that might not be optimal or complete, even if emails are currently passing authentication via other means. Addressing these warnings can prevent future deliverability issues.
Views from the trenches
Best practices
Always maintain a single, comprehensive SPF record for your domain to avoid errors.
Ensure that all email sending services used by your domain are included in your SPF record.
Regularly check your DMARC reports to monitor authentication passes and failures for all senders.
Common pitfalls
Over-relying on a single diagnostic tool's output without cross-referencing with email headers.
Forgetting to include Google's SPF mechanism if sending from Google Workspace.
Assuming a "pass" in email headers means your DNS is perfectly configured for all scenarios.
Expert tips
Use SPF record flattening if you exceed the 10-DNS lookup limit to maintain proper validation.
Implement DMARC with a p=quarantine or p=reject policy once comfortable with your authentication data.
Use a DMARC monitoring service to gain comprehensive insights into your email authentication.
Expert view
Expert from Email Geeks says to check which DKIM key is being used; some ESPs sign with their own key, and sometimes the branded key might not exist.
2020-01-23 - Email Geeks
Marketer view
Marketer from Email Geeks says to verify the domain name differences in the DKIM pass results, as it might align with SPF.
2020-01-23 - Email Geeks
Navigating email authentication complexities
The apparent conflict between G-Suite Check MX toolbox reports and actual email headers regarding DKIM and SPF often comes down to the different scopes of their checks. The toolbox performs a static DNS lookup, while email headers reflect the dynamic, real-time authentication process by a receiving mail server. As long as your email headers show DKIM=PASS and SPF=PASS (and ideally DMARC=PASS) for your domain, your emails are successfully authenticated and aligned, which is the most critical factor for deliverability. Nevertheless, it is a good practice to ensure your DNS records are as comprehensive as possible to avoid confusion and potential future issues.
G-Suite Check MX toolbox, typically perform a static DNS query for the presence of a DKIM record. They look for a specific selector (e.g., google._domainkey) or a general DKIM record for your primary domain.
Dotdigital (like in the example) and Google Workspace to send emails from the same domain, your SPF record needs to include mechanisms for both. An SPF record like "v=spf1 include:spf.dotmailer.com -all" will only authorize Dotdigital's servers. If 
