Fix DKIM Expired or Invalid in AWS SES

Why is your DKIM signature expired or invalid in AWS SES?

You sent a batch of transactional emails through AWS SES. They bounced. Or worse, they landed in spam folders. You checked your logs. Everything looked fine. But the sender domain still isn’t trusted.

Here’s the silent culprit: your DKIM signature expired. AWS SES generates a DKIM key with a 365-day lifespan by default. Once it’s up, it doesn’t renew. No alerts. No reminders. Just a quiet failure in authentication.

DKIM isn’t just a checkbox—it’s a cryptographic signature proving your email came from a legitimate source. If it’s expired or invalid, even a perfectly formatted message fails SPF and DMARC checks. That means bounces, poor deliverability, and damaged sender reputation.

Fixing it isn’t about reconfiguring your entire email pipeline. It’s about knowing the clock is ticking and acting before the next 365 days are gone.

Key takeaways

AWS SES DKIM keys expire after 365 days unless manually renewed or automatically managed through Route 53.
An expired DKIM signature causes authentication failure, leading to bounces or spam placement—even with a valid domain.
Even correct DNS records become ineffective if the private key behind DKIM is outdated.

What happens when a DKIM signature is expired or invalid?

When a DKIM signature is expired or invalid, receiving mail servers reject your emails or flag them as untrusted, even if your content is clean. This triggers authentication failures that hurt deliverability, drop inbox placement, and damage sender reputation over time. Let’s break down why this matters.

Emails get blocked or marked as spam

If the DKIM signature is expired or malformed, the receiving server can’t verify that your message came from a legitimate source. Most modern mail providers, including Gmail and Outlook, treat failed DKIM as a strong signal of potential spoofing or abuse. A failed signature means your email may be rejected outright or moved to the spam folder.

For example, RFC 6376, the standard defining DKIM, requires valid signatures and proper key rotation. If the private key used to sign the email no longer matches the public key in DNS, the signature is invalid. This alone can result in rejection, regardless of content quality.

Some providers, like Amazon SES, automatically renew DKIM keys on a rolling basis, but you still need to ensure DNS records are correctly updated. A misconfigured or outdated TXT record can leave your messages unsigned or signed with a revoked key — essentially leaving your messages vulnerable.

Inbox placement drops and trust erodes

Even if an email gets through, a consistently invalid signature hurts long-term deliverability. Mail providers track sender behavior across multiple messages. Repeated DKIM failures signal poor infrastructure, which reduces trust.

According to data from Return Path (now Validity), emails that fail authentication are 70% less likely to land in the inbox — this is not a small gap. Over time, this impacts open rates and conversion, even for messages with strong content.

You can test this in advance. Use our inbox placement test to send a sample message to major providers and see how it lands—before you send to your full list. It checks SPF, DKIM, DMARC, and content signals in one go.

Fixing a bad DKIM signature isn’t just about compliance. It’s about maintaining the foundation of trust that lets your messages reach real inboxes. A single failed signature can cost you visibility.

How to verify if your DKIM signature is expired or invalid

You can confirm if your DKIM signature is expired or invalid by checking the AWS SES console for status, validating your domain’s DKIM TXT record via a DNS lookup tool like MxToolbox, and testing delivery through a real-time verification service that includes DKIM signature validation. These steps confirm whether your signature is active, properly formatted, and not expired.

Check your DKIM status in AWS SES

Go to the AWS SES console and navigate to the Domains section under Identity Management.
Find your verified domain and check the DKIM status listed under the domain's row. A status of Active means DKIM is properly set up and currently valid.
If it shows Disabled or Failed, your DKIM key may have expired or the DNS record is misconfigured.

Validate your DKIM TXT record with a DNS tool

Use a DNS lookup tool like MxToolbox or DNSChecker.org to query your domain’s TXT records.
Look specifically for a TXT record with a name matching your DKIM selector (e.g., selector1._domainkey.yourdomain.com).
Confirm the record value matches the one AWS SES generated. An incorrect or missing value means your signature is invalid.
Check the Expiration Time of the DKIM key in the record. Expired keys don't contain a valid expiration date in the format defined in RFC 6376, and most DMARC-compliant systems will reject such signatures.

Once your DKIM key is validated, you can be confident your emails are properly signed. But validation isn’t the end—real-world deliverability depends on how receiving servers interpret your signature during delivery. Let’s check if a real email delivery confirms it works.

The 3 steps described in “Check your DKIM status in AWS SES”, in order.

The best way to be sure is to test a real email via a verification service that runs all the same checks a mail server does.

Use a service like MailTester’s bulk verification to simulate real sends and check for DKIM issues at scale. It validates not just syntax, but also signature freshness and alignment with SPF and DMARC policies. You’ll receive detailed feedback including whether the signature is expired or invalid, even before sending to thousands of customers.

What does MailTester’s DKIM validation detect that AWS doesn’t?

You might see "valid" in AWS SES, but that doesn’t mean your DKIM signature is actually working. MailTester goes beyond AWS by checking whether your DKIM record is cryptographically valid, still within its expiration date, and properly configured—catching stale, misconfigured, or missing keys that AWS doesn’t flag. That’s why sending from a domain marked “valid” in AWS can still fail in real inboxes.

DKIM validity isn’t just about existence

AWS checks if a DKIM DNS record exists—period. But it doesn't verify if the key has expired, if the signature algorithm is unsupported, or if the cryptographic hash is mismatched. A record can be syntactically correct but still no longer valid due to expiration (often set to 365 days), which breaks sender authentication silently.

Let’s say your DKIM key expired last month. AWS still reports it as "valid" because the TXT record is present. But mail servers today check the key’s validity window, and they’ll reject your message if it’s expired. MailTester detects this. It checks both the record’s existence and its current cryptographic viability, including the time-to-live (TTL) and expiration timestamp published in the record.

Failures before they hit your campaign

MailTester integrates with your domain during real-time verification, testing the full email path—including DKIM signing—before you send. You’re not relying on AWS’s limited validation after you’ve already sent. This catches misconfigurations like improper key placement, incorrect selector names, or mismatched domains in the signature header.

For example, you might have a valid DKIM record, but it’s set for mail._domainkey.example.com while your sending domain is example.com. AWS won’t warn you about this mismatch. MailTester does. It compares your DKIM configuration against the actual sending headers and fails early—before you waste sends on invalid or blocked addresses.

Understanding DKIM at the RFC level helps: RFC 6376 outlines the required structure and validation logic. It’s not enough to publish a record; it must be usable and current. Tools that only check for existence miss the full picture.

Test your DKIM setup before you send. Use the inbox placement tester to verify your setup in real mailbox environments—or run a bulk check with MailTester’s bulk verification to surface invalid or misconfigured domains in your list.

How to renew your DKIM signature in AWS SES

If your DKIM signature has expired or is invalid in AWS SES, you need to re-generate the signing keys. In the AWS SES console, select your verified domain, choose 'Re-generate DKIM tokens', and update the new DNS TXT records with your DNS provider. Wait up to 72 hours for propagation, then test the new configuration with a real email verification service to confirm it’s working.

Step-by-step: Re-generating DKIM keys in AWS SES

Go to the AWS SES console and select the domain with the expired or invalid DKIM signature. This ensures you’re updating the correct email sending identity.
Choose ‘Re-generate DKIM tokens’. AWS generates a new public-private key pair for DKIM signing. The private key stays with AWS; the public key (a TXT record) must be updated in your DNS.
Copy the new TXT record values provided in the console. You’ll need to paste these into your DNS management tool (like Route 53, Cloudflare, or GoDaddy) to replace the old records.
Update your DNS provider with the new TXT records. You can verify the change using tools like MxToolbox or dig, which check DNS propagation in real time.
Wait up to 72 hours for DNS propagation. While some networks update faster, waiting the full window ensures global consistency. Shorter wait times are common, but not guaranteed.

Verify the new configuration works

After propagation, use a trusted tool to test if your DKIM signature is now valid. MailTester’s inbox placement tool sends a test message to real inboxes and checks if DKIM passes, helping you confirm deliverability is restored. Alternatively, use the API to validate your sending setup programmatically.

DKIM is a core part of email authentication. A failed signature means most recipients reject your email as suspicious or untrusted. Re-generating the key ensures your messages continue to be accepted by major email providers like Gmail, Outlook, and Yahoo.

For context, DKIM is defined in RFC 6376, which outlines how digital signatures should be applied to email headers. Misconfiguration is common, especially when keys expire or DNS updates fail silently. Regular checks and testing prevent sudden delivery drops.

Best practices to avoid expired DKIM signatures in the future

You can prevent DKIM signature expiration in AWS SES by reviewing keys every six months, using automated verification tools, and monitoring domain status with third-party services. Proactive checks reduce send failures and maintain sender reputation. Let’s get into how.

Regular monitoring is required

Set a recurring calendar reminder every six months to review your DKIM status in the AWS SES console. Keys expire automatically; manual checks catch issues before they impact delivery.
Don’t rely on AWS SES notifications alone — they’re not always timely. A scheduled audit ensures you don’t miss a window where your domain becomes unverified.

Automate validation at scale

Use MailTester’s verification API to scan your mailing list and validate DKIM status across domains before sending. It integrates with SendGrid, Klaviyo, and others.
Test your sending infrastructure with MailTester’s inbox placement tester to see if your DKIM-signed emails land in inboxes or get filtered — especially after key changes.
Monitor domains with tools that track DKIM expiration and DNS changes, like MxToolbox or tools based on public DNS records (e.g., RFC 6376, which defines DKIM syntax and expiration behavior).
Combine automated validation with periodic manual oversight. Even the best tools can miss edge cases, especially when domains use non-standard configurations.

DKIM verification failures are a leading cause of email rejection. A single expired key can drop inbox placement by 20–30% across major providers.

DKIM alignment with SPF and DMARC is a baseline for deliverability. When one breaks, the whole chain weakens. Use the existing AWS SES tools to manage keys, but don’t treat them as a replacement for vigilance. The real defense is consistency. Check, verify, and test — every six months, at scale, in production.

Why DKIM failure often gets overlooked in email campaigns

DKIM signatures are a technical safety check in email delivery — they’re not visible to users, and when they fail, they often appear as hard bounces, not spam flags. Because you don’t see a failure message like "This email looks suspicious," you assume delivery is working. But if your DKIM key expires or is misconfigured, emails silently fail to authenticate. Without proactive checks, invalid signatures can linger for months, eroding your sender reputation and harming inbox placement, even if you’re sending to valid addresses.

The invisible layer problem

DKIM operates beneath the surface of your email workflow. It’s not a feature you monitor daily like open rates or click-throughs. When you send an email and it arrives in the inbox, you assume it worked — but that’s only half the story. The true test is whether the receiving server can verify the signature using your public key. A failed check means the email is rejected or marked as suspicious, but not always in a way that triggers immediate alert fatigue. That’s why an expired signature can go unnoticed.

Assuming once works means always works

Many teams assume that since a campaign sent successfully once, it will always work. But DKIM keys have expiration dates. Amazon SES allows you to auto-rotate keys, but if you don’t verify the new key is active, your next bulk send fails silently. This is especially risky during high-volume campaigns or automated workflows. You’re not checking if the signature is valid — just if the email sent. The result? A high bounce rate masked as "delivery issues," not authentication problems.

Even when you see a bounce, it's often misclassified. A hard bounce from a DKIM failure might appear as "address unknown" or "rejected," which leads you to clean up the list, not check your signature. The real issue — a broken authentication mechanism — remains untouched. This is why automated, real-time validation is essential.

Use a tool like MailTester’s bulk email verification to test your entire list for deliverability risks, including invalid, catch-all, disposable, and high-risk addresses. It also checks for common domain-level misconfigurations, including failed DKIM validation, helping you catch issues before they hit the inbox.

For ongoing campaigns, pair this with automated testing using the real-time verification API. These tools don’t just validate addresses — they test the full path to inbox delivery, including SPF, DKIM, and DMARC. This is how you protect your sender reputation not just today, but in the future.

As the IETF’s DKIM specification confirms, correct signature verification is mandatory for email integrity. Ignoring it is like driving without checking your brakes. Fixing DKIM isn’t a one-time task. It’s a continuous practice — especially in platforms like AWS SES where keys rotate automatically.

How to test DKIM validity in a live email delivery scenario

You can verify DKIM signature status under real-world delivery conditions by sending test emails through MailTester’s inbox placement tool. It simulates actual email delivery to Gmail, Outlook, and Yahoo, checks the full authentication stack, and reports exactly whether DKIM is expired, invalid, or missing—just as it would appear in a real inbox.

Run a live authentication check with inbox placement testing

Send a test email via MailTester’s inbox placement tester. Choose one of the major providers—Gmail, Outlook, or Yahoo—and send a message from your AWS SES setup. This mimics real delivery, not just local parsing.
Check the full authentication report. The test includes SPF, DKIM, and DMARC checks across real mail servers. You’ll get a clear pass/fail result for each, with detailed reasons for any failure.
Look specifically for DKIM status. The report will show if DKIM failed due to an expired signature, invalid format, or missing key. This is the same check that ISPs perform in production.
Validate your key’s timing and format. A mismatched timestamp, expired key, or malformed signature will show up here—even if your DNS records look correct. The tool surfaces issues that simple DNS checks miss.
Compare against industry standards. Email providers like Google and Microsoft use real-time validation based on RFC 6376 (DKIM) and RFC 7489 (DMARC). Testing in the wild ensures compliance with those standards.

Many teams assume their DKIM setup is working because DNS shows a public key. But that doesn't prove it's valid at send time. A signature can be expired, mangled, or signed with the wrong domain. Inbox placement testing catches this before you send to 10,000 customers.

The 5 steps described in “Run a live authentication check with inbox placement testing”, in order.

For example, even if your DNS TXT record is correct, AWS SES may reuse a key beyond its lifetime. The system will still send mail, but ISPs will flag it. MailTester’s live test surface this instantly.

While you can validate DKIM in isolation using tools like Spamhaus’ email validation service or MXToolbox, those don’t simulate actual delivery. Only live testing under real provider conditions reveals whether your DKIM passes in practice.

Use MailTester's inbox placement tester to send test messages through Gmail, Outlook, and Yahoo. You’ll see exactly how your DKIM performs in production—no guesswork. If the signature is expired or invalid, the report will tell you why, down to the specific error code.

What DKIM verification reveals about your sender reputation

DKIM failures aren’t just technical hiccups—they signal inconsistent authentication practices. Receiving servers see repeated failures as signs of poor sender hygiene, which directly impacts your sender reputation. Over time, this can lead to higher bounce rates, increased spam filtering, and lower inbox placement. Fixing DKIM isn’t just about compliance; it’s about rebuilding trust.

Authentication stability builds long-term trust

Consistent DKIM signing tells email providers you’re a reliable sender. Every successful verification reinforces that your infrastructure is well-managed. Major platforms like Google and Microsoft use authentication signals over time to assess sender legitimacy—flaky DKIM undermines this trust, even if individual messages still arrive.

Consider DKIM not as a one-time setup, but as ongoing proof of ongoing responsibility. If your records expire and go unrefreshed, it sends the same signal as using a fake address: you’re not invested in deliverability.

Proactive checks surface hidden risks

When DKIM fails repeatedly across a list, it’s a red flag that something is broken—either in configuration, key rotation, or domain management. You might not notice unless you test at scale. That’s where bulk tools come in. MailTester’s bulk verification checks dozens or thousands of addresses at once and flags those with persistently failing DKIM signatures. This helps isolate domains or sending patterns that are dragging down your overall reputation.

For developers and ops teams, the real-time API can integrate into your workflow to verify addresses before sending, catching failed DKIM early. It’s not just about preventing bounces—it’s about preventing reputation damage before it starts.

RFC 6376, which defines DKIM, emphasizes that the system relies on correct, consistent signing. A single failure doesn’t break delivery—but consistent failure does. That’s why the long-term integrity of your DKIM setup matters more than the immediate outcome of any one email.

Can you use third-party tools to validate DKIM without AWS?

You can, and you should—third-party tools like MailTester, Bouncer, and ZeroBounce validate DKIM signatures independently of AWS by checking DNS records in real time. They confirm if the DKIM signature is valid, expired, or missing, giving you a clear picture of your email’s authenticity without relying on AWS’s console. This is especially useful when debugging delivery issues or when you've rotated keys manually and need to verify the new setup.

Different tools, same goal: real-time DKIM verification

MailTester checks the actual DKIM signature in real time across top email providers like Gmail, Outlook, and Yahoo, not just DNS records.
It returns a precise verdict including "invalid DKIM", "expired key", or "signature missing", helping you fix issues fast.
Bouncer and ZeroBounce also perform DKIM validation as part of their email verification checks, but focus more on inbox placement and deliverability, not deep protocol-level analysis.
You can verify individual addresses or run bulk checks via the bulk verification tool to catch all DKIM-related failures before sending.
These services do not replace AWS’s tools entirely, but they provide independent validation—one of the most reliable ways to confirm your setup works outside your own environment.

Why real-time verification matters

DKIM keys expire or get misconfigured without warning. Even if your AWS console shows "valid", real-world providers like Gmail may reject messages with expired keys. Third-party tools like MailTester test what actually lands in an inbox—what matters most. The DKIM standard requires valid signatures on every sent message, and automated validation ensures you meet that requirement consistently.

MailTester’s 98.9% accuracy includes real-time checks of DKIM record integrity and signature validity across major platforms. This is not just a "pass/fail" test—it surfaces subtle issues like incorrect selector names, malformed signatures, or expired public keys that AWS might not surface until you see bounces.

For teams using SendGrid, Mailchimp, or Klaviyo, integrating MailTester via the native integrations lets you validate DKIM status before sending, even if you’re not using SES. The same applies to automated workflows using the real-time API.

Don’t wait for bounces — prevent DKIM failures before they happen

Expired or invalid DKIM signatures break trust. They lead to rejected messages, poor inbox placement, and damaged sender reputation. Ignoring them is not an option if you’re sending at scale through AWS SES.

Regular validation isn’t a one-time fix. It’s part of ongoing list hygiene. Use MailTester’s bulk verification to scan entire email lists and catch expired or malformed signatures before they cause outages.

With 100 free verifications to start and credits that never expire, testing is low-risk and immediate. No setup, no long-term commitments — just faster delivery and cleaner sends.

Sources

The number of top domains at DMARC enforcement grew from 233,249 in 2023 to 411,935 in 2026 — a 77% increase driven largely by mailbox-provider sender mandates. — EasyDMARC 2026 DMARC Adoption & Enforcement Report (2026)
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)

Keep reading

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

Frequently asked questions

How often should I regenerate DKIM keys in AWS SES?

Regenerate keys every 6 to 12 months, even if no issues appear, to avoid expiration-related failures.

Can AWS SES auto-renew DKIM keys?

No — AWS SES does not auto-renew DKIM keys. You must manually re-generate them before expiration.

What does 'DKIM signature invalid' mean in MailTester?

It means the DKIM TXT record exists but fails verification due to expiration, typo, or cryptographic mismatch.

Does MailTester check DKIM for every email sent?

Yes — MailTester’s real-time API checks DKIM status during verification, and its inbox placement tests confirm it in live delivery.

How long does DNS propagation take after regenerating DKIM keys?

Typically 1 to 24 hours, but may take up to 72 hours in some cases depending on your DNS provider.

Can invalid DKIM affect inbox placement in Gmail?

Yes — Gmail heavily weights DKIM authentication, and failed signatures often result in messages going to spam or being blocked.

What’s the difference between SPF and DKIM in AWS SES?

SPF validates the sending IP, while DKIM validates the content integrity and sender authenticity via cryptographic signatures.

Can a domain have multiple valid DKIM records?

Yes — multiple DKIM records can coexist, but only one is used per sending domain. Conflicts may occur if not properly managed.

How do I know if my DKIM is working after regeneration?

Use MailTester to send a test email or check via DNS lookup tools like MxToolbox; real-time testing shows immediate results.

Is DKIM required to send emails with AWS SES?

No — but without DKIM, deliverability drops significantly, especially with large-volume or enterprise mailers.

Can I use MailTester with Mailchimp and SendGrid?

Yes — MailTester integrates with Mailchimp, SendGrid, HubSpot, and Klaviyo to verify lists and check DKIM status before sending.

Do DKIM failures trigger real-time alerts in AWS SES?

No — AWS SES does not send alerts for expired DKIM keys. You must monitor status manually or via third-party tools.