Why RSA-SHA1 in Email Authentication Is No Longer Secure

You send a message, confident it arrives as intended. But what if an attacker could forge a signature that looks identical to your valid one — and your email system still accepts it as real? That’s the risk of RSA-SHA1 in email authentication.

Once standard for digital signatures in email, RSA-SHA1 is now broken. Since 2017, known vulnerabilities in SHA1 have made it possible to create two different inputs with the same hash — a collision. Attackers exploit this to forge DKIM signatures, making spoofed messages appear legitimately signed.

This undermines the foundation of email security: SPF, DKIM, and DMARC. If a signature can be forged, these protocols fail. An attacker can impersonate your domain, and your inbox filters may not catch it. The security implications are not theoretical — they’re active, and they’re growing.

Key takeaways

  • RSA-SHA1 is cryptographically broken due to SHA1 collision vulnerabilities demonstrated in 2017.
  • Attackers can forge DKIM signatures using SHA1 weaknesses, allowing spoofed emails to pass validation.
  • Forced reliance on RSA-SHA1 undermines SPF, DKIM, and DMARC, enabling undetected domain impersonation.

How RSA-SHA1 Exposure Undermines DKIM Authentication

Using RSA-SHA1 in DKIM signing creates a critical vulnerability: attackers can exploit known SHA-1 collision weaknesses to craft two different messages with the same hash, then reuse a valid signature from one to forge the other. This allows malicious emails to pass DKIM validation and appear fully legitimate, bypassing filters and undermining trust in your domain’s digital identity.

DKIM’s Role and Why Signature Integrity Matters

Digital signatures in DKIM authenticate email by proving a message originated from an authorized domain. When a receiving server checks the signature, it verifies the domain’s public key and ensures content hasn’t been altered. This process only works if the underlying cryptography is unbroken.

But when RSA-SHA1 is used, that trust erodes. SHA-1 has been known to be cryptographically weak since at least 2011, when researchers demonstrated practical collision attacks. In theory, two distinct emails can be constructed with identical SHA-1 hashes. If an attacker can obtain a legitimate signature for one message, they can reuse it on the forged version—without breaking the private key.

Attackers Exploit the Flaw Without Hacking Your Server

The danger isn’t from compromising your infrastructure. It’s that the algorithm itself is flawed. An attacker doesn’t need your private key. They just need to find a collision pair—one valid, one malicious—and replace the content while keeping the signature. Since the hash matches, DKIM validation passes.

Because DKIM signatures are often long-lived (some last weeks), a single forged signature can validate dozens of attacks. Even with strong SPF and DMARC policies, a valid DKIM signature can still grant an attacker credibility in the eyes of receiving servers. This is why the broader email security community has moved away from SHA-1.

As outlined in RFC 8301 and confirmed by NIST, SHA-1 is deprecated for digital signatures in all new systems. Email platforms like Google, Microsoft, and Yahoo have phased out support for SHA-1 in DKIM validation. But legacy systems, especially in older email platforms and poorly maintained configurations, may still accept it.

Let’s be clear: if your organization still signs DKIM with RSA-SHA1, your domain is at risk of being misrepresented—even if you haven’t been breached. The signature itself is the weakness.

If you're managing a sender infrastructure, checking your DKIM setup for weak algorithms is part of maintaining a good reputation. You can test your domain’s email security posture with real-world delivery checks. Use the inbox placement tester to simulate real-world reception and see if your domain’s DKIM policy passes current standards.

Impact on DMARC and Sender Reputation

Using RSA-SHA1 in email authentication weakens DMARC enforcement because attackers can forge DKIM signatures with known vulnerabilities, making malicious messages appear legitimate. Even though the domain’s DKIM key is valid, the underlying flaw lets attackers bypass checks—so DMARC reports show compliance while the domain is actually compromised. This erodes trust in authentication, harms sender reputation, and can lead to false negatives in security monitoring.

How RSA-SHA1 Weaknesses Undermine DMARC Checks

DMARC relies on valid DKIM signatures to confirm that an email was sent from an authorized source. If an attacker exploits RSA-SHA1’s cryptographic weaknesses, they can generate a valid-looking DKIM signature without access to the private key. This means a forged email from your domain can pass DKIM validation, and DMARC will treat it as compliant—despite being malicious.

Let’s be clear: DMARC doesn’t verify the strength of the signing algorithm—it only checks if the signature matches. When RSA-SHA1 is used, this check passes even if the signature was generated using a known collision attack. As a result, email systems accept the message, and the domain’s reputation appears intact, even though it's being exploited.

Consequences for Sender Reputation and Trust

When malicious emails pass DMARC checks due to faulty signatures, legitimate senders suffer. Systems that rely on DMARC reports for reputation scoring may label your domain as trustworthy—even if it’s compromised. This leads to false positives in compliance data and undermines confidence in your domain’s security posture.

Over time, this kind of deception damages sender reputation. If your domain starts showing up in abuse reports, blocklists, or inbox placement drops, the root cause might be invisible to you—because the authentication chain appears correct. It's not a failure of sending, but of outdated cryptography.

Fixing this starts with retiring RSA-SHA1 in DKIM. Major industry players, including Google and Microsoft, now require newer algorithms like RSA-SHA256. You can check your setup with tools that validate signature strength and alignment. For example, RFC 8301 details the move away from SHA1 in digital signatures.

Using tools like MailTester, you can verify your domain’s compliance before sending. Their real-time verification API and bulk checker help identify misconfigurations and vulnerable key setups. You can run a quick test at their single email checker to validate the integrity of your domain’s authentication chain.

What Organizations Should Do About Legacy RSA-SHA1 Implementations

You must audit and replace all RSA-SHA1 signatures in DKIM configurations immediately. Legacy RSA-SHA1 is cryptographically weak and increasingly rejected by modern mail systems. Replace it with RSA-SHA256 or ECDSA (like ES256) on every outbound mail server, and verify that your email platforms enforce secure signing by default.

Step-by-Step Remediation

  • Run a full audit of your outbound email infrastructure to identify domains still using RSA-SHA1 for DKIM signing. Check your mail server logs, DNS records, and third-party sending platforms.
  • Update your DKIM key generation process to produce RSA-SHA256 or ES256 signatures. These are industry-standard, widely supported, and not deprecated.
  • Replace older DKIM keys on all sending servers. This includes on-premise systems, AWS SES, and cloud-based marketing tools like Mailchimp, HubSpot, and SendGrid.
  • Verify that your email service providers support modern signing methods and configure them explicitly. Many platforms still default to RSA-SHA1 in legacy setups — confirm the change is active.
  • Monitor email deliverability and bounce logs for unexpected failures after updating. A small number of older mail transfer agents may still reject newer signatures, but those are exceptions, not norms.
  • Test your new DKIM setup using publicly available tools, like the MXToolbox DKIM Check or the RFC 8301 compliance guide, to confirm proper configuration.

Protecting Your Sending Reputation

For organizations using third-party senders, ensure they do not silently fall back to RSA-SHA1 when new domains are added. Use your own pre-send verification to catch invalid or risky addresses early — tools like bulk email list verification help detect issues before they impact your sender reputation.

How Email Verification Tools Like MailTester Help Prevent Crypto-Based Exploits

You can’t stop every cryptographic vulnerability in email infrastructure, but you can stop sending to addresses that rely on outdated, broken protocols like RSA-SHA1. Tools like MailTester help by filtering out domains and addresses tied to insecure authentication practices before they ever reach your inbox — reducing exposure to known weaknesses and preventing misuse of legacy systems. This isn’t about replacing encryption; it’s about cutting off the path to systems that still depend on outdated, vulnerable methods.

Spotting Insecure Infrastructure Before It’s Used

When you send email to a domain using RSA-SHA1 for authentication, you’re trusting a protocol that’s been deprecated for years. SHA-1 collisions are computationally feasible, and RSA-SHA1 has been shown to be vulnerable in real-world attacks. Even if your own setup is secure, hitting a server still using it opens you up to potential relay misuse or interception through weaker infrastructure.

MailTester’s real-time API checks don’t just validate syntax or domain existence — they examine the underlying security posture. By identifying domains that still rely on outdated crypto practices, the tool flags them as risky. You then have the choice to block or review those addresses before sending, reducing the chance your email becomes part of a larger exploit chain.

While standards like RFC 3279 and RFC 4055 define when and how RSA-SHA1 should be phased out, many systems continue to support it for backward compatibility. This is where verification helps: it’s not about enforcing compliance directly, but about surfacing environments that are likely still using compromised methods.

Reducing Exposure to High-Risk Addresses

Every bad address you send to is a potential vector for abuse — especially if it’s a role account, disposable domain, or catch-all mailbox. These are commonly used in phishing campaigns, and often hosted on infrastructure that hasn’t adopted modern security controls. Sending to them doesn’t just hurt deliverability; it risks your domain reputation and can expose you to spoofing or abuse-related blocklists.

MailTester’s 98.9% accuracy rate comes from combining live SMTP checks, DNS validation, and heuristic analysis. This means it can identify not just invalid or disposable addresses, but also those that are catch-all — which are frequently abused — or high-risk due to their infrastructure. You’re not just cleaning your list; you’re eliminating exposure to environments where weak protocols like RSA-SHA1 are still in use.

Use the bulk email list verification to proactively vet entire campaigns. Or integrate the real-time verification API into your send flow to block riskier domains instantly. Either way, you're building a send pipeline that avoids the weakest links — cryptographic and otherwise.

Best Practices for Email Authentication Security in 2025 and Beyond

You should retire RSA-SHA1 immediately, use SHA-256 or better for DKIM, monitor DMARC reports for anomalies, rotate DKIM keys regularly, and decommission old key sets. These steps reduce the risk of spoofing, ensure alignment with modern standards, and prevent long-term exposure. Legacy algorithms like RSA-SHA1 offer no meaningful security and are deprecated by industry leaders.

Modern Cryptographic Standards

  • Use SHA-256 or higher for DKIM signatures. These algorithms resist collision attacks and are recommended by RFC 8301 as the baseline for new deployments.
  • Avoid RSA-SHA1 entirely in new email authentication setups. It has no known path to recovery and is no longer trusted by modern email providers and security frameworks.
  • Ensure your signing keys are at least 2048 bits long and avoid RSA altogether when possible—ECDSA with SHA-256 offers stronger security with smaller key sizes.

Proactive Monitoring and Key Management

  • Review DMARC aggregate reports at least weekly. Look for unexpected alignment failures, spikes in signed mail from unknown sources, or high rejection rates—early signs of misconfiguration or compromise.
  • Rotate DKIM keys every 90 to 180 days. Shorter cycles reduce the window of exploitation if a key is leaked.
  • Disable old DKIM key sets immediately upon deprecation. Leaving them active risks bypassing authentication if attackers reuse expired keys in spoofing attempts.
  • Use a tool like MailTester’s email checker to validate individual addresses before sending, ensuring your outbound messages are not flagged by filtering systems due to invalid or poorly authenticated domains.
“Cryptographic algorithms degrade over time. What’s secure today may be broken tomorrow—stay ahead through disciplined key rotation and updated standards.”

Why Sender Reputation Depends on Proper Authentication Setup

You can’t have strong sender reputation if your email authentication is built on outdated cryptography. Even if your messages are harmless and your content is on-brand, using weak signature methods like RSA-SHA1 signals poor security hygiene. Mail providers flag these domains in reputation systems, which increases the chance your emails land in spam or graymail folders — regardless of quality or engagement. Your inbox placement isn’t just about content; it’s about trust, and trust starts with proper tech standards.

How Providers Validate Trust with Cryptography

Mail providers like Gmail, Outlook, and Yahoo use cryptographic validation to assess whether a sender is legitimate. They check SPF, DKIM, and DMARC records — all of which rely on digital signatures to verify origin. When these signatures use outdated algorithms like RSA-SHA1, providers treat them as a red flag. Even if your domain hasn't been breached, the algorithm itself is deprecated because it's no longer considered secure against modern attacks.

For example, the Internet Engineering Task Force (IETF) deprecated RSA-SHA1 in RFC 8398, citing its vulnerability to collision attacks. Major platforms now prioritize signals from systems using stronger algorithms like SHA-256. If your domain still uses RSA-SHA1, your email may be treated as suspicious, even when sent from a well-known, compliant address.

Reputation Systems Catch Weak Signals Early

Reputation systems track technical hygiene as much as user behavior. A domain using outdated cryptographic methods can receive a reputation penalty, even without spam complaints or high bounce rates. This happens because weak signatures suggest a broader pattern of lax security — the kind that often precedes abuse.

Once flagged, your messages get routed through deeper filters. They are less likely to hit the primary inbox and more likely to end up in a folder labeled "Social" or "Promotions." This impacts open rates and engagement, even if your content is perfect. The system doesn’t assess intent — it assesses risk, and RSA-SHA1 is a known risk.

Let’s be clear: you don’t need to wait for an attack to fix this. Modern tools like bulk email verification can identify invalid or poorly configured addresses early — including those tied to domains using weak signatures. Proactively checking your list ensures your authentication setup isn’t dragging down your deliverability.

Understanding the Role of SPF, DKIM, and DMARC in Email Security

You rely on SPF, DKIM, and DMARC to validate that an email genuinely comes from its claimed sender. SPF checks the sending IP against domain records. DKIM cryptographically signs the message body and headers to ensure the content hasn’t been altered. DMARC combines SPF and DKIM results and tells receiving servers what to do if either fails. All three depend on strong crypto — using outdated algorithms like RSA-SHA1 weakens the entire chain and opens doors to spoofing and bypassing security controls. Let’s look at how they work together.

How Each Protocol Works

SPF acts as a whitelist. When an email arrives, the receiver checks your domain’s TXT record to see if the sending IP is authorized. It only checks the envelope sender (MAIL FROM), not the visible "From" address — which is a common point of confusion.

DKIM works differently. It signs parts of the email with a private key and publishes the corresponding public key in your DNS. Receiving servers use that key to verify the signature. If the content was changed in transit — even a single character — the signature fails.

DMARC is where enforcement happens. It tells receivers how to handle emails that fail SPF or DKIM. You can set it to monitor-only (no action), quarantine, or reject. It also provides reports on who’s sending on your behalf, helping you detect spoofing attempts.

Why Crypto Matters: The RSA-SHA1 Problem

Both DKIM and DMARC can be undermined by weak cryptographic standards. RSA-SHA1, once considered secure, is now vulnerable to collision attacks. Modern systems should use RSA-SHA256 or, better yet, ECDSA with SHA-256. Using RSA-SHA1 in DKIM signatures breaks trust — a malicious actor can forge a valid signature without detection. You can’t validate authenticity if your signature algorithm is broken.

Protocol What It Validates How It Works Reliance on Strong Crypto
SPF Sender IP address Checks published TXT records in DNS Minimal — relies on DNS integrity
DKIM Message integrity and origin Signs content with a private key, verified with public key in DNS High — requires SHA-256 or better for signatures
DMARC Policy compliance Uses SPF and DKIM results to decide delivery action Dependent on validity of SPF/DKIM

Using RSA-SHA1 in DKIM undermines everything. Even if SPF passes and DKIM syntax checks, a forged signature can slip through if the algorithm is broken. This isn’t theoretical — RFC 8301 explicitly advises against using SHA-1 in cryptographic signatures.

Before sending to a large list, use a tool to catch invalid or risky addresses — including those from domains relying on outdated crypto. Bulk verification tools can help identify problematic emails early, protecting your sender reputation and inbox placement.

How to Test Inbox Placement and Security Readiness Using Real-World Checks

You can verify if your emails land in inboxes and meet modern security standards by sending real test messages through Gmail, Outlook, and Apple Mail via MailTester’s inbox placement service. This reveals how your domain’s cryptographic practices—like avoiding outdated algorithms such as RSA-SHA1—affect delivery and spam filtering. Combine this with domain-level checks to ensure your infrastructure supports current security protocols.

Step-by-Step: Real-World Inbox and Security Testing

  1. Send test emails through MailTester’s inbox placement tool. Choose targets like Gmail, Outlook, and Apple Mail. Each message goes through actual receiving infrastructure, not simulators. This tells you if your sending domain passes real-world filters, including those that penalize weak crypto.
  2. Check delivery outcomes and spam placement rates. The report shows whether emails landed in inboxes, spam folders, or were blocked. High spam placement often correlates with poor sender reputation and outdated authentication practices like RSA-SHA1, which many email providers now flag or restrict.
  3. Run a full domain-level verification. Use MailTester’s domain verification to validate SPF, DKIM, and DMARC configurations. These controls are essential for email security. If your domain doesn’t support modern signature algorithms (like SHA-256), your messages may fail authentication even if the address is valid.
  4. Review cryptographic configuration in relation to your results. If RSA-SHA1 is still in use—especially for DKIM signatures—this can cause rejection by modern mail servers. Tools like RFC 8314 discourage the use of SHA-1 in security-critical contexts. Test results showing repeated rejections may point to this flaw.
  5. Fix and re-test using the same inbox placement tool. Update your signing keys to use SHA-256, verify the new configuration, and send a new batch of test emails. Repeat until delivery rates stabilize in inboxes across all providers.

Why This Matters

Many security vulnerabilities in email stem not from code, but from outdated infrastructure. You can’t trust a single verification result—your domain must pass both technical and contextual checks. MailTester’s inbox placement service combines real message delivery with real-time feedback, so you’re not guessing whether your security choices are actually protecting the delivery of your messages.

For teams with large sending volumes, pair these tests with automated verification using the verification API or bulk list cleaning via bulk verification, so only valid, secure recipients receive your messages.

The Bottom Line: Fixing RSA-SHA1 Is Part of Protecting Your Brand

Outdated algorithms like RSA-SHA1 weaken email authentication, making your domain vulnerable to spoofing and abuse. This risk isn’t theoretical — it directly impacts inbox placement, sender reputation, and customer trust.

Modern email verification tools detect insecure configurations, identify high-risk addresses, and expose domains still relying on deprecated protocols like RSA-SHA1. These insights are critical for maintaining deliverability in an environment where reputation is everything.

Updating your email authentication stack is not a technical footnote — it’s foundational. Without it, you’re exposing your brand to impersonation, blocklists, and long-term sender degradation.

Sources

Keep reading

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

Frequently asked questions

Is RSA-SHA1 still used in email authentication today?

Yes, legacy systems and outdated configurations still use RSA-SHA1, especially in older mail infrastructure. However, it is no longer considered secure.

Can a compromised DKIM signature with RSA-SHA1 lead to email spoofing?

Yes. Due to known SHA1 collision vulnerabilities, attackers can forge valid-looking DKIM signatures, allowing spoofed emails to bypass filters.

How do I know if my domain uses RSA-SHA1 for DKIM?

Check your DKIM public key records using DNS lookup tools. Look for the algorithm tag; if it specifies 'rsa-sha1', replacement is required.

What replaces RSA-SHA1 in DKIM signing?

Stronger algorithms like RSA-SHA256, ECDSA (ES256), or RSA-SHA384 are recommended. These are resistant to known cryptographic attacks.

Does MailTester detect outdated authentication methods?

MailTester does not directly scan for cryptographic algorithms, but its verification process identifies domains with poor infrastructure or high risk, which often correlate with outdated practices.

How does list hygiene affect email security?

Sending to invalid, role, or disposable addresses increases exposure to malicious infrastructure. Clean lists reduce risk from compromised endpoints.

What happens if a domain uses RSA-SHA1 but has no known breaches?

Even without active breaches, the cryptographic weakness remains. Attackers can exploit it at any time, leading to impersonation or spam distribution.

Why is SPF not affected by RSA-SHA1 vulnerabilities?

SPF uses DNS record matching, not cryptographic signing. It is unaffected by hash algorithm weaknesses like those in RSA-SHA1.

How often should I rotate DKIM keys?

Best practice is to rotate DKIM keys every 6 to 12 months, or immediately if a key is exposed, to limit the window of compromise.

Are there tools to scan email authentication setups for insecure algorithms?

Yes — domain security scanners like MxToolbox, DMARCian, and DNSCheck can evaluate DKIM configuration, including algorithm strength.