Why does an expired DKIM key cause email rejection?

You send an email. It looks right. The content is on-brand. The sender address is valid. But it vanishes into the void — or worse, lands in spam. No bounce message. No clear reason.

One silent culprit? An expired DKIM key. It’s not about the message. It’s about the signature. And when that signature fails, the mail server does too.

DKIM signs every outgoing email using a cryptographic key tied to your domain’s public key record in DNS. The private key used to sign the email must be active and valid at the time of sending. If it’s expired, the signature—no matter how legitimate—is invalid.

Receiving mail servers check that signature using your domain’s published public key. If the key is missing, expired, or misconfigured, validation fails. That failure often means immediate rejection or spam filtering, even with a clean sender reputation.

Key takeaways

  • DKIM signatures are only valid if the private key is active at time of sending — expired keys break validation even for legitimate emails.
  • Receiving servers reject or flag emails with expired or missing DKIM signatures, regardless of content or sender reputation.
  • DKIM key expiration is a common, preventable cause of email rejection due to mismanaged key rotation schedules.

How do you know if a DKIM key is expired at time of signature?

You can only confirm if a DKIM key was expired at the time of signature by checking the DNS record at the exact moment the email was sent. The key’s t= tag in the DKIM record defines its expiry time in Unix timestamp format. If that timestamp is in the past, the key has expired—even if it’s still published in DNS. Emails signed with expired keys are typically rejected by Gmail, Yahoo, and Outlook unless the receiving server allows lenient handling of expired signatures.

How the DKIM t= tag works in practice

DKIM keys include a t= tag that specifies when the key stops being valid. This timestamp is fixed at the time the record is published. It doesn’t change based on when the email is sent. For example, a key with t=1700000000 expires at a specific point in time—even if the record stays in DNS beyond that.

When an email is sent, the receiving server checks the DKIM signature using the public key from DNS *at the time of receipt*. But this doesn’t tell you if the key was expired *at the time of signing*. Only by retrieving the DNS record from the exact moment the message was sent can you verify that the key was still valid then.

The real danger: key expiry without detection

The key’s expiry date and the email’s sending time are independent. You could send a message today with a key that expired yesterday. The DNS record might still look valid, and the key might even be in use—but the signature fails validation if the server checks the t= timestamp and finds it in the past. This is why expired keys cause rejections, even if the domain still sends mail successfully.

Major providers like Gmail and Outlook enforce strict DKIM validation. They often reject messages with expired keys outright, especially if the domain has a low sender reputation. Some providers may temporarily accept such messages—but they treat them as high-risk, increasing the chance of inbox placement failure or filtering.

This is why automated monitoring is critical. Manually checking DNS records at arbitrary times won’t catch key expiry at the time of signature. You need time-accurate DNS snapshots from the moment each email was sent.

Some tools can simulate this by capturing DNS records during real send events. MailTester’s inbox placement tests, for instance, include full message and DNS inspection at the point of delivery. These can reveal whether a DKIM key had expired at signature time.

For a deeper understanding of how DKIM works and its common failure points, refer to the official DKIM specification (RFC 6376) and resources from DMARC Analyzer.

What happens when a DKIM key expires during the email send window?

If a DKIM key expires while an email is queued or in transit, the signature becomes invalid—receiving servers check the public key in DNS at the moment of receipt, and if it's no longer valid, the DKIM check fails. This results in a "signature invalid due to expired key" error, which most email services treat as a red flag, potentially leading to rejection, filtering, or reduced sender reputation—even if the email content is legitimate.

How DKIM key expiration breaks the chain

DKIM relies on a public-private key pair. The private key signs the message at send time; the public key lives in your domain’s DNS record. Receiving servers fetch the public key from DNS when they receive the email. If the key has expired—say, due to misconfigured key rotation—the receiving server can’t verify the signature.

This isn’t an issue with the email itself. The server didn’t reject it for spam or policy, but because the cryptographic proof is missing. The error usually appears in DMARC reports as “key not found” or “signature invalid due to expired key,” even if the key was present at the time of signing.

Why one failed DKIM check matters

Most email providers treat failed DKIM as a strong signal of misconfiguration or compromise. While a single failure won’t instantly blacklist a sender, repeated or unexplained failures degrade sender reputation. According to industry standards, a consistent drop in verification success rates correlates with lower inbox placement over time.

DMARC policies that enforce strict checks (p=reject) will block messages with failed DKIM, even if SPF passes. This happens because the receiving server sees a failed cryptographic validation and has no reason to trust the message originated from your domain.

If you’re managing bulk sends, ensure your email platform or sending service handles key rotation automatically. Manual key management is error-prone and often leads to gaps in coverage. A common issue is extending the valid-to date in DNS too late, or failing to update DNS when the key expires.

Tools like the MailTester email checker can help you test whether a domain’s DNS records include a valid DKIM public key at any given time. For larger campaigns, run a bulk verification to proactively identify domains with outdated or missing DKIM records in your list. This helps prevent hard bounces and inbox placement drops due to cryptographic mismatch.

DKIM is not optional. It’s part of the foundational stack for deliverability. Keeping keys current—both in your sending system and in DNS—is non-negotiable. Even a brief expiration window during delivery can trigger rejection.

How can you prevent DKIM key expiration from breaking your email delivery?

Set automated alerts 30 days before DKIM key expiry, use DNS tools that track metadata like 't=', rotate keys before they expire, remove old keys immediately, test every outbound message, and audit your DNS zone regularly. This prevents delivery failures caused by expired signatures. DKIM verification fails silently if the key is no longer valid, even if the rest of your setup is correct.

Automate detection and act early

  • Enable alerts in your DNS or email infrastructure tooling when a DKIM key’s expiry date approaches—aim for a 30-day window.
  • Use tools that parse the 't=' tag in DKIM DNS records to track validity periods automatically. This tag specifies the key’s intended lifetime in seconds.
  • Never rely solely on manual checks. Key expiry is a silent failure point that can go unnoticed for weeks.

Rotate keys safely and verify everything

  • Generate and deploy new DKIM keys before the old ones expire. Do this well in advance to avoid overlap gaps.
  • Immediately deprecate the old key by removing it from DNS or marking it inactive. Don't leave expired keys in place—spammers often exploit outdated records.
  • Test every outgoing message through your production pipeline with a real email verification tool that checks DNS record validity. Use MailTester’s email checker to validate recipient addresses and verify that DKIM-signing domains are correctly configured and active.
  • Include DKIM key status as part of your regular DNS audit. Run quarterly scans for all domain records, flagging any with near-term or past expiry dates.

According to RFC 6376, the DKIM signature includes a timestamp field to verify key validity at the time of signing. If the key has expired, the receiving mail server rejects the message—even if the key was valid when sent.

Failure to update expired DKIM keys results in legitimate email being rejected without notification. The fix isn’t technical—it’s procedural.

Many email platforms and sending vendors now include health checks for DKIM, but these often lag behind actual DNS changes. Use a third-party tool like MailTester’s inbox placement tester to simulate end-user delivery and confirm that signed messages pass authentication steps.

What’s the connection between DKIM key freshness and inbox placement?

DKIM signatures are a core part of how major inbox providers like Gmail and Yahoo verify sender authenticity. When your DKIM key expires at the time of signature, the validation fails — and repeated failures signal technical instability, leading to reduced inbox placement, even if your content is clean. You might still send, but your messages are far more likely to land in spam or be throttled.

DKIM validates trust, not just legitimacy

Mail providers don't just check if a DKIM signature exists — they check if it’s valid and consistently delivered. A clean history of valid signatures builds sender reputation over time. Every failed signature, especially one from an expired key, erodes that trust. Receiving services like Gmail use this as input for their behavioral scoring systems, meaning inconsistent authentication can trigger filtering even without a hard bounce.

Let’s be clear: it’s not just about one failed message. A single expired key in a high-volume campaign can cause temporary delivery blocks. Providers may rate-limit or delay messages from senders they see as unreliable — not because of content, but due to technical mismanagement. This isn’t theoretical. The DMARC implementation reports show that senders with recurring authentication failures are far more likely to be flagged in aggregate abuse patterns.

Recovery is slower when keys expire frequently

Once a sender shows intermittent key validity, recovering inbox placement takes longer. Spam filters assign higher weights to senders who appear unstable, and the path back to deliverability is nonlinear. Even after fixing the expired key, the system may take days or weeks to re-evaluate your risk profile — especially if multiple expirations occurred in rapid succession.

Many senders assume that as long as their email gets delivered, they’re fine. But authentication is invisible until it fails. That’s why consistent, automated key rotation is a non-negotiable part of reliable email delivery. Tools that alert you before a key expires or monitor your DNS setup for inconsistencies can prevent these issues before they impact your audience.

If you're managing bulk sends and want to catch technical red flags early — like expired keys, poor header alignment, or misconfigured domains — you can test your list for valid, trustworthy addresses before sending with MailTester’s bulk verification. It runs checks like SPF, DKIM, and MX consistency in real-time, helping you avoid delivery failures caused by expired or broken authentication.

How to verify DKIM is working at time of send — real-time testing

Send a test email to a MailTester inbox, then check the full headers. Look for the DKIM-Signature header and compare its t= timestamp to the one in your DNS record. If the signature’s timestamp is before the DNS record’s expiry, the key was valid when the message was sent. If not, your email was signed with an expired key — a surefire reason for rejection. This real-time test confirms whether your DKIM setup is active at delivery time.

Step-by-step verification process

  1. Send a test message to a MailTester inbox. Use a real sending environment — not a test tool — to simulate actual outbound mail. This ensures you’re checking the actual DKIM signing behavior, not just a sandbox.
  2. Fetch the full email headers from the delivered message. MailTester retains and exposes the original headers of every message sent to its inbox. Use a tool like MXToolbox Header Analyzer or your email client’s "Show original" feature to access them.
  3. Locate the DKIM-Signature header. It appears in the email’s header section, usually near the top. It includes a t= field that encodes the timestamp when the signature was created.
  4. Extract the t= value from the signature. This timestamp is in Unix time format — a number of seconds since January 1, 1970. Note this value down.
  5. Check the corresponding DKIM DNS record for your domain. Query your DNS (e.g., using DNSSEC Validator) for the DKIM selector record, which includes a t= field indicating when the key expires.
  6. Compare the two timestamps. If the header’s t= is earlier than the DNS record’s t=, the key was valid when the email was sent. If it’s later, the key had already expired — and your email likely failed rejection due to an expired signature.

Why this matters at scale

DKIM signatures are only effective if the key is valid at the moment of signing. A key that expires during the transmission window — especially in long queue systems or delayed sends — will result in a failed signature check, leading to rejection even if the sender is legitimate.

For teams using automated senders, bulk email platforms, or third-party ESPs, this test verifies that DNS records are correctly published and that the sending system doesn’t misalign time zones or timing expectations. It’s not enough to check DNS once; you must validate real-time behavior.

You can run this test at any time, across any sending system. For teams managing large lists, automate it through the MailTester Verification API to ensure every sender’s DKIM chain is sound — before or during campaign delivery.

MailTester’s real-time verification API checks email addresses and validates DNS records—including DKIM key timing—so you catch expired or misconfigured keys before they cause bounces or rejections. It identifies addresses that might be sending from outdated or legacy DKIM systems, and inbox-placement testing confirms whether emails land in the inbox, not spam, even with weak or outdated DKIM signatures. This helps you catch and fix issues before they impact deliverability.

Real-time validation catches expired DKIM keys early

DKIM keys must be valid at the time of signature. If a key has expired or is misaligned with the selector in the DNS record, the receiving server rejects the email—even if the address is otherwise valid. Our verification API checks the full DNS chain, including the current validity of DKIM public keys, so you can spot these issues before sending. Let’s say your system auto-generates keys every 90 days—our API can confirm that the key in use matches what’s published. If not, you know immediately.

DNS records are often static, but keys rotate. A key that was valid during list signup might be expired by the time you send. MailTester’s bulk verification scans large lists for such drift, flagging addresses that may be tied to outdated or expired signing keys. This is especially useful if you’ve imported old lists or rely on third-party systems that don’t manage key rotation.

Inbox placement reveals real-world impact

Even if a DKIM key is technically present, weak or poorly managed key timing can still lead to spam filtering. That’s why we include inbox-placement testing: you send a test email through our system, and we deliver it to known inbox providers like Gmail, Outlook, and Apple Mail. If the email lands in spam despite passing syntax checks, DKIM may be part of the issue—even if the key is present.

Our AI assistant scans verification results for patterns like mismatched key selectors, outdated key ages, or inconsistent signing domains. It flags anomalies and suggests fixes—like regenerating keys, updating DNS records, or auditing integration workflows. It doesn't store or manage your keys; instead, it gives you the data to act.

For more details on how we test deliverability, [run a test on your sender setup](https://mailtester.com/inbox-tester/). If you're validating a list, [bulk verify it](https://mailtester.com/email-list-verify/) to find problematic addresses early. The system doesn’t replace your email infrastructure—but it prevents failures before they occur.

Why DNS record inspection alone isn’t enough to prevent rejection

You can have a valid DKIM record in DNS, but if the private key used to sign the email expired last month, the signature still fails—regardless of how far in the future the record’s t= timestamp claims it’s valid. DNS checks don’t verify whether the actual signing key was still active at the moment the email was sent.

The illusion of safety in DNS

Many teams assume that if a DKIM record is present and syntactically correct, the key is safe to use. That’s not true. The t= tag in a DKIM record specifies an expiry date, but it’s not enforced by the receiving server. It’s a hint—nothing more. You might have a t=1700000000 tag (about 2023), and the record stays in DNS for years. But if your signing key was rotated in 2023, any message sent today using that old key will fail validation—even if DNS says it’s still valid.

No email service validates against when the key was created. They only check if the key was still valid at the time the signature was generated. So if the key expired on January 1, 2024, and you sent a message in June 2024, the signature fails no matter what your DNS says. It’s like having a valid passport with a future expiration date—but using it after the visa was revoked.

Legacy keys linger in DNS, but don’t help you at send time

Some organizations keep old DKIM keys in DNS for years to maintain traceability or for compliance. That’s fine for auditing—but it doesn’t stop new messages from failing if they use an expired private key. The email server doesn’t know the key was retired. It only knows the signature’s time window has passed.

That’s why relying only on DNS record inspection is fragile. It gives a false sense of security. You may think everything’s fine because the record is “there.” But the real risk—expired keys—is invisible unless you validate signing activity at the moment of send.

For example, the DKIM specification defines how signatures are verified, but leaves the key rotation process to the sender. It doesn’t enforce real-time validation or key lifecycle tracking. Without monitoring, you’re sending blind.

Let’s be clear: having a long-lived DNS record doesn’t mean your keys are safe. The only way to prevent rejection due to expired DKIM keys is to verify the actual signing state at send time. That means checking not just DNS, but the current validity of the private key used.

How to audit your domain’s DKIM key lifecycle

If your DKIM signature uses an expired key at time of sending, the receiving server will reject the email. Use DNS records to check your key expiration timestamps, compare them to your sending window, and validate with real deliveries before sending to live lists. Let's walk through the steps.

1. Export your current DKIM records from your DNS provider

Log into your DNS management dashboard — whether it's Cloudflare, AWS Route 53, or a third-party provider — and copy the full TXT records for your DKIM selectors (e.g., default._domainkey.yourdomain.com). These records contain the public key and metadata like expiration.

2. Extract the 't=' expiration field from each key record

DKIM keys include a timestamp field marked with t=. Look for this in the raw TXT value (e.g., t=1705020600). Convert the timestamp to a human-readable date using an online Unix timestamp converter. This tells you exactly when the key is set to expire.

3. Compare these timestamps against your email sending patterns

Check if any DKIM keys expired in the last 30 days or are scheduled to expire within the next 30. If you send regularly — say, daily newsletters or marketing campaigns — a key that expired during your last send window is a likely cause of rejection. This alignment is why timing matters: a valid key at the time of generation must still be valid at delivery.

4. Flag expired or soon-to-expire keys

Mark any keys where the expiry falls within the sending period. For example, if you sent emails on January 5 and your key expired on January 4, it failed at time of signature. Even minor gaps can trigger rejection.

5. Validate with real-time delivery checks

Use MailTester’s bulk verification to send test messages to real addresses. The tool checks whether DKIM passes at time of delivery in an actual email path, not just in a static DNS check. This confirms whether the key is live during transit.

DKIM is not a one-time setup. Expiry timing must match sending frequency. An RFC 6376-compliant system [RFC 6376] expects valid keys at time of signature. Misalignment means no validation — even with correct DNS, a expired key fails silently at the server level.

Use inbox placement testing to verify your deliverability after key rotation. It simulates real delivery paths across inboxes and identifies blocking behavior early. This is the only way to confirm your keys are not just present — but actively working when they matter most.

An expired DKIM key at time of signature silently breaks email authentication. No bounce. No alert. Just failed delivery and a damaged sender reputation.

This isn’t a flaw in email protocols—it’s a gap in operational oversight. Keys must be active, rotated, and verified in real time, not assumed to be working.

How to stay ahead

  • Verify DNS records (SPF, DKIM, DMARC) before sending.
  • Test deliverability across inboxes and devices.
  • Use tools that inspect sending behavior and DNS state together.

MailTester’s real-time verification and inbox-placement testing expose these hidden risks before they cost you deliverability.

Keep your domain’s cryptographic infrastructure active, monitored, and validated—automated checks are not optional.

Sources

Keep reading

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

Frequently asked questions

Can an expired DKIM key still be used after it expires?

Yes, but only if the key remains published in DNS and the 't=' tag is past the current time. No, if the key is removed from DNS or the timestamp is before the current time.

Does MailTester detect expired DKIM keys?

Yes — through real-time header inspection and DNS record validation during inbox-placement testing.

How often should I rotate my DKIM keys?

Every 90 to 180 days is standard. Always deprecate old keys immediately after replacement.

Can a valid DKIM signature still be rejected?

Yes — if the key is expired, the domain has no valid DNS record, or the signature is malformed.

Why do some emails fail DKIM even if the recipient accepts them?

Because some providers accept messages with failed DKIM if they pass other checks. Others mark as spam or reject outright.

Is DKIM required for email deliverability?

Not strictly required, but required for high deliverability. Major email providers use DKIM as a signal of legitimacy.

Can I use multiple DKIM keys for different mail servers?

Yes — but each key must be properly managed, documented, and rotated without overlap.

What happens if my DKIM key expires during a campaign?

All messages signed with expired keys fail validation, may be rejected or marked as spam, and can harm sender reputation.

Do all email providers validate DKIM?

Most major providers do — including Gmail, Yahoo, and Outlook. Some smaller providers may skip validation.

How do I check if my DKIM key has expired?

View the 't=' tag in your DKIM record. Compare it to the current time. If it's in the past, the key has expired.

Can I recover a campaign that failed due to expired DKIM?

Yes — but only after fixing the key and re-sending. Recovery depends on rate limits and reputation impact.

Does MailTester test DKIM signature validity at time of send?

Yes — through our inbox-placement testing and header analysis, we validate whether DKIM signatures were valid at the moment of delivery.