DKIM Signature Expired (Clock Skew and x= / z= Bounds)
DKIM signatures can include timestamp hints: signers set issuance time (`t=`) and may cap validity with `x=` relative to signing time. When clocks disagree, transport delays stretch, or intermediaries strip Date headers, receivers may treat signatures as stale. Mailing lists that hold messages for moderation exacerbate the window. Unlike body-hash failures, expiry issues spike suddenly when NTP drift crosses a threshold or when a mailbag release bursts old messages. The DNS key can be perfect while DKIM still fails purely on temporal policy. Many issues come down to a missing DKIM record or a selector mismatch in DNS.
Updated for 2026 to reflect current Gmail, Outlook, and Yahoo behavior.
If signatures fail, check the DKIM selector troubleshooting guide.
Learn the bigger picture in our Email Authentication Explained guide and compare SPF vs DKIM vs DMARC to understand how these protocols work together.
Quick answer
- t= is seconds since epoch in the signature header.
- x= sets an explicit expiry; omitting it avoids artificial windows.
- Greylisting plus retry can push mail past tight custom expiries.
- Some appliances rewrite Date, invalidating verification assumptions.
One-Minute Fix
Synchronise NTP on every signing MTA, widen or remove overly aggressive x= windows unless you have a security reason, and confirm Date headers survive your pipeline so receivers can reconcile signing time sensibly.
t=1735689600; x=1735776000;If moderation can exceed x−t seconds, signatures expire before delivery finishes.
Run free checkFree live DNS check. No signup required.
Wrong vs correct setup
Aggressive expiry
x=t+300 # five-minute lifetime on slow listsShort expiries break legitimate delayed delivery paths even without malice.
Balanced policy
Default platform lifetimes + stable clocks + accurate Date headers.Let the signer’s defaults apply unless you have threat-driven reasons to tighten.
Why expiry checks fire
Receivers defend against replay. They compare signing timestamps to receipt time, DNS TTL, and internal heuristics. Skewed infra clocks break the contract immediately. In practice it usually traces back to a missing selector or an invalid DKIM key in DNS.
Operational symptoms
- Random subset failures correlated with delayed queues.
- Passes inside LAN tests, failures on real internet paths.
- Forensic spikes after daylight-saving changeovers on poorly patched boxes.
- Archive re-injection workflows failing signature replay rules.
Deliverability insight
Short-lived failures often coincide with bulk sends because volume exacerbates queueing variance—watch for expiry alongside reputation noise. Providers tend to trust domains with a stable DKIM record and clean DKIM signatures far more than those with intermittent failures.
Common causes
- Hypervisors without NTP discipline.
- Custom signer plugins injecting minute-scale x= windows.
- Moderation queues in highly regulated inboxes.
- Manual clock rollbacks during incident response.
What we checked
Static DKIM DNS validation cannot see header timestamps. Provide full message headers when expiry is suspected so we can correlate t= with real arrival times.
Live DNS lookup. No login. No saved domains. No tracking.
FAQ
Should I always remove x=?
Only if business requirements allow. Security-sensitive streams sometimes keep tight expiries; then fix moderation latency instead of weakening crypto policy.
Does Gmail show the reason as expired?
Diagnostics vary; Authentication-Results may note key related failures. Compare t=/x= with received timestamps.
Are replay attacks realistic for marketing mail?
Low, but providers still enforce sane windows. Align operational latency with signature policy.
Next steps
- Audit NTP across signing infrastructure.
- Measure worst-case hop delay for each mail flow.
- Relax x= or redesign queues breaching the window.
- Preserve Date integrity through transformations.
- Re-test after DST or infra migrations.
- Review the full troubleshooting guidance in the DKIM Hub.
- Explore sender authorization issues in the SPF Hub.
- Review alignment and policy issues in the DMARC Hub.