Why is AWS SES rejecting emails with a DKIM t= timestamp older than 1 hour?

You sent a message via AWS SES, it was authenticated with DKIM, and still got rejected. The bounce report says: “DKIM t= timestamp older than 1 hour.” Not a misconfiguration. Not a typo. It’s by design.

AWS SES enforces real-time validation of DKIM signatures. The t= tag in a DKIM signature must reflect a timestamp within the last 60 minutes. Any older, and delivery fails—no exceptions. It’s not a soft filter. It’s a hard rule.

This isn’t arbitrary. It’s a defense against replay attacks. If an attacker captured a valid DKIM-signed email, they’d need the t= timestamp to be recent to reuse it. If it’s outdated, the system rejects it outright.

Key takeaways

  • AWS SES requires the DKIM signature’s t= timestamp to be within the last 60 minutes for delivery.
  • Rejection due to t= timestamp older than 1 hour is non-negotiable and applies to all outbound messages.
  • This rule prevents replay attacks by invalidating DKIM signatures that are too old to be considered fresh.

How DKIM timestamps work in AWS SES

When AWS SES receives an email, it checks the DKIM signature’s t= timestamp. If the signature was created more than 60 minutes before receipt, the email is rejected. This rule applies whether you send via SMTP or the API, and it's enforced to prevent replay attacks. The system compares the t= value against the current time at the moment of delivery. A timestamp older than one hour fails validation, even if the rest of the DKIM signature is correct.

Why the t= timestamp matters

DKIM includes a t= field to show when the message was signed. This is a security feature—it stops attackers from resending old, valid signatures to impersonate a sender. The 60-minute window is standard across most email providers, including Google and Microsoft, and aligns with RFC 6376 (the DKIM specification).

You might see a Invalid DKIM signature: t= timestamp older than 1 hour error in SES logs. This doesn’t mean your domain is misconfigured—it means the email was signed too long ago relative to when it was delivered. This commonly happens when messages are queued for too long before sending, especially if you’re using a custom SMTP relay or delayed delivery systems.

Let’s say you generate a DKIM signature at 10:00 AM, but the message isn’t delivered until 11:03 AM. AWS SES will reject it. This isn’t about your DNS setup, SPF, or DMARC—it’s about timing. The signature is valid, but outdated.

What this means for your email flow

If you're building a system that pre-signs emails or holds messages in a queue, check your delivery timing. Any delay exceeding one hour between signing and delivery will trigger this rejection. This applies equally to API calls and SMTP submissions.

Use a verification tool to catch these flaws earlier. You can check how a sender’s infrastructure handles timing with real-world email delivery tests—like those in inbox placement testing, which simulates real recipient inboxes and catches timing and signature issues before they go live.

While you can’t bypass AWS SES's timestamp rule, you can avoid it by ensuring messages are signed close to delivery. If you're using a third-party service, verify that it doesn’t cache or delay signed messages. Also confirm your queue systems don’t introduce unnecessary delays.

For developers, using tools like the MailTester API lets you verify DKIM and delivery readiness in advance, helping catch timing issues in your automated workflows before you send.

Common causes of DKIM t= timestamp rejection

DKIM t= timestamp rejections occur when the signature’s timestamp is older than one hour from when the message was sent, violating RFC 6376. This typically happens when emails are signed too early—before delivery—due to delayed delivery pipelines, misconfigured SMTP servers, or using pre-signed templates without real-time timestamp updates. You can prevent this by ensuring DKIM signing happens as close to send time as possible.

Delayed signing in the delivery pipeline

  • Messages queued for more than 60 minutes before signing trigger t= rejections, even if the message is ultimately delivered quickly.
  • Use AWS SES’s built-in DKIM signing—don’t pre-sign emails in long-running queues or batch processors.
  • Check queueing delays in your infrastructure; a 20-minute delay in a job queue can break DKIM validity.

Pre-signed templates or early SMTP signing

  • Signing messages hours before sending (e.g., in a templating system) sets an outdated timestamp, leading to rejection.
  • Ensure any template-based system inserts the DKIM timestamp dynamically at send time—never cache or pre-sign.
  • Some SMTP servers incorrectly sign messages during message construction, long before the transport layer sends them.
  • Verify your email server or application doesn’t sign messages before handing them off to the delivery endpoint.

DKIM timestamps must reflect send time within a single hour. This is not a recommendation—it's a standard requirement defined in RFC 6376. If your system signs emails before transport, you’re likely violating the spec.

For teams using AWS SES, this often stems from misconfigurations in Lambda functions, SQS queues, or server-side mailers that generate or sign emails before triggering SES. Even with proper DKIM configuration, a misaligned clock or timestamp can break validation.

Let’s be clear: if you’re pre-generating or caching signed messages, you’re inviting rejection. The timestamp must be set at delivery time.

Want to catch these issues early? Use real-time email validation to test how your emails will perform in inbox placement before sending at scale. See how your messages actually land with inbox placement testing. It helps you verify that your DKIM, SPF, and other headers are functioning as intended under live conditions.

How to verify if your DKIM t= timestamp is within the hour

Check your sent email’s DKIM-Signature header for the t= field. Extract the Unix timestamp it contains, then compare it to the current UTC time. If the difference is over 3600 seconds (1 hour), AWS SES will reject the email. This is a strict validation window set by the DKIM spec to prevent replay attacks.

Step-by-step verification process

  1. Access the raw email header from your sent message. This is the full message source, not the visible body. You can find it in your mail client's "View Original" or "Show Raw" option.
  2. Locate the DKIM-Signature header. It typically starts with DKIM-Signature: and includes multiple fields separated by ;. Look for the t= field within it.
  3. Extract the t= value. It will be a Unix timestamp like t=1712345678;. Copy the number exactly as it appears.
  4. Compare it to the current UTC time. Use a trusted timestamp converter like Epochconverter to see when that timestamp corresponds to.
  5. Calculate the time difference. Subtract the old timestamp from the current UTC time. If the result exceeds 3600 seconds, your DKIM signature is outdated.

Why this matters: AWS SES enforces strict time windows

AWS SES validates DKIM signatures using the t= timestamp to prevent forged or replayed emails. According to RFC 6376 (the DKIM specification), the timestamp must be within a reasonable window—typically one hour—to ensure freshness.

If your system generates DKIM signatures too far in advance, or if the server clock is misaligned, the signature will fail. This often happens when sending from systems with poor time synchronization or in high-volume environments where signing logic is batched across long intervals.

Even small clock drift between your server and AWS’s systems—just a few minutes—can trigger rejection. Regular auditing of DKIM timestamps prevents these issues before they affect deliverability.

Use MailTester’s email checker to validate individual addresses and ensure your sending practices align with authentication standards. For recurring checks across large lists, try bulk verification to spot issues early and improve inbox placement.

How to fix and prevent DKIM t= timeout issues

If your AWS SES emails are rejected with a t= timestamp older than one hour, it means your DKIM signature’s timestamp was too far in the past when the receiving server validated it. This usually happens when you pre-sign emails before sending or use a third-party service that doesn’t respect the t= validity window. Fix it by ensuring DKIM signing happens at the moment of delivery using AWS SES’s built-in signature engine, never cache signed emails, and avoid long-lived signatures.

Best practices to avoid DKIM t= timeouts

  • Let AWS SES sign your emails via the API or SMTP—its built-in engine automatically sets the t= timestamp to the exact moment of delivery.
  • Never pre-sign emails and store them for later send. A DKIM signature with a fixed t= timestamp becomes invalid if sent more than an hour after signing.
  • Avoid caching signed messages in a queue or database. Even a minute delay can push the timestamp out of the valid window accepted by receivers like Gmail and Yahoo.
  • If using a third-party service to send emails, confirm it respects the t= timestamp and dynamically signs messages at the time of delivery. Some services allow pre-signing with long validity, which breaks deliverability.
  • Use tools that check real-time email deliverability and test actual inbox placement before sending at scale—these help catch timing issues early.

When third-party signing goes wrong

Some outbound email platforms allow manual or scheduled signing with fixed timestamps. That’s a common cause of t= rejection. Even if a message is technically valid, receiving servers like Google’s can reject it when t= exceeds one hour from delivery time. This is expected behavior—per RFC 6376, the t= field is a hard limit for signature validity.

For a deeper look at how email authentication works, refer to the DKIM specification in RFC 6376. It defines the t= field semantics and why timing matters for trust.

Consider using inbox placement testing to validate your full sending flow—including timing, headers, and alignment—before sending to real users. This helps catch infrastructure-level issues like delayed signing before they cause bounces or spam filtering.

Real-world example: DKIM t= rejection in a high-volume campaign

When a marketing team sent 10,000 emails via a custom SMTP relay, AWS SES rejected 92% due to DKIM timestamps older than one hour. The messages had been signed 2 hours before delivery by a legacy signing server, triggering the t= timestamp check. This caused inbox placement to drop to 41% and triggered deliverability warnings, despite valid emails.

How the DKIM t= timestamp check works in practice

Every DKIM signature includes a t= timestamp that must be within one hour of when the email is sent. AWS SES enforces this strictly — it won’t accept a signed message if the key was generated more than 60 minutes before the send. If you're using a custom SMTP relay or delayed queue system, this timing gap can slip through without notice.

Let’s say your signing server generates a DKIM signature at 10:00 a.m. and your mail server sends the email at 12:00 p.m. — that’s a 2-hour difference. Even if the rest of your authentication (SPF, DMARC) is correct, AWS SES will reject the message. The rejection reason is clear: t= timestamp older than 1 hour.

According to RFC 6376 (the standard for DKIM), the t= tag is designed to prevent replay attacks. While it’s not a hard rule for all providers, AWS SES uses it as a gatekeeper. This makes timing alignment crucial in high-volume campaigns, especially when signatures are generated separately from delivery.

Fixing the root cause: aligning signing with delivery

The team realized their legacy signing server wasn’t synchronized with their delivery pipeline. They were using a batch process that signed all emails ahead of time, not knowing the delivery time would be delayed. This isn’t a flaw in SMTP or DKIM — it’s a mismatch in workflow.

Fixing it required reworking the signing process to generate signatures just before sending. They moved signing into their delivery loop, ensuring t= was set to within 59 minutes of send time. After the change, reject rates dropped to under 5%, and inbox placement recovered to 86%. This isn’t a rare case — it’s a common failure when integrating older systems with cloud providers.

Even without automation, you can catch these risks early. Use a real-time verification tool like inbox placement testing to validate deliverability before launch, or run a bulk email list check with MailTester’s bulk verification to remove invalid or poorly authenticated addresses before sending.

How to test DKIM timestamps before sending at scale

You can avoid AWS SES DKIM t= timestamp rejections by validating that your DKIM signatures are generated within 59 minutes of sending time. Use MailTester’s real-time API to check DKIM validity at scale, run inbox-placement tests to simulate AWS SES behavior, and verify that t= timestamps in your headers are current. This prevents bounces before sending to your full list.

Step-by-step: Test DKIM timestamps before rollout

  1. Use MailTester’s real-time verification API to validate your entire send list. The API checks for valid DKIM signatures, including the t= timestamp, before you send. This catches non-compliant addresses early, reducing risk during batch sending.
  2. Run inbox-placement tests with MailTester’s inbox tester. These tests simulate real-world delivery behavior, including how AWS SES and major providers evaluate DKIM time constraints. You’ll see if messages land in the inbox, spam, or get rejected due to timestamp drift.
  3. For individual message validation, check the DKIM header output using a public tool like DKIM Validator. Paste your message header to confirm that the t= value is within the 59-minute window of the sent-at time. RFC 6376 requires this tight alignment to prevent forgery.
  4. Before full-scale rollouts, verify that all test messages have t= timestamps less than 59 minutes old. Timestamps older than one hour are rejected by AWS SES, and this rule applies even if other DKIM checks pass. Automated validation ensures compliance across thousands of sends.

Why time matters in DKIM verification

Digital signatures rely on time-based validation to prevent replay attacks. A t= value older than one hour suggests the signature may have been reused or delayed intentionally. AWS SES enforces this rule strictly. Even minor delays in your mail server’s signing process—like when processing bulk sends—can push signatures past the threshold.

Detecting timestamp issues early helps avoid sending failures and protects sender reputation. You can't rely on post-send logs alone; catching it before delivery is essential. The RFC 6376 section on signature validity outlines the exact behavior AWS SES follows.

How MailTester helps avoid DKIM t= timestamp issues

You're getting DKIM t= timestamp older than 1 hour rejections from AWS SES because your email’s DKIM signature timestamp is too far in the past. MailTester catches this before it happens by validating your domain’s full authentication setup, including DKIM, SPF, and DMARC, and simulates AWS SES’s exact header validation process. This includes checking if your DKIM t= timestamp falls within the one-hour window AWS expects.

Domain authentication checks prevent DKIM timestamp failures

DKIM’s t= timestamp must be set within the last 60 minutes when sending via AWS SES. If it's older, the signature fails validation, and the mail is rejected. MailTester checks this explicitly during domain verification. It doesn’t just confirm that DKIM is set up—it checks whether the t= value in the signature is recent enough and whether the key is correctly aligned.

Let’s say you’re using AWS SES but haven’t checked if your DKIM keys are rotating or if your email service is setting outdated timestamps. MailTester exposes that risk before your first send. It verifies your AWS SES configuration: proper CNAME records, key length, and alignment—everything that could break delivery.

Inbox-placement testing mimics real AWS SES behavior

Our inbox-placement test doesn’t just say “valid” or “invalid.” It simulates an actual AWS SES send, validating the full email chain: headers, DKIM signature, t= timestamp, and SPF alignment. The test runs across multiple email providers, confirming your messages won’t be blocked due to a stale timestamp.

Using this, you can see how your message will be handled in real environments—especially critical when running automated campaigns where a timestamp mismatch can silently sabotage delivery.

If you’re validating addresses in bulk, our bulk verification tool checks each email against live infrastructure, flagging catch-alls, disposable domains, and outdated timestamps. All data is returned with full header diagnostics, so you can see exactly where a DKIM timestamp fails.

For automated workflows, the real-time API validates large volumes with full metadata, including DKIM timestamp checks, so you can catch issues in real time—before they hit AWS SES.

DKIM timestamps matter. You can’t fix them after the fact. But you can catch the root cause early. MailTester does that, using real-world validation logic aligned with AWS SES’s strict policies. For more on how this works across standards, see the DKIM specification and AWS’s guidance on email authentication.

MailTester vs. other tools on DKIM header validation

You don’t just need to check if an email address is syntactically valid — you need to know if it will pass AWS SES’s DKIM validation, including timestamp checks. Unlike most tools, MailTester verifies DKIM signatures in full, including the t= timestamp, to predict whether SES will reject the message. It identifies expired, misconfigured, or malformed DKIM keys — a capability missing in many competitors.

Differentiation in DKIM validation depth

Let’s be honest: many tools stop at syntax and basic deliverability signals. ZeroBounce and NeverBounce scan for syntax errors and role accounts, but skip full DKIM header parsing. Kickbox and Bouncer focus on deliverability risk and typo detection — they don’t validate signature compliance. If your DKIM key is expired or the timestamp exceeds one hour (a common t= rejection in AWS SES), these tools won’t flag it. That’s why a clean syntax check doesn’t equal delivery success.

MailTester goes further. It parses the full DKIM header, including the t= field, and checks if the timestamp falls within the acceptable window. This is not just about compliance — it’s about catching real-world delivery failures before they happen. The SMTP specification (RFC 5322) and AWS SES documentation both confirm that a timestamp older than one hour triggers rejection during DKIM validation.

Tool DKIM Header Validation Timestamp (t=) Check Expired/Misconfigured Key Detection
MailTester Full header parsing with signature verification Yes — detects t= older than 1 hour Yes — identifies expirations, malformed, or missing keys
ZeroBounce Basic syntax and format validation No No
NeverBounce Primarily syntax and role account checks No No
Kickbox Deliverability risk prediction only No No
Bouncer Address format and domain reputation No No
Hunter / Emailable / MillionVerifier Limited to syntax, typo detection, or domain health No No

If you’re sending at scale via AWS SES, ignoring DKIM timestamp checks is a common reason for silent bounces. MailTester’s 98.9% accuracy includes catching these edge cases. You can test your list with full header inspection at bulk verification or validate individual addresses before sending with the email checker.

While AWS SES doesn’t provide detailed diagnostics on rejected emails, understanding the root causes — like expired DKIM keys or timestamp mismatches — is critical. Tools that only verify syntax are not enough. RFC 5322 and AWS SES's own documentation on DKIM validation confirm this requirement. Don’t assume success — verify it.

Best practices for maintaining DKIM integrity with AWS SES

When AWS SES rejects your message with a "t= timestamp older than 1 hour" error, it’s usually because the DKIM signature was generated too early or outside SES’s signing window. To prevent this, always generate DKIM signatures at send-time using AWS SES’s own SMTP or API endpoints. This ensures the timestamp is valid within the 60-minute window required by email receivers, and avoids manual signing inconsistencies that lead to rejection.

Generate DKIM signatures at send-time, not in advance

  • Never pre-sign emails with DKIM before sending through AWS SES — this breaks the timestamp validation.
  • Let AWS SES handle signing automatically when using its official APIs or SMTP interface.
  • If you’re integrating with a custom email system, ensure the signing step happens immediately before the message is handed to SES.

Use AWS SES’s SMTP or API endpoints for consistent signing

  • Stick to AWS SES’s native SMTP relay or API calls — they guarantee proper DKIM timestamping.
  • Custom sending methods (like direct SMTP to a third-party server) bypass SES’s signing logic and can result in invalid or expired t= values.
  • Use the AWS SDK or standard SMTP libraries with SES credentials to maintain predictable behavior.

Monitor logs for t= timestamp errors

  • Check Amazon CloudWatch logs for messages tagged with DKIM signature verification failed or t= timestamp older than 1 hour.
  • Monitor SES sending metrics and Bounce/Complaint events, which can point to DKIM misconfigurations.
  • Set up alerts on failed deliveries to catch timestamp-related issues early.

Test your DKIM setup regularly with inbox-placement tools

  • Use MailTester’s inbox placement tool to verify how your message lands in real inboxes, including DKIM validation.
  • It checks not just deliverability but whether your DKIM signature is recognized and timestamp-compliant.
  • Testing with tools like MailTester’s inbox tester helps catch problems before sending to a large list.
DKIM timestamps must be within one hour of message submission. The receiver will reject any signature where t= is older, even by a few minutes.

For deeper verification, run a bulk list through MailTester’s email list verification to catch invalid or high-risk addresses before they hit your SES sending pool. While AWS SES handles much of the signing logic, your setup must align with email standards — including proper header alignment and timestamp integrity. The IETF’s DKIM specification outlines timestamp requirements clearly; adherence is non-negotiable for inbox placement.

Proactive verification reduces DKIM failures and improves delivery rates

Invalid or misconfigured email addresses cause SMTP rejections, including AWS SES DKIM t= timestamp older than 1 hour errors. These bounces waste bandwidth and degrade sender reputation over time.

MailTester’s bulk list verification identifies bad addresses, catch-alls, and role accounts before you send. This reduces bounce rates and prevents your domain from being flagged by filtering systems.

Real-time API checks ensure only valid, properly configured addresses receive your messages. Inbox-placement tests confirm your messages will be accepted by AWS SES and other providers, reducing delivery risk.

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 DKIM t= timestamp mean?

The t= field in a DKIM signature is a Unix timestamp indicating when the email was signed. AWS SES requires it to be within the last 60 minutes.

Can I pre-sign an email with DKIM for later delivery?

No. Pre-signing emails with DKIM and delaying delivery beyond 60 minutes results in rejection by AWS SES due to expired t= timestamps.

How long does AWS SES wait for DKIM t= timestamps?

AWS SES accepts only DKIM signatures where the t= timestamp is within the last 60 minutes from the time of message reception.

Why does AWS SES enforce DKIM t= time limits?

To prevent abuse such as replay attacks. Expired timestamps indicate outdated messages, reducing spam risk.

Do all email providers enforce DKIM t= checks?

Not all do, but AWS SES, Google, Microsoft, and many enterprise providers apply time-based DKIM validation.

How can I test if my email’s DKIM t= is valid?

Use tools like https://dkimvalidator.com/ or extract the DKIM-Signature header and compare the t= value to current time.

Can MailTester detect DKIM t= timestamp issues?

Yes. MailTester analyzes DKIM headers during verification and can flag signatures with timestamps older than 60 minutes.

Does using AWS SES SMTP avoid t= timeouts?

Yes. AWS SES SMTP signs emails at the moment of send, ensuring t= is always within the valid window.

What happens if my DKIM t= is too old?

The email is rejected by AWS SES without delivery notification. No bounce is returned if the address is invalid.

How often should I test my DKIM setup?

Test with inbox-placement tools after setup and before large campaigns. Use real-time API checks on high-volume senders.

What’s the role of SPF and DMARC in DKIM rejection?

SPF and DMARC are independent of DKIM t=. A DKIM t= rejection happens even if SPF and DMARC are valid.

Can a catch-all email cause DKIM t= timestamp issues?

No. Catch-all addresses do not affect DKIM timestamp validation. The issue stems from the signing time, not the recipient.