DKIM Invalid RSA-SHA256 Hash Error

What causes a DKIM invalid RSA-SHA256 hash error in email headers?

You’re debugging an email that’s getting blocked or marked as spam, and the report says: "DKIM invalid: RSA-SHA256 hash mismatch." It feels like a technical dead end — everything looks right, yet the signature fails. This error isn’t a fluke. It’s a signal that something went wrong during the digital signing process.

The DKIM signature is a cryptographic check that proves an email wasn’t altered in transit. When the hash of the message body or headers doesn’t match what’s expected, the receiver rejects it. The root causes are often hidden in subtle configuration details — not broken infrastructure, but incorrect settings that slip past routine checks.

Key takeaways

A DKIM hash mismatch usually stems from incorrect header or body canonicalization settings in the DKIM signature.
Even a valid key can fail if the signing process uses a different hash algorithm than the verifier expects, particularly if SHA256 is misapplied.
Some email tools and providers mishandle whitespace or header order during hash calculation, leading to false failures despite correct setup.

How does DKIM validate a message’s integrity?

DKIM ensures an email hasn’t been altered in transit by signing specific parts of the message with a cryptographic hash. The sender uses their private key to encrypt a hash of selected headers and body content, then adds that signature to the email header. The recipient’s server retrieves the sender’s public key from DNS, decrypts the signature, recomputes the hash using the same rules, and compares the results. If they match, the message is authentic and unmodified.

The Core Process

Hash selected message parts using SHA-256. DKIM only signs specific headers (like From, To, Subject) and the body. The sender runs a SHA-256 hash on these parts, following strict formatting rules. This creates a unique fingerprint of the message content.
Encrypt the hash with the domain’s private key. The hash is then encrypted using the domain’s private key, which only the sender holds. This step proves the message came from the domain and wasn’t tampered with since signing.
Add the signature to the DKIM-Signature header. The encrypted hash, along with metadata like the signing domain, selector, and timestamp, is included in a DKIM-Signature header field. This field is added to the email’s headers before it is sent.
Retrieve the public key from DNS. The receiving server looks up the sending domain’s public key using the selector specified in the DKIM-Signature header. This key is published in a TXT record at selector._domainkey.example.com.
Decrypt the signature and recompute the hash. Using the retrieved public key, the server decrypts the signature to recover the original hash. It then recomputes the SHA-256 hash of the same message parts using the same rules.
Compare the hashes. If the recomputed hash matches the decrypted hash, the message passes DKIM validation. If not, the signature is invalid — meaning the message may have been modified, forged, or sent from an unauthorized source.

Why This Matters for Your Deliverability

Misconfigured DKIM leads to invalid signatures — often due to incorrect header selection, improper hashing rules, or mismatched keys. A single misplaced character in a header or an unescaped delimiter in the body can break the hash alignment. This triggers a "rsa-sha256 hash mismatch" error, commonly flagged by receivers like Gmail and Microsoft. According to RFC 6376, the algorithm must be applied consistently across all elements — even minor deviations invalidate the result.

The 6 steps described in “The Core Process”, in order.

Regularly testing your emails with tools that simulate real inbox conditions helps catch these issues early. You can verify the DKIM signature and header integrity directly in your sent messages using our inbox placement tester. It validates not just the signature, but also how recipients and filters interpret the message.

For teams managing large email lists, you can also use bulk email verification to scan for invalid or malformed addresses that may result in failed DKIM checks due to header inconsistencies or unverified sources.

What does 'invalid RSA-SHA256 hash' mean in the DKIM-Signature field?

A 'DKIM-Signature: invalid RSA-SHA256 hash' error means the receiving server calculated a different hash from the one embedded in the email’s DKIM signature. The RSA encryption itself is not broken—what failed is the agreement on the data being hashed. This mismatch typically happens because the message body or headers were altered during transit, canonicalization was inconsistent (simple vs relaxed), or non-deterministic whitespace was introduced. When this occurs, the recipient server rejects the signature, which can lead to the email being marked as spam or rejected outright.

Why the hash mismatch happens

DKIM relies on both sending and receiving servers agreeing on exactly which parts of the email are hashed, and how they are formatted. Even a single space added during transit or a missing line break can change the canonicalized content. The receiving server computes its own hash using the same rules—but if the sender used relaxed canonicalization and the receiver used simple (or vice versa), the hash won’t match. This isn’t a cryptographic flaw; it’s a data alignment problem.

Non-deterministic whitespace—such as line endings between CRLF vs LF, or extra spaces in header fields—can also sneak in during routing. These differences aren’t visible in a plain-text view but alter the hash. Many older email systems or third-party gateways inadvertently modify headers, leading to this error. The DKIM RFC outlines the exact rules for canonicalization, but not all mail software implements them uniformly.

What happens when DKIM fails

When the hash does not match, the receiving server treats the DKIM signature as invalid. This doesn’t necessarily block the email immediately, but it reduces sender reputation. If multiple emails fail DKIM validation, ISPs may start filtering messages into spam folders or rejecting them entirely. This is especially true for senders with poor reputation or inconsistent authentication.

While DKIM is not the only signal used for delivery, it's a strong one. A failed signature weakens the overall trust score. To prevent these issues, ensure you’re using strict, consistent canonicalization settings and test your messages through a trusted tool before sending to large lists. Tools like MailTester’s bulk verification check for valid email syntax, deliverability risk, and can help surface alignment problems before they affect your inbox placement.

Why can header changes during transit break DKIM signature verification?

Even small alterations to an email’s headers or body during transit—like added line breaks, reordered headers, or collapsed whitespace—can invalidate a DKIM signature. The signature is based on a hash of the original content, so any deviation breaks the match, even if the change seems minor. This often happens because email systems use different canonicalization methods, especially when one side applies strict rules and the other relaxes them.

How transit systems alter email structure

When your email moves from sender to receiver, it passes through multiple MTAs, gateways, and filtering tools. Each may normalize line endings (e.g., converting CRLF to LF), reorder headers for clarity, or strip trailing whitespace. While these changes seem harmless, they alter the exact text used to generate the DKIM hash. Even a single extra newline in the body or a header moved from position 5 to 2 breaks the cryptographic match.

DKIM uses a canonicalization process to standardize content before hashing. The two main modes—relaxed and simple—handle whitespace and header ordering differently. If your sender uses relaxed canonicalization (allowing some formatting changes), but the receiver applies strict canonicalization (matching the original exactly), the hash doesn’t match—even if the content is meaningfully identical. This misalignment is a common source of DKIM failures.

Why strict canonicalization often causes verification errors

Receiving mail servers sometimes enforce strict canonicalization, especially in high-security environments. While this improves spam protection, it exposes a flaw in real-world email handling: not all systems preserve the exact formatting of the original message. If your mail server or ESP applies strict header canonicalization, but the sender did not, or vice versa, the signature fails.

For example, RFC 6376 specifies how DKIM should handle header normalization, but implementation varies. A header like Received: from mx.example.com might get reformatted or reordered by a gateway. If the original signature was computed with strict rules and the receiving server applies relaxed rules (or vice versa), the hash mismatch triggers a failure.

Let’s be clear: you cannot fix these issues through sender-side DKIM signing alone. You need to ensure your email delivery path doesn’t alter the content in ways that break the canonicalization. This includes testing your outgoing mail flow with tools that simulate real-world transit, checking if headers get modified, and ensuring your mail server and third-party providers (like SendGrid or Mailchimp) use consistent canonicalization.

Use mailbox testing tools to verify your DKIM signature remains valid through actual delivery. MailTester’s inbox placement tester helps uncover hidden issues like altered headers or mismatched canonicalization: test email deliverability in real inboxes to see how your message lands.

How to verify your DKIM configuration is correct: a diagnostic checklist

When you see a "DKIM invalid rsa-sha256 hash error," start with the DKIM-Signature header. Confirm it uses 'relaxed' canonicalization for both headers and body—this is standard and expected. Double-check the 'b' value is correctly base64-encoded and matches the signature computed from the signed content. Ensure the 'h' tag lists only the headers included in the hash, in the exact order they appear. Confirm the 'd' domain matches the one in your DNS TXT record. Verify the 't' timestamp is current and the 'l' length parameter is accurate. Use tools like MxToolbox to check your TXT record is published and publicly visible. These steps resolve 90% of DKIM hash mismatches.

Check your DKIM-Signature header fields

Ensure header-canonicalization and body-canonicalization are both set to relaxed or both to simple.
Verify the b tag contains a base64-encoded signature and not a placeholder like "b=..." or empty.
Confirm the h tag lists only the headers actually signed, in the order they appear in the email, separated by colons (e.g., from:to:subject).
Check that the d field matches the subdomain or domain where the DKIM selector is published (e.g., selector1._domainkey.example.com).

Validate DNS and timing

Use MXToolbox DKIM Checker to confirm your domain’s DKIM TXT record exists and is publicly accessible.
Ensure the t (timestamp) is not expired—DKIM signatures typically expire within 24–72 hours.
Confirm the l (body length) parameter is accurate and reflects the size of the body part that was signed.
Validate that the public key in DNS is properly formatted and the selector matches the one in the s tag of the DKIM-Signature.

For a quick, automated way to scan your email list for valid, deliverable addresses—even before sending—use our email checker to validate individual addresses or integrate with your workflow via our verification API. It helps catch issues like invalid DKIM setup at the source, before they impact sender reputation. The same tool can verify whether an email is deliverable across major inboxes—including Gmail, Outlook, and Yahoo—through our inbox-placement tester. The underlying mechanism mirrors how actual email providers validate DKIM, so it’s a reliable proxy for real-world results.

Common canonicalization misconfigurations and how to fix them

DKIM signature validation fails with a "invalid rsa-sha256 hash" error when the header or body canonicalization mode used to generate the signature doesn't match what the receiving server expects. If you're using relaxed canonicalization for headers but the receiver enforces simple, or vice versa, the resulting hash mismatch will trigger rejection. The most common cause is inconsistent interpretation of whitespace or header ordering during signature verification. Always align your sender-side canonicalization with the standards of your email provider and test across multiple receivers.

Header ordering and whitespace handling differences

Some legacy or non-compliant receiving servers expect strict, simple canonicalization—meaning the exact header order and normalized whitespace must match the original message. If your system uses relaxed canonicalization (which allows reordering and collapsing of whitespace), those small differences can alter the hash and cause rejection. This is especially common with older mail transfer agents or custom-built systems. Let’s say you send a message with headers in one order and the receiving server expects a strict, fixed sequence—any deviation breaks the signature.

Relaxed canonicalization, defined in RFC 6376, is designed to handle real-world email processing, such as message headers being reordered by gateways. But not all servers handle it correctly. If a receiver only supports simple, your relaxed signature will fail—no matter how correct the keys or domain setup. The solution is to test your DKIM setup using a multi-provider inbox tester like MailTester’s inbox placement tool to see how your emails perform across different domains.

Consistency is key—align across sender and receiver

For high-volume senders, always use relaxed canonicalization on both sides. This accounts for typical email processing, such as content rewriting, header addition, or transport delays. If one side uses relaxed and the other simple, hash mismatches are guaranteed. Even major providers like Gmail, Yahoo, and Outlook prefer relaxed, but older or custom setups may not follow suit. Always verify your configuration with real mailbox providers—not just DMARC analysis tools.

Use MailTester’s email checker to validate individual addresses and simulate delivery across providers. That way, you catch canonicalization mismatches early. If your signature fails only on certain domains, the issue is almost certainly in how those receivers interpret the header or body. Test with multiple configurations: simple vs. relaxed, and ensure both sender and receiver align. Consistency prevents 90% of invalid hash failures. RFC 6376, the DKIM standard, confirms that relaxed is widely adopted and recommended for modern email environments—so if your setup diverges from that, it’s likely the source of the error.

How to test DKIM signature validity before sending mail

You can catch DKIM signature failures like an invalid rsa-sha256 hash early by sending test emails through inbox-placement testing tools. These tools simulate real delivery to major email providers and return the full raw headers, where you can see exactly where the DKIM check failed and what hash mismatch occurred. MailTester’s inbox-placement test lets you send real emails to Gmail, Outlook, Yahoo, and others, then inspect the headers to verify DKIM alignment and detect issues before sending to your entire list.

Inspect raw headers to pinpoint DKIM failure

When DKIM validation fails, the email headers will show a DKIM-Signature field with a result like fail (invalid hash). The exact reason — often a mismatch between the signed header hash and what the receiver recalculated — will be visible in the header. Using a tool that provides full, real-time raw headers lets you see this in context, rather than guessing from a vague error message. This is the most reliable way to confirm whether your DNS TXT record, signing key, or header selection is at fault.

Use real email delivery testing to avoid real-world impact

Don’t rely on simulated or mock headers. Use tools that send live messages to actual inbox providers. This ensures you’re testing against the same authentication filters that real messages face. MailTester’s inbox placement feature sends emails through real MX servers and returns full headers that include DKIM validation results. You’ll see whether the signature was verified, or if it failed with an error like Invalid hash in rsa-sha256. The platform also highlights if the body or header selection during signing doesn’t align with the receiver's expectations.

Many DKIM issues stem from misconfigured signing algorithms or header field selection. RFC 6376 outlines the correct format for DKIM-Signature fields, including the required hash algorithms and canonicalization methods. When you verify the header in a real inbox context, you aren’t just checking syntax — you're ensuring that your signature survives the actual email delivery pipeline. Tools like MxToolbox or Spamhaus can help diagnose DNS-level issues, but only full header inspection reveals what the inbox actually sees.

Let’s say you’re debugging a campaign that keeps landing in spam. A simple inbox test through MailTester shows the DKIM signature failed due to a mismatched hash on the Subject header, which you had included in the signature but that wasn’t preserved in transit. Fixing the header selection and retesting confirms the signature now passes. This saves hours of guesswork. With MailTester’s inbox-tester tool, you can test before you send and catch DKIM mistakes early. Test your email in real inboxes and get full headers — the only way to be certain your DKIM is working.

You can catch DKIM signature failures before they impact deliverability by testing real messages in actual inboxes. MailTester’s inbox-placement tests simulate real sends to Gmail, Outlook, and Yahoo, returning full raw headers with DKIM validation results. When a rsa-sha256 hash mismatch occurs, MailTester identifies the exact header field causing the failure, such as a misaligned dkim-signature or incorrect canonicalization. This clarity lets you pinpoint and fix the problem without guesswork.

Real inboxes, real headers, real answers

Unlike tools that only check syntax or return abstract pass/fail results, MailTester runs tests through actual email platforms. We don’t simulate — we send. The raw headers you receive include a full DKIM validation status, showing whether the signature passed, failed, or was missing. If the hash fails, you’ll see exactly which part of the header chain caused it, including the signed headers list and the body canonicalization method. This level of detail is essential for diagnosing issues like incorrect q= or l= tag values, or unexpected whitespace in signed fields.

Proactive prevention with bulk verification

Let’s say you’re about to send a campaign to 100,000 addresses. Some of those domains may have misconfigured DKIM, or worse, use catch-all setups that appear valid but can’t properly handle signed emails. MailTester’s bulk verification identifies these risky or invalid domains upfront — including those with improperly signed or missing DKIM records — so you don’t waste sends or risk triggering spam filters. This prevents your sender reputation from being harmed by bad emails, even before they leave your system.

You can also use our inbox placement tests to validate your message in real inboxes after setup, ensuring the full signature stack works as intended. For developers or system admins, our verification API integrates directly into your workflow, allowing you to test addresses and check DKIM readiness at scale. The system also flags suspicious patterns like malformed DKIM signatures with non-standard algorithms or mismatched key lengths.

When you’ve got a cryptic header dump, our in-app AI assistant helps parse the output. It doesn’t just say “DKIM failed”—it looks at the structure, checks known error patterns, and suggests fixes like standardizing header order or adjusting the d= domain alignment. These insights come from real-world data and align with RFC 6376, the standard governing DKIM authentication. You’re not left decoding logs alone.

When to suspect a compromised or expired DKIM key

If you see a sudden spike in DKIM failures across multiple domains or senders—especially after a system update or migration—it may signal a compromised or improperly rotated private key. A leaked key means old signatures become invalid, and even correct emails fail verification. This is especially common when keys are not rotated every 6–12 months, as recommended by industry best practices.

Signs of key compromise or mismanagement

DKIM signatures rely on a private key you keep secure. If that key is exposed—through a server breach, misconfigured deployment, or accidental leak in logs—attackers can forge emails that appear to come from your domain. A sudden rise in "invalid rsa-sha256 hash" errors in headers, even for known good addresses, often points to this. Even if the key itself wasn’t stolen, incorrect rotation can leave old keys active while new ones start signing, causing mismatched hashes across the network.

Many organizations use automated systems to manage DKIM, but even then, manual key management errors occur. For example, if a new key is added without fully deprecating the old one—or if the old key continues to be used in old systems—duplicates or invalid hashes will appear. This breaks the trust chain and can lead to inbox filtering or outright rejection.

How to verify DKIM validity at scale

Let’s say you suspect your domain’s DKIM setup is broken. The best way to test it isn’t just checking one or two sample messages—it’s testing individual addresses on a large scale. That’s where the real-time verification API can help. By sending a batch of real email addresses through MailTester's API, you can identify if a domain’s DKIM is failing consistently across multiple inboxes, which indicates a systemic issue.

This method isn’t about validating individual addresses—it’s about spotting patterns. If a large number of valid-looking addresses from your domain consistently return "DKIM invalid" or "rsa-sha256 hash failed," the problem lies with the domain’s signing configuration. You can then cross-check the DNS records using tools like MXToolbox or follow the guidelines in RFC 6376 to ensure your DKIM selector and public key are correct.

Why you should test DKIM signatures in real-world recipient environments

Even if your DKIM signature passes internal validation tools, it might still fail in Gmail, Apple Mail, or Outlook due to differences in header normalization, content rewriting, or strict filtering policies. These ISPs don’t just check the signature—you need to test it in their actual environments to catch errors like invalid rsa-sha256 hash that only appear under real-world conditions.

Differences in header normalization break signatures

DKIM relies on precise header ordering and whitespace. While your test environment may preserve this exactly, real-world mail servers like Gmail or Microsoft’s systems can normalize headers differently. That subtle change—adding or removing a newline, changing capitalization—can invalidate a signature even if the key and domain are correct.

According to RFC 6376 (the DKIM specification), the signing and verification process must account for normalization. But in practice, each provider implements this differently. A signature that validates in one system may not in another—especially when content filters modify the body or header order during transit.

Inbox placement testing reveals actual delivery behavior

Internal tools like DKIM validators or SPF checkers only verify technical correctness, not real-world deliverability. They don’t simulate how Gmail strips attachments, rewrites headers, or applies its own reputation filters. That’s why a pass in your test suite doesn’t guarantee delivery.

Only inbox placement testing—sending messages through real recipient environments—exposes whether your DKIM signature survives transit. It’s the only way to catch issues like RSA hash mismatches, missing or altered headers, or policy-based rejection.

MailTester’s inbox-placement testing lets you send real messages through trusted ISPs like Gmail, Yahoo, and Apple Mail. You get full headers, real-time feedback, and the ability to identify signature issues before they impact your campaigns.

Start with 100 free verifications at inbox placement tests. Credits never expire—perfect for ongoing verification and troubleshooting. Use the real-time verification API to catch invalid signatures early in your workflow.

Conclusion: Prevent DKIM failures by testing in real conditions

A DKIM invalid RSA-SHA256 hash error isn’t always due to misconfiguration. Some errors surface only when email passes through third-party processing or receiver-specific filtering systems.

Only testing in real inbox environments reveals these silent failures. Automated tools that check headers in isolation miss behavior triggered by real-world receiving systems.

Use tools like MailTester to validate DKIM signatures within actual recipient systems.
Verify sender reputation with real-time inbox placement tests.
Proactively clean and verify email lists to avoid deliverability drops.

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 DKIM fail if a header is added during transit?

Yes, if the header wasn’t included in the original signature hash, the receiver’s re-computed hash will differ. This breaks DKIM validation unless relaxed canonicalization is used.

Can an email have multiple DKIM signatures?

Yes, multiple DKIM signatures can exist on one email, each signed by a different domain. Each must validate independently.

Why does Gmail show DKIM failure even when the signature appears correct?

Gmail uses strict alignment checks and may flag signatures with misaligned canonicalization or non-compliant headers, even if the hash matches.

How often should I rotate DKIM keys?

Every 6 to 12 months is recommended. Rotate keys with proper deprecation and test the new configuration with inbox-placement tools.

What does 'relaxed' canonicalization do in DKIM?

It allows for whitespace normalization and header ordering flexibility during hash computation, making DKIM more resilient to normal email processing.

Can a misconfigured SPF cause a DKIM failure?

No, SPF and DKIM are independent. However, if SPF fails, receivers may apply stricter filtering that impacts deliverability even when DKIM is valid.

Why do some emails fail DKIM validation only on mobile devices?

Mobile clients may modify headers or reformat content during rendering, which alters the hash. This often points to relaxed canonicalization being required.

Is it safe to use simple canonicalization?

Only if you control the entire email path. Most modern senders should use 'relaxed' for both headers and body to account for standard processing.

How can I tell if my DKIM key is compromised?

Unexplained spikes in DKIM failures, unexpected signature changes, or reports from recipient ISPs may indicate key compromise. Rotate keys and audit logs.

What’s the quickest way to test DKIM validity?

Send a test email via inbox-placement testing tools that return raw headers and DKIM validation status—like MailTester’s real-time service.