Why do some email servers still allow RSA-SHA1 while others block it?

You send an email to a customer. It shows as delivered. But a week later, you get a bounce. No error code, no clear reason — just a silent rejection. This happens more often than you’d expect, and one hidden culprit is RSA-SHA1.

It’s a legacy cryptographic signature method used in DKIM and TLS handshakes. While SHA-1 has known collision vulnerabilities, its use persists in older systems that haven’t been updated. This inconsistency creates unpredictable delivery — some servers accept it, others reject it outright, even if the email is otherwise valid.

Key takeaways

  • RSASHA1 is still accepted by some email servers due to backward compatibility with legacy infrastructure.
  • Newer servers enforce RSA-SHA256 for TLS and DKIM, blocking RSA-SHA1 to reduce security risk.
  • Different server policies mean the same email address may deliver to one recipient but fail for another, even without syntax errors.

What is RSA-SHA1 and why is it still in use?

RSA-SHA1 is an older cryptographic combination used to sign digital messages and secure TLS connections in email systems. It relies on the RSA encryption method paired with the SHA-1 hash function, which was considered secure when widely adopted in the early 2000s. Even though SHA-1 was officially deprecated in 2017 due to known vulnerabilities, many legacy email systems still use RSA-SHA1 because updating them risks breaking existing infrastructure.

How RSA-SHA1 works in email infrastructure

When email servers communicate, they often use TLS to encrypt the channel. RSA-SHA1 was a common choice for signing the digital certificates that authenticate the server's identity. Back then, SHA-1 was fast and widely supported, making it a practical default. Today, newer standards like SHA-256 are preferred because they’re resistant to collision attacks, which SHA-1 isn’t.

Despite this, millions of email systems—especially on-premise servers, older SMTP gateways, and niche email platforms—still use RSA-SHA1. Migrating to stronger algorithms is costly and complex. Some systems lack modern software updates, or their vendors haven’t released patches. For many organizations, the risk of downtime or misconfiguration outweighs the theoretical security benefit.

Why progress is slow

The internet operates on compatibility. If a server rejects a connection because it doesn’t support RSA-SHA1, the sender can’t deliver messages. That’s a real business cost. So, while new systems default to stronger signatures, older ones remain stuck in place.

Organizations that send bulk emails—especially those using third-party platforms—need to verify that their recipients’ servers still support current security standards. Tools like inbox placement testing can simulate delivery attempts across multiple mail providers, helping identify compatibility issues early.

According to the IETF’s RFC 6176, SHA-1 should no longer be used for digital signatures. Industry-wide, systems have been deprecating it since 2017. But real-world migration doesn’t happen overnight. The inertia of technical debt, limited resources, and fear of breaking workflows keep RSA-SHA1 active in production environments.

If you're sending email at scale, don’t assume your messages will be accepted everywhere. Testing delivery and configuration on real infrastructure is the only way to know. MailTester’s email checker lets you validate individual addresses and catch issues before sending, including potential TLS or domain configuration problems tied to outdated crypto.

How do modern email servers evaluate RSA-SHA1?

Modern email servers like Gmail, Outlook, and SendGrid now reject TLS handshakes and DKIM signatures that use RSA-SHA1 because SHA-1 is cryptographically broken, making it unreliable for verifying message integrity. These systems enforce current standards—like RSA-SHA256—so messages using outdated cryptography are treated as low-reputation risks, often flagged as spam or quarantined. The transition isn’t universal, though: smaller providers or internal systems may still allow RSA-SHA1, creating inconsistent behavior across the ecosystem.

Why RSA-SHA1 is no longer trusted

SHA-1 was formally deprecated by the IETF in 2011 after researchers demonstrated collision attacks. Today, any system using SHA-1 for digital signatures—especially in email—creates a known weakness attackers can exploit. Modern servers don’t just check if a signature exists; they validate that the underlying algorithm meets today’s security thresholds. RSA-SHA1 fails this validation.

When a server rejects a message for using RSA-SHA1, it’s not because of a configuration error—it’s because the cryptographic trust chain is broken. That means messages that pass through older or poorly maintained systems may slip through, while well-configured servers drop them. This inconsistency can hurt deliverability for senders who haven’t updated their infrastructure.

What this means for email senders

You’re not just sending an email—you’re sending a cryptographic promise of authenticity. If your DKIM signature relies on RSA-SHA1, you’re sending a signal that your system hasn’t kept up with industry standards. Even if your message gets delivered, it may land in spam, be throttled, or receive degraded reputation scores.

Luckily, most modern ESPs and email tools—like SendGrid and Mailchimp—now enforce stronger signing. But if you're managing your own infrastructure, you need to audit your signing keys and update them. The industry-wide shift to RSA-SHA256 is now expected, not optional. For help catching these issues early, verify your sender infrastructure with a real-time test. Run a full inbox placement test to see how your messages are evaluated by real systems across domains.

While some older systems still accept RSA-SHA1, relying on them is risky. You may get delivery today, but that window is closing. The long-term path is to use updated cryptographic standards. For reference, RFC 3161 covers time-stamping and digital signatures, and NIST SP 800-131A provides official guidance on deprecated algorithms. The message is clear: SHA-1 isn't secure anymore—not for email, not for data, and not for identity proof.

How does RSA-SHA1 affect email deliverability?

Messages signed with RSA-SHA1 are increasingly blocked or marked as suspicious by modern email servers, even if the email address is valid. This happens because RSA-SHA1 is considered cryptographically weak, and many servers now reject such signatures outright. As a result, even well-maintained lists and strong sender reputations won’t prevent deliverability issues if your encryption is outdated.

Why outdated signatures trigger rejections

While RSA-SHA1 was once standard, it’s no longer secure by industry standards. Major providers like Google, Microsoft, and Apple have phased out support for it in their mail systems, especially when verifying DKIM signatures. If your email uses RSA-SHA1 and is routed through one of these systems, it may not just be filtered—it may be outright rejected.

Let’s be clear: this isn’t about your domain’s reputation, list hygiene, or sender IP blacklisting. It’s a protocol mismatch—your message fails not because you’re spammy, but because it doesn’t meet current cryptographic requirements. This can lead to sudden drops in inbox placement or spikes in hard bounces, often without obvious cause.

How to find and fix the issue

You might not know your emails are failing unless you test across multiple real-world mail servers. Generic tools or email validators won’t catch this kind of cryptographic mismatch—they only check syntax or existence. Real deliverability testing shows how your emails actually land, including whether signature-level checks block them.

Use a tool that simulates real-world inbox delivery and checks for issues like weak signing. For example, MailTester’s inbox placement testing lets you send messages through major providers like Gmail, Outlook, and Apple Mail to see how they respond. This gives you a clear picture of whether RSA-SHA1 is affecting your results. Test your message in real inboxes before sending to your list.

For ongoing checks, use the bulk verification tool to scan your list and identify any domains or addresses using outdated verification methods. While you can’t fix the signing method on the fly, identifying weak links helps you plan updates. RFC 8301 (and the broader IETF community) has formally deprecated SHA-1, so moving to stronger algorithms like SHA-256 is not optional—it’s necessary for reliability. Read the RFC for the full technical background on why this shift happened.

How can you verify if an email address is safe despite RSA-SHA1 use?

Use a real-world email verification service like MailTester that tests delivery behavior across live email servers—including how they handle older TLS handshake methods like RSA-SHA1. A valid-looking address can still bounce or land in spam if the recipient server rejects messages signed with outdated cryptographic methods. Only a live test during actual transmission reveals whether an email will be accepted, regardless of syntax or domain records.

Why syntax checks aren’t enough

Just because an address passes syntax and domain checks doesn’t mean it will deliver. Many servers still accept RSA-SHA1 for backward compatibility, but others now reject it outright. This inconsistency means an address marked “valid” by a basic validator might fail silently in production. Tools that only check format or DNS records don’t simulate actual mailbox behavior.

MailTester goes beyond basic validation. It checks not just syntax, domain existence, and MX records, but also how real servers respond during a live SMTP transaction. This includes observing the TLS handshake, watching for rejection codes after authentication, and tracking whether the server accepts or declines the message based on cipher suite support.

For instance, a server may accept a message with RSA-SHA1 during negotiation but reject it after the handshake if it enforces updated policy at the mail delivery stage. MailTester captures these nuances by querying actual infrastructure, like Gmail’s, Yahoo’s, and Outlook’s, across different regions and configurations. This gives a clearer picture of real inbox placement than any static rule-based check.

The same applies to catch-all domains, greylisting, and role-based addresses—all of which can pass basic checks but fail in delivery. MailTester’s approach reveals whether a recipient will actually accept an email, not just whether it’s structurally correct. This is especially critical when dealing with legacy systems that still support RSA-SHA1, even as modern gateways phase it out.

Test a single email address to see whether it will be accepted by real servers, including those that have strict security policies. Use our bulk verification if you're cleaning a large campaign list, or leverage the inbox placement testing to simulate how your message lands in actual inboxes.

For deeper context, refer to the ongoing evolution of TLS and PKI standards as defined in RFC 8998—which outlines deprecated cipher suite usage in email systems. While RSA-SHA1 is still tolerated in some deployments, adoption of stronger algorithms like RSA-SHA256 is accelerating. The only way to know for sure whether your message will be delivered is to test it where it matters: with the actual mail servers.

How to check if your sending setup uses outdated cryptosignatures

You can verify whether your email setup uses RSA-SHA1 by checking your DKIM public record and reviewing TLS handshake logs. If your DKIM selector or key includes rsa-sha1, or if your outbound server logs show SHA-1 during TLS negotiation, you’re using a deprecated algorithm. Upgrading to SHA-256 or better is necessary to maintain inbox placement and avoid rejection by modern email providers.

Check your DKIM configuration

  1. Locate your DKIM public TXT record in your DNS zone. Use a tool like MXToolbox or your domain registrar’s DNS editor to retrieve it.
  2. Look for the algorithm=rsa-sha1 value in the record. If it’s present, your domain is signing messages with an outdated cryptosignature.
  3. Compare this with the current standard: RFC 8301 requires SHA-256 or better for new DKIM implementations. RSA-SHA1 is now deprecated and no longer recommended.

Validate TLS handshake behavior

  1. Use OpenSSL to examine outgoing TLS connections from your mail server: openssl s_client -connect mail.example.com:587 -starttls smtp.
  2. Check the output for handshake agreements using SHA1 or rsa-sha1 in cipher suites. If found, your server is negotiating with outdated security parameters.
  3. For a real-time simulation, send a test message through MailTester’s inbox placement tool. It returns detailed reports on how your message is handled by major providers, including whether SHA-1-related warnings were logged during delivery.

If you confirm your setup still relies on SHA-1, update your DKIM key pair to use SHA-256 or higher. Most email platforms allow you to reconfigure your DKIM settings in the administration console. Be sure to publish the new TXT record and allow time for propagation before disabling the old key.

Legacy systems, especially older on-premise mail servers or poorly maintained third-party integrations, may still enforce RSA-SHA1. If you’re using a service like SendGrid, Mailchimp, or HubSpot, check their documentation for DKIM key generation guidance—most have moved to SHA-256 by default.

While some older email servers may still accept RSA-SHA1, modern providers increasingly reject messages with weak cryptosignatures. This isn’t just about compliance—it’s about deliverability. Proactively upgrading your cryptographic standards reduces rejection risks and improves sender reputation over time.

What are the real-world risks of sending with RSA-SHA1?

Using RSA-SHA1 in email security is like sending a letter with a known outdated lock—many modern mail servers will reject it outright, leading to high bounce rates. Even if your message gets through, outdated signature algorithms signal poor sender hygiene, increasing the odds of landing in spam folders. Over time, this damages your sender reputation, especially when no real-time delivery test confirms the outcome. Email verification tools won’t catch this: only live delivery behavior reveals whether your messages are blocked.

Why RSA-SHA1 still appears in mail flows

Some old infrastructure or misconfigured systems still accept RSA-SHA1—largely due to legacy software, lack of monitoring, or poor policy enforcement. But it’s not a safe bet. You might get through today, but many receiving servers now block or flag messages using outdated cryptographic standards. The real risk isn’t just rejection—it’s long-term damage that’s hard to trace.

  • High bounce rates when receivers enforce modern TLS standards: many mail servers (including Microsoft, Google, and iCloud) no longer accept RSA-SHA1 in TLS handshake negotiations. RFC 8998 explicitly discourages its use.
  • Increased spam filtering risk: outdated cryptographic signatures are commonly associated with low-quality or compromised senders. Even if not rejected, such mail is more likely to be marked as suspicious.
  • Gradual sender reputation damage: even if your messages deliver, receiving servers use cryptographic health as part of reputation scoring. A consistent pattern of weak signature algorithms reduces trust over time—visible only in deliverability trends, not in bounce logs.
  • Verification tools can’t predict real-world delivery: services like MailTester’s email checker can confirm syntax and basic validity, but not how a modern receiver will treat a message with RSA-SHA1. Only sending to real domains and monitoring deliverability reveals true risk.
  • No direct fix in verification logic: no tool can flag RSA-SHA1 as a risk during address validation. The flaw lies in the sending stack, not the address itself.

How to test what actually happens

Let’s be clear: you don’t know unless you send. Static checks won’t show you the full picture. The only way to confirm if RSA-SHA1 is blocking your messages is through inbox placement testing. Use a service like MailTester’s inbox placement tool to send real messages to known mailboxes across major providers and track whether they arrive, land in spam, or get rejected.

How does MailTester help catch RSA-SHA1 issues before sending?

MailTester catches RSA-SHA1 issues by sending real emails through live mail servers during inbox-placement testing. It doesn’t rely on theoretical checks—it observes actual delivery behavior, flagging addresses that accept messages with outdated signatures like RSA-SHA1, even if those signatures are now deprecated. This reveals which addresses will silently fail in practice, regardless of whether they pass syntax or basic validation.

Real-world delivery behavior beats theoretical validation

You might pass all syntax checks, but that doesn’t mean your email will land in the inbox—if the recipient server still supports RSA-SHA1 for legacy systems, it might accept your message. But if it doesn’t, your email gets silently dropped or quarantined. MailTester tests exactly this: it sends messages through real mail infrastructure and logs whether the server accepts, rejects, or holds your email. This includes edge cases like servers that accept old signatures but block them from reaching the inbox.

For example, some older enterprise mail systems still accept RSA-SHA1-signed emails for inbound messages due to backward compatibility, while newer systems like Gmail or Outlook reject them outright. Without testing, you’d have no way of knowing. MailTester’s inbox placement test reveals these behaviors by simulating real sends—no assumptions, no guesswork.

Bulk verification surfaces hidden delivery risks

When combined with bulk verification, MailTester identifies addresses that pass basic checks (valid syntax, active domain) but fail delivery due to cryptographic incompatibility. These are the "theoretically valid" addresses that won’t work in real-world delivery. You’re not just checking whether an address exists—you’re testing whether it accepts your message, which is far more meaningful.

Let’s say your list includes an old employee email that still exists but is hosted on a legacy email server. The server might accept RSA-SHA1—so your email gets accepted, but ends up in quarantine or spam. MailTester spots this early by observing the full delivery journey. You can then exclude or update those addresses before sending.

Learn more about how this works in practice: test inbox placement with real messages before your campaign goes live. It’s not just about syntax or domain health—it’s about whether your message reaches the inbox, or falls through a gap in security policy. The Internet Engineering Task Force (IETF) has documented the deprecation of SHA-1 in RFC 7457, but real-world support varies widely. Testing is the only way to know for sure.

What are the practical steps to fix RSA-SHA1 dependencies?

You can resolve RSA-SHA1 issues by reviewing your DKIM records, replacing any rsa-sha1 keys with RSA-SHA256 or ed25519, updating your DNS records, verifying the changes with a DNS debugger, and monitoring deliverability. This reduces the risk of rejection by major mail providers like Gmail and Yahoo, who now increasingly filter or reject messages with weaker signatures.

Step-by-step: Update your DKIM configuration

  1. Check your current DKIM keys using a DNS lookup tool or your email provider’s admin panel. Look for the selector and alg fields in your DKIM TXT record. If the alg is set to rsa-sha1, it’s outdated and may trigger rejection.
  2. Generate a new DKIM key pair using a secure algorithm like RSA-SHA256 or ed25519. These are widely supported today and meet modern security standards. Tools like OpenSSL or your ESP’s key manager can create these.
  3. Update your DNS record with the new public key. Most ESPs allow multiple DKIM keys to coexist during transition, but ensure the new record is correctly formatted and published.
  4. Verify the DNS record with a tool like MXToolbox’s DNS lookup or RFC 6376 (which defines DKIM). Confirm the record is live and returns the expected values, including the correct algorithm.
  5. Test email deliverability after the change. Use an inbox placement tester like the MailTester Inbox Placement Tool to send test messages through Gmail, Yahoo, and Microsoft mail systems. Monitor bounce rates and inbox placement over 48–72 hours.

Why this matters now

Email providers like Google and Microsoft are deprecating legacy cryptographic standards. While RSA-SHA1 still works in some environments due to backward compatibility, many now block or flag messages using it. This isn’t about technical failure—it’s about security posture. Mail systems that continue to accept rsa-sha1 are often behind in compliance and threat mitigation.

Switching to SHA256 or ed25519 reduces the chance of spam classification and improves authentication alignment with DMARC, which is critical for high-volume senders. For businesses running bulk campaigns, this change is not optional—it’s foundational to consistent delivery.

Is RSA-SHA1 still acceptable for internal or low-sensitivity mail?

Even if your internal email system uses RSA-SHA1, it’s no longer safe to assume that traffic will be accepted—many cloud email gateways now block or flag it as insecure, regardless of message sensitivity. Relying on outdated crypto increases the risk of accidental routing to low-trust zones or rejection, even for internal mail. The best practice is to upgrade to SHA-256 or newer standards across all systems, whether public-facing or internal.

Cloud gateways don’t distinguish between internal and external mail

Modern email security gateways—including those run by Microsoft, Google, and other major platforms—apply consistent policies to all inbound traffic. If a message arrives with a signature using SHA-1, the gateway may flag it as non-compliant, even if it’s destined for an internal user. This is because RSA-SHA1 is considered cryptographically weak and no longer aligned with industry standards like RFC 8301.

It’s not just about the message content. Even a compliant email with an outdated signature can be quarantined, especially when sent through third-party services. The signal may be treated as a red flag, regardless of whether the mail is from HR or IT. This happens because modern gateways prioritize consistency and defense-in-depth over exceptions for low-risk messages.

Legacy standards increase unintentional delivery failures

Using RSA-SHA1 in any environment introduces unnecessary risk. While the data might be internal, the path it takes—through gateways, firewalls, or cloud filtering engines—often doesn't preserve that context. What starts as a routine internal update may end up blocked or rerouted simply because of the algorithm used in the digital signature.

For example, even a well-configured on-premise server sending to a trusted recipient via Exchange Online may fail delivery if the message includes a SHA-1-based signature. The recipient’s system will apply security checks that don’t care about internal status—only the cryptographic strength.

Avoiding this requires upgrading to current standards, like SHA-256 for signing and TLS 1.2+ for transport. This isn’t just about perception—it’s about measurable compliance. You don’t need to know what a "weak" algorithm is to be affected by it. As long as systems still support SHA-1, the risk of unintended blockages remains.

And here’s the practical fix: test your email setup early. Tools like inbox placement testing help you see how your messages are treated in real-world conditions, including signature validation. It’s easy to overlook cryptographic details when sending a message to an internal team—but if the system can’t recognize the signature, the delivery fails regardless of intent.

There’s no need to wait for a breach to act. Upgrading the signature standard now reduces your attack surface and aligns with modern infrastructure expectations. Internal mail isn’t immune to security policies—even if it’s not public, it still goes through the same filters. Keep your systems future-proof by moving off RSA-SHA1 today.

The bottom line: don’t trust validity alone—test delivery

Just because an email address passes syntax and domain checks doesn’t mean it will deliver. Some servers still accept RSA-SHA1 signatures, but others reject them outright—leading to silent bounces even for valid-looking addresses.

MailTester’s 98.9% accuracy isn’t just about catching invalid formats. It includes real-world behavior testing across active mail servers, revealing whether an email will actually land in the inbox or be blocked by crypto policy.

You don’t need to understand SHA-1’s lifecycle to fix deliverability. What matters is knowing if your email reaches the user. Verification is not just about correctness—it’s about confirmation that your message will be received.

Sources

Keep reading

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

Frequently asked questions

Does RSA-SHA1 still work for email delivery in 2026?

Some older or internal servers may still accept it, but most modern providers block or quarantine messages using RSA-SHA1 due to known cryptographic weaknesses.

Can mail verification tools detect RSA-SHA1 issues?

Standard tools only validate syntax and existence. Only deliverability testing with real server interaction can expose RSA-SHA1 rejection.

What is the safest DKIM signing algorithm to use?

RSA-SHA256 or ed25519 are recommended. These are widely supported, secure, and required by most major email providers.

Why does my email bounce even though the address is valid?

The address may be valid, but your signing method (like RSA-SHA1) could cause server-level rejection during TLS or DKIM validation.

How do I know if my mail server uses RSA-SHA1?

Check your DKIM TXT record for 'rsa-sha1' in the algorithm field. Use a DNS tool to inspect the record or test with an email authentication checker.

Is SHA-1 still used in any modern email systems?

It persists in some legacy environments, but all major email providers enforce SHA-256 or better for inbound mail in 2026.

Can I test RSA-SHA1 issues without sending real emails?

No—only real transmission to actual servers reveals TLS handshake rejections. Testing tools that simulate mail are not reliable for this.

How does MailTester improve deliverability beyond basic verification?

It tests across real inbox environments and detects issues like outdated crypto signatures that static checks miss.

What happens if I don’t update from RSA-SHA1?

Your emails will increasingly be blocked by modern servers, leading to delivery failure, reduced sender reputation, and poor campaign performance.

Are disposable or role email addresses affected by RSA-SHA1?

No—the RSA-SHA1 issue is unrelated to address type. It affects any sender using outdated signature methods, regardless of recipient characteristics.

Can SPF or DMARC fix RSA-SHA1 delivery issues?

No. SPF and DMARC only validate domain and authentication policies. RSA-SHA1 issues occur during transport and are not caught by these protocols.

Is there a list of email providers that reject RSA-SHA1?

Yes—Gmail, Yahoo, Outlook, and SendGrid all reject such messages, but enforcement varies by implementation and time of update.