Step by step DKIM troubleshooting with specific error message explanations.
If your DKIM is not verifying, it means the cryptographic signature attached to your outgoing email cannot be validated by the receiving server. DKIM verification requires two things to match: the private key used to sign the email on your sending server and the public key published in your domain's DNS. When these do not match, or when the DNS record is missing or misconfigured, the receiving server returns a dkim signature invalid result. This hurts deliverability because DKIM is one of the three authentication checks, alongside SPF and DMARC, that email providers rely on to verify your identity.
Send a test email to a Gmail account and view the original headers. Look for the DKIM result line. It will show one of several statuses. A result of dkim=fail means a signature was found but did not verify. A result of dkim=neutral or dkim=none means no valid signature was present. The header also shows the selector used, which looks like s=selector1 or s=google. Note this selector because you will need it to verify the correct DNS record exists.
The DKIM public key is published as a DNS record at [selector]._domainkey.yourdomain.com. Look up this record using a DNS query tool. If no record is found, the public key was never published or was accidentally deleted. For Google Workspace, the record is a TXT record. For Amazon SES, the records are three CNAMEs. For Microsoft 365, the records are two CNAMEs. Regenerate the DKIM records in your email provider's admin console and add them to your DNS if they are missing.
The most common dkim fail fix involves correcting the DNS record name. Many DNS providers automatically append your domain name to the host field. If you paste the full record name including your domain, you end up with a doubled domain like selector._domainkey.yourdomain.com.yourdomain.com, which will not resolve. Check your DNS provider's documentation to understand whether you should enter just the subdomain portion or the full name. Look up the actual published record to confirm it matches what your email provider expects.
Different email providers use different DNS record types for DKIM. Google Workspace uses a TXT record containing the public key directly. Amazon SES uses CNAME records that point to AWS managed endpoints which serve the keys. Microsoft 365 also uses CNAME records. If you created a TXT record when your provider requires a CNAME, or vice versa, the DKIM lookup will fail even though a record exists at the correct name. Verify you are using the record type your provider specifies.
Some email providers rotate DKIM keys periodically for security. If a key was rotated but your DNS record still points to the old key, verification will fail. For Amazon SES, all three CNAME records must be present for Easy DKIM key rotation to work. If you only added one or two during initial setup, key rotation can cause intermittent failures. Check your provider's admin console for the current DKIM records and compare them against what is published in your DNS.
Having the DNS record published is only half of the requirement. DKIM signing must also be enabled in your email provider's settings. For Google Workspace, you need to explicitly enable DKIM signing in the admin console after adding the DNS record. For Microsoft 365, you enable it in the Security settings under Email authentication. If the DNS record is correct but dkim not passing persists, verify that signing is actually turned on in your provider's dashboard.
After setting up DKIM, verify it is working by sending test emails and checking headers before starting any campaigns. Monitor your DNS records periodically to catch accidental deletions or changes. When changing DNS providers or migrating domains, include DKIM records in your migration checklist. If your email provider generates new keys, update DNS promptly. Keep documentation of which selector and record type each provider uses so troubleshooting is faster if problems occur later.
EmailQo runs DNS authentication validation as part of its pre send inbox health checks. If your DKIM records are missing, misconfigured, or not resolving correctly, the check flags the issue before your campaign sends. This catches DKIM problems immediately after DNS changes or provider migrations rather than discovering them through failed deliverability after emails have already been sent.
Yes, a DKIM failure alone does not always mean the email is rejected. If SPF passes and your sender reputation is decent, many providers will still deliver the email, possibly to spam. However, failing DKIM weakens your overall authentication profile and makes it easier for other negative signals to push your emails to spam. Fixing DKIM should be treated as urgent.
The most common causes are a DNS record that was accidentally deleted during other DNS changes, a key rotation by your email provider that was not reflected in DNS, or a DNS provider migration that did not include the DKIM records. Check your DNS first, then check whether your provider has generated new keys that need to be published.
Yes, unlike SPF, DKIM typically survives forwarding because the signature is attached to the email content itself rather than being tied to the sending server's IP address. This is one of the reasons DKIM is especially important for cold email, where your messages may be forwarded by recipients to colleagues.