Migrate from SHA-1 to SHA-256 in DKIM

Why SHA-1 in DKIM Is Now a Deliverability Risk

You’re sending emails. Your DKIM signature checks out. Yet some recipients don’t receive them—and you’re left wondering why. One likely reason: your DKIM signature still uses SHA-1, a hash algorithm now considered insecure.

Think of SHA-1 like an old lock with a known weak spot. Even if it still "locks," attackers can force it open. Major email providers have stopped accepting emails signed with SHA-1 in DKIM, not because the signature fails validation, but because they treat the algorithm itself as a security threat.

How to migrate from SHA-1 to SHA-256 in DKIM isn’t just a technical tweak—it’s a deliverability necessity. If you’re still using SHA-1, you’re at risk of rejection, increased bounce rates, or being flagged as suspicious, even with technically correct headers.

Key takeaways

Major email providers like Google and Microsoft now reject DKIM signatures using SHA-1 due to known cryptographic vulnerabilities.
Even if a SHA-1 DKIM signature passes technical checksums, receivers may still reject the email due to outdated hash algorithm policies.
Migrating to SHA-256 in DKIM is required to maintain inbox placement and sender reputation with modern email providers.

How to Migrate from SHA-1 to SHA-256 in DKIM to Avoid Invalid Hash Errors

You must update your DKIM configuration to use SHA-256 instead of SHA-1 to prevent email rejection due to invalid hash errors. Start by confirming your current DKIM setup uses SHA-1, then ensure your email service provider supports SHA-256 signing. Generate a new DKIM key pair with SHA-256, update your DNS TXT record with the new selector and algorithm, test with a real email, and monitor logs to confirm the fix. This change is required by modern email providers and prevents deliverability issues.

Confirm Your Current DKIM Setup

Check your existing DKIM configuration to see which hash algorithm is in use. Many legacy systems still rely on SHA-1, which is now deprecated. You can inspect your outgoing email headers or use tools like MXToolbox to verify the DKIM signature. If you see h=sha1 in the header, migration is necessary.

Update Your DKIM Configuration Step-by-Step

Verify ESP support for SHA-256. Not all email platforms or DNS providers allow you to switch algorithms. Check your provider’s documentation or support portal. Major platforms like SendGrid, Amazon SES, and Mailchimp support SHA-256, but older setups may not.
Generate a new DKIM key pair using SHA-256. Use OpenSSL or your ESP’s key manager to create a new RSA key with SHA-256 as the hash algorithm. This ensures the signature aligns with current standards.
Update your DNS TXT record. Create a new DKIM record with a unique selector (e.g., selector2._domainkey.example.com) and include h=sha256 in the record. Example: v=DKIM1; h=sha256; k=rsa; .... Avoid overwriting the old record until testing is complete.
Test the new signature with a real email. Send a test message to a verified inbox and inspect the header. Confirm the DKIM signature now uses h=sha256 and the signature passes validation. Tools like DMARC.org provide free header analysis.
Monitor delivery logs and bounce reports. After deploying the change, track email delivery rates and error logs. If you stop seeing "invalid hash" errors, the migration was successful. Keep the old key active for a grace period in case of compatibility issues.

Once confirmed, you can gradually phase out the old SHA-1 record. This migration is a standard step in modern email security and helps maintain sender reputation. Tools like bulk email verification can help identify invalid or suspicious addresses before sending, reducing the risk of delivery failure.

What Happens If You Don’t Migrate from SHA-1 to SHA-256

If you don’t migrate from SHA-1 to SHA-256 in DKIM, your emails risk being silently dropped by modern email providers like Gmail and Outlook, especially if they enforce strict cryptographic policies. This can lead to failed deliveries, declining sender reputation, and poor inbox placement—often without clear warnings. You’re not just risking delivery; you’re exposing your brand to compliance and trust issues.

The 5 steps described in “Update Your DKIM Configuration Step-by-Step”, in order.

Modern receivers are dropping SHA-1-signed emails

Major email platforms now enforce strong cryptographic standards. Gmail and Microsoft’s servers actively reject messages with outdated signature algorithms like SHA-1, even if the rest of the DKIM setup is correct. This behavior isn’t optional—it’s baked into their filtering rules to protect users from weak cryptography.

There’s no bounce message. The email vanishes. That’s the problem: you don’t know it failed. You only notice when your open rates drop, delivery logs show missing entries, or your engagement metrics fall off a cliff.

Reputation decay happens fast and quietly

When DKIM signatures fail consistently—even under valid, non-malicious reasons—monitoring systems like Microsoft SNDS or Spamhaus register the pattern. Even a few dozen failed verifications a day can trigger reputation flags. It’s not about one email; it’s about consistency over time.

Once a sender’s reputation begins to erode, it takes months to rebuild, even if you fix the technical issue. The receiver’s systems assume the sender is inconsistent or compromised. This applies equally to transactional and marketing mail.

Enterprise gateways and DMARC enforcement policies are especially strict. If you're sending to large organizations or financial institutions, they’ll reject anything that doesn’t meet current standards. It’s not a “nice to have”—it’s a requirement.

Let’s be clear: SHA-1 is deprecated. The Internet Engineering Task Force (IETF) officially deprecated it years ago. You don’t need to wait for a crisis to act. If you’re still using SHA-1, you’re operating with outdated security assumptions and risking delivery reliability.

One way to catch these issues early is to verify your sending infrastructure. You can test how well your messages land in real inboxes with tools that simulate real delivery conditions. MailTester’s inbox placement tests can confirm whether your DKIM-signed emails are being accepted—or dropped—by major providers.

Verify Your DKIM Configuration With Real In-App Testing

You can confirm your DKIM setup is using SHA-256 by sending a test email through your domain’s signing path, then checking the DKIM-Signature header in the delivered message. Use MailTester’s inbox-placement test suite to simulate real-world delivery and pull the raw headers to verify h=sha256 appears. Cross-check your DNS TXT record with tools like MxToolbox to ensure the selector and algorithm align. Run a bulk list test to ensure all outbound messages consistently use SHA-256, not SHA-1.

Test Your Setup Step-by-Step

Go to MailTester’s inbox-placement tester and send a test message using your domain’s DKIM signing path.
After delivery, retrieve the full email headers and look for the DKIM-Signature line. Confirm h=sha256 is present for the signed header fields.
Use MxToolbox’s DNS lookup or the dig command to verify your DKIM DNS TXT record includes the correct selector and sha256 in the a= tag.
Check that q=dns; c=relaxed/simple is set properly, as misconfiguration here can cause verification failure even with correct hash algorithms.
Run a bulk list test via MailTester’s bulk verification tool to validate that every outbound message from your domain maintains consistent SHA-256 signing.

What to Watch For

If you see h=sha1 in the header, your domain is still using an outdated algorithm. This can result in rejection by modern DMARC-compliant systems. The transition must be complete across all sending sources—transactional, marketing, and API-based.

Many email providers, including Google and Microsoft, now treat SHA-1 as invalid for DKIM. According to RFC 6376, which defines DKIM, SHA-256 is the recommended algorithm for new implementations and future-proofing.

Let’s say you’re using a third-party service to send marketing emails. You must verify that your sending platform, not just your domain TXT record, is generating SHA-256 signatures. Even a single misconfigured source can break deliverability for your whole domain.

Common Misconceptions About SHA-256 and DKIM Migration

You don’t need to overhaul your SPF or DMARC records when switching to SHA-256 for DKIM—only the DKIM signature algorithm changes. Existing alignment and policy enforcement remain valid. You also don’t have to re-sign every email from the past; only new messages sent after the update need SHA-256. Some email service providers handle algorithm selection automatically, but confirm yours doesn’t default to SHA-1, which can cause validation failures.

DKIM Migration Isn’t a Full-Stack Rewrite

Let’s be clear: upgrading to SHA-256 affects only the DKIM signing process. Your SPF records define which IPs can send on behalf of your domain, and DMARC enforces compliance between SPF and DKIM. Changing the hashing algorithm in DKIM does not alter those policies. If you’re updating your DKIM key, you’re only adding a new record—or updating an existing one—without changing sender authentication fundamentals.

Many teams assume they must re-sign all archived emails, but this isn’t necessary. Invalid hash errors are triggered only when a message is signed with SHA-1 and the recipient’s system expects SHA-256. You only need to ensure new outbound messages use SHA-256 moving forward. Older emails remain valid as long as they were signed with a compliant method at the time of sending.

ESP Defaults Can Surprise You

Some email service providers, especially those managing DKIM automatically (like SendGrid or Amazon SES), default to SHA-1 unless explicitly configured otherwise. Check your provider’s documentation—RFC 6376 (which defines DKIM) now recommends SHA-256 as the preferred hash algorithm for stronger security. IETF’s RFC 6376 outlines the current best practices, and major providers are phasing out SHA-1 support.

Don’t assume your current setup is secure. If you're using an older outbound system, it may still sign with SHA-1 by default. Validate your outbound DKIM signatures before assuming they’re up to date. You can check the public key in your DNS records and verify signature validity using tools like MailTester's inbox placement tests, which simulate real-world delivery conditions and check for signing alignment across protocols.

How to Check if Your Email Service Provider Supports SHA-256

You can confirm SHA-256 support in your ESP by checking the official documentation, specifically for DKIM algorithm options in API references, SMTP settings, or domain configuration pages. If your ESP doesn’t explicitly mention SHA-256 or allow you to select it when generating new DKIM keys, you’re likely still limited to SHA-1. When in doubt, contact support directly and ask if new DKIM keys can be generated using SHA-256.

Check Your ESP’s Documentation

Go to your ESP’s developer or technical documentation portal (e.g., SendGrid, Mailchimp, Amazon SES).
Search for terms like “DKIM”, “algorithm”, “hashing”, or “key generation” in the API reference or SMTP setup guides.
Look for explicit mentions of “SHA-256” or “RSA-SHA256” in configuration options, not just SHA-1.
For reference, the IETF RFC 6376 (which defines DKIM) specifies that both SHA-1 and SHA-256 are valid but recommends SHA-256 for future-proofing. See the full standard at RFC 6376.

Contact Support for Confirmation

If documentation is unclear, reach out to your ESP’s support team via email or live chat.
Ask directly: “Can I generate new DKIM keys using the SHA-256 algorithm?”
Do not accept vague responses like “we support modern standards”—demand a yes/no on SHA-256.
Some providers (like Microsoft 365) support SHA-256 but require manual configuration in the DNS management console or admin portal.

Pro tip: Even if your ESP allows SHA-256, you’ll need to update DKIM records in DNS and ensure your sending infrastructure uses the new key. Misconfigured keys lead to authentication failures—even with the correct hash algorithm.

Once you’re confident your ESP supports SHA-256, move on to generating a new DKIM key. If you're testing email delivery, you can use a real-time inbox placement tool like MailTester’s inbox placement tester to validate that your messages arrive in inboxes without rejection due to signature issues.

Real-World DKIM Migration: A Step-by-Step Example

You can migrate from SHA-1 to SHA-256 in DKIM by updating your email service’s DNS settings to use a new selector and selecting SHA-256 as the hashing algorithm. Once updated, your DKIM signature header will reflect the new algorithm, and your emails will pass modern verification standards. Test delivery with a real-time tool to confirm inbox placement and signature success.

Step-by-Step Migration Process

Identify your current DKIM configuration. Check your SendGrid dashboard to confirm that the current DKIM selector uses SHA-1. Most legacy setups default to SHA-1, which is no longer trusted by major providers. As outlined in RFC 6376, SHA-1 is deprecated for cryptographic integrity checks.
Create a new DKIM selector and enable SHA-256. In your SendGrid settings, set up a new TXT record under a unique selector (e.g., mail2025._domainkey). Choose SHA-256 as the signing algorithm. This ensures new signatures are generated using a stronger hash function.
Update your DNS TXT record with the correct hash. The record must include h=sha256 in the DKIM-Signature header. Double-check that the public key in the TXT record matches the one generated during the setup. Any mismatch breaks DKIM validation.
Send a test email and inspect the DKIM-Signature header. Use a test email to validate. Open the raw header and look for h=sha256. If it appears, your new signature is active. If you still see h=sha1, the change wasn’t fully applied.
Verify across inbox providers using real-time tools. Senders using modern infrastructures often face delivery drops due to weak or outdated signatures. Use MailTester’s real-time API to check if your message passes DKIM validation across Gmail, Outlook, Apple Mail, and other platforms. This catches issues invisible to internal testing. Test DKIM and deliverability in real time.

Why This Works

SHA-256 prevents hash collision attacks that compromise email integrity. Major providers like Google and Microsoft now reject emails signed with SHA-1. Upgrading isn’t optional—it’s required to maintain sender reputation.

Even if you don’t change your selector, using SHA-256 ensures compliance with current standards. You can keep the old record temporarily for backward compatibility while phasing in the new one. Eventually, disable the old selector once you confirm all messages are signing correctly.

Once live, monitor deliverability. Tools like MailTester’s inbox placement tester can show if messages reach inboxes or get quarantined—something static header checks can’t do.

Why You Should Verify Your DKIM Migration with a Real Email Test

Just updating your DNS records isn’t enough—only sending a real email through Gmail, Outlook, or other providers confirms whether your new SHA-256 DKIM signature is accepted. DNS checks can’t show how receivers actually process your signed message, and a failed signature in the wild will hurt your sender reputation.

DNS Isn’t Enough—Real Delivery Matters

Checking your DNS entries might tell you the key is published, but it won’t confirm whether receivers like Gmail actually validate it correctly. Some services reject emails with SHA-256 signatures if they’re not properly formatted, even if the DNS looks correct.

Even small mismatches—like incorrect header alignment or missing canonicalization—can trigger rejection. You can’t test this with a tool that only checks records. You need to send a real message through actual email infrastructure to see how it’s treated.

Test in Real Conditions with Inbox-Placement Checks

Only inbox-placement testing replicates what happens when your email hits a real inbox. These tests verify how receivers process your full message, including DKIM validation, header checks, and spam filtering behavior.

MailTester’s inbox-placement tests simulate delivery across 15+ major email providers—Gmail, Outlook, Yahoo, Apple Mail, and others—by sending actual test emails from your domain. This shows whether your SHA-256 DKIM signature is accepted, whether the message lands in the inbox, and whether it fails due to signature mismatches.

While RFC 6376 specifies DKIM’s technical framework, real-world handling varies. For example, some older systems still default to SHA-1, or have partial support for SHA-256. Testing helps you catch these edge cases before they affect your deliverability.

RFC 6376 defines DKIM’s structure, but actual validation depends on each provider’s implementation. Real-world testing confirms what specs alone can’t.

With MailTester’s inbox-tester, you can validate your migration without sending to real recipients: run a full inbox-placement test to check your DKIM, SPF, and DMARC alignment in actual receiver environments.

How MailTester Helps Prevent DKIM Migration Failures

You can avoid DKIM hash errors during migration from SHA-1 to SHA-256 by testing real email delivery before sending. Our inbox-placement tests send emails to actual inboxes and report whether DKIM passes, letting you catch signature mismatches early. With the real-time API, you can verify individual addresses and check header signatures before a campaign runs. Bulk list verification also identifies domains still using outdated DKIM setups, so you catch issues before they hurt deliverability.

Test Real Deliverability, Not Just Headers

Many tools check DKIM signatures in isolation—but that doesn’t show how they perform in real inboxes. MailTester’s inbox-placement tests send live emails to major providers like Gmail, Outlook, and Yahoo. Each test reports whether DKIM passes, fails, or is ignored, so you see the actual effect of your new SHA-256 configuration. This matches best practices from industry sources like the IETF's DKIM specification, which emphasizes real-world validation over theoretical correctness.

Validate Addresses Before They Hit Your Server

Before you send a bulk campaign, use our real-time API to check individual addresses. It verifies not just syntax and existence, but also whether the domain’s public key aligns with your signing setup. If the domain still uses SHA-1, you’ll know before sending. This is especially useful during migration windows when some domains may have updated and others haven’t.

For larger lists, run a bulk verification through our email list verification tool. It flags domains with outdated DKIM configurations, including those that still rely on SHA-1 or have misconfigured public keys. Catching these early keeps your sender reputation intact and avoids batch bounces due to signature failures.

Even if your setup is correct now, domains evolve. A one-time check won’t catch future issues. Our API and bulk verification integrate seamlessly with your workflow—whether you’re using Mailchimp, HubSpot, or SendGrid—so you test continuously. No more guessing. No more failed deliveries because of forgotten migration steps.

What to Do If You Still See Invalid Hash Errors After Migration

If you’re still seeing invalid hash errors after switching from SHA-1 to SHA-256 in DKIM, the issue is likely not with your DNS or signing key—it’s probably an intermediary rewriting or stripping your DKIM-Signature header. Double-check the delivered email’s header for h=sha256, confirm third-party services aren’t re-signing with SHA-1, and use external tools to validate your setup in real-world conditions.

Verify the DKIM-Signature Header in Delivery

Open a freshly delivered message and inspect the raw header; look for h=sha256 in the DKIM-Signature field. If you see h=sha1, the signature has been altered post-signing.
Ensure your mail server or ESP is not re-signing the message during relaying—some systems auto-re-sign with outdated algorithms.
Check for any inline rewriting (e.g., by a content filter or email gateway) that may drop or modify the header entirely.

Validate End-to-End with External Tools

Use MXToolbox or the Microsoft Remote Connectivity Analyzer to check DKIM alignment and signature validity from multiple ISP perspectives.
If using a third-party forwarding service (like Google Workspace, Amazon SES, or a relay provider), confirm it doesn’t modify or strip DKIM headers. Some services will re-sign with their own keys, often using SHA-1.
Test with a known-good email address via an inbox placement tool—such as inbox placement testing—to see if the signed message reaches inboxes with valid DKIM.

Even if your signing process is correct, a single layer of re-signing or header modification can break DKIM validation. The real test is what arrives in the recipient’s inbox.

Consider Your Sending Infrastructure

If you use an ESP like SendGrid, Mailchimp, or HubSpot, review their documentation for DKIM handling policies. Some platforms sign outbound mail automatically, and you must disable their default signing if you're managing it yourself.
Use your email verification service to audit your list for malformed or synthetic addresses that might trigger unexpected behaviors in the delivery stack.
Monitor logs from the receiving side—especially if you send to large providers like Gmail or Outlook. They often reject messages with invalid or mismatched DKIM signatures.

Migrating to SHA-256 Is the Minimum Standard for Modern Email Delivery

SHA-1 is no longer considered secure by modern cryptographic standards. Major email providers and security frameworks have phased it out due to known vulnerabilities that allow spoofing and tampering.

Proactively migrating to SHA-256 avoids forced downtime, invalid hash errors, and reputational harm from rejected messages. Delaying the change increases the risk of email delivery failures as infrastructure evolves.

Keeping signing practices up to date is not optional—it’s foundational. Consistent use of strong algorithms like SHA-256 supports sender reputation and improves inbox placement across major providers.

Sources

Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)
DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)

Keep reading

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

Frequently asked questions

Does SHA-256 replace SHA-1 in all DKIM configurations?

Yes. Any DKIM signing using SHA-1 must be replaced with SHA-256 to meet modern security standards and ensure email delivery.

Can I use SHA-256 with RSA keys?

Yes. SHA-256 is compatible with RSA-based DKIM key pairs. Ensure the key length is at least 2048 bits.

Do I need to change my SPF or DMARC records when migrating?

No. Only DKIM signing algorithms and DNS records require update. SPF and DMARC are independent of hash algorithm.

What does an invalid DKIM hash error mean?

It indicates the receiving server detected a malformed or outdated hash in the DKIM-Signature header, often due to SHA-1 use.

How do I know if my ESP supports SHA-256?

Check your ESP’s developer docs or support team. Providers like SendGrid and Mailgun support SHA-256; others may require configuration changes.

Can a forwarding service break DKIM even after migration?

Yes. Forwarding services may re-sign messages with outdated algorithms. Use trusted providers and monitor header integrity.

Is there a deadline for migrating from SHA-1?

While no global cutoff exists, providers are increasingly rejecting SHA-1 signatures. Migrating now avoids future delivery issues.

How often should I validate my DKIM setup?

At least monthly, especially after configuration changes. Use real email testing to confirm delivery and signature validity.

Can I test DKIM signature validity without sending emails?

Limited. DNS checks confirm record presence but not real delivery. Only actual email tests expose signature acceptance by receivers.

What’s the difference between SHA-1 and SHA-256 in DKIM?

SHA-256 provides stronger cryptographic security and is resistant to collision attacks, while SHA-1 is vulnerable and no longer trusted.

How does MailTester help with DKIM validation?

MailTester sends real emails through your domain’s setup, verifies DKIM signatures, and reports delivery status across multiple inbox providers.

What’s the accuracy of MailTester’s verification?

MailTester achieves 98.9% accuracy in email verification, including header-level checks like DKIM signing integrity.