A delayed message can fail a time-related DKIM check even when nobody changed its content. Diagnose the signature's time fields and the verifier's decision before rotating keys or blaming a gateway. The message Date header, signature creation time and receiver arrival time describe different events.
Read t and x correctly
In a DKIM-Signature header, t is the signature creation timestamp and x is the absolute expiration timestamp, both expressed as seconds since the Unix epoch in UTC. RFC 6376 section 3.5 formally marks both tags RECOMMENDED. They may be absent, but this allowance should not be confused with an OPTIONAL requirement level. The x value is not a duration to add to the current time. When both are present, x must be greater than t. Missing t means an unknown creation time; missing x means no signature expiration is specified by that tag. DNS TTL is a different concept and does not set x. The t tag in a DNS DKIM key record is a set of flags, not this signature timestamp.
RFC 6376 section 3.5 permits implementations to ignore a signature with a future timestamp. It also permits a signature to be considered invalid when verification is past its expiration. For the comparison, the verification time should be when the verifier's administrative domain first received the message if reliably available, otherwise the current time. This leaves implementation choices that an incident record must distinguish from a universal rejection rule.
Build a three-clock timeline
Capture the exact signature and raw receiver evidence. Convert t and x to readable UTC while retaining the original integers. Record the signer's clock, first reliable receipt time at the verifying administrative domain, and time of the diagnostic recheck. Add relevant queue delays. Do not use an untrusted Date header as proof of when a system received a message.
Illustrative scenario: a signature is created at 10:00 UTC with expiration at 12:00 UTC. The message reaches the receiver at 11:50 but is examined again at 12:15. A verifier with reliable first-receipt information may use 11:50; a later standalone tool may only have its current time. Different outcomes do not by themselves show corrupted content. The example describes the protocol's timing distinction, not a promise about a particular provider.
Distinguish clock skew from a tight window
If newly emitted signatures appear to come from the future, inspect the signer's clock synchronization and timestamp generation. If the values are sensible but mail regularly arrives after x, examine queueing, retry routes and the chosen validity interval. RFC 6376 does not prescribe a universal ideal lifetime. Set one using your actual delivery requirements and supported signer settings.
A short expiration is not a complete replay defense. RFC 6376 section 3.5 explicitly says x is not intended for that purpose. It also does not replace key protection or abuse monitoring. Removing an old public key can make delayed verification impossible independently of x, so coordinate expiration policy with key retention.
Test the repair and retain the distinction
After correcting clock or policy configuration, send new controlled messages through the slow and normal paths. Verify their timestamps and receiver results. Preserve evidence showing whether the prior failure concerned time, key availability, body hash or signature verification. Do not edit t or x on an existing signed message: those values are covered by the signature and changing them is not a repair.
Work an epoch example
Synthetic values t=1794132000 and x=1794139200 correspond to 8 November 2026 at 10:00 UTC and 12:00 UTC. Their difference is 7,200 seconds, or two hours, but x itself remains an absolute timestamp. A reliable first receipt at 11:50 is before expiration; a standalone recheck at 12:15 is after it. The verifier’s chosen reference time and permitted expiration handling explain the possible difference. By contrast, x=t violates the required ordering when both tags are present. These values illustrate arithmetic and protocol rules, not an executed mail test.
Keep a compact investigation record
Use this suggested worksheet for the route under review. It is a planning aid, not evidence of an executed test.
- Signature: original t and x values, their UTC conversions, d and selector.
- Timeline: signer clock, first reliable receipt and later recheck, with time zones.
- Finding: future timestamp, expired signature, unavailable key or another verification failure.
- Repair: supported clock or lifetime change and results from newly sent normal and delayed-path tests.