Fixing SMTP Relay Delay with DKIM Cache

Why Does an Expired DKIM Record Cause SMTP Relay Delay?

You send a message. It passes all checks. SPF, DKIM, DMARC — all look good. Yet it sits in the queue for 22 minutes, sometimes longer. Why?

It’s not a misconfigured server. Not a broken key. Not even a rejected signature. It’s a cached expired DKIM record — and some email gateways hold on to it for up to 48 hours.

When a DKIM selector expires, the DNS record disappears. But the gateway still sees an old, cached signature for that domain and selector. Because RFC 6376 allows servers to cache validation results, and many do — especially in cloud-based email services — the new, valid signature gets blocked until the old one expires.

This delay isn’t a failure. It’s a side effect of a system designed to reduce load by caching DNS lookups — even when that cache becomes stale.

Key takeaways

Expired DKIM records can delay email delivery for up to 48 hours due to DNS caching in email gateways.
The delay occurs even when DKIM is correctly reconfigured, because gateways wait for expired cached entries to expire.
RFC 6376 permits caching of DKIM signature validation results, which can cause relay delays if records are not refreshed or removed.

How Do Gateway Caches Handle Expired DKIM Records?

SMTP gateways like Gmail, Microsoft, and AWS SES cache DNS responses for DKIM public keys to speed up email validation and reduce load. This caching can keep outdated or expired DKIM records active for hours, sometimes up to 48, even after a domain has updated or removed the key. As a result, legitimate emails may fail verification until the cache refreshes — a delay that’s hard to predict and often invisible to senders.

The Hidden Delay in DNS Caching

When a domain updates its DKIM key or switches to a new signing system, the new public key should be available immediately. But in practice, gateways may still reference the old selector from cached DNS data. Because DNS TTLs (Time to Live) can be set high — sometimes 24 to 48 hours — the gateway won’t probe the DNS again until that interval lapses. This means valid emails sent with a new key can be delayed or silently rejected simply because the gateway is stuck on old data.

Even if the key is truly invalid or has expired, the caching behavior doesn’t know. It only knows what it downloaded last. The system doesn’t revalidate unless the TTL resets. This is why a domain that renewed its DKIM key last week may still encounter deliverability issues today.

Why This Matters During Key Rotation or Switches

It’s common during migrations or key renewals to forget about the gateway cache. You update the DNS zone, set up a new signing system, and assume everything’s working — but it’s not. The SMTP gateway remains unaware for up to two days. If you're sending transactional or time-sensitive emails during this window, you’ll see inconsistent results: some users get emails, others don’t, and the cause is often hidden from logs.

There’s no universal standard for how long gateways hold onto DKIM records. It varies by provider and their internal policies. What’s known is that this delay is real and documented in industry discussions and technical forums. You can confirm this behavior by using tools that simulate DNS lookup timing, and by testing with providers like MxToolbox or Google Public DNS to observe TTLs in action.

Using a real-time email verification service like MailTester’s email checker helps you identify these issues before they affect your send rate. It can flag whether a domain’s DKIM record is stale, missing, or returning outdated data — giving you a chance to act before deliverability problems emerge. The key is not just updating records, but ensuring they’re seen and accepted in a timely way.

Can You Detect Faulty DKIM Records Before They Cause Delivery Delays?

Yes — you can detect expired or inactive DKIM records before they trigger SMTP relay delays, but only if you verify the public key is not only present in DNS but also currently active, correctly aligned with your domain’s signing setup, and not expired. A simple DNS lookup won’t catch this; you need to validate the key’s real-world usability.

Why DNS Checks Alone Fall Short

Many legacy tools check only for the existence of a DKIM record. That’s not enough. A record may still be in DNS but have expired, been replaced, or been signed with a key that no longer matches your current configuration. These mismatches cause SPF/DKIM alignment failures, which can lead to delivery delays or outright rejections — especially when gateways cache outdated results.

Gateways like Microsoft 365 or Gmail rely on DNS lookups and cache them for hours to weeks. If your DKIM key expires and isn’t updated in time, the cached version is still used, and your mail is marked as untrusted. This delay isn’t because of your sending rate or content — it’s because the cryptographic verification no longer matches.

How to Catch It Early

Let’s be clear: you can’t rely on manual DNS checks or basic tools that only confirm existence. You need active validation. The correct approach is to verify that the DKIM public key is both published and currently in use — meaning it matches the private key your mail server is using to sign messages in real time.

This validation involves checking the key’s expiration date (if it’s time-bound), its algorithm and selector, and its alignment with the sending domain. If you’re using automated email systems, this becomes part of your pre-send verification process. Tools that only tell you “record found” don’t help here.

MailTester’s real-time verification API and bulk verification tools include these checks as part of their core process. They don’t just look for a record — they test whether it can be validated in practice, including whether it’s expired or misaligned. You can use bulk verification to check large lists, or the API to validate addresses before they ever reach your outbound pipeline.

As outlined in RFC 6376 (the DKIM standard), domain owners are responsible for ensuring their public key remains valid. This isn’t just a compliance step — it’s a deliverability requirement. Delayed deliveries, poor inbox placement, and sender reputation damage often trace back to overlooked cryptographic alignment.

What’s the Real-Time Fix for Expired DKIM Records in Cache?

Expired DKIM records in gateways’ caches cause SMTP relay delays because receiving servers validate signatures using stale DNS data. The only real-time fix is to verify your sender domain’s full email infrastructure—including active DKIM, SPF, and DMARC records—before sending. This prevents messages from being delayed or blocked due to cached invalid keys, even if the DNS has since been updated.

How to Catch Stale DKIM Records Before They Break Delivery

Don’t rely on DNS checks alone—many gateways cache records for hours or days, even if they’re expired or invalid.
Validate your sender domain’s complete email infrastructure (DKIM, SPF, DMARC) in real time, not just the recipient address.
Use the MailTester API to run a live check on your domain’s email setup just before sending mail—this detects stale or missing DKIM keys before they trigger relay delays.
Verify both the sending domain and the specific subdomain used in your mail (e.g., mail.yourcompany.com)—some misconfigured setups only fail under specific paths.
Check sender reputation and domain status, not just syntax. Even valid syntax can fail if the domain is blocked or has a poor deliverability history.
Integrate verification into your send flow—automate checks before sending through tools like Mailchimp, HubSpot, Klaviyo, or SendGrid via our integrations.

Why Real-Time Checks Prevent Cache-Based Delays

When a gateways cache an expired DKIM record, it will reject or delay messages—even if the domain has updated DNS records. This happens because DNS TTLs often mean changes take time to propagate. But caching policies are aggressive. According to RFC 6376 (DKIM), receivers are expected to validate signatures using the current DNS records—but in practice, many systems use cached data, especially when performance is prioritized over freshness.

That’s why pre-sending checks matter. You’re not just validating addresses—you’re testing the entire mail path. The MailTester real-time verification API gives you a full snapshot of your sender domain’s health: is your DKIM key valid? Is the selector correct? Has the record been updated? Are any TXT records misconfigured?

Fixing this at the source means your messages never hit a gateway with a cached error. No retries. No delays. No bounce chains. You’re not waiting for DNS to refresh—you’re ensuring it’s right the first time.

How MailTester Checks for Stale DKIM Records

MailTester prevents SMTP relay delays caused by expired DKIM records by performing a real-time DNS lookup to verify the current existence, validity, and alignment of the DKIM public key. It checks whether the selector is active, correctly published under the domain’s subdomain (e.g. selector._domainkey.example.com), and matches the domain’s current signing policy—flagging stale or missing keys as 'risky' or 'invalid' to protect your sender reputation.

The Detection Process

Initiate a real DNS query to fetch the DKIM record under the expected subdomain (e.g. default._domainkey.example.com). This bypasses cached or stale responses by hitting the authoritative DNS server directly.
Validate the key’s expiration by checking the expires tag in the DKIM record. If the key has passed its validity window, MailTester flags it as expired or risky—commonly seen in legacy or mismanaged configurations.
Confirm selector alignment with the domain’s current signing policy. If a domain now uses a different selector (e.g. mail1 instead of default), but the old one remains active, it creates a misalignment that can cause relay delays or rejection.
Check DNS record syntax and format against RFC 6376. Malformed records or missing required fields (like DKIM-Signature) are rejected as invalid, preventing false positives from outdated or incorrectly published keys.
Evaluate signal strength using multiple data points: key age, DNS TTL, historical sender behavior, and domain reputation. A missing key with strong historical alignment may be marked 'risky' rather than 'invalid'—allowing you to assess the risk before sending.

Why It Matters for Deliverability

Stale DKIM records aren’t just technical clutter—they’re a direct path to sender reputation damage. When a gateway’s DNS cache holds an expired key, it may reject messages even if the sender is legitimate, causing SMTP relay delays or outright rejection.

The 5 steps described in “The Detection Process”, in order.

This is why RFC 6376 mandates timely key rotation and proper DNS publication. MailTester automates this validation in real time, so you’re not depending on outdated or misconfigured gateway caches.

Unlike some tools that rely on cached or historical data, MailTester uses live DNS lookups to detect issues before they impact delivery. You can test your domains or verify email lists at scale using our bulk verification tool, or integrate the real-time API to validate sender infrastructure on every send.

Why Verifying the Sender Infrastructure Matters More Than the Email Address

You can have a valid, well-formatted email address, but if the sender’s domain lacks a valid DKIM record or has a misconfigured SPF/DKIM setup, your email will still delay or fail in transit—often silently. A single expired or missing DNS record can break the entire delivery chain, regardless of how clean your list looks. This isn’t a bounce—it’s a delivery failure rooted in infrastructure.

The Hidden Layer: DNS Records That Control Delivery

DKIM isn’t just a formality—it’s cryptographic proof that your message hasn’t been altered in transit. When a receiving server checks DKIM, it queries your domain’s DNS. If the record is expired or misconfigured, the server can’t verify authenticity. Even if the email address is real, the mail server may queue or reject the message.

Many providers rely on cached DNS records to speed up mailbox checks. If a DKIM record expired, that cached version might persist for days—leading to delays that look like technical glitches. This is especially common with bulk senders who assume a valid address means a valid delivery path.

Verifying the Full Stack Prevents Silent Failures

An email list cleanup removes invalid addresses—but it can’t fix a domain that’s misconfigured at the infrastructure level. A valid address still fails if SPF, DKIM, or DMARC aren’t properly set. This is why verifying only the address is insufficient. You’re testing the wrong thing.

MailTester’s bulk verification and real-time API check not just the address—but the full sender stack. This includes parsing DNS records, validating SPF, checking DKIM signatures, and assessing DMARC policy enforcement. It’s one of the few tools that goes beyond syntax and deliverability, exposing configuration risks before they cause delays.

For example, a domain with a valid email address but expired DKIM records can be flagged as “risky” or “delayed” instead of “valid.” This avoids sending to recipients that will eventually get blocked or quarantined—often days after delivery.

Industry-standard practices (like RFC 6376 for DKIM or RFC 7483 for DMARC) require strict alignment. Ignoring them means losing inbox placement timing and harming sender reputation. No list hygiene can compensate for poor authentication setup. Even well-maintained lists will suffer from poor deliverability if sender infrastructure is flawed. RFC 6376 and RFC 7483 outline these mechanisms explicitly.

That’s why you should test not just whether an email exists—but whether the entire sending infrastructure is capable of delivering it. If you’re sending to 10,000 people and 20% are delayed due to expired DKIM records, you’re losing engagement and hurting sender reputation. Use bulk email verification to catch these hidden issues before they affect your results.

What Happens When You Send to a Domain with Cached Invalid DKIM?

When you send to a domain with a cached invalid DKIM record, the receiving SMTP gateway may accept the message but delay delivery for 12 to 48 hours while it re-validates the record. During this time, your email sits in a holding state, leading to missed engagement windows and elevated time-to-delivery metrics. These delays often trigger outbound routing alarms and can prompt ESPs to throttle your sending rates if they detect consistent slowness.

How Cached DKIM Records Impact Delivery Timing

Even if your email passes initial SMTP handshake checks, a stale or invalid DKIM record cached by the recipient's gateway can cause a hard delay. The gateway won’t accept the message outright—it will tentatively accept it, then queue it for revalidation. This process is not instant and can take up to two days, depending on how aggressively the receiving server updates its DNS cache.

This delay isn’t just about a slow inbox. It’s about reputation. Most ESPs track delivery speed as part of sender health. Consistently slow delivery windows signal instability, which can trigger throttling—even if your email content or authentication is otherwise solid. The longer the delay, the lower the likelihood of your email being seen as timely or relevant.

Why This Delays Real-Time Engagement

For time-sensitive campaigns—like password resets, transaction confirmations, or onboarding flows—delays beyond 12 hours drastically reduce the probability of user action. Email metrics such as open and click rates begin to degrade because users have already moved on. Some ESPs use these drop-offs to classify senders as low-quality, which further degrades future inbox placement.

Let’s be clear: DKIM validation is not a one-time check. It’s a dynamic process, and the caching behavior of gateways is an unspoken factor in deliverability. If your email sends to domains with expired or misconfigured DKIM, you’re not failing authentication—you’re triggering a silent, recurring delay that erodes your sender reputation over time.

Tools like MailTester’s bulk verification can detect invalid or outdated DKIM configurations across your list before you send, helping avoid this class of delay entirely. By identifying addresses with stale DNS records early, you can clean your list or flag domains for follow-up. Proper validation reduces the risk of sending to domains with known DNS issues while keeping your delivery speed within acceptable ranges.

Best Practices to Avoid DKIM Cache Delays

Expire DKIM records properly by rotating selectors on key updates, announce changes via DNS TXT notifications, use real-time verification to catch issues early, and audit DNS weekly. These steps prevent gateways from serving outdated keys from cache, which can delay SMTP relay and hurt deliverability.

Prevent cache staleness with proactive DNS hygiene

Never reuse a DKIM selector for longer than your key rotation period—rotate it every 90 days or when updating keys.
When updating DKIM records, immediately add a DNS TXT record with a clear announcement (e.g., "Key rotation in progress: new selector active") to help gateways recognize and refresh cached records faster.
Check for misaligned or expired DKIM records weekly using a tool like MXToolbox or your DNS provider’s inspector; delayed detection leads to relay timeouts.

Validate sender health before sending

Use a real-time email verification API to validate domains and addresses before sending. This catches expired or misconfigured records before they hit an SMTP relay.
Run inbox placement tests with a service like MailTester’s inbox tester to validate end-to-end deliverability, including how gateways handle DKIM updates.
Ensure your SPF and DKIM records align across your domain setup. Mismatches cause gateways to reject messages, even if the DKIM signature is technically valid.
Monitor sender reputation signals: a high bounce rate or delayed delivery can indicate caching issues or DNS misconfigurations.

Gateways cache DNS records for up to 24 hours—sometimes longer. If the record is expired or stale, even a valid signature won’t help. Proactive DNS management is how you beat the delay.

DKIM is only effective if the public key is current and accessible. A delayed cache refresh turns a valid message into one that’s misidentified. Treat DNS updates like time-sensitive system deployments. Every day you wait to rotate or announce a key, you risk blocking messages across multiple recipients.

Let’s be clear: cache delays don’t just slow things down—they trigger rejections. Once a gateway caches the expired signature, it will reject future mail until the TTL refreshes. The fix isn’t in your code or server logs—it’s in your DNS process. Make rotation, visibility, and validation part of your workflow.

Use MailTester’s email checker to test individual addresses before bulk sends. Test your domain’s entire email stack with bulk verification, and automate checks with the real-time API—all without spending credits they expire. This is not about perfection. It’s about catching the 5% of bad sends before they become 50%. That’s how you stay in inbox.

How MailTester Integrates with SMTP and ESPs to Prevent These Issues

You can catch expired DKIM records and other sender infrastructure flaws before they cause SMTP relay delays by verifying email addresses in real time through MailTester’s API. It checks current DNS records—including DKIM, SPF alignment, and DMARC policies—so that domains with outdated or misconfigured security setups are flagged early, preventing failed delivery attempts and maintaining sender reputation.

Prevent Failures at the Gateway with Early Validation

When a sending domain’s DKIM records expire, even minor caching delays in the receiving gateway can result in hard bounces or message rejection—especially on strict inbound filters. MailTester’s real-time API checks these records against current DNS data before your email is sent. This lets you fix misconfigurations during list hygiene, not after delivery fails.

Let’s say your campaign uses SendGrid. Instead of sending to 10,000 contacts blindly, you run them through MailTester’s API first. The tool identifies addresses with expired DKIM records or invalid SPF alignment. You can clean the list before sending, avoiding unnecessary strain on your sender reputation and reducing the risk of being marked as spam by gateways like Google or Microsoft.

This approach is how industry-standard tools like DKIM RFC 6376 and SPF RFC 7052 work in practice—only with live verification instead of static checks.

Seamless Integration with Your Current Tools

MailTester integrates directly with SendGrid, Mailchimp, Klaviyo, and HubSpot via built-in connectors. You don’t need to rewrite workflows. After setting up the integration, each new list or campaign is automatically verified against real-time DNS and deliverability signals.

The verdicts returned—valid, invalid, catch-all, or risky—reflect the current state of the recipient’s domain. For example, a "risky" status may indicate a catch-all setup or degraded DKIM setup, both of which impact inbox placement. You can choose to exclude such addresses or flag them for review before release.

These checks are fast—typically under 200 milliseconds per address. They help you avoid the cost of wasted sends and unnecessary relay delays caused by outdated DNS records.

See how it works in practice with our real-time verification API, or check your list with zero risk using our bulk verification tool.

A Note on Misleading DKIM Verifiers – Don’t Rely on Basic Checks

Many DKIM verifiers only check if a TXT record exists—never whether it’s active, valid, or currently in use. That’s why you can see a "valid" DKIM record that’s actually expired or never used, leading to false confidence and delayed email delivery. Real-time verification is the only way to catch this.

Why a TXT Record Isn’t Enough

Just because a DKIM TXT record appears in DNS doesn’t mean it’s authoritative or active. Old keys linger in caches, especially in gateways or email providers that rely on cached DNS lookups. A stale record can pass basic checks but fail signature validation when the email is actually sent.

Let’s say your email server signs messages using a key that expired three months ago. A basic verifier sees a TXT record and says “OK.” But when the message hits the receiving gateway, the signature fails. The recipient’s system logs the failure, possibly marking your sender reputation as inconsistent or unreliable. That’s the delay you’re trying to fix.

How MailTester Avoids These Pitfalls

We don’t just scan DNS. Our 98.9% accuracy comes from active validation: we test the actual signing behavior using real-world sending patterns. This means we catch expired, unused, or misconfigured keys before they cause delivery problems.

For example, we verify that the public key in the TXT record correctly validates the signature in a test message. This prevents you from relying on outdated or inactive records during bulk sending. It’s not just about DNS presence—it’s about whether the key actually works when it matters.

This is why using MailTester’s bulk verification (email list verification) or real-time API (API email checker) prevents SMTP relay delays caused by expired DKIM records in gateway caches. It’s not just hygiene—it’s proactive assurance.

The industry standard for email authentication is defined in RFC 6376, which outlines how DKIM signatures must be validated. But many tools don’t follow the full spec—only the basics. That gap is where your sends break.

Final Step: Test Your Sender Readiness Before Every Campaign

SMTP relay delays caused by expired DKIM records in gateway cache are preventable. Don’t assume your DNS records are up to date — they often aren’t, especially after infrastructure changes or domain rollouts.

Use MailTester to validate domains and email addresses before each campaign. The tool checks for expired DKIM records, catch-all setups, and other deliverability risks in real time.

Run 100 free verifications to test your workflow without commitment.
Credits never expire, so you can build a consistent verification loop without urgency.
This step removes caching delays and improves inbox placement consistency across major inboxes.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
52.1% of the world's top 1.8 million domains (937,931 domains) now publish a valid DMARC record, up from 29.1% in 2023. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)

Keep reading

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

Frequently asked questions

Can a stale DKIM record cause an email to be rejected?

No — it usually causes a delay, not rejection. The gateway accepts the message but waits until the cached record expires before validating the new one.

How long does a gateway cache a DKIM record?

Typically between 12 and 48 hours, depending on the provider. This is why outdated records can block delivery for days.

Does SPF check for expired DKIM records?

No. SPF only validates sender address alignment. It does not detect DKIM key expiration or caching issues.

Can I clear the gateway cache manually?

No — only the receiving provider can clear their cache. You must ensure your key is active and properly published.

How does MailTester detect expired DKIM records?

It performs a live DNS check and validates that the key is currently published, active, and aligned with the domain's signing policy.

Do DKIM record updates cause immediate delivery changes?

Not always. If the receiving gateway has cached the old record, delivery may still be delayed until the cache expires.

Should I verify domains or just email addresses?

Both — but domain verification prevents delays caused by infrastructure faults like expired DKIM, which email-only checks miss.

What's the difference between a 'risky' and 'invalid' verdict?

A 'risky' verdict indicates the domain may be configured incorrectly, like with a stale DKIM record. An 'invalid' verdict means the address or domain is unverifiable.

Can MailTester help with DMARC policy issues?

Yes — it checks DMARC policy existence, alignment, and validity as part of its sender infrastructure verification.

Does MailTester work with SendGrid and Mailchimp?

Yes — it integrates directly with SendGrid, Mailchimp, Klaviyo, and HubSpot to verify domains and email addresses in real time.