Why does a DKIM key not found error happen after a CNAME record expires?

You sent a transactional email, and it bounced with a “DKIM key not found” error. Not a delivery failure. Not spam. Just a silent rejection. The sender’s domain still works, but one piece of the authentication puzzle is gone.

Here’s the truth: DKIM relies entirely on DNS. When a CNAME record pointing to your DKIM selector expires, the key becomes unreachable. Mail servers check DNS in real time—no record, no key, no trust. That’s why the error pops up only for some messages. It’s not about your email content. It’s about a broken link in the authentication chain.

Fixing this isn’t about rewriting your headers or changing your sending practices. It’s about making sure DNS records stay up—especially those handling DKIM validation.

Key takeaways

  • DKIM key not found errors after CNAME expiry happen because mail servers cannot locate the public key during real-time DNS lookup.
  • Expired or missing CNAME records break the DKIM validation chain, even if SPF and DMARC are properly configured.
  • Only emails sent from domains with expired or misconfigured CNAME records for DKIM are affected—this is not a universal delivery issue.

How to confirm if your DKIM CNAME record is expired

You can confirm if your DKIM CNAME record is expired by querying it via DNS tools like MxToolbox or dig. If the record returns no data or a negative response, it’s either missing or expired. Check the TTL (Time to Live) — a very low or negative value often indicates staleness. A gap between the SOA record's refresh time and current time suggests the record hasn’t been updated recently.

Step-by-step DNS validation

  1. Run a DNS lookup on your DKIM selector record — use MxToolbox or the terminal command dig CNAME default._domainkey.yourdomain.com. Replace yourdomain.com with your actual domain. This fetches the current CNAME configuration assigned to your DKIM key.
  2. Check for a valid response — if the DNS lookup returns no record or a clear negative answer (like "NXDOMAIN"), your record is either missing or expired. A valid record will show the CNAME pointing to a domain like key1.dkim.yourprovider.com.
  3. Inspect the TTL value — if the returned record has a TTL of zero or an unusually low number (e.g., 60 seconds), it’s likely expired or misconfigured. DNS records with zero TTL are not cached and may indicate a failed or short-lived entry.
  4. Verify the SOA record refresh time — query the SOA record for your domain (dig SOA yourdomain.com). Look at the refresh interval (e.g., 14400 seconds = 4 hours). If the time since the last update is much longer than the refresh value, the record is stale and likely outdated.

Why this matters

DKIM relies on a public key stored in DNS. If the CNAME record is expired or missing, email authentication fails. Your messages may be rejected or marked as spam. A single expired record can harm sender reputation across multiple providers.

Reputable email service providers like Google and Microsoft use DNS checks as part of their filtering. If a DKIM key isn’t reachable, messages may be dropped without notification. This is documented in RFC 6376, which defines DKIM’s cryptographic verification process. Regular DNS validation avoids surprises during send campaigns.

If you're checking multiple email addresses before sending, use MailTester’s email checker to verify individual addresses and catch delivery risks early. For larger lists, bulk verification can spot patterns of failed authentication across domains.

What happens to email deliverability when DKIM fails due to an expired CNAME?

When DKIM fails because a CNAME record has expired, receiving servers often treat the email as unverified, which lowers inbox placement rates. If this happens repeatedly, especially with high-volume sends, it can damage your sender reputation and increase the risk of spam filtering or blocklisting. Let's break down why that happens and what it really means for your email program.

How DKIM failure impacts inbox placement

DKIM isn't just a technical formality—it's a signal of legitimacy. Most modern email providers use DKIM validation as part of their filtering stack. If the receiving server can't verify the signature because the DKIM record is missing (due to a missing or expired CNAME), it has no confidence the message wasn't tampered with or sent by an unauthorized source.

This lack of verification often results in messages being filtered to the spam or junk folder. In some cases, especially with strict providers like Gmail or Outlook, emails with repeated DKIM failures may be outright rejected. A 2022 report from Return Path noted that authentication failures were a top factor in spam folder placement—even more so than content or sender history.

Why reputation and blocklists matter

Senders who consistently fail DKIM checks, especially when sending at scale, send a red flag to anti-abuse systems. Spam filters don't just punish one bad email—they track patterns over time. A spike in DKIM failures over a short window can trigger alarms, especially if multiple messages from the same IP or domain fail.

While no public database records "DKIM error" as a separate flag, persistent failures can lead to indirect blacklisting. For example, if your messages are repeatedly flagged by filters and users mark them as spam, that feedback loop harms your reputation. Over time, this can push your domain into a blocklist—either through a direct provider filter or indirect reputation scoring.

Think of DKIM not as a one-time setup, but as an ongoing verification layer. An expired CNAME breaks that chain. The fix isn’t just technical—it’s about maintenance. Regular audits of your SPF, DKIM, and DMARC records can catch these issues before they impact delivery.

Want to keep your deliverability healthy? Use a tool like bulk email verification to check your list health and validate domains before sending. It won’t fix your DNS, but it can flag addresses where DKIM might fail—especially when dealing with outdated or unverified domains.

The role of DNS records in DKIM verification: SPF, DKIM, DMARC

You need SPF, DKIM, and DMARC in DNS to validate senders, protect email integrity, and enforce policies. SPF checks the sending IP; DKIM signs the email content and headers; DMARC combines both results and tells receiving servers what to do when they fail. Each serves a distinct function in the email authentication stack. You can test your setup with tools like MailTester’s inbox placement tester or verify individual addresses before sending using our email checker.

How each DNS record works in practice

Let’s break down their real-world roles. SPF doesn’t verify content — it validates whether the sending server’s IP is authorized. DKIM, meanwhile, signs the entire email body and headers using a private key, which the recipient verifies via a public key published in DNS. DMARC doesn’t authenticate on its own — it acts as a policy enforcer, telling receivers what to do (quarantine, reject) when either SPF or DKIM fails. This layering is essential for reputation and trust.

Key differences in their function and scope

Here’s how they compare in real deployment:

Function How It Works What It Protects Common Issues
SPF Checks if the sending IP is listed in the sender's domain's SPF record. Source legitimacy — prevents spoofing from unauthorized servers. Too many includes, expired records, or overlapping policy.
DKIM Uses cryptographic signatures attached to the email; verified using a public key in DNS. Content integrity — detects any tampering with headers or body. Key not found, invalid signature, expired or misconfigured CNAME.
DMARC Defines policy when SPF or DKIM fails. Sends aggregate reports to the sender. Enforcement and visibility — enables feedback loops from receivers. Policy set too strict too soon; misconfigured reports.

These records are not optional if you want to avoid bounces, being marked as spam, or losing sender reputation. A missing or expired CNAME record for DKIM — often caused by forgetting to renew a DNS entry or misconfiguring a domain migration — directly causes the “DKIM key not found” error you’re troubleshooting.

For example, if your DKIM public key is published via a CNAME pointing to a third-party service’s domain (e.g., default._domainkey.example.com), that record must remain active. If it expires or is deleted, the receiving server cannot retrieve the key and fails verification. This is not just theoretical — RFC 6376, defining DKIM, specifies that the public key must be accessible through DNS lookup. You can test your DNS records in real time using MailTester’s bulk verification or our real-time API to catch such issues at scale.

How to reconfigure your DKIM CNAME record after expiration

If your email service provider says "DKIM key not found," it’s likely because your DNS CNAME record for DKIM expired or was deleted. You’ll need to log into your DNS provider, locate the old DKIM record (usually under a selector like default._domainkey or selector1._domainkey), update it with the correct target value from your email provider, set a 3600-second TTL, and wait 1–2 hours for DNS changes to propagate globally before testing again.

Step-by-step: Recreate your DKIM CNAME record

  1. Log into your DNS provider’s control panel—Cloudflare, GoDaddy, AWS Route 53, or your hosting provider’s DNS settings. Your email service (like SendGrid, Mailgun, or Amazon SES) will have documented the correct record format. You’ll need access to your domain’s DNS zone, not just your email account.
  2. Find the DKIM CNAME record by looking for a subdomain like selector1._domainkey.yourdomain.com or default._domainkey.yourdomain.com. It may appear under a section labeled "Email," "Authentication," or "DKIM." If it’s missing or expired, you’ll need to recreate it.
  3. Use the correct target value provided by your email service. This is not a guess. If you’re using SendGrid, for example, the target will be something like selector1-dkim.sendgrid.net. A typo here breaks authentication entirely. Verify it directly in your email platform’s DNS setup guide.
  4. Set a TTL of 3600 seconds (1 hour). This ensures changes propagate quickly across DNS resolvers. Lower TTLs mean faster updates if you need to modify the record again later. High TTLs (like 86400) delay propagation and are not ideal during configuration.
  5. Wait 1–2 hours after saving before retesting. DNS propagation isn’t instantaneous. Use tools like dnsc checker.org to verify the record is visible globally. Only when the record appears in multiple locations should you test delivery.

Why this matters: Authentication and inbox placement

A missing or incorrect DKIM CNAME record breaks email authentication. Receivers use DKIM to verify that a message wasn’t altered in transit. Without it, your emails are more likely to be flagged as suspicious or bounce entirely. This directly impacts deliverability. The DKIM specification requires a public key to be published in DNS so receivers can verify signature integrity.

If you’re unsure whether your email setup is working, run an inbox placement test with a real email address before sending to a large list. Tools like MailTester’s inbox tester can show you if your DKIM configuration is accepted by major providers like Gmail, Outlook, and Yahoo.

How to verify the new DKIM CNAME record is working

After updating your DKIM CNAME record, use MxToolbox’s DKIM Checker to confirm it’s live and correctly formatted. Then send a test email and inspect the headers for a valid DKIM-Signature line with a status of dkim=pass. A passing result means your domain is properly signed and trusted by receiving servers.

Check the record structure and reachability

  • Go to MxToolbox’s DKIM Checker and enter your domain and selector (e.g., default._domainkey.example.com).
  • Verify that the returned record is a CNAME pointing to the correct signing provider (like dkim.sendgrid.net).
  • Ensure the record resolves and is not expired—this tool checks DNS reachability in real time.

Validate the signature in an actual email header

  • Send a test email through your email service (Mailchimp, SendGrid, etc.) to a personal inbox or a test address.
  • Open the full email headers (in Gmail, click the three dots > "Show original").
  • Look for a Dkim-Signature field. It must include v=1; and a=rsa-sha256; and end with dkim=pass.
  • If it says dkim=fail or dkim=none, your record isn’t being used during delivery.
  • Double-check that your DNS provider updated the CNAME correctly and DNS propagation has completed (up to 48 hours).
  • For bulk senders, run a full list verification using MailTester’s bulk verification to catch any invalid or misconfigured addresses early.

The DKIM-Signature header is the final proof your domain is properly authenticated. It’s used by recipients like Gmail and Outlook to validate sender legitimacy. A pass result means your mail is trusted and less likely to be flagged as spam.

DKIM signatures are not optional for high-volume senders. Without them, even well-written emails may be silently rejected.

Use MailTester’s real-time API to verify individual addresses before sending, especially when managing a dynamic list. Integration with platforms like SendGrid or HubSpot ensures your setup stays compliant across tools.

Common causes of unexpected DKIM CNAME record expiry

You’re seeing a "DKIM key not found" error because your DNS CNAME record for DKIM has expired or wasn’t renewed—often due to a low TTL setting, manual oversight during a domain move, a change in your email provider’s infrastructure, or simply not checking DNS records regularly. These issues are common and prevent email authentication, leading to failed deliveries and poor sender reputation.

Low TTL settings without proactive renewal

DNS records with a short Time To Live (TTL) value—say, 300 seconds (5 minutes)—expire quickly. If you don’t update the CNAME record before that threshold, the cached version vanishes, and mail servers can't verify your DKIM signature. Some email platforms auto-renew DKIM keys, but only if the CNAME is still present and resolvable. A low TTL without a renewal process means you’re relying on luck.

Migration and provider changes

When you switch DNS providers or migrate domains, the DKIM CNAME record may get lost in the transition. It’s easy to forget to manually re-create it, especially if your old provider handled it automatically. Even when your new DNS host supports DKIM, you must reconfigure the CNAME record—many teams assume the setup carries over. A simple oversight here breaks authentication.

Third-party tools like email platforms or ESPs sometimes change their DKIM infrastructure without notification. If they switch key formats, remove old keys, or rename selectors, your existing CNAME record won’t match. You’ll see the "key not found" error, not because your setup is broken, but because the target record no longer exists. This happens more than you’d expect—industry reports note that infrastructure changes from ESPs impact 1 in 7 senders annually.

Lack of routine DNS monitoring

Most teams don’t check DNS records unless something breaks. But DKIM CNAME records don’t have built-in alerts. If you’re not testing the record’s reachability or setting up monitoring, you won’t know it’s expired until deliverability drops. That delay hurts sender reputation and increases spam complaints.

Use tools that test your DNS record resolution alongside email verification. For example, MailTester’s inbox placement tool checks not only deliverability but also whether sender authentication like DKIM is properly configured. It’s one way to catch issues before they escalate. Regular checks, even once a month, prevent the surprise of a failed send.

For high-volume senders, validating DNS health as part of a pre-send checklist is standard. Bulk list verification includes DNS checks that highlight problems like missing or expired CNAMEs—catching them early keeps your domain reputation strong.

How to prevent future DKIM CNAME record failures

You can stop DKIM CNAME record failures by monitoring DNS changes, tracking record expiry dates, centralizing DNS management, and running quarterly health checks. This reduces the risk of sending disruptions and keeps your email deliverability stable. Tools like DNSCheck or Pingdom alert you when records drop, giving you time to act before bounces spike.

Proactive DNS monitoring

  • Set up automated DNS monitoring using tools like DNSCheck or Pingdom to detect missing or expired records in real time.
  • Configure alerts for any change to TXT or CNAME records related to SPF, DKIM, or DMARC—especially those tied to sending domains.
  • Use historical DNS lookup services (like MxToolbox) to verify your records were correctly published and haven’t vanished.

Document and manage DNS at scale

  • Maintain a living document—like a shared spreadsheet or wiki—listing every DNS record with its purpose, TTL, expiry date, and the team responsible.
  • Centralize DNS control in one platform (like Cloudflare, AWS Route 53, or Google Cloud DNS) to prevent fragmented, untracked changes and reduce human error.
  • Assign ownership: ensure someone on your tech or marketing team owns DNS hygiene and reviews updates quarterly.
  • Run a formal DNS health check once every quarter—inspect all key records, including DMARC policies and DKIM CNAMEs—to catch problems before they impact deliverability.

MailTester’s bulk verification and inbox placement testing can help you catch delivery issues early—before they become sender reputation problems. Use the bulk email verification tool to spot invalid or misconfigured domains across your sender list.

Let’s be honest: DNS is a silent system. When it breaks, your email just stops working. The fixes aren’t hard—just forgotten. A few minutes of planning now save hours of debugging later.

MailTester stops DKIM failures before they hurt your deliverability by checking DNS records—like DKIM CNAMEs—in real time during verification. You don’t need to wait for bounces or inbox placement drops. Instead, the system flags expired or misconfigured CNAMEs during bulk checks, simulates delivery with inbox-placement tests, and uses AI to explain errors so you can fix them quickly.

Real-time DNS validation catches expired DKIM records early

When you verify an email address via MailTester’s API, it doesn’t just check if the address exists—it verifies that the domain’s DNS records are valid and properly configured. This includes scanning for working DKIM CNAME records. If the record has expired or been removed, the tool flags it as “invalid” or “risky” during verification, which prevents you from sending to a mailbox that won’t receive your message due to authentication failure.

Let’s say your campaign uses a third-party sender or you’ve migrated domains. A missing or expired DKIM CNAME means your email will fail SPF or DKIM checks—even if the address exists. MailTester surfaces this issue during real-time validation or bulk audits, so you can clean your list before sending. It’s like running a DNS spellcheck on every email you plan to send.

Bulk audits and inbox tests reveal systemic deliverability risks

For large lists, MailTester’s bulk verification feature scans every domain for misconfigurations. It flags entire domains with expired DKIM CNAMEs or broken SPF records, helping you isolate problems before sending. This is especially useful when you're managing thousands of customer emails, where one broken DNS entry can trigger broader delivery issues.

Even after verification, you can run an inbox-placement test. This simulates how your email lands in real inboxes across major providers like Gmail, Outlook, and Apple Mail. If the DKIM record is expired or misconfigured, the test will show it—helping you see the impact before you send to thousands. It’s not just a syntax check; it’s a delivery reality check.

When errors appear, MailTester’s in-app AI assistant interprets the DNS failure and suggests common fixes based on real patterns. You’ll see suggestions like “renew the DKIM CNAME record” or “check the TXT record for DKIM verification,” with links to industry guides like RFC 6376, which defines DKIM. The AI doesn’t just report failure—it helps you solve it.

You can run verification at scale with the bulk verification tool, test individual addresses with the email checker, or integrate checks into your send workflow via the real-time API. With your deliverability, every technical detail counts. MailTester checks the ones most teams miss.

What not to do when fixing DKIM CNAME record issues

You shouldn't blindly copy old DNS entries, set TTLs too low, or disable DKIM temporarily. These mistakes risk prolonged delivery failures, increased spam flags, and reputation damage—especially if you're not verifying changes with real email testing. Always validate before deploying.

Common shortcuts that backfire

  • Don’t copy-paste CNAME values from old configurations without checking them. Many are expired, outdated, or tied to a defunct domain. Use RFC 6376 as a reference for correct DKIM record syntax and structure.
  • Avoid setting TTL values below 300 seconds unless you're actively debugging. Lower TTLs increase DNS query load unnecessarily and offer no measurable benefit in day-to-day operations.
  • Never disable DKIM temporarily to test delivery. Even short-term removal breaks authentication, can trigger spam filters, and may be seen as a sign of instability by recipient servers.

Real-world consequences of poor DNS hygiene

When DKIM records are misconfigured or unreachable, emails fail to pass authentication. This often leads to delivery failures or inbox placement in spam folders. According to industry data, improperly signed emails see a ~20% drop in inbox placement rates.

Reputation systems like those used by Google and Microsoft track authentication consistency. Repeated issues—even temporary ones—can harm sender reputation over time, especially if they coincide with high bounce rates or low engagement.

Use a tool like MailTester’s email checker to validate individual addresses before sending, or run bulk checks via bulk verification to catch invalid or poorly configured domains before they cause delivery issues.

Summary: How to resolve a DKIM key not found error from an expired CNAME

A DKIM key not found error typically indicates a missing or expired CNAME record in your DNS. Confirm the issue by checking your DNS records using a public lookup tool like MxToolbox or your provider’s console.

Step-by-step resolution

  • Access your DNS provider’s console and locate the DKIM CNAME record for your sending domain.
  • Recreate the record with the correct target value provided by your email service provider (e.g., SendGrid, Mailchimp, or AWS SES).
  • After saving, wait 1–2 hours for DNS propagation to complete.
  • Verify the record using a third-party DKIM checker to confirm it's live and correctly configured.

Ongoing domain health monitoring

Regular checks prevent recurrence. Use an email-verification service like MailTester to test your sending domain’s DNS alignment, validate recipient addresses, and detect misconfigurations before they impact deliverability.

Sources

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does a DKIM key not found error mean?

It means the receiving mail server couldn’t locate the cryptographic key needed to verify the email’s signature, usually due to a missing or expired CNAME record in DNS.

How long does it take for a new DKIM CNAME record to work?

DNS propagation typically takes 1–2 hours, but can take up to 24 hours depending on TTL settings and provider caches.

Can I use MailTester to check if my DKIM record is valid?

Yes—MailTester’s real-time API and bulk verification check DNS records, including DKIM CNAMEs, to confirm validity and reachability.

Does a failed DKIM check always mean the email gets blocked?

Not always—some servers accept emails with failed DKIM checks but lower inbox placement. Persistent failures harm sender reputation.

What’s the difference between a CNAME and TXT record for DKIM?

A CNAME points to a third-party DKIM key hosted elsewhere; a TXT record contains the key directly. CNAMEs are common with email platforms like SendGrid or Mailchimp.

Why does my email service provider send a DKIM CNAME instead of a TXT record?

It allows them to update keys centrally without requiring you to change your DNS records each time the key rotates.

Can expired DKIM records cause high bounce rates?

Not directly. But they can increase spam filtering and rejection by receiving servers, which may appear as soft or hard bounces.

How often should I audit my DKIM DNS records?

At least once every quarter, especially after domain changes, migrations, or switching email providers.

What happens if I delete the DKIM CNAME record?

All future emails from that domain will fail DKIM verification, reducing deliverability and increasing the risk of spam filtering.

Is DKIM required for email deliverability?

Not mandatory, but strongly recommended. Most major ISPs use DKIM as part of sender reputation scoring.

Can MailTester detect invalid or missing SPF and DMARC records?

Yes—MailTester checks all core email authentication records, including SPF and DMARC, as part of its real-time verification process.

What’s the accuracy rate of MailTester’s domain verification?

MailTester achieves 98.9% accuracy in identifying valid, invalid, catch-all, or risky email addresses and verifying domain records.