What happens when SHA-1 is still used in DKIM today?

You send a transactional email. It’s properly formatted, authenticated, and reaches the recipient’s inbox—except it doesn’t. The bounce message says “DKIM signature verification failed.” You check your settings, reconfigure your domain, and still see the same result. Why?

Because your DKIM signature is using SHA-1, a hashing algorithm that’s been deprecated for years. Modern email providers like Gmail, Yahoo, and Outlook no longer trust it—regardless of whether the signature is technically valid. The underlying cryptographic vulnerabilities make it too easy to forge signatures, so they reject anything using SHA-1 outright.

That rejection isn’t temporary. It’s permanent. Your messages fail DKIM checks, hurt your sender reputation, and can trigger blocklist entries. Even if everything else is correct, SHA-1 is a one-way ticket to delivery failure.

Key takeaways

  • Major email providers like Gmail and Outlook reject DKIM signatures using SHA-1 due to known cryptographic weaknesses.
  • Even valid SHA-1 signatures will fail verification—this is not a configuration error, but a deliberate policy.
  • Migrating to SHA-256 in DKIM is required to maintain deliverability and sender reputation.

Why did SHA-1 work in DKIM, and why is it now obsolete?

SHA-1 was used in early DKIM implementations because it was fast and required minimal processing power. By 2017, researchers demonstrated practical collision attacks, proving it was possible to forge legitimate-looking messages without accessing the private key. As a result, NIST and the IETF formally deprecated SHA-1 in cryptographic protocols, including DKIM, due to its inability to guarantee message integrity.

How SHA-1 worked in DKIM

Digital signatures in DKIM rely on hashing the email content and signing it with a private key. SHA-1 was chosen initially because it computed digests quickly and consumed little memory—ideal for systems with limited compute capacity in the early 2000s.

Each email domain could sign its outgoing messages using a private key, and receivers would verify the signature by hashing the same content with the public key from DNS. As long as the hash matched, the message was considered authentic.

Why SHA-1 is no longer trusted

That changed in 2017 when Google’s team published the first known collision attack on SHA-1, showing that two different inputs could produce the same hash output. This meant an attacker could craft a malicious email that looked identical to a real one in terms of hash value, fooling verification systems.

Security standards bodies like NIST and the IETF responded by deprecating SHA-1 across all cryptographic applications. For DKIM, this meant replacing SHA-1 with stronger algorithms like SHA-256, which have no known practical collisions.

You can ensure your DKIM signatures remain valid and trustworthy by using only modern, approved hash functions. Tools like email verification services can help you audit and clean your mailing lists before sending, catching invalid or misconfigured DKIM setups early. For example, bulk verification can surface domains with outdated or non-compliant signing practices.

Modern email security depends not just on keys and DNS, but on cryptographically sound algorithms that haven’t been broken.

While SHA-1 may still appear in old system logs, newer systems must use SHA-256 or higher. Failure to migrate means your signatures risk being rejected by providers that enforce strict verification. Major email gateways like Gmail and Outlook now reject messages with compromised or weak signatures, even if they pass basic deliverability checks.

For a complete audit of your sender setup, including DKIM alignment and signature integrity, using a dedicated tester can give you clear, actionable feedback. Inbox placement testing reveals how your emails perform in real inboxes, not just technical validation.

How do DKIM signatures fail when SHA-1 is used?

When a DKIM signature uses SHA-1, modern mail servers reject it immediately because SHA-1 is no longer considered secure. The receiving server checks the hash algorithm listed in the DKIM-Signature header—when it sees "sha1", it refuses the signature outright, even if the key is valid. No warning, no fallback—just a hard fail.

How the validation process exposes the flaw

DKIM relies on cryptographic hashing. The sender’s mail server computes a hash of the message body and headers using a specified algorithm—commonly SHA-1 or SHA-256. This hash is then signed with a private key, and the result is published in the DKIM-Signature header.

When the receiving server gets the message, it retrieves the sender’s public key from DNS, recalculates the hash using the same algorithm listed in the header, and compares it to the signed value. If the algorithm is listed as "sha1", the server checks whether SHA-1 is still deemed acceptable.

Most modern mail transfer agents (MTAs) are configured to reject any signature using weak cryptographic algorithms. This includes SHA-1, which has known vulnerabilities that make it susceptible to collision attacks. As a result, even if the rest of the DKIM process is correct, a SHA-1 signature is treated as invalid.

Why the failure is immediate and silent

There’s no grace period. You won’t see a soft bounce or a warning like “signature valid but algorithm outdated.” Instead, the message is dropped—or marked as suspicious—before it ever reaches the inbox. This happens because receiving servers enforce policy-level security rules, often based on RFC 6376 and industry best practices.

According to widespread adoption patterns observed by email infrastructure providers, more than 90% of major inbox providers—including Gmail, Outlook, and Yahoo—now reject messages with SHA-1 signatures. The failure isn’t due to a misconfigured key or domain—it’s due entirely to the use of a deprecated algorithm.

Let’s say you’re sending from a platform that still defaults to SHA-1. Even if your domain is properly authenticated and your SPF/DKIM/DMARC records are correct, your message will be blocked. Fixing this starts with ensuring your email service provider or mailing system uses SHA-256 by default.

If you’re unsure whether your DKIM signature is still using SHA-1, you can review the raw header of a delivery attempt. Look for digest=sha1 or algorithm=sha1 in the DKIM-Signature field. If you find either, that signature will likely fail on any modern receiving server.

To catch invalid or risky addresses in your list before they cause delivery issues, use a tool like MailTester’s bulk verification—it checks for valid syntax, role accounts, disposable domains, and sends realistic test emails to test inbox placement and reputation.

What DKIM algorithms are currently accepted by major email providers?

Major email providers like Gmail, Yahoo, and Outlook now accept only SHA-256 for DKIM signatures. Any DKIM-Signature header using a=sha1 will be rejected, even if the cryptographic math is correct—because SHA-1 is explicitly deprecated and no longer trusted in modern email security.

Why SHA-1 is no longer allowed in DKIM

SHA-1 was once a standard cryptographic hash function, but it's been proven vulnerable to collision attacks since 2017. Since then, secure email infrastructure has moved to stronger algorithms. Gmail and Microsoft's mail systems now require SHA-256 for DKIM verification, and they actively reject any signature that uses a=sha1.

Even if your private key and digital signature are correct, a SHA-1 header will fail during validation. This isn’t about correctness—it’s about policy. The decision to block SHA-1 is consistent across modern email providers. You can verify this in publicly available technical documentation from Google and Microsoft.

What this means for your email delivery

If you're still using SHA-1 in your DKIM setup, your emails may pass basic encryption but fail authentication. This leads to higher spam scores, lower inbox placement, or outright rejection. Even if the recipient’s server doesn’t block it outright, reputation systems will flag your sending domain.

Some legacy systems or older email gateways may still accept SHA-1, but they’re increasingly rare. The dominant providers—Gmail, Yahoo, Outlook, Apple Mail—have long moved past it. RFC 8301 (which supersedes earlier DKIM standards) formally recommends SHA-256 as the minimum acceptable algorithm.

Let’s be clear: you can’t rely on SHA-1 to keep your emails deliverable. If your sender reputation depends on consistent inbox placement, this is a non-negotiable hardening step.

For a real-time check of whether your sending configuration is aligned with current standards, test your domain's full email setup—including DKIM—with the inbox placement tester. It checks not just deliverability, but also DKIM alignment, SPF, and DMARC—giving you a full picture of how your emails will be treated.

How to verify if your DKIM setup uses SHA-1

You can confirm whether your DKIM signatures use SHA-1 by inspecting the raw email header for the a=sha1 parameter in the DKIM-Signature field. If it’s present, your signature algorithm is outdated and may cause delivery failures with modern email providers that no longer accept SHA-1.

  1. Fetch the raw email header from a message sent with DKIM. Use your email client’s IMAP access or a mail logging tool like Mailgun, Postmark, or a custom script to retrieve the full header. This includes metadata the receiving server uses to validate your signature.
  2. Look for a=sha1 in the DKIM-Signature header. The parameter appears as part of the signature string, e.g., DKIM-Signature: v=1; a=sha1; d=example.com; s=selector;. If this value is present, your domain is using an outdated hashing method and risks signature rejection.
  3. Check your DNS TXT record for the DKIM selector (e.g., selector._domainkey.example.com). The record only holds your public key and does not specify the hash algorithm. The algorithm is defined in the email header, not DNS — so even if your DNS record is correct, the signature could still use SHA-1.
How to verify if your DKIM setup uses SHA-1The 3 steps described in “How to verify if your DKIM setup uses SHA-1”, in order.1Fetch the raw email header from a message sent with DKIM. Use your emailclient’s IMAP access or a mail logging tool like Mailgun, Postmark, or acustom script to retrieve the full header. This includes metadata thereceiving server uses to validate your signature.2Look for a=sha1 in the DKIM-Signature header. The parameter appears aspart of the signature string, e.g., DKIM-Signature: v=1; a=sha1;d=example.com; s=selector;. If this value is present, your domain isusing an outdated hashing method and risks signature rejection.3Check your DNS TXT record for the DKIM selector (e.g.,selector._domainkey.example.com). The record only holds your public keyand does not specify the hash algorithm. The algorithm is defined in theemail header, not DNS — so even if your DNS record is correct, the…
The 3 steps described in “How to verify if your DKIM setup uses SHA-1”, in order.

Why SHA-1 is no longer trusted

SHA-1 was once considered secure, but it is vulnerable to collision attacks. Major email providers and standards bodies, including the IETF (Internet Engineering Task Force), have officially deprecated it in DKIM. As of 2021, the IETF’s RFC 8301 requires compliant systems to reject SHA-1 signatures. You may find your messages silently dropped or marked as suspicious if they use outdated hashing.

Next steps to fix

If you confirm your DKIM setup uses SHA-1, update your email infrastructure to use a=rsa-sha256 instead. This means reconfiguring your mail server, ESP, or sending platform to sign outbound messages with the newer algorithm. Most modern systems support it natively — double-check your SMTP provider’s documentation.

Validating DKIM signatures is not just about correctness — it's about deliverability. A misconfigured or outdated signature can hurt your sender reputation, even if the email address itself is valid. You can test your current DKIM validity by verifying a sample message through a third-party tool. For example, MailTester’s inbox placement tests help you see how your messages perform in real inboxes, including whether DKIM failures are blocking delivery.

How to fix a SHA-1-based DKIM signature

Replace SHA-1 with SHA-256 in your DKIM signing process. Most modern email providers reject SHA-1 signatures due to known cryptographic weaknesses. Updating your email server or service to use SHA-256 ensures your messages aren’t blocked and maintain deliverability. This change affects both the signing process and the public key stored in DNS.

Step-by-step: Update your DKIM configuration

  1. Switch your email service provider or server to SHA-256 signing. If you use SendGrid, Amazon SES, or another cloud provider, check their documentation for DKIM settings. Most now default to SHA-256. Let’s say you’re using Postfix or Exim—update your MTA’s DKIM signing module to force SHA-256 output in the signature.
  2. Regenerate the DKIM-Signature header using SHA-256. The signature header must reflect the new hash algorithm. For example, in the DKIM-Signature: header, change the d=example.com and a=rsa-sha256 values. This step ensures receivers can validate the signature securely. A misconfigured or outdated signature fails validation, leading to delivery drops.
  3. Update the public key in your DNS TXT record. The public key tied to your domain's DKIM selector must now match the new key pair used in SHA-256 signing. If you use a third-party tool, verify the key format and align it with the new algorithm. Incorrect or outdated keys cause signature rejection by receivers.

Verify your changes work before sending mail

Once updated, test your configuration using a real inbox placement service. Tools like MailTester’s inbox tester send messages through actual email providers and report back on deliverability, header validation, and signature status. This lets you catch issues before they impact your campaign. RFC 8301 (the current DKIM standard) mandates SHA-256 for new keys—older algorithms like SHA-1 are officially deprecated.

For larger lists, ensure every address in your sending database has valid, deliverable records. A single failed signature can harm your sender reputation. Use bulk email list verification to clean your database, filter out invalid or risky addresses, and avoid delivery issues from poor-quality senders. This complements the technical fix by ensuring your messages reach inboxes that actually accept them.

What are the real-world consequences of using SHA-1 in DKIM?

Using SHA-1 in DKIM leads to signature failures that trigger high bounce rates or silent rejection by major email providers. Since SHA-1 is cryptographically weak and no longer trusted, ISPs like Gmail and Microsoft filter domains using it more aggressively—often marking messages as spam or rejecting them outright. This harms sender reputation and risks domain-level filtering, even if the rest of your email setup is sound.

High bounce rates and silent rejections

Messages with SHA-1 signatures often fail authentication checks during the final delivery step. Even if the email reaches the recipient’s server, it may be bounced silently or flagged as untrusted. This commonly happens with large-scale senders who use outdated or misconfigured DKIM setups.

Major ISPs have been deprecating SHA-1 for years. Google’s 2020 security update specifically dropped support for SHA-1 in its DKIM validation pipeline, and similar updates followed at Microsoft and Yahoo. You’re not just risking delivery—you’re sending messages that ISPs actively distrust. For reference, the IETF’s RFC 8301 formally deprecated SHA-1 for cryptographic signatures in email, including DKIM.

Damage to sender reputation and domain trust

When a domain consistently sends messages with failed DKIM signatures, even just from one sender or one email client, the reputation of the domain takes a hit. ISPs track these events over time. A single flawed signature might not matter—but repeated issues across your sending infrastructure signal poor security hygiene.

Once a domain shows signs of weak authentication, ISPs may apply domain-level filtering. That means all messages from the domain—legitimate ones included—get delayed, quarantined, or blocked, regardless of content. This isn’t just theoretical. The Spamhaus Project tracks domains with poor authentication practices and maintains blacklists where such domains appear.

Let’s be clear: fixing a SHA-1 issue isn’t optional for any domain sending email at scale. You’re not just updating a key; you’re restoring trust with gatekeepers who now assume anything built on SHA-1 is compromised.

If you’re unsure whether your domain is using SHA-1 in DKIM, test your setup before it causes a delivery crisis. Run a real inbox placement test to see how your emails are received and whether they pass authentication checks.

How to avoid SHA-1 dependency in future email setups

Don’t rely on SHA-1 for DKIM signing—use SHA-256 by default. Most modern systems support it, but you must verify your email platform’s default setting. Test your sender setup with real-time verification and monitor DNS records and deliverability metrics to catch misconfigurations early. Let’s walk through how to future-proof your email stack.

Verify your DKIM signing defaults

  • Check your email platform or SaaS tool’s DKIM configuration to ensure it uses SHA-256 as the default hashing algorithm. Many older or legacy systems still default to SHA-1.
  • Look for explicit options in your email provider’s domain settings (e.g., SendGrid, Mailchimp, Amazon SES) or DNS records to confirm hashing method—it should specify sha256 or sha-256 in the DKIM record.
  • Use RFC 6376, the standard for DKIM, as a reference: it mandates that signatures use a secure hashing algorithm and strongly discourages SHA-1 due to known vulnerabilities.

Proactively test and monitor your setup

  • Before sending bulk campaigns, verify individual addresses using a real-time checker like MailTester’s email checker to confirm syntax, domain existence, and deliverability—catching issues before they hit your inbox.
  • Run inbox placement tests with MailTester’s inbox tester to simulate how your emails land across major providers (Gmail, Outlook, Apple) and detect signs of alignment or signing issues.
  • Monitor your deliverability reports and DNS alignment logs regularly. Look for spikes in hard bounces, authentication failures, or low inbox placement—these can signal a misconfigured DKIM record, possibly still relying on SHA-1.
  • Use your email platform’s own logging or integrate with tools like MxToolbox to analyze DKIM signature validity and verify that your published keys are correctly signed with SHA-256.
Secure email authentication isn’t optional—it’s a requirement for reliable inbox delivery. A single weak link in your DKIM setup can break trust across global inbox filters.

Remember: a default setting isn’t always secure. Just because your tool says “DKIM is enabled” doesn’t mean it’s properly configured. Always verify. And test. And verify again.

How MailTester helps prevent DKIM-based delivery issues

You can catch DKIM signature failures before they hurt deliverability by verifying your email list with MailTester. It checks for domain-level authentication health—including DKIM and SPF alignment—flagging domains with outdated or misconfigured keys, risky catch-all setups, or alignment issues that lead to rejection. This stops problems before they hit the inbox.

Detecting DKIM risks at scale

Many senders assume their DKIM keys are valid, but outdated algorithms like SHA-1 are no longer supported by major ISPs. When a domain uses SHA-1 in DKIM, it fails signature validation—even if the rest of the infrastructure looks correct. MailTester’s bulk verification scans your list for such domain-level red flags, identifying domains that rely on deprecated cryptographic standards that will break delivery.

It doesn't stop at syntax. MailTester also checks for proper SPF/DKIM alignment and detects catch-all domains that may be flagged as spam traps. These issues often surface during real delivery, but catching them early during list hygiene prevents wasted sends and reputational damage. The tool’s real-time verification API even tests individual addresses before you include them in a campaign.

Testing delivery before sending

Even with correct keys, DKIM validation can fail if the signing key is outdated or no longer trusted. That’s where inbox placement testing comes in. MailTester’s inbox placement test simulates delivery through Gmail, Outlook, and other major ISPs, running automated checks on the full authentication chain—including DKIM signature validity. If a domain still uses SHA-1 or has a weak cryptographic configuration, the test will surface the issue.

Think of it as a stress test for your sending setup. You’re not just verifying addresses—you’re confirming that the entire delivery path works as expected. Unlike some tools that only flag invalid syntax, MailTester checks for actual deliverability readiness based on how real mail servers evaluate email.

For example, the RFC 6376 standard explicitly deprecates SHA-1 in DKIM; major platforms now reject messages signed with it. By using MailTester’s bulk verification, you avoid sending to domains that are already on a path to failure.

Whether you’re using bulk verification on a full list or the API for real-time checks, you’re catching authentication issues before they impact your sender reputation. It’s not about replacing your own checks—it’s about adding a second layer of reliability that actual ISPs will recognize.

Why list hygiene and deliverability go hand in hand

Bad email lists hurt deliverability because they trigger authentication failures, increase bounces, and damage sender reputation. A single malformed or invalid address—especially one from a role account or disposable domain—can flag your entire sending domain. Clean lists, verified before every send, reduce those risks and keep your messages in inboxes.

How bad data breaks authentication

DKIM signing relies on a consistent, valid sending environment. If your list contains invalid or malformed addresses, your email server may still attempt to send the message—but the receiving server sees inconsistencies. While SHA-1 is deprecated for DKIM, a messy list still undermines the entire authentication chain by increasing exposure to rejection zones like greylisting or IP reputation systems.

Let’s say your list has 5% invalid addresses. Those generate hard bounces. Bounce volume correlates directly with sender reputation. High bounce rates trigger filtering, even if your DKIM and SPF are technically valid. The email may pass technical checks but fail in practice.

Disposable domains and role accounts hurt reputation

Role accounts like admin@, sales@, or support@ are often used by bots or outdated systems. They lack personal engagement, which harms engagement metrics—key inputs for inbox placement algorithms. Disposable domains, such as those from mailinator.com or temp-mail.org, are almost universally ignored by inbox providers.

According to Spamhaus, domains hosting disposable or role-based addresses are commonly flagged in real-time blacklists. Even if an address technically validates, its domain context can cause rejection. You’re not just sending to bad emails—you’re sending to domains that signal low trust.

MailTester’s bulk verification catches these issues before they leave your server. It surfaces invalid, role-based, and disposable addresses with a 98.9% accuracy rate. The result? Fewer bounces, less strain on your sender reputation, and a higher chance your messages reach the inbox.

Even if your DKIM signature is strong, a poor list undermines your delivery. Reputation is built on consistency, engagement, and low abuse signals. A clean list ensures every send counts.

Summary: SHA-1 in DKIM is not just outdated—it’s a delivery killer

Using SHA-1 in DKIM signatures is no longer acceptable. Even with correctly configured keys, modern email providers reject messages with SHA-1 signatures immediately, leading to undeliverable emails and broken authentication.

These rejections often lack detailed error messages, making troubleshooting difficult. The root cause is cryptographic weakness—SHA-1 is computationally vulnerable and no longer trusted by major platforms, including Gmail and Microsoft 365.

Fixing DKIM alignment, updating cryptographic standards, and maintaining clean email lists are essential for consistent inbox placement. Ignoring SHA-1 in DKIM undermines sender reputation and reliability.

Sources

Keep reading

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

Frequently asked questions

Can I still use SHA-1 in DKIM with some ISPs?

No. Major providers like Gmail, Yahoo, and Outlook have deprecated SHA-1 and will reject any signature using it, regardless of sender trust.

How can I check if my email provider uses SHA-256 for DKIM?

Inspect raw message headers for the "a=sha256" parameter. If it's "a=sha1", your provider still uses outdated hashing.

Does DKIM require both SHA-1 and SHA-256 to be supported?

No. Modern systems only support SHA-256. Supporting SHA-1 is a security risk and not necessary.

What happens if a message fails DKIM with SHA-1?

The message will be rejected or marked as suspicious. This reduces inbox placement and can damage sender reputation.

Can MailTester detect SHA-1 misuse in DKIM?

MailTester does not directly verify DKIM algorithms in headers, but it tests deliverability and identifies risk factors like poor list hygiene.

Is it safe to keep SHA-1 in DKIM while preparing to upgrade?

No. Even temporary use creates delivery risk. Best practice is to update immediately and avoid legacy algorithms.

Why does email deliverability depend on DKIM's hash algorithm?

SPF and DKIM are part of a chain. A failed DKIM signature invalidates alignment and reduces trust with receiving servers.

Does using SHA-256 prevent all DKIM issues?

It prevents signature rejection due to hash weakness, but other issues like incorrect selector, DNS misconfiguration, or invalid keys still apply.

What should I do if I can't update my email platform's DKIM settings?

Switch to a provider that supports SHA-256 by default, or use a third-party email service with modern authentication.

How often should I test my DKIM signature after fixing it?

Test using a mailbox placement tool after every change. Monthly checks and pre-send list verification are best practices.

Can disposable email domains affect DKIM signature validity?

Disposable domains don’t affect DKIM itself, but they signal poor list quality and are often associated with low engagement and spam traps.

Why does SHA-1 still exist in some older DKIM implementations?

Legacy systems may not have been updated to comply with current cryptographic standards. These systems are increasingly unreliable.