Summary
DKIM (DomainKeys Identified Mail) is a critical email authentication standard that allows a recipient to verify that an email was indeed sent and authorized by the owner of that domain. When your DKIM records aren't validating, it can lead to significant deliverability issues, even if the records appear to be correctly published. This often stems from subtle DNS configuration problems, interactions with hosting providers, or misunderstandings about how multiple DKIM keys for the same service are handled. Troubleshooting these issues requires a systematic approach to identify the root cause, which is frequently a discrepancy between where DNS records are managed and where they are being checked.
Key findings
- DNS hosting discrepancies: A common cause for DKIM validation failure is when DNS records are configured in one platform (e.g., Shopify's DNS settings, which might point to Google Domains) but the domain's authoritative DNS is actually hosted elsewhere (e.g., Squarespace, GoDaddy, or Cloudflare). This means the changes aren't propagating to the live DNS.
- Incorrect selector or domain in DNS: The DKIM selector is a crucial part of the DNS record, located at the beginning of the CNAME or TXT record name, for instance, s1._domainkey. An incorrect selector or misconfigured domain within the record itself will prevent proper lookup, leading to validation failure.
- Automatic domain appending by DNS providers: Some DNS providers automatically add your root domain to the end of CNAME or TXT records. If the DKIM record provided by your ESP (Email Service Provider) already includes the domain, this automatic appending can result in a duplicated domain, making the record invalid. For example, entering selector._domainkey.yourdomain.com when the provider automatically adds .yourdomain.com results in selector._domainkey.yourdomain.com.yourdomain.com, which won't resolve.
- Multiple DKIM sets for the same sending service: While having multiple DKIM records with different selectors from different ESPs is generally fine, some services, like Amazon SES, may only have one active key at a given time for a specific setup. Additional keys might be for rotation purposes and not immediately resolvable, leading to confusion if multiple services using the same underlying infrastructure try to publish separate keys.
Key considerations
- Verify authoritative DNS: Always confirm which DNS server is truly authoritative for your domain before attempting to configure DKIM. Tools can reveal your current name servers, ensuring you're making changes in the right place.
- Check CNAME format: For DKIM CNAME records, verify that the 'Name' field is entered exactly as required by your ESP, without any unintended duplication of your domain. Pay close attention to whether the domain needs to be omitted from the 'Name' field due to automatic appending.
- Understand DKIM selectors: Ensure you are using the correct DKIM selectors provided by each sending service. These are specific to the key being used and must match the 's=' tag in your email headers. You can learn more about common DKIM selectors in our guide.
- Utilize DKIM lookup tools: After making DNS changes, use a DKIM verification tool to confirm that your public DKIM key is resolving correctly in DNS. This helps pinpoint if the record is inaccessible or malformed. For more help, see our article on why MXToolBox might say your DKIM signature is not verified.
- Inspect email headers: Examine the raw email headers of messages sent from your domain. Look for the DKIM-Signature header and its 's=' (selector) and 'd=' (domain) tags to understand which key is being used and which domain it's attempting to authenticate. This is crucial for debugging.
What email marketers say
Email marketers often face challenges with DKIM validation, particularly when dealing with complex hosting environments or multiple email sending platforms. The common refrain is that the records look correct in their DNS provider's interface, but validation tools or DMARC reports show failures. This highlights a gap in understanding between how DNS changes are made and how they actually propagate and resolve on the internet. Frustration often mounts when basic checks seem to pass, yet deeper issues persist. Many marketers share anecdotes of time-consuming trials and errors, especially with providers that have unique DNS handling quirks.
Key opinions
- DNS provider complexity: Many marketers find DNS configuration, especially CNAME records for DKIM, confusing due to varying interfaces and automatic domain appending by providers like GoDaddy or Shopify (which often uses Google Domains under the hood).
- Hidden DNS management: A frequent point of confusion is when a platform (like Shopify) seems to manage DNS, but the actual authoritative name servers are elsewhere, leading to changes being made in the wrong place without effect.
- Diagnostic difficulty: Marketers often struggle to diagnose DKIM validation issues because the public key records might not be resolving at all from an external perspective, even if they appear set up in their control panel.
- Selector visibility: The issue of DKIM selectors not being visible to external checkers, despite being entered into the DNS, is a key indicator of a deeper DNS misconfiguration or an incorrect authoritative DNS.
Key considerations
- Confirm DNS authority: It's vital for marketers to definitively know where their domain's name servers are pointing. This determines where DKIM records must be added for them to take effect. If you're setting up DKIM, SPF, or DMARC, it's a good idea to know the basics of email authentication.
- Educate clients/customers: For ESPs, clearly communicating the exact format needed for DKIM records, especially regarding automatic domain appending by various DNS providers, can prevent many issues.
- Verify all records: Ensure that all required DKIM CNAME or TXT records are published and resolvable. If an email service provides multiple selectors (e.g., for key rotation), confirm which one is currently active or expected to resolve. Our article on fixing 'DKIM record published no DKIM record found' errors can provide further assistance.
- Screenshare for precise troubleshooting: When assisting clients, a screenshare session can be invaluable to directly observe how they are entering records into their specific DNS provider's interface and verify the correct hostname and value formats.
Marketer view
Email marketer from Email Geeks shared a situation where their client's Shopify store had two sets of DKIM records for Amazon SES: one from their service and another from a different provider, Flodesk. Despite the records being distinct and appearing accurate, their DKIM validation consistently failed. This scenario raised questions about potential conflicts when multiple entities attempt to configure DKIM for the same underlying email sending service, even with different selectors.
Marketer view
An email marketer from a marketing forum explained that they frequently encounter issues where clients assume their DNS is managed by their e-commerce platform (like Shopify), but the platform's DNS setup actually points to a third-party like Google Domains or Squarespace. This creates a disconnect, as changes made in the e-commerce platform's interface do not propagate to the live DNS, leading to DKIM records not validating.
What the experts say
Email deliverability experts consistently point to DNS configuration as the primary culprit when DKIM records fail to validate despite seeming accurate. The consensus is that if a DKIM public key isn't resolving, it's almost always an issue with how the DNS records are published or where the domain's name servers are actually pointing. Experts emphasize the importance of understanding the authoritative DNS server for a domain, as well as the specific requirements of the DNS provider for CNAME or TXT record entry, including how they handle domain appending. Misinterpretations of 'selector' versus 'name' fields are also common pitfalls.
Key opinions
- Authoritative DNS is paramount: Experts stress that the single most critical step is verifying which DNS servers are authoritative for a domain. If DKIM records are added to a non-authoritative DNS, they will never propagate or resolve.
- DKIM key resolution indicates DNS problem: If a DKIM public key cannot be found or resolved using tools like host -tTXT or online checkers, it's a clear signal that the DNS configuration is incorrect, regardless of what appears in a control panel.
- Understanding selectors vs. names: There's often confusion between the 'Name' field in DNS (which includes the selector and _domainkey) and the actual DKIM selector itself (the 's=' value in the email header). Correctly identifying these is essential for lookup and validation.
- Platform-specific DNS quirks: Different platforms (like Shopify) and DNS providers (like Google Domains or GoDaddy) have unique ways of handling DNS entry, particularly concerning automatic domain appending. Awareness of these specific behaviors is crucial.
Key considerations
- Always verify NS records: Before troubleshooting DKIM, explicitly check the domain's NS (Name Server) records to confirm the actual DNS host. This is often the first and most overlooked step.
- Use command-line tools for direct checks: Tools like host -tTXT selector._domainkey.yourdomain.com provide direct insights into whether a DKIM record is truly published and resolvable in the global DNS. This bypasses potential misleading information from local DNS caches or specific UI views.
- Review email headers thoroughly: Analyze the raw email headers to identify the exact DKIM signature present, paying attention to the 's=' (selector) and 'd=' (signing domain) values. This helps ensure alignment between the published record and the outgoing email's signature.
- Beware of service-specific DKIM key management: Be aware that services like Amazon SES might only activate one of several generated DKIM keys at a time for validation. The other keys are typically for rotation and won't resolve until they become active. This can create confusion if not understood.
- Consider DMARC reports: DMARC reports provide aggregate data on your email authentication results, including DKIM failures. Analyzing these reports (perhaps using a DMARC monitoring solution) can reveal patterns of DKIM failures that might not be immediately apparent from individual tests.
Expert view
Email expert from Email Geeks, Todd Herr, queried the DNS for the provided DKIM records and found that the hostnames, like flodesk._domainkey.egoswim.com, were not found (NXDOMAIN). This immediately indicated that the DKIM public keys did not exist in DNS at all, which is a definitive reason for DKIM failures. He pointed out that while the records might be entered in some UI, they weren't publicly resolvable.
Expert view
Email expert from Word to the Wise, Laura, suggests that if you can't determine the exact selector and domain (the 's=' and 'd=' values) being used in the DKIM signature, it becomes impossible to properly look up the public key in DNS. She emphasized that knowing these specific values is critical for troubleshooting why a DKIM key isn't publishing correctly. This precise information allows for direct DNS queries to confirm existence.
What the documentation says
Official DKIM documentation and related RFCs (Request for Comments) define the precise structure and lookup mechanism for DKIM records. The core principle is that a recipient Mail Transfer Agent (MTA) constructs a query using the 's=' (selector) and 'd=' (signing domain) values from the email's DKIM-Signature header. This query is sent to the DNS to retrieve a public key, typically stored in a TXT record. Any deviation from the specified format, incorrect host, or failure of the record to resolve publicly will result in a DKIM validation failure. Documentation also often specifies the best practices for key rotation and managing multiple keys, but the primary focus remains on the DNS publishability.
Key findings
- Public key in DNS: The DKIM public key must be published in the DNS as a TXT record at a specific hostname derived from the selector and signing domain (e.g., selector._domainkey.example.com).
- Selector and domain alignment: The 's=' and 'd=' tags in the email's DKIM-Signature header must precisely match the published DNS record for successful validation. A mismatch will cause the signature to fail.
- Canonicalization and hashing: DKIM validation involves canonicalizing the email header and body (applying a standard format) and then hashing them. If the recipient's canonicalization or hashing process differs from the sender's, or if the message content changes in transit, the body hash will fail. More information on DKIM body hash failures is available.
- DNS propagation delays: DNS changes can take time to propagate across the internet due to caching. While records may be updated in the authoritative DNS, it can take minutes to hours for these changes to be universally recognized, leading to temporary validation failures.
Key considerations
- Adhere to RFC 6376 specifications: DKIM records must strictly conform to the specifications outlined in RFC 6376 to ensure proper parsing and validation by receiving mail servers.
- Use TXT records for public keys: The DKIM public key is always published within a TXT record in the DNS. Ensure that the record type is correctly set.
- Verify CNAME targets: If using CNAME records (often for services like AWS SES where they manage the underlying key), ensure the CNAME target is exactly as provided by the service. The CNAME must point to a resolvable TXT record containing the public key.
- Understand key length: While DKIM supports various key lengths (e.g., 1024-bit, 2048-bit), the public key value must be entered precisely into the TXT record without truncation or modification. Our article on invalid RSA public key errors in DKIM records can help.
Technical article
Documentation from RFC 6376 specifies that the DKIM-Signature header field contains all the necessary information for a verifier to locate the appropriate public key in DNS. This includes the 'd=' tag for the signing domain and the 's=' tag for the selector. The verifier then constructs a query for s._domainkey.d to retrieve a TXT record containing the public key. Any discrepancy in these values or the record's location will lead to a lookup failure.
Technical article
Amazon SES documentation for DKIM setup indicates that for easy configuration, they provide CNAME records that customers should add to their DNS. These CNAMEs point to Amazon's own DNS, where the actual TXT records with the public keys are hosted. Validation failures often occur if these CNAMEs are not correctly added, or if the domain's name servers are not pointing to the DNS where these CNAMEs reside.
Related resources
13 resources
Related pages
Why is my DKIM body hash failing and how do I fix it?
Why are DKIM validations failing intermittently with Office365?
Why are Microsoft Office 365 DKIM signatures failing and how to fix it?
Why is Microsoft DKIM failing when Gmail passes, and how to fix it?
Why is DKIM failing at some ISPs but not others, and how can I fix it?
A list of the most common DKIM selectors and how to use them
How to fix “DKIM record published no DKIM record found” errors
How to fix DKIM body hash mismatch failures
A simple guide to DMARC, SPF, and DKIM
Why Your Emails Are Going to Spam in 2024 and How to Fix It
