Why does a 550 5.7.1 SMTP error appear when your DKIM key expires?

You send an email. It hits the inbox. Then, suddenly, you get a 550 5.7.1 SMTP error — silent, sudden, and unexplained. You check the logs. The sender didn’t even try to send again. Why? Because your DKIM key expired during the rotation cycle.

DNS records don’t update themselves. If you’ve rotated your DKIM keys but missed publishing the new public key before the old one expired, receiving servers see a failed signature. The error isn’t about spam. It’s about trust: the digital fingerprint on your message is broken, and the server won’t accept it.

Key takeaways

  • A 550 5.7.1 error due to expired DKIM occurs when the receiving server validates a signature using a DNS public key that no longer exists or has expired.
  • DKIM key rotation is mandatory for security but must include a staggered transition window to avoid delivery failures.
  • Even one expired key in your rotation cycle blocks all messages signed with that key, regardless of content or sender reputation.

How to detect expired DKIM keys before they cause SMTP errors

Expired DKIM keys cause SMTP 550 5.7.1 errors because the receiving server checks the signature against a public key in DNS, and if it’s outdated, the message fails authentication. To catch this early, verify your DNS records match your current private key using tools like MxToolbox or the dig command. Also, monitor key expiration dates in your email provider’s dashboard—most platforms display expiry dates for DKIM keys. When your domain is marked as risky during verification, it often indicates misconfiguration like an expired key. Check DKIM first if you see sudden delivery failures or blocklist reports.

Check DNS records regularly

Use tools like MxToolbox or run dig TXT yourdomain.com to pull the current DKIM DNS record. Compare this public key with the one your email service is actually signing with. A mismatch means the key has changed or expired. This mismatch is the root cause of 550 5.7.1 errors. Running this check weekly helps you catch drift before it impacts deliverability.

Monitor key lifecycles in your provider dashboard

Most email service providers—SendGrid, Amazon SES, Microsoft 365—display DKIM key expiry dates in their security or domain settings. These dates are often set to 12–18 months. Set calendar reminders for 30 days before expiry to restart the rotation process. If you’re using a third-party email platform, check their documentation or support portal for details on key rotation cycles. For example, RFC 6376 outlines the structure of DKIM signatures and key expiration handling.

Automated email verification systems like MailTester’s email checker scan for signs of misconfiguration. When a domain returns a ‘risky’ or ‘invalid’ status during validation, it often flags expired or missing DKIM as a red flag. This is especially useful during list hygiene before sending to known high-volume campaigns.

The role of DKIM in email deliverability

DKIM acts as a cryptographic seal on your emails, proving the message hasn’t been tampered with since it left your server. If the signature doesn’t match the public key in DNS — because it’s expired, missing, or changed during rotation — receiving servers treat it as a red flag, often returning a 550 5.7.1 error. This failure harms your sender reputation and can block deliverability.

How DKIM works in practice

When you send an email, your server signs it using a private key. The receiving server then retrieves the corresponding public key from your domain’s DNS records using a selector — a label that specifies which key to use. This public key is part of a DNS TXT record tied to your domain, like selector._domainkey.example.com.

If the key is outdated, removed, or not properly published during a rotation cycle, the signature won’t validate. Most modern email providers treat this failure as a strong signal of potential spoofing or poor technical hygiene. You might see a 550 5.7.1 error, which means "mail rejected: authentication failure" — and it’s often not a temporary glitch, but a system-level rejection.

Why DKIM failures derail deliverability

A failed DKIM check isn't just a technical hiccup. It signals to receiving servers that your email infrastructure may not be reliable. According to industry standards laid out in RFC 6376, DKIM is a core element of email authentication and is widely used by major providers like Gmail, Microsoft, and Yahoo.

If your DKIM key isn’t updated in DNS after rotation, mail is essentially unsigned in the eyes of the receiver. Even a single failed check can hurt your sender reputation over time. If you’re sending bulk mail or using transactional email services, this can lead to higher bounce rates, slower inbox placement, and inclusion on blocklists.

Proactively verifying your DNS records and checking key validity — especially after a rotation cycle — helps prevent this fallout. Tools like MailTester’s email checker let you verify whether a domain’s DKIM configuration is active and accessible, and whether a specific address can receive mail without issues.

Common causes of DKIM key expiration during rotation

You get a 550 5.7.1 SMTP error because your DKIM key expired mid-rotation cycle — often due to missed DNS updates, overly long key lifespans, failed automation, or multiple keys lingering in DNS without tracking. These issues break the alignment required by receivers and trigger delivery failures. Even a single misstep in the rotation process can expose your domain to rejection.

Manual rotation without DNS updates

  • You manually rotate the DKIM key in your email platform but forget to update the DNS TXT record, leaving the old, expired key in place.
  • Receivers validate the signature against the public key in DNS, so an outdated record causes immediate rejection — even if the sending system has the new key.
  • Let’s be honest: manual processes are the single biggest source of DKIM misconfigurations. Automate the update step or use a tool like MailTester’s email checker to validate DNS changes post-update.

Long validity periods and poor tracking

  • You set your DKIM key to expire only every 18 months, making it hard to track when it’s due — and easy to miss the window.
  • Without clear internal audit logs or calendar alerts, the key goes stale before the next rotation, causing a gap in published keys.
  • Industry best practice (RFC 6376) recommends rotating keys every 3–6 months. Tools that auto-generate keys with embedded expiry dates reduce this risk significantly.

Automation failures during rotation

  • Your script rotates the key but fails to publish it to DNS due to a timeout, permission error, or malformed request.
  • It leaves the old key active and the new one unpublished, causing a split in authentication records.
  • Some scripts run without verification, so you never know if the new key is live. Check your DNS directly using MXToolbox or DNS.google to confirm the TXT entry was published.

Multipe keys in DNS with no tracking

  • You have multiple DKIM keys in DNS, sometimes from outdated configurations, with no naming convention or expiry tracking.
  • Receivers may choose the wrong key or reject the signature if the active key isn’t clearly identified.
  • Always keep only one active key per selector. Use unique selectors like default._domainkey or 2024q2._domainkey to make key lifecycle management easier.
DKIM relies on trust in the public key — if that key isn’t correct when the message is received, the email fails. Consistency in DNS is non-negotiable.

How to fix the 550 5.7.1 SMTP error from expired DKIM keys

When your outbound emails trigger a 550 5.7.1 SMTP error due to an expired DKIM key, the fix is straightforward: renew the key pair, update the DNS TXT record with the new public key using the correct selector, and wait for propagation. Most mail servers validate DKIM signatures within minutes to hours, but DNS changes can take up to 48 hours to fully propagate globally. Test delivery once propagation is complete.

Step-by-step fix process

  1. Identify your current DKIM selector — Check your email service provider’s DNS or email configuration settings. The selector is the identifier in the DKIM-Signature header (e.g., selector1._domainkey.example.com). You’ll use this to update the correct DNS record.
  2. Generate a new DKIM key pair — Use your email provider’s key management tool (such as in Google Workspace, Microsoft 365, or a SMTP relay like SendGrid) to create a new private and public key. Never reuse old keys or generate them manually unless your system supports it.
  3. Update the public key in DNS — Replace the existing TXT record associated with the selector and domain with the new public key. Ensure the selector and domain match exactly. A single typo breaks DKIM validation.
  4. Wait for DNS propagation — DNS changes typically propagate within 1–6 hours, though some servers may take up to 48 hours. Most modern systems check DKIM records within a few hours, but allow time for full global update. Use MXToolbox to verify the record is live and correct.
  5. Test email delivery — Use a real-time verification API or an inbox placement test to send a test message to a valid address. Tools like MailTester’s Inbox Placement Test simulate real-world delivery and check if the DKIM signature is now valid and accepted.

Why this works

DKIM validates that your message wasn’t altered in transit and confirms your domain’s authenticity. An expired key means the signature can’t be verified — recipients reject the email with a 550 5.7.1 error. By rotating the key and updating DNS, you restore signature legitimacy. This is an industry-standard practice; the DKIM RFC specifies that keys should have a short lifespan (typically 30–90 days) to reduce exposure.

If multiple domains use DKIM, ensure each has its own selector and record. Do not merge records. Also, avoid overlapping selectors — confusion here can cause rejection on mail servers using strict validation rules.

You can prevent 550 5.7.1 SMTP errors caused by expired DKIM keys by checking email addresses in real time before sending. MailTester's API verifies not just the format and existence of an address, but whether the domain’s authentication records—including DKIM—are valid and active. If a domain’s DKIM key has expired or is misconfigured, the tool flags it as 'risky', letting you clean your list before delivery.

Real-time checks catch authentication flaws early

When you send email, the receiving server checks SPF, DKIM, and DMARC to verify sender legitimacy. A failed DKIM signature can trigger a 550 5.7.1 error—even if the mailbox exists. MailTester’s real-time API scans domain records during validation. If the domain lacks a valid DKIM record or uses an expired one, it returns a 'risky' verdict, indicating high chance of bounce or rejection.

Let’s say you’re about to send a campaign. Instead of guessing, you run the list through the MailTester API. It returns results in milliseconds, showing which addresses are safe to send to and which have authentication issues. This stops problems before they hit a mail server’s blocklist.

Authentication flaws are common. According to RFC 6376, the framework for DKIM includes strict key expiration rules. When keys aren’t rotated properly, mail delivery fails. MailTester doesn’t just detect the absence of a key—it checks its validity and expiration status. It’s not guessing; it’s testing actual DNS records.

Interpret verdicts with the in-app AI assistant

Not all 'risky' addresses are bad—for example, some may be in a catch-all domain or have temporary misconfigurations. MailTester’s in-app AI assistant helps you interpret these verdicts in context. Ask, “Why is this address flagged as risky?” and it breaks down the reason—whether it’s missing DKIM, an expired signature, or SPF misalignment.

This clarity prevents over-cleaning. You’re not just rejecting emails; you’re understanding why they’re risky. That saves delivery rate, reduces hard bounces from non-existent addresses, and improves sender reputation.

Prevention is faster than recovery. Fixing a single expired key in a mass email campaign is harder than preventing it with a simple verification step. Use bulk verification to scrub large lists, or run single checks before sending critical messages. The result? Fewer 550 5.7.1 errors and better inbox placement.

What does MailTester’s accuracy mean for DKIM detection?

MailTester’s 98.9% accuracy means it detects domains with expired or invalid DKIM keys during verification—without requiring you to send a single test email. It checks DNS records, MX settings, and authentication protocols like SPF and DKIM in real time, flagging domains with weak or broken authentication. A 'risky' verdict warns you upfront about flaws that could cause a 550 5.7.1 SMTP error or harm your sender reputation.

How DKIM validation works without sending email

You don’t need to send mail to confirm if a DKIM key is expired—MailTester does it via DNS inspection. It queries the domain’s DNS records for the DKIM selector and public key, then checks their validity, expiration, and alignment with the sending domain. This is how you catch problems before they trigger bounces or blocklists.

Unlike some tools that rely on sending test messages to validate deliverability, MailTester works purely on record-level checks. This means you can verify your list at scale—millions of addresses in minutes—without risking your sender reputation or triggering spam filters.

What a 'risky' verdict tells you

A domain marked as 'risky' indicates broken or misconfigured authentication. This includes expired DKIM keys, missing or malformed TXT records, or mismatched SPF/DKIM alignment. For example, if a DKIM key expired 10 days ago, MailTester flags that domain instantly, even if the mailbox is still active.

This early warning lets you clean your list before sending. Preventing delivery failures due to authentication issues means lower bounce rates, better inbox placement, and a healthier sender reputation. According to RFC 6376, DKIM authentication is a key factor in email acceptance by major mailbox providers.

Use MailTester’s bulk verification to scan large lists and catch outdated keys in bulk. Or integrate the real-time verification API into your signup or checkout flows to block risky addresses before they enter your system.

Best practices for DKIM key rotation without delivery failures

Rotate DKIM keys safely by publishing the new key in DNS before retiring the old one, automate DNS updates to avoid errors, validate delivery with inbox placement tests afterward, and check your entire sending list for authentication issues using a bulk verification tool. This prevents 550 5.7.1 SMTP errors caused by expired or missing signatures during the transition.

Plan the rotation with overlapping keys

  • Always publish the new DKIM key in DNS at least 72 hours before deprecating the old one. This ensures receiving servers can verify messages sent during the shift.
  • Allow both keys to be active simultaneously during the overlap window. This maintains continuity for messages sent from older systems or with delayed DNS propagation.
  • Use a DNS record with a selector prefix (e.g., default._domainkey and 2024._domainkey) to distinguish between keys without breaking existing configurations.

Automate DNS updates and verify results

  • Use your domain registrar’s or DNS provider’s API to automate key deployment. Manual changes increase the risk of typos, timing delays, or forgotten updates.
  • Set up monitoring for DNS propagation delays using tools like MXToolbox or RFC 6376, Section 3.7 to validate that the new key is reachable.
  • Immediately after rotation, run inbox placement tests using a service like MailTester's inbox tester to confirm messages aren’t being rejected or routed to spam.
  • Check your overall sender reputation using historical data and real-time monitoring. A sudden drop in delivery rates may signal unresolved authentication gaps.
  • Scan your entire email list with a bulk verification tool to catch invalid or misconfigured addresses that might trigger 550 errors even with valid DKIM.

Let’s be clear: a single misstep in key rotation can trigger hard bounces. But by overlapping keys, automating updates, testing deliverability, and validating your list, you avoid delivery outages even during routine maintenance. This is how you keep your mail stream reliable.

How to verify DKIM status with MailTester’s inbox placement testing

You can test whether your DKIM configuration is causing a 550 5.7.1 SMTP error by sending a test email through MailTester’s inbox placement feature. If DKIM is misconfigured or expired, the test will show the email being rejected with a clear error code and server-side reason, often revealing the exact failure point during the SMTP handshake. This gives you hard evidence to diagnose whether the issue lies with DKIM, SPF, DMARC, or another authentication setting.

What the test reveals

When you run an inbox placement test, MailTester sends your message through real email infrastructure—including major providers like Gmail, Outlook, and Yahoo—to see where it lands. If your DKIM key has expired or isn’t properly rotated, the receiving server will reject the message with a 550 error code, frequently followed by a reason like “Authentication failed” or “DKIM verification failed.” The test response includes the full SMTP trace, so you can see exactly when and why the rejection occurred, down to the specific error code.

You’re not guessing. The output shows whether the failure was due to a missing, expired, or malformed DKIM signature, or if another mechanism like SPF or DMARC is the culprit. For example, a 550 5.7.1 error with “authentication=none” might point to a missing DKIM header, while “policy=reject” could indicate a DMARC enforcement rule being triggered. These details are critical for correcting the issue without trial and error.

How to use it effectively

Let’s say you’re seeing 550 5.7.1 errors in your logs after a DKIM key rotation. Run a test from MailTester’s inbox placement tool using the same sender address and domain. It will simulate a real customer message and return the exact same rejection you’d see from a real mailbox provider. If you get a 550 error with “DKIM failed,” you know the key is either outdated, misaligned, or not signed on all outbound messages.

For deeper analysis, compare the test results across different domains, or check whether the same domain works with different sending IPs. This helps isolate whether the issue is with the key itself or with a broader policy mismatch. You can also use MailTester’s real-time verification API to validate individual addresses before sending, ensuring your entire campaign starts from a clean slate.

The SPF, DKIM, and DMARC standards are documented in RFC 7052, which outlines best practices for key rotation and alignment. While no single standard enforces auto-rotation, maintaining consistent, timely updates is a widely recognized requirement for reliable sending. MailTester’s inbox placement test is one of the few tools that gives you a real-world preview of how your messages are treated by actual email infrastructure.

Common misconceptions about DKIM and SMTP errors

You don’t need to panic when you see a 550 5.7.1 error—just because DKIM failed doesn’t mean your email is spam. It means the receiving server couldn’t validate the digital signature. Even with a correct domain and valid SPF, a failed DKIM check can trigger rejection, especially if the key has expired or the algorithm isn’t supported. Let’s clarify what’s actually happening behind the scenes.

DKIM isn’t about spam—it’s about proof

  • Digital signatures in DKIM do not indicate spam. They verify that the message hasn’t been altered and that it actually came from the domain’s authorized servers.
  • Even with a valid DKIM key, your email may still be rejected if the signing algorithm is outdated or not supported by the recipient (e.g., using SHA-1 instead of the modern SHA-256).
  • Some mail servers reject messages outright when DKIM fails—even if SPF passes—because the receiving policy requires both signatures to match.
  • The 550 5.7.1 code specifically means authentication failed, usually due to expired, malformed, or unsupported DKIM keys. It’s not a delivery logic error, so retrying immediately won’t help.
  • Other 5xx SMTP codes (like 550 5.7.0) may relate to sender policy, access restrictions, or blocked IPs—these are separate from signature validation and require different fixes.
  • Some systems still allow emails with failed DKIM if other checks (like DMARC policy) are permissive, but most enterprise-grade receivers enforce strict alignment.

When a key expires, it’s not the email— it’s the process

  • DKIM keys are rotated automatically in many setups, but if the rotation schedule lags or the new key isn’t published in DNS, validation fails.
  • It’s possible to have multiple valid keys in flight during rotation—but only one active key should be published at a time. Having stale keys can lead to confusion.
  • Use tools like MxToolbox or RFC 6376 to audit your DKIM setup and ensure signature alignment.
  • Even if your outbound system signs correctly, a delay in DNS propagation can cause temporary failures—especially if you're relying on automated rotation.
  • Double-check that your DNS TXT records are up-to-date and that the selector (the part of the domain before _domainkey) matches the one used in the signature.
  • Before sending to a new list, verify all inbound email paths with a tool like inbox placement testing to catch alignment issues early.

Expired DKIM keys disrupt email delivery, but they’re preventable with consistent list hygiene. Regular verification catches domains with failing authentication before they cause SMTP errors like 550 5.7.1.

Use MailTester’s bulk verification to scan your entire email list for domains with expired or broken authentication. Filter out any address flagged as 'risky' or 'catch-all'—these are high-risk for delivery failure and sender reputation damage.

Integrate MailTester with Mailchimp, SendGrid, or HubSpot to auto-verify new signups in real time. Keep your list clean from the start, and maintain sender reputation by avoiding authentication mismatches during key rotation cycles.

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 the 550 5.7.1 SMTP error mean?

It means the receiving mail server rejected the message due to a failed authentication check — most commonly a failed DKIM signature.

Can expired DKIM keys cause high bounce rates?

Yes — when a domain’s DKIM key expires, incoming mail is rejected with a 550 error, leading to hard bounces.

How long does it take for a new DKIM key to propagate?

DNS propagation usually takes 1–6 hours, but can extend to 48 hours depending on TTL settings and resolver caches.

Does MailTester test DKIM authenticity?

Yes — it checks DNS records, including DKIM TXT entries, as part of its verification process to flag domains with expired or misconfigured keys.

Can MailTester fix my DKIM configuration?

No — MailTester detects issues but doesn’t modify DNS or email infrastructure. It tells you what’s wrong so you can fix it.

What’s the difference between SPF and DKIM errors in SMTP logs?

SPF checks the sending IP; DKIM checks the message content signature. Both can cause 550 errors, but for different reasons.

Is a 'risky' verdict from MailTester always due to DKIM?

No — 'risky' includes invalid domains, catch-alls, role accounts, and domains with expired DMARC or SPF, as well as DKIM issues.

Can a catch-all email address cause a 550 5.7.1 error?

Not directly — catch-alls can receive mail, but if DKIM or SPF fail, rejection still happens during authentication.

How often should I rotate DKIM keys?

Best practice is every 90 to 180 days, but always ensure the new key is published in DNS before deprecating the old one.

Can I test DKIM without sending emails?

Yes — MailTester verifies DKIM status via DNS lookup without sending a message, reducing risk and saving resources.

What happens if I don’t fix an expired DKIM key?

All emails sent from that domain will fail authentication, resulting in hard bounces, delivery failures, and damage to sender reputation.

Does MailTester integrate with email service providers?

Yes — it integrates with Mailchimp, SendGrid, HubSpot, and Klaviyo to verify lists and prevent sending to invalid or risky addresses.