DKIM RSA-SHA256 Hash Failure

What does 'invalid RSA-SHA256 hash' really mean in DKIM verification?

You send an email, it passes SPF and DKIM checks, but the recipient’s server rejects it with a cryptic “invalid RSA-SHA256 hash” error. You didn’t change anything. The key’s valid. The signature looks fine. So why is it failing?

The issue isn’t the key. It’s not even the signature. It’s the math: the hash of the signed content doesn’t match what the receiver computes. A single mismatch in header order, a missing line break, or a corrupted byte in transit can break this. And it’s not rare—many DMARC failures start here.

DKIM signing relies on precise, deterministic formatting. When the hashing process doesn’t align with the receiver’s expectations, verification fails—even with a legitimate key. This failure is often a red flag for misconfigurations, not attacks. Understanding what this error actually means is the first step to fixing it.

Key takeaways

An 'invalid RSA-SHA256 hash' means the computed digest of the signed content doesn’t match the one in the DKIM signature, not that the key is compromised.
Even small changes in header order, line endings, or whitespace during signing or transit can cause hash mismatches.
Verification tools can detect these mismatches during email testing, letting you catch issues before sending to production.

How does DKIM use RSA-SHA256 hashing in practice?

DKIM signs email by hashing selected headers and body content with SHA256, then encrypting that hash with the sender’s private RSA key. The receiving server fetches the public key from DNS, decrypts the signature, and independently recomputes the hash. If the values don’t match, verification fails — commonly reported as an “invalid RSA-SHA256 hash” — indicating tampering or misconfiguration.

Step-by-step: how the signature is created and verified

Compute the SHA256 hash of email components — DKIM selects specific headers (like From, To, Subject) and the message body, then applies the SHA256 algorithm to create a fixed-size digest. This ensures any change to the email alters the hash.
Encrypt the hash with the private RSA key — The sender’s private key signs the SHA256 digest, producing a digital signature that only the corresponding public key can decrypt. This step anchors the signature to the sender’s domain.
Embed the signature in a DKIM-Signature header — The resulting encrypted hash is sent in the email as a DKIM-Signature header, including details like the selector, domain, and algorithm used (e.g., rsa-sha256).
Retrieve the public key from DNS — The recipient server queries DNS using the selector (e.g., default._domainkey.example.com) to fetch the public key published by the sender’s domain.
Decrypt the signature with the public key — Using the retrieved public key, the recipient decrypts the signature to recover the original SHA256 hash.
Recompute the hash independently — The receiver applies SHA256 to the same headers and body, recalculating what the hash should be if the message is untampered.
Compare the hashes — If the original encrypted hash (from decryption) and the independently computed hash match, the signature is valid. Otherwise, it fails — and tools often report "invalid RSA-SHA256 hash" at this stage.

Why mismatches happen in practice

Even with correct implementation, failures occur due to subtle misconfigurations. For example, if the body is reformatted during transit (e.g., line breaks altered), the hash changes. Some mail servers also add or alter headers, breaking the signature. Misconfigured DNS records, expired keys, or incorrect selector usage are common root causes. The RFC 6376 specification defines the standard process, but real-world deployment often deviates.

The 7 steps described in “Step-by-step: how the signature is created and verified”, in order.

It’s worth noting that SHA256 is considered secure and widely adopted. As specified in RFC 6376, it's the recommended hashing algorithm for modern DKIM implementations. Using older, weaker algorithms like SHA1 is no longer acceptable for strong authentication.

If you’re troubleshooting failed DKIM signatures, use a service like inbox placement testing to simulate real-world delivery and identify where signatures break under actual conditions.

Three technical causes of invalid RSA-SHA256 hash in DKIM

DKIM signature verification fails with an invalid RSA-SHA256 hash mainly due to header reordering during transport, incorrect signed header lists, or a malformed RSA signature. Even small changes like capitalization shifts or header order changes break the hash. Misconfigured signing headers or improper private key usage during signing result in decryption failure. These issues are common in misconfigured senders and can be caught early with proper domain and email infrastructure validation.

Header reordering or missing headers during transport

DKIM signing relies on the exact byte sequence of headers in the email. Any change — even capitalization or order adjustments — invalidates the hash. Transport agents, proxies, or gateways often modify formatting silently.
Mail transfer agents (MTAs) that normalize CRLF or fold long lines before signing can introduce mismatches. The receiving server verifies using the exact headers it sees — not the original ones.
Use tools like RFC 6376 to ensure header alignment matches the signer’s expectations. Validate headers during testing.

Incorrect or incomplete signed header list

The h= tag in the DKIM-Signature header must exactly match the list of headers being signed. If any header listed in h= is missing, or if an extra header is included, the hash is invalid.
Common mistakes include omitting mandatory headers like From, To, or Date, or including non-signable headers like Content-Transfer-Encoding or DKIM-Signature.
Double-check your signed header list during setup. Use tools that simulate real-world delivery conditions to test against live receivers. Verify individual email addresses with a real-time checker to assess deliverability early.

Malformed or incorrectly padded RSA signature

Even if the header hash is correct, an improperly formed RSA signature — due to incorrect padding (e.g., PKCS#1 v1.5 or PSS) — will fail during decryption.
Using an outdated or mismatched private key, such as one not generated with the correct modulus or padding scheme, leads to a hash that cannot be verified.
Ensure your signing library uses the correct RSA padding standard. Most modern systems expect PSS by default. Verify that your private key has the right key size (2048 bits or higher) and format. Test bulk addresses via our API to detect pattern failures in outgoing mail campaigns.

How mail servers process DKIM verification step by step

DKIM signature verification fails with an "invalid RSA-SHA256 hash" when the receiving server computes the expected hash of the signed headers and body, decrypts the signature using the public key, and finds the values don’t match. This mismatch typically stems from incorrect header hashing, a malformed signature, incorrect key usage, or a mismatched hash algorithm. Let's walk through how this process unfolds.

Step-by-step: What happens during DKIM verification

Fetch the public key from DNS. The receiving server extracts the selector and domain from the DKIM-Signature header and queries the DNS record at selector._domainkey.domain.com. This record contains the public key used to verify the signature.
Parse the 'h' tag to identify signed headers. The h tag in the DKIM-Signature header lists the email headers that were included in the signature. The server uses this list to know which headers to include in the hash computation — any deviation here causes the hash to fail.
Compute the SHA256 hash of the signed content. The server reassembles the listed headers and the email body (with canonicalization rules), then computes a SHA256 hash exactly as specified in RFC 6376. Even small differences — like extra whitespace or different line endings — change the final hash.
Decrypt the signature using the public key. The server takes the b value from the DKIM-Signature header and uses the public key to decrypt it. This returns the original hash value the sender computed.
Compare the two hash values. If the decrypted hash doesn’t match the one the server computed, the signature fails. The most common error code for this is invalid RSA-SHA256 hash, signaling a mismatch in either the hash algorithm, the signed content, or the key.

Why this process matters for senders

Even a single unlisted header or incorrect whitespace can break DKIM. This is why using tools like email verification before sending is critical. If your DKIM setup is off by even one character, the message fails to validate — often silently — and ends up in spam or rejected outright. Tools that test deliverability, like our inbox placement tester, help catch these silent failures early by simulating how real servers process your message.

The 5 steps described in “Step-by-step: What happens during DKIM verification”, in order.

For more complex setups, ensure that your signing software correctly follows the standard. RFC 6376 details the canonicalization and hashing process. Misaligned hashing algorithms (for example, using SHA1 instead of SHA256) are a frequent cause of failure. You can verify your setup using tools like MXToolbox or Spamhaus's lookup tools to validate DNS records and signature integrity.

Why is header normalization critical to DKIM success?

DKIM signature verification fails with an invalid rsa-sha256 hash when the message headers don’t match exactly between signing and verification — even tiny changes in whitespace, line endings, or order break the hash. This is because DKIM requires strict header normalization: all whitespace is collapsed to a single space, line endings are standardized to CRLF, and header keys are lowercase. Any deviation during relay — such as an MTA adding extra spaces or reordering headers — invalidates the signature, even if the key and signing process were correct.

The hidden culprit: MTA and ESP header manipulation

Let’s be honest: most email systems don’t preserve header formatting exactly as sent. Email Service Providers (ESPs) and MTAs often rewrite headers during routing — inserting, reordering, or adjusting spacing. These changes might seem minor, but they alter the canonical form of the message headers, which is used to compute the DKIM hash. A single extra space between a header and its value can shift the entire hash, causing verification to fail even when the private key is valid.

For example, if your email has:

Subject: Hello

and another system turns it into:

Subject: Hello

the normalized version changes — and so does the hash. This is why DKIM validation still fails in 70% of cases where the key and signature appear correct. The issue isn’t with the signature itself; it’s with how the message was altered in transit.

How to diagnose and fix header normalization issues

Even if you’ve configured SPF and DMARC properly, DKIM can still fail due to these subtle header changes. The fix isn’t in your key or signing process — it’s in how the message is handled between sender and recipient. Always test your final sent message against the canonical form used in DKIM signing. You can use tools like MxToolbox’s DKIM debugger or RFC 6376 — the official specification — to verify normalization logic.

For teams sending at scale, running DKIM checks before sending can catch normalization problems early. MailTester’s inbox placement testing simulates how real inboxes see your messages, including how headers are processed. Using the platform’s email verification tools helps you identify issues before they hit the inbox.

Common pitfalls in DKIM implementation that break RSA-SHA256 hashing

DKIM signature verification fails with an invalid RSA-SHA256 hash when the public key isn’t correctly retrieved or the signing process uses mismatched algorithms, often due to a typo in the selector, outdated hashing standards, or incomplete DNS propagation. Even a single missing dash or incorrect DNS record syntax can prevent the receiving server from finding the key. Let’s break down the most common, real-world issues that trigger these failures.

Selector or DNS syntax errors

Even a single typo in the DKIM selector — like a missing dash in selector._domainkey.example.com — breaks key retrieval. The verifier looks for an exact match in DNS, so sel-ector._domainkey won’t work.
Using incorrect syntax in the TXT record, such as unquoted values or extra spaces around the dkim= tag, causes parsing errors. The DKIM RFC mandates precise formatting.
Test your DNS record with tools like MXToolbox before sending to catch syntax issues early.

Hash algorithm mismatches

While SHA-1 is still technically supported, modern systems expect SHA256 as the standard. If your signing process still uses SHA1, the signature may fail validation on servers enforcing newer standards.
Some legacy systems or poorly configured tools still default to SHA1, creating interoperability problems. Ensure your email service or library explicitly sets h=SHA256 in the DKIM-Signature header.
Verify the hash algorithm by inspecting the DKIM-Signature header field h= — it should list sha256 or sha1. Use a real email to test, not a mock.

Delayed DNS propagation

After updating a DKIM record, propagation delays can last up to 48 hours. During this window, some servers may not see the new public key, causing validation to fail even with correct data.
Check propagation status using global DNS tools like DNSWatch or DNSChecker.org to confirm the record is live everywhere.
Monitor for inconsistencies: one server sees the key, another doesn’t. That’s often a caching issue, not a configuration one.

If you're unsure whether your DKIM setup is sound, run a real email through a verified inbox placement test to see how it performs in live mail environments. Test deliverability in 30+ real inboxes before sending to customers.

How to test DKIM verification independently and reliably

You can test DKIM signature verification independently by simulating real inbox delivery with tools that validate the full chain: DNS lookups, header parsing, hash recomputation, and signature decryption. Tools like MailTester’s inbox-placement tester run these checks end-to-end, pinpointing exact failures such as an invalid RSA-SHA256 hash with contextual details like which part of the signature or body failed.

Use real tools that trace the full verification chain

Many basic validators only check if a DKIM-Signature header exists. The real test is whether the receiving server can recompute the hash, resolve the public key, and verify the signature using the correct algorithm. This includes checking that the hash is computed over the correct canonicalized body and headers—something that changes if the mail is modified in transit.

Tools that mimic inbox behavior, like MailTester’s inbox-placement testing, perform these checks in real time. They don’t just verify existence—they replay the actual delivery process, using real DNS queries, header analysis, and cryptographic verification. This catches subtle failures like incorrect hash algorithms (e.g., reporting RSA-SHA256 when the server expects rsa-sha1) or misconfigured DNS records.

Test across multiple inboxes and clean domains

Not every inbox behaves the same. Some filter or modify content—especially if it detects suspicious patterns. To get reliable results, you need to test on inboxes that don’t alter the message. MailTester provides dedicated test domains that bypass common filters and deliver messages exactly as sent, preserving header structure and content for accurate verification.

Use these test domains to isolate the root cause of a failed invalid RSA-SHA256 hash—whether it’s an error in signing, a misconfiguration in the DNS record, or incorrect canonicalization. Testing across multiple domains and providers also reveals whether the issue is sender-specific or widespread.

For accurate results, tools should verify against the actual standards. The DKIM specification (RFC 6376) mandates how headers, body, and signatures must be processed. Deviations in canonicalization or key format invalidate the signature, even if all parts seem present.

Whether you’re troubleshooting a single email or validating a bulk send, rely on tools that don’t just scan for syntax but simulate real delivery. MailTester’s inbox-placement testing covers SPF, DKIM, and DMARC together, so you see where each step fails and why.

How MailTester helps prevent DKIM validation failures

DKIM signature verification fails with an invalid rsa-sha256 hash when the signing key doesn’t match the public key in DNS, or when the signature syntax is malformed. MailTester’s real-time API and bulk verification tools catch these issues early by validating the full DKIM setup — including key alignment, hash algorithm consistency, and correct header signing — before you send. This prevents bounces, blocks, and sender reputation damage.

Real-time API detects syntax and key issues before send

You don’t need to wait for bounces to find out your DKIM is broken. The MailTester verification API checks the full email envelope and header structure, including DKIM signature validity, at the moment you’re about to send. It flags malformed signatures, incorrect hash algorithms (like using sha256 with a key expecting sha1), or mismatches between the signing domain and the selector used in DNS. If your domain’s public key is missing or incorrectly formatted, this shows up immediately.

Bulk analysis surfaces systemic DKIM misconfigurations

Let’s say your campaign to 20,000 users is seeing a 12% bounce rate — not because addresses are fake, but because DKIM signature validation is failing across domains. MailTester’s bulk verification tool identifies this pattern. It doesn’t just tell you an address is invalid; it tells you whether a domain consistently fails DKIM checks, revealing systemic issues like misconfigured DNS records or third-party email services using incorrect signing keys.

When you pull logs from providers like Gmail or Outlook, you often see cryptic errors like “dkim=bad-signature” or “rsa-sha256 hash mismatch.” MailTester’s in-app AI assistant cross-references these messages against known RFC standards — including RFC 6376, which defines DKIM signing and validation — to explain what went wrong. It can tell you if the error stems from a missing or invalid selector, an incorrect header list order, or a mismatch between the private key used and what’s published in DNS.

Unlike many tools that only say “this email is invalid,” MailTester tells you why. You’re not just cleaning up a list — you’re fixing the underlying architecture. And because all verified credits never expire, you can run these checks continuously as you grow your list. The result is fewer blocked messages, better inbox placement, and a stronger sender reputation.

Best practices for maintaining DKIM integrity

DKIM signature verification fails with an invalid rsa-sha256 hash when headers aren’t normalized before signing, or when the signing process deviates from RFC 6376. Even minor changes in whitespace, header order, or encoding break the hash. To prevent this, always follow the standard rigorously, validate signatures in isolation, and test across real inboxes over time. Let’s fix it at the source.

Header normalization and signing consistency

Always normalize email headers before signing—strip extra whitespace, use lowercase for header names, and ensure line endings are CRLF as defined in RFC 6376.
Never sign headers in their raw, unprocessed form. Even a single trailing space alters the hash outcome.
Use an automated tool to verify all outbound messages in a clean test environment to catch normalization issues before emails hit the wire.
Check your signing logic against the official DKIM specification—deviations here are the top cause of rsa-sha256 validation failure.

Monitoring and DNS hygiene

Monitor actual DKIM signatures across multiple inboxes over time—some providers apply different validation strictness, and not all will catch issues immediately.
Use deliverability testing tools to simulate how your emails perform in real-world inboxes, including Gmail, Outlook, and Apple Mail.
Regularly audit your DNS records for DKIM, SPF, and DMARC—editing one without testing all three can break email authentication entirely.
Even small changes—like adding a subdomain or modifying a TXT record—can break DKIM if not applied consistently.

Automated validation isn’t optional when sending at scale. You can test the integrity of your email stream with tools like MailTester’s inbox placement tester, which checks how your emails land across providers and validates DKIM, SPF, and DMARC in real inboxes.

Never assume a signature is good just because it passes your internal test. Only real-world delivery reveals the full picture.

When to suspect mail server behavior vs. your own configuration

If your DKIM signature fails with an invalid rsa-sha256 hash, it’s not always your setup — some mail servers modify message content (like reformatting HTML or inserting tracking pixels) after signing, breaking the signature unless the server adjusts for it. A failure that only happens with certain domains likely points to the receiving server rewriting or sanitizing the message. Test with known clean senders like Gmail, Outlook, or a private test domain to isolate whether the issue is on your end or theirs.

When mail servers alter content after signing

Many email providers, especially those with high-volume inbound traffic, insert their own tracking pixels, update URLs, or reformat HTML to improve security or analytics — all of which change the original message body. Since DKIM signs the content exactly as it is at the moment of sending, any post-send alteration breaks the signature. This is a common reason why your carefully signed emails pass with one provider but fail with another.

Services like Google Workspace, Microsoft 365, and Amazon SES are known to rewrite content in transit, even when the original message was signed correctly. If you’re seeing failures only with emails going to these providers, suspect content modification on their end rather than misconfiguration on yours.

How to isolate the source of DKIM signature failure

Let’s test with a clean baseline: send identical messages to Gmail, Outlook, and a private test domain you control. If the signature passes on some but not others, the problem is likely server-side modifications. Use tools like MailTester’s inbox placement tester to simulate delivery and verify actual inbox placement across providers, including how signatures hold up in real-world conditions.

If DKIM fails consistently across all destinations, then it’s time to check your own configuration. Verify your DNS records (DKIM selector, public key placement), ensure the signing algorithm is set to rsa-sha256 (not sha1), and check that the message body is being signed exactly as expected. Misaligned header or body canonicalization can also result in a failing hash — a common issue in poorly configured email gateways.

In short: test with multiple receivers. If only some fail, the receiving server is likely modifying the message. If all fail, audit your signing process and DNS setup. The MailTester email checker helps you verify the structure and deliverability of sender domains quickly.

For deeper diagnosis, consult the RFC 6376 specification on DKIM, which details how signatures are constructed, normalized, and validated — particularly the part on canonicalization rules, which are often the root cause of hash mismatches even when the key is correct.

Conclusion: Fix the root cause, not just the symptom

An 'invalid RSA-SHA256 hash' error doesn't mean your key is broken—it means the signature didn't match the received message. This mismatch usually stems from how the message was processed during transit, such as header modifications, encoding changes, or misconfigured signing workflows.

Test like the real internet does

Generic validators and email clients don’t catch subtle delivery chain issues. They don’t simulate SMTP handshakes, DNS lookups, or real-world server behavior. Use tools that verify by sending messages through actual delivery paths to expose problems before they hit inboxes.

MailTester’s inbox-placement testing replicates live delivery conditions. It checks if your message arrives, whether headers are preserved, and if DKIM signatures remain valid through the full chain—no guesswork, no false positives.

Sources

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)
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)

Keep reading

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

Frequently asked questions

What happens if DKIM fails due to an invalid RSA-SHA256 hash?

The receiving mail server flags the message as potentially forged or altered. It may still deliver to the inbox, but it lowers sender reputation and increases spam risk.

Can DKIM fail even if the key is correct?

Yes — if headers are reordered, normalized incorrectly, or if the signing process includes unintended content, the hash will be incorrect even with a valid key.

Is RSA-SHA256 the only valid algorithm for DKIM?

The standard supports SHA1 and SHA256; however, SHA1 is deprecated. All modern systems expect SHA256. Using SHA1 may result in rejection.

Should I retry sending emails after a DKIM failure?

Retrying with the exact same signature will produce the same failure. Correct the root cause first — such as header normalization or key setup.

Does DKIM work with all email providers?

Most major providers (Gmail, Outlook, Yahoo) enforce DKIM. But some may still accept messages with failed signatures if other authentication checks pass.

Can a third-party email service break DKIM signing?

Yes — if the service modifies the message body or headers after signature, DKIM fails. Ensure signing happens after all routing and processing.

How do I verify that my DKIM record is correct?

Check DNS using tools like MxToolbox or dig. Confirm the selector, domain, public key format, and algorithm match what your sender uses.

What’s the difference between DKIM and SPF?

SPF authenticates the sending IP; DKIM authenticates the message content. They serve different purposes and both need to pass for optimal deliverability.

Can a single malformed character break DKIM?

Yes — even a single extra space, newline, or misordered header can change the computed hash. DKIM is extremely sensitive to exact content.

How can I test DKIM on emails sent through SendGrid?

Use MailTester’s integration with SendGrid to verify delivered messages end-to-end, including full DKIM validation in real inbox environments.

How often should I audit DKIM configurations?

At least monthly, especially after changes to email templates, routing, or delivery tools. Continuous monitoring prevents reputation damage.

Do disposable email domains affect DKIM verification?

No — disposable domains don’t usually implement DKIM. If a message fails DKIM, it’s due to the sender’s setup, not the recipient domain.