Fix 550 5.7.1 Spam Rejection | Email List Validation

What does the 550 5.7.1 spam rejection mean exactly?

You sent a campaign, and suddenly your delivery rate drops. One message fails with a 550 5.7.1 spam rejection. You check your logs, and the message didn’t even reach the inbox. It was blocked at the gate.

This error means the receiving mail server rejected your message because its DKIM signature had expired. The signature was valid when created, but like a time-limited access code, it no longer works. Even if your content is clean and your sender reputation is strong, an expired DKIM signature triggers a hard bounce before the message can be evaluated further.

DKIM signatures are cryptographic proofs that bind a message to a domain. They’re time-bound for security reasons—each signature has a defined validity window. Once that window closes, the server no longer trusts the signature, and the message is rejected as potentially forged or delayed.

Key takeaways

DKIM signatures expire and must be refreshed before the validity window closes
A 550 5.7.1 rejection occurs during SMTP handshake, resulting in a hard bounce
Expired DKIM is a deliverability issue rooted in authentication, not content or reputation

Why does an expired DKIM signature cause a 550 5.7.1 rejection?

When a DKIM signature expires, receiving servers reject the message with a 550 5.7.1 error because they check the signature’s validity window using the 't=' timestamp. Even if your domain, selector, and public key are correct, an expired signature fails the check — and that failure triggers the rejection. It’s not about whether the email is spam; it’s about whether the cryptographic proof was still valid when the server received it.

The role of the 't=' parameter in DKIM

Every DKIM signature includes a 't=' parameter that defines the expiry time in Unix timestamp format. This window typically lasts 24 hours but can vary depending on your setup. The receiving server checks this timestamp against its current time. If the current time is past 't=', the signature is invalid by design — and the email is rejected.

Let’s say your signature’s 't=' is set to 1717324800 (May 25, 2024, 00:00:00 UTC). If the inbox server receives the message on May 26, 2024, it sees that the signature is no longer valid and flags it as untrusted. This is not about spam detection — it’s about cryptographic time bounds, a feature built into the DKIM RFC (specifically RFC 6376).

Why expired signatures still break delivery

Even if your email content, SPF, and DMARC are all properly configured, a single expired DKIM signature can halt delivery. Receiving servers rely on DKIM as a core trust signal. If the signature fails validation due to expiration, the receiving server treats the message as potentially forged — even if you own the domain.

Many senders assume that as long as the domain and selector match, delivery will work. But DKIM isn’t a one-time setup. If you rotate keys, use long-lived signatures without renewal, or don’t monitor expiry, your emails will start failing. This is especially problematic when sending to Gmail, Microsoft 365, or other large providers whose filtering systems are strict about cryptographic validation.

For senders managing large lists, checking signature validity across hundreds of emails in real time is difficult. You can reduce the risk by using tools that validate DNS records and signature parameters during list hygiene. Bulk email list cleaning identifies invalid or expired records early, so you don’t send to addresses that will trigger rejection before they even reach the inbox.

How do you diagnose an expired DKIM signature?

You diagnose an expired DKIM signature by checking the full SMTP error response for the exact 550 5.7.1 code and the phrase "expired DKIM signature." Then, examine your message headers using a mailbox provider's debugger like MxToolbox or Mail-Tester to locate the dkim-signature field and confirm the t= parameter date. If the timestamp is in the past, your DKIM signature has expired and needs renewal.

Step-by-step diagnosis process

Inspect the full SMTP delivery report — Look past the generic "550 5.7.1" error. The real clue is in the message body: find the exact phrase "expired DKIM signature." Many email servers include this detail only if the failure is due to a cryptographic timestamp issue, not a general spam filter.
Use a header analyzer — Tools like MxToolbox or Mail-Tester let you paste your full email headers and analyze them in real time. These tools decode the DMARC and DKIM structures, showing where the failure occurred.
Find the dkim-signature header — This field contains multiple parameters. Look specifically for the t= parameter, which contains the timestamp when the signature was signed. If the timestamp is a date in the past, the signature has expired and is no longer valid.
Verify the signature's validity window — DKIM signatures are typically valid for 24 hours. If your signing process uses a long or fixed timestamp (e.g., set on a cron job that runs every 30 days), the signature will expire quickly. Check your signing software or email service’s configuration for automatic key rotation.
Review your email infrastructure — If you use a third-party ESP like SendGrid, Mailchimp, or HubSpot, ensure that their DKIM keys are automatically renewed. Some providers require manual rekeying after a key lifetime ends.

Understanding why this happens

Digital signatures expire intentionally. They're not meant to last forever — they prevent long-term key compromise. A typical DKIM key lasts from 24 hours to one week. When the timestamp t= passes, even a technically valid signature is rejected. You’re not failing because of content — you’re failing because of time.

When your sender reputation is on the line, even temporary issues like this can impact inbox placement. If you’re managing large send volumes, automated header validation is essential. You can use a real-time email verification API to catch invalid or misconfigured addresses before they ever get sent — helping reduce the risk of deliverability failures caused by poor infrastructure hygiene.

What’s the difference between DKIM expiry and failed authentication?

DKIM expiry means the signature is technically valid but has passed its time window—typically 15 to 30 minutes—requiring a new signature. Failed authentication means the signature didn’t verify due to broken DNS, incorrect keys, or wrong selector, and no amount of time adjustment will fix it. One is time-dependent; the other is structural.

DKIM expiry: a time-based, predictable issue

When a DKIM signature expires, the receiving server still sees it as valid in format but rejects it because the timestamp is outside the allowed window. This is common when messages are delayed in transit or requeued. The key point: the signature itself is correct, just too old. You can fix this by re-sending the message with a fresh signature. Unlike some delivery issues, DKIM expiry is entirely predictable and doesn’t reflect poor setup.

DNS-based Message Authentication, Reporting & Conformance (DMARC) policies often allow a grace period for expired DKIM, but many servers enforce strict time limits. This is standard behavior across email providers and documented in RFC 6376, which sets the validity window. If your outbound emails consistently hit this, your mail system likely needs to generate new DKIM signatures before the limit.

Failed authentication: a deeper setup problem

When authentication fails, the issue is not time—but configuration. The selector may be wrong, the public key isn’t published, or the DNS record is malformed. Even a single character typo in the DKIM record can break the entire chain. These errors don’t resolve themselves. They require inspection and correction in your DNS zone.

You might see this as an error like 550 5.7.1 Invalid DKIM signature, 550 5.7.1 Missing public key, or 550 5.7.1 Failed to verify DKIM. These aren’t time errors. They point to misconfiguration, which can be more persistent and harder to diagnose without checking DNS records manually or using a tool like MXToolbox.

It’s critical to distinguish between a signature that's just old and one that’s fundamentally broken. The former is a small re-send fix. The latter means audit your DNS TXT records, verify the key selector, and ensure public keys are published at the correct domain and path. If you’re sending bulk email, this step is essential. Use a service like bulk email list cleaning to ensure your sender setup matches industry standards and avoid these issues before they impact deliverability.

How to fix an expired DKIM signature in transit

If your email is being rejected with a 550 5.7.1 spam error due to an expired DKIM signature, the issue lies in a signature that no longer matches the sender’s public key. This usually happens when the signing process doesn’t refresh keys within the validity window. The fix is straightforward: ensure your outbound system automatically re-signs messages before delivery, and verify that your DKIM key rotation is active and functioning.

Verify your email platform’s DKIM configuration

Check whether your email service provider (e.g., SendGrid, Mailgun, Amazon SES) automatically re-signs outgoing messages before they leave your mail server. Many platforms use short-lived keys—typically 10 to 60 minutes—so signatures must be updated within that window.
If you use a third-party sender, review their DKIM key rotation settings. Some providers rotate keys manually or without clear notification; confirm the system is set to auto-renew.
For self-hosted systems, verify that your MTA (e.g., Postfix, Exim) or email pipeline includes logic to re-sign messages regularly. A static signature stored for longer than the validity period will fail validation.
Use tools like MXToolbox DKIM Lookup or RFC 6376 to validate that your DKIM records are correctly published and that signatures align with current keys.

Ensure consistent signing across outbound systems

If you use a combination of senders (e.g., your CRM, ESP, and a transactional service), confirm that each system re-signs messages independently. A single missed re-sign can trigger rejection.
Check your email logs for "DKIM verification failed" errors and cross-reference them with the timestamp of the original message. This helps pinpoint when the signature expired.
For enterprise systems: audit your signing process every time a new batch of emails is sent. Automated systems can fail silently when the key rotation window is misconfigured.
Run inbox placement tests to confirm that fixes resolve the rejection. You can test deliverability in real inboxes via inbox placement testing, which includes validation of authentication headers like DKIM.

DKIM fails when the signature expires before delivery. A single expired key blocks delivery—regardless of content.

Verifying your email list before sending reduces the risk of bounce storms, delayed delivery, and spam filter flags—especially those tied to weak or expired digital signatures like DKIM. Invalid or dormant addresses can trigger retry loops, increasing your sender reputation risk. Clean lists mean fewer delivery attempts on unstable domains, reducing stress on your infrastructure and lowering the chance of rejection due to technical issues, including outdated DKIM configurations.

Remove bad addresses before they cause delivery stress

Every time you send to an invalid or inactive email, you risk triggering a bounce chain. If your system retries or keeps trying to deliver to a dormant address, your domain’s reputation can degrade. This is especially dangerous when DKIM is misconfigured, as retry loops on problematic domains may be interpreted as malicious behavior by filters. Email verification catches these addresses early—before you send. A list scrubbed of invalid, dormant, or non-existent addresses reduces unnecessary delivery attempts and prevents signal noise that can indirectly impact DKIM trust signals.

Catch authentication quirks before they trigger rejections

DNS issues, missing MX records, and expired cryptographic signatures often overlap in behavior. You might see a 550 5.7.1 error not because your DKIM key is expired, but because the receiving server can’t properly validate it due to a prior misconfiguration or missing DNS record. A real-time verification API checks exactly that: it verifies whether the domain accepts email, resolves properly, and has valid mail server infrastructure. This includes testing for basic SPF, DKIM, and DMARC readiness—not just whether an address exists. You can test a single address in seconds, and integrate the check directly into your workflow.

With the real-time verification API, you can validate hundreds of emails in a single request, checking DNS, deliverability risk, and inbox placement conditions. This includes flags like catch-all detection, role accounts, and disposable domains—all of which can skew delivery performance even if your DKIM is technically correct. Catching these issues early prevents them from becoming delivery roadblocks.

For deeper insight, test how your messages are received across real inboxes using inbox-placement testing. This helps you see how often your emails hit spam, how your sender reputation stands, and whether technical missteps like broken DKIM are already triggering filters. A sender that sends only to valid, high-quality inboxes avoids the kind of stress that leads to technical delivery failures.

The underlying goal is not just to verify addresses—it’s to prevent conditions that trigger rejection. And since DKIM failures often stem from a broader pattern of poor list hygiene or technical misalignment, a solid verification process acts as preventative maintenance. It’s not just about fixing old problems—it’s about stopping new ones before they start.

What should you do if the 550 5.7.1 error keeps recurring after fixing DKIM?

If your 550 5.7.1 spam rejection persists despite renewing your DKIM signature, it’s not just about the signature itself. The error might stem from a damaged sender reputation, misconfigured SPF or DMARC, or underlying automation failures. Check blocklists, validate your alignment, and monitor bounces to find the root cause—especially if you’re using automated email systems that rotate keys without proper tracking.

Confirm your sending infrastructure is clean and aligned

Check if your sending domain appears on known blocklists like Spamhaus or MXToolbox. A high reputation risk can cause even briefly expired signatures to be rejected.
Verify your SPF record includes only authorized sending sources. Overly permissive or missing records can trigger rejection even with valid DKIM.
Ensure your DMARC policy is not set to none in production. Misalignment between SPF and DKIM results in policy failures and increased rejection likelihood.
Test your alignment using RFC 7672-compliant tools or services that validate the DMARC pass criteria across all authentication methods.

Look for automation or key rotation failures

Review email logs daily for repeated 550 5.7.1 errors. A recurring pattern often points to an automated system that fails to rotate or re-sign messages properly.
If using a third-party mailer or API, confirm that your DKIM keys are refreshed without dropping signing sessions or invalidating cached keys.
Monitor your daily bounce rates. A spike in hard bounces combined with 550 5.7.1 errors suggests delivery filters are flagging your domain as untrustworthy.
Use real-time email verification to clean your list and rule out delivery issues caused by non-existent or risky addresses—especially if you’re sending at scale. Verify email accuracy in real time to reduce backscatter and reputation damage.

Even with a valid DKIM signature, a domain with a history of spam or inconsistent authentication alignment will be treated with suspicion by modern filtering systems.

How can you avoid DKIM expiry in the future?

You can prevent 550 5.7.1 spam rejections due to expired DKIM signatures by shortening your signature’s validity window to under 60 minutes, using a service that auto-rotates keys (like SendGrid or Amazon SES), and setting up alerts for expiration events. This proactive approach drastically reduces the window for transit delays to trigger a failure. It’s not about perfection — it’s about reducing the chances a signature expires before reaching the inbox.

Shorten your signature’s expiry window

DKIM signatures are only valid for a set time, typically defined in the signature header. If your signature expires during transit — which can happen due to queue delays or slow SMTP delivery — the receiving server may reject the message with a 550 5.7.1 error.

Set your key validity window to less than 60 minutes. This keeps the window tight enough that even a delayed delivery won’t trigger expiry. Most modern email providers can handle short windows reliably, and the trade-off in security is minimal.

For reference, RFC 6376 allows signature validity times to be negotiated; shorter windows are a common practice for high-volume senders to avoid timeouts.

Automate key rotation and monitor expiry

Manually rotating DKIM keys is error-prone. It’s easy to miss a rotation or misconfigure the DNS entry, both of which lead to failed signatures. Instead, use a system that auto-rotates keys — services like SendGrid, Amazon SES, and Mailgun manage this automatically.

Even with automation, you should monitor expiration events. Set up alerts in your email service or monitoring tool that trigger when a key is nearing expiry. This prevents surprises. An expired key doesn’t just stop one message — it can break a whole sending pipeline until resolved.

If you’re validating email data at scale, catch issues early. You can test for deliverability issues like this using inbox placement tests, which simulate real-world delivery and expose issues like expired signatures before they hit production.

Set DKIM signature validity to under 60 minutes.
Use a service with automated key rotation (e.g., SendGrid, Amazon SES).
Enable logging and real-time alerts for key expiry events.
Validate your domain’s DMARC alignment and DNS records regularly.
Test your email streams with inbox placement tools to catch delivery failures early.

What if your domain doesn’t have DKIM at all?

If your domain lacks DKIM, your emails are significantly more likely to be rejected, especially by big providers like Gmail and Microsoft. Without DKIM, there’s no cryptographic proof your message wasn’t altered in transit, so it’s treated as high-risk. High-volume senders without DKIM often hit 550 5.7.1 rejections—common when receivers can’t verify authenticity.

Why DKIM matters for senders

DKIM isn’t optional if you’re sending more than a few hundred emails a day. It’s a core part of email authentication and used by major platforms to assess sender legitimacy. Without it, your messages may land in spam folders, get blocked outright, or be flagged as phishing attempts. While small-scale senders might get lucky, volume triggers stricter checks.

How to set up DKIM correctly

Start by checking your email service provider’s documentation—SendGrid, Amazon SES, Microsoft 365, and others all have clear instructions. You’ll need to generate a public key and add it as a TXT record in your domain’s DNS configuration. This key is used to verify that your messages are authentic and haven’t been tampered with in transit.

After setup, use tools like DKIMCore.org or MxToolbox to verify that your DKIM record is properly published. These tools check if the DNS TXT record exists, is readable, and contains a valid public key. A failed validation means your sender reputation is at risk—fixing it early prevents widespread delivery failures.

Don’t assume your provider handles it automatically. Many require manual setup, even on enterprise plans. Double-check the selector (e.g., default, mail, send) and ensure the record matches exactly what’s requested. A single typo breaks the signature.

Once confirmed, monitor your delivery rates and spam complaints. DKIM alone won’t fix poor list hygiene or weak sender reputation—but it’s a non-negotiable baseline for reliable inbox placement.

How to verify your DKIM setup works before sending to real users

You can’t rely on a DKIM signature just being present—its key needs to be valid, properly aligned, and tested under real-world conditions. Use inbox-placement testing to simulate how your messages land in actual inboxes, check sample addresses for authentication issues with a real-time API, and verify your DNS TXT records directly through a public lookup tool. This combination proves your setup works, not just looks correct.

Run tests that mimic real delivery conditions

Use inbox-placement testing to send test messages through providers like Gmail, Yahoo, and Outlook. This shows whether your DKIM signature survives filtering and reaches the inbox—something internal checks won’t catch.
Check your DNS TXT records by running a public lookup on MXToolbox or DNSLeakTest. Confirm the selector, domain, and public key match exactly what your email system publishes.

Validate deliverability down to the address level

Run a real-time verification API check on a small, representative sample of your list. This confirms not only that addresses are valid—but whether they’re flagged for issues like expired DKIM signatures or known spam patterns.
Review the API’s output for authentication status fields. If the system reports “DKIM: invalid” or “key expired,” you’ve found the root cause of the 550 5.7.1 rejection.
For larger campaigns, use bulk verification to scrub your list before sending. It flags high-risk addresses before they trigger bounces or spam complaints.
Ensure that SPF and DMARC are correctly configured alongside DKIM. Misalignment between these three protocols is a common cause of rejection, even when DKIM appears correct.

The key is testing the full path—DNS record, message signing, and inbox reception. A single gap in this chain can trigger a 550 5.7.1 error. Fix it before your next send.

For tools that help with this workflow, consider using Email List Validation's inbox-placement testing feature to simulate real inbox behavior, or its real-time verification API to spot authentication issues early:

Test how your email lands in real inboxes before sending to your audience.
Verify individual addresses for deliverability and authentication flags at scale.

Final step: clean your email list before sending

Invalid, catch-all, role-based, and disposable email addresses increase bounce rates and trigger spam filters. They also mask real deliverability issues like expired DKIM signatures.

Bulk email verification removes these addresses before sending, reducing the risk of spam traps and improving sender reputation. A clean list makes authentication failures easier to diagnose and resolve.

With 98.9% accuracy, Email List Validation spots domains with known delivery issues and flags problematic addresses before you send. This prevents wasted sends and strengthens inbox placement.

Keep reading

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

Frequently asked questions

Can a valid DKIM signature cause a 550 5.7.1 error?

Yes — if the signature has expired due to a time-bound 't=' parameter. The signature may be cryptographically correct but no longer valid.

How often should DKIM keys rotate?

Most systems rotate keys every 10 to 60 minutes. Shorter intervals reduce the chance of expiry during transit.

Does DKIM affect sender reputation?

Yes — consistently failing DKIM checks can harm sender reputation. Even expired signatures signal poor maintenance.

Can you fix a 550 5.7.1 error without changing DKIM?

Only if the error was caused by another factor like a misconfigured SPF or DMARC. If DKIM is expired, the signature must be renewed.

Is DKIM required for all email sends?

It’s strongly recommended for all outbound email above low volume. Most major providers reject or flag unauthenticated emails.

What happens to emails with expired DKIM signatures?

They are rejected at the SMTP level with a 550 5.7.1 error, typically resulting in a hard bounce and no delivery.

How do I test if my DKIM signature is valid?

Use a tool like MxToolbox or DKIMCore.org to analyze the message header and verify the public key and signature match.

Can spam filters detect expired DKIM?

Yes — while they don’t flag it directly, an expired signature is treated as a failure that increases the likelihood of rejection.

Does Email List Validation check DKIM expiration?

Not directly — but it checks deliverability, domain health, and mailbox validity. A high-risk domain is more likely to have authentication issues.

How does Email List Validation improve deliverability?

By filtering out invalid, role, and disposable addresses. A clean list reduces bounce rates and improves inbox placement.

Can expired DKIM cause inbox placement failure?

Yes — even if the message is accepted, expired signatures reduce trust and may trigger filtering or placement in the spam folder.

What’s the role of DMARC in relation to DKIM expiration?

DMARC uses DKIM results to enforce policy. If DKIM fails (including expiry), DMARC may reject the message, depending on policy.