Table of Contents
Last Updated
Do not index
IntroductionWhat DKIM Actually DoesWhy DKIM Failures Go UndetectedThe Six Most Common Causes of DKIM FailureHow to Diagnose a DKIM FailureHow to Fix ItHow to Prevent DKIM Failures Going ForwardOther Things You Need to Know About DKIM
Introduction
DKIM failures happen when the cryptographic signature attached to an outgoing email doesn’t match the public key published in the sender’s DNS records. The receiving server checks this signature on every inbound message, and when the verification fails, the email gets flagged, filtered to spam, or rejected outright, depending on the provider’s policies and the sender’s DMARC configuration.
Most people assume DKIM breaks because of a missing record. It rarely does. The real trigger, the one that goes undetected for weeks or months at a time, is a mismatch between the signing configuration on the sending platform and the DNS entry on the domain.
What DKIM Actually Does
Before getting into fixes, it helps to understand what DKIM is verifying in the first place. When your email platform sends a message, it generates a cryptographic signature using a private key that only the platform holds. This signature gets attached to the email header as a “DKIM-Signature” field. On the receiving end, Gmail or Outlook or Yahoo looks up the corresponding public key in your domain’s DNS, and uses it to verify that the signature is valid and the message hasn’t been altered in transit. If the signature matches the public key, DKIM passes. If it doesn’t, DKIM fails. The receiving server then decides what to do with the message based on your DMARC policy.
SPF answers the question “Is this server allowed to send for this domain?” DKIM answers a different one entirely: “has this email been tampered with since it left the sender?” Both are checked independently; both affect inbox placement.
Why DKIM Failures Go Undetected
I worked with a company last month that had been in exactly this situation for over eight weeks. They’d moved their marketing emails from Mailchimp to HubSpot back in January. The migration was technically smooth on the platform side. But the Mailchimp DKIM records were never removed from DNS, and the HubSpot DKIM records were never added. For 60+ days, every marketing email they sent failed DKIM authentication without a single alert from any system they were monitoring.
The Six Most Common Causes of DKIM Failure
- Platform migration without updating DNS records This is the most common cause. When you switch from one email service to another, the new platform generates a new private key and signs all outgoing messages with it. But the public key in DNS still belongs to the old provider. The receiving server tries to verify the new signature against the old key. It fails every time and will continue to fail until someone updates the DNS entry. If you migrated from Mailchimp to SendGrid, or from Google Workspace to Microsoft 365, or from any platform to any other platform in the last 12 months, check your DKIM records right now.
- The DKIM record was never published in DNS Some email platforms require you to manually add the DKIM DNS records after connecting your domain. If you skipped that step during setup, the platform is signing emails with its private key, but there’s no corresponding public key in your DNS for receiving servers to check against. The result is a DKIM failure on every message.
- Selector mismatch
Every DKIM signature includes a selector value (e.g., “s1”, “google”, or “k1”) that tells the receiving server which DNS record to check. The DNS record lives at
[selector]._domainkey.yourdomain.com.If the selector in the email header doesn’t match the selector in DNS, or if the DNS record for that selector doesn’t exist, verification fails. This happens when someone publishes the DKIM record under the wrong selector name, or when a platform changes its default selector during an update and the DNS record still references the old one.
- Content modification by intermediaries Email forwarding services, mailing lists, and some corporate security gateways modify message headers or body content after the DKIM signature was applied. Any change at all, even something as minor as appending a footer or adjusting a header field, invalidates the signature. The DKIM check fails even though the original email was legitimate. If DKIM passes on direct sends but fails on forwarded messages, the issue isn’t your configuration. It’s an intermediary altering the message after signing.
- Multiple sending platforms without individual DKIM configuration If your domain sends email through Google Workspace for internal communication, SendGrid for transactional emails, and HubSpot for marketing campaigns, each of those platforms needs its own DKIM key pair. A single DKIM record doesn’t cover all of them. Each platform signs with its own private key, and each needs its corresponding public key published in DNS under a unique selector. If one platform has DKIM configured and the others don’t, every email from the unconfigured platforms fails DKIM.
- Expired or rotated keys Some platforms rotate DKIM keys periodically for security reasons. If a key rotation happens and the new public key isn’t updated in DNS, all subsequent emails fail DKIM until the record is refreshed. This is less common than the other causes, but it does happen, particularly with platforms that handle key rotation automatically on their end without notifying the domain administrator.
How to Diagnose a DKIM Failure
- Check the email headers: Send a test email from each platform that sends on your domain. Open the full email headers on the receiving end. Look for a line that says
“dkim=pass”or“dkim=fail”in the Authentication-Results header. If it says fail, your DKIM configuration needs attention.
- Run a DNS lookup on your DKIM record: The format is
[selector]._domainkey.yourdomain.com.Your email provider will tell you what selector they use. Google Workspace uses “google” as its selector. SendGrid typically uses “s1” and “s2.” HubSpot uses a platform-specific selector that you can find in their DKIM setup documentation. If the DNS lookup returns nothing, the record was never published or got removed.
- Compare the signing domain with your From address: DKIM signs emails using a specific domain, and that domain needs to align with the domain in your From header for DMARC to pass. If you’re signing with mail.yourdomain.com but sending from yourdomain.com, DMARC alignment may fail depending on whether your policy is set to strict or relaxed. Relaxed allows subdomain matching; strict does not.
- Use Mailwarm’s infrastructure health check: Mailwarm runs automated checks across SPF, DKIM, DMARC, blacklists, and SMTP configuration, showing you exactly what passed, what failed, and what needs attention. It catches broken DKIM records before they reach your audience.
How to Fix It
Once you’ve identified the cause, the fix is usually straightforward.
For platform migrations: Go into the new platform’s settings, find the DKIM section, and copy the DNS records they provide. Add them to your domain’s DNS as TXT records under the correct selector. Remove the old platform’s DKIM records unless you’re still sending through that service.
For missing records: Follow your email platform’s DKIM setup guide. They’ll give you the exact DNS records to publish. Add them, wait for DNS propagation (usually 15 minutes to an hour), then send a test email and verify the headers show
“dkim=pass.”For selector mismatches: Compare the selector value in your DKIM-Signature email header with the selector in your DNS. They need to match exactly. If they don’t, update the DNS record to use the correct selector.
For content modification: This one is harder to fix because the modification happens outside your control. If a mailing list or forwarding service is altering your emails, DKIM will fail on those forwarded copies. This is a known limitation of DKIM, which is why DMARC evaluates both SPF and DKIM rather than relying on one protocol alone.
For multiple platforms: Each platform that sends email on your domain needs its own DKIM key pair. Configure DKIM individually for Google Workspace, SendGrid, HubSpot, Salesforce, or whatever combination of services you use. Publish each public key in DNS under its own unique selector.
How to Prevent DKIM Failures Going Forward
Don’t treat DKIM as a one-time setup. Review your DKIM records whenever you add a new sending service, change email platforms, migrate DNS providers, or make any change to your email infrastructure. A quarterly audit of your authentication records takes about 15 minutes and prevents the kind of silent failure that can erode deliverability for months before anyone notices.
Keep your sending domains warm with continuous engagement signals running alongside your campaigns. Get a tool that monitors inbox placement in real time and runs infrastructure health checks that catch DKIM failures before they reach your audience.
Other Things You Need to Know About DKIM
Does DKIM protect against email spoofing on its own?
DKIM alone doesn’t prevent spoofing. It verifies that the message wasn’t altered in transit, but it doesn’t check whether the visible “From” address matches the signing domain. A spoofed email can carry a valid DKIM signature from the attacker’s own domain while displaying a different sender name to the recipient. Full spoofing protection requires DKIM working alongside SPF and DMARC, where DMARC enforces alignment between the authenticated domain and the visible sender address.
Can I use the same DKIM key on multiple email platforms?
No. Each platform generates its own private key and signs outgoing emails with it. You can’t share private keys between platforms; they’re generated and stored internally by each service. Every platform needs its own key pair, and every public key needs to be published in your DNS under its own selector.
How long does it take for a DKIM DNS record to propagate?
DNS propagation typically takes between 15 minutes and 24 hours, depending on your DNS provider and the TTL (time to live) setting on your records. Most modern DNS providers propagate changes within an hour. Send a test email after publishing the record, then check the email headers to confirm that DKIM is passing before sending emails at scale.
What’s the difference between a DKIM soft fail and a hard fail?
DKIM doesn’t have a soft fail mechanism the way SPF does. It either passes or fails. If the signature doesn’t verify, the result is
“dkim=fail” and the receiving server handles it based on your DMARC policy. If DMARC is set to “none,” the failure gets logged but the email may still be delivered. If DMARC is set to “quarantine” or “reject,” the email gets filtered or blocked.Should I rotate my DKIM keys regularly?
Key rotation is a security best practice, but it’s not required by most email providers. If you do rotate keys, make sure the new public key is published in DNS before the old one is removed. Running both keys simultaneously during a transition period prevents any gap where emails would fail DKIM verification.