DKIM b= Field Failure Causes

What happens when a DKIM signature’s b= field hex values change during transit?

You send an email. It passes through multiple servers, proxies, and filters. The DKIM signature validates it as authentic—until it doesn’t. Why? Because a single hex value in the b= field changed during transit.

DKIM signatures depend on pixel-perfect encoding. Any deviation—whether from a misconfigured proxy, a MIME header normalization, or an encoding error—breaks the signature. The receiving server sees a mismatch: the signed content and the actual content no longer align. The email fails. And no amount of SPF or DMARC fixes that.

Key takeaways

Digital signatures in DKIM are sensitive to even minor changes in hex-encoded values within the b= field.
Common email transit processes like header normalization, proxy rewriting, or MIME encoding can alter the b= field and cause DKIM failure.
DKIM validation fails silently if the b= field doesn’t match exactly—no warning, just rejection.

Why is the b= field so sensitive to hex value changes?

The b= field in a DKIM signature contains a base64-encoded hash of the email’s signed headers and body—down to the last space, line break, or capitalization. Even a single character change, like transforming CRLF to LF in a raw message, alters the hash value entirely, causing the signature to fail. This sensitivity is intentional: it ensures any transit-side alteration invalidates the signature, preserving message integrity. Because of this, DKIM breaks easily when mail goes through poorly configured gateways or misaligned encoders.

What exactly does the b= field hash?

DKIM signs specific headers and the body content using a cryptographic hash function, typically SHA-256. The b= field includes the raw, unprocessed bytes of those components, with exact whitespace and newline sequences preserved. This means a single space added, removed, or transformed from \r\n to \n changes the hash input, and the resulting signature no longer matches the original. The system is designed to detect even minor modifications—this is how it prevents tampering.

Why do transit systems break DKIM this way?

Many email gateways, especially older or misconfigured ones, normalize line endings or adjust whitespace during processing. For example, a system might strip trailing spaces, convert line breaks for internal handling, or insert soft breaks in long headers. These changes are invisible to users but fatal to DKIM checks. The signature becomes invalid because the hash no longer matches. This is common with poorly implemented MTA (Mail Transfer Agent) middleware or content filters that modify messages without preserving alignment with original signed content.

According to RFC 6376, the base64-encoded signature must reflect the precise content as signed. Any deviation breaks verification. Tools like RFC 6376 emphasize that the entire message body and selected headers must be sent unchanged after signing. Even a minimal transformation—like folding a long header line—can trigger failure.

Because DKIM validation fails silently, this often leads to undetected delivery issues. Emails pass through SPF and DKIM checks during inbound routing but are silently rejected later. Understanding this sensitivity helps teams avoid common pitfalls: never modify a signed message after DKIM is applied. Always verify signatures using tools that test the full delivery path, not just static checks.

Common scenarios that corrupt b= field hex values during transit

You lose DKIM signature validity when the b= field’s hex values are altered because even a single modified character breaks the cryptographic digest. This can happen during transit due to line-endings being rewritten, whitespace removed, or content encoding changed—especially when non-8bit encodings are used. These changes, while often invisible to users, invalidate the signature. To ensure DKIM works, preserve the exact byte sequence from sender to receiver. Tools like MailTester’s real-time verification API can help detect flawed signatures early.

Line-ending and whitespace modifications

Many filtering services standardize line endings from CRLF to LF or strip trailing whitespace—altering the exact content in the b= field. Even one removed space or newline changes the signature.
SMTP servers may normalize whitespace in headers or body—especially in plaintext messages—without preserving the original byte stream.
Some legacy systems expect strict CRLF and drop messages with malformed line endings, which can truncate or modify the signature field during processing.

MIME transformations and content encoding changes

When content uses Content-Transfer-Encoding like quoted-printable or base64, improper parsing can rewrite line length or encoding, breaking the hex sequence in b=. RFC 2045 mandates strict adherence to encoding rules—violations corrupt the signature.
CDNs or load balancers that compress or reformat email bodies during transit can alter whitespace or line breaks in headers or sections used in the DKIM signature. Even if the visible content looks the same, byte-level differences are fatal.
Some email clients or mail servers re-normalize HTML or plain-text content—adding or removing spaces, indenting lines, or changing quote styles—which directly affects the b= field even if the message appears untouched to the user.

These transformations are common and often automated. They’re rarely intentional, but the result is always the same: DKIM fails. You can’t rely on the recipient’s mail server to “fix” a broken signature. The solution starts at send time—ensure your email pipeline preserves byte-for-byte integrity from signature generation to delivery. MailTester’s inbox placement test checks whether your messages reach inboxes reliably, including signal-based checks for valid DKIM alignment.

How DKIM verification works in real time

When an email arrives, the receiving server fetches the sender’s public key from DNS, re-computes the hash of the signed content exactly as the sender did, and compares it to the b= value in the DKIM-Signature header. If the values don’t match—even if just one byte is different—the signature fails, and the email may be rejected, flagged, or sent to spam. This check happens in milliseconds, silently and automatically, for every message that uses DKIM.

The Verification Process Step by Step

Retrieve the public key. The receiving server looks up the sender’s domain in DNS, finds the DKIM record (a TXT record), and retrieves the public key used to verify the signature.
Reconstruct the signed content. It pulls the headers and body listed in the d= and h= fields of the DKIM-Signature header, then applies the same canonicalization rules (relaxed or simple) that the sender used when signing the email.
Recompute the hash. Using the same algorithm (usually SHA-256), it generates a hash of the reconstructed content. This is the expected hash, which must match the b= value.
Compare the hash values. The server checks if the computed hash matches the b= value sent in the email. Even a single character change—like a space replaced with a tab or an added line break—breaks the match.
Fail or pass based on the result. If they don’t match, the signature fails. Most modern mail servers treat this as a red flag, often leading to rejection, poor deliverability, or spam filtering.

Why Altered Hex Values Break DKIM

DKIM relies on exact byte-level consistency. The b= value is a Base64-encoded hash, often appearing as a string of hex characters. Any change during transit—in the headers, body, or even whitespace—alters the computed hash. For example, MIME encoding changes, content filtering, or email optimization tools (like some ESPs or forwarding tools) can silently modify content. Even a single line break difference breaks the hash. Since the verifier computes the hash from scratch using the same rules, if the input differs, the result will never match.

The 5 steps described in “The Verification Process Step by Step”, in order.

This is why DKIM fails unpredictably when b= values are altered: there’s no tolerance for change. It’s not a security flaw—it’s how the system is designed. A mismatch is not a signal of fraud by itself, but it does indicate an interruption in the chain of trust. If a message is modified after signing, the signature must be recomputed. Otherwise, the validation fails.

Understanding this process helps you debug deliverability. If your emails are failing DKIM verification, check if your email service provider, third-party tool, or internal relay is modifying the content before delivery. Use tools like MailTester’s email checker to validate the final message before sending and ensure signing integrity holds all the way to the inbox.

For more, see the original DKIM specification or explore how deliverability tools test for signature issues in real-world environments.

What does a failed DKIM signature mean for deliverability?

A failed DKIM signature means the email’s cryptographic proof of origin has been broken—either by intentional tampering or unintentional transit changes, like a corrupt b= field. This triggers spam filters and inbox providers to treat the message as potentially malicious or illegitimate. Even one failed DKIM can push an email toward the spam folder, especially if SPF and DMARC are weak or missing. Over time, repeated failures degrade sender reputation and risk domain-level blocking.

How failed DKIM impacts inbox placement

When DKIM fails, it’s one of the strongest signals to modern spam filters that the email path has been compromised. Major providers like Gmail and Outlook use DKIM validation as part of their authentication stack. If the b= field changes during transit—due to non-mandatory header normalization, content rewriting by a gateway, or misconfigured MTA routing—the signature no longer matches. This isn't just a technical glitch; it’s treated as a red flag. According to the RFC 6376, DKIM's purpose is to verify that an email hasn’t been altered since signing. When that verification fails, the inbox provider defaults to caution, often marking the message as suspicious.

Even if your SPF and DMARC are properly set, a persistent DKIM failure can override their trust signals. SPF validates the sender's IP, and DMARC defines what to do when authentication fails. But if DKIM consistently fails across a large volume of mail, even a valid SPF and a DMARC policy that allows delivery may not be enough to avoid filtering. The cumulative effect is lower inbox placement—especially in aggressive providers like Yahoo or Hotmail.

Why one failure can snowball into a reputation crisis

Let’s be clear: a single failed DKIM doesn’t instantly block your domain. But consistent failures show poor email hygiene. If your system is rewriting headers without re-signing the email, or if third-party services (like mailing list software or API gateways) are altering the b= field, the damage compounds. Every failed signature reduces your sender reputation score. Spamhaus and MXToolbox use these patterns to assess email sender trustworthiness.

And here’s the catch: once reputational damage starts, it’s hard to reverse. Even if you fix the underlying issue, the historical failure rate may keep your domain in a high-risk pool. That’s why it’s critical to check DKIM integrity before sending—especially when using third-party tools. Use bulk verification to test your sender list for domains with weak or inconsistent DKIM alignment, and pair that with inbox placement testing to confirm your messages land where they should.

How to validate that your DKIM b= field is intact before sending

You can ensure your DKIM b= field remains unaltered by testing the signature integrity in real time before sending. Use a verified email testing tool to inspect the raw signed content, confirm your ESP and SMTP relay preserve the original body hash, and avoid third-party services that modify or re-encode your message. This prevents failures caused by subtle changes during transit.

Use a real-time email verification tool to catch failures early

Test your message’s DKIM signature structure before sending using a real-time verification API — this catches corruption before it reaches the inbox.
Tools like MailTester’s real-time email verification API check the full signature, including the b= field, against known standards and flag any deviations.
Look for alerts indicating the body hash mismatch or signature tampering — these are direct signs the b= value was altered during transit.

Ensure outbound systems preserve original content

Verify that your ESP, SMTP relay, and email gateways do not insert or modify whitespace, line endings, or encoding — even a single space added to the body can invalidate the b= hash.
Compare the raw email output from your system against a baseline created by sending from a verified, non-translating server; any difference indicates a processing change.
Disable automatic content transformations in your email service unless they explicitly preserve DKIM integrity — many default settings modify the body or headers in ways that break signatures.
For inbound systems, ensure that DMARC policies are set with rua or ruf reporting enabled so you can monitor delivery issues and detect unexpected signature failures.

Determining that the b= field is intact requires checking both the signature and the underlying content. The standard defines how the body is hashed in RFC 6376, Section 3.4, which relies on exact byte-for-byte matches. Even minor changes can lead to rejection. Tools that offer inbox placement testing, like MailTester’s inbox placement tester, simulate real-world delivery conditions and expose hidden signature issues in staging.

Even small changes — like adding a newline or converting a character encoding — invalidate a DKIM signature. Integrity is not optional.

Never rely solely on third-party services that reformat content unless they guarantee preservation of the original signature. If you’re routing through a shared gateway or integration platform, confirm their documentation explicitly states DKIM compatibility.

Where does MailTester fit into DKIM integrity validation?

You can validate DKIM integrity in real time by checking whether the b= field in a signature matches the actual content of the email. MailTester’s API and bulk verification tools analyze the full email structure, including DKIM signatures, to detect if hexadecimal values in the b= field have been altered during transit—such changes break DKIM validation and signal possible tampering or delivery path issues. This helps you avoid sending to addresses where authentication fails silently.

How MailTester checks DKIM signature integrity

When you use MailTester’s real-time verification API, it doesn’t just confirm an address exists—it simulates a realistic SMTP exchange and verifies that DKIM signatures are intact. It recomputes the expected hash from the email’s content and compares it to the b= field in the signature. If the values don’t match, it flags this as a failure, even if the address otherwise appears valid.

Many delivery issues stem from intermediaries—forwarding services, mailing lists, or third-party providers—altering the message body or headers during transit. Such changes corrupt the signature unless properly handled by a resigner. MailTester catches these discrepancies early, so you know whether a recipient's inbox will reject the email due to failed DKIM checks.

You can use the real-time verification API to integrate this validation into your sending workflow, or run full bulk list validation to find addresses where DKIM issues are recurring. The system highlights invalid signatures, missing ones, or malformed headers, giving you actionable data to clean the list before sending.

Why real-time DKIM checks prevent deliverability failures

Dkim failures often go unnoticed when only basic syntax checks are performed. A valid email address might still be bounced due to failed authentication. This is why many senders see low inbox placement even with clean lists. MailTester surfaces these hidden issues—like altered hex values in the b= field—before you waste sends.

According to the DKIM specification (RFC 6376), the b= field must be a base64-encoded hash of the canonicalized message body. Any change to even a single character in the content will invalidate the signature. MailTester checks this by reconstructing the canonicalized body and verifying it against the recorded b= value.

For senders using tools like SendGrid, HubSpot, or Klaviyo, this level of scrutiny is essential. You can test your current campaign's inbox placement with the inbox placement tool to see whether your DKIM setup holds up across real inboxes. Addressing signature issues early prevents reputation damage and boosts long-term deliverability.

The technical role of SPF, DKIM, and DMARC in email security

You rely on SPF, DKIM, and DMARC to verify sender legitimacy, protect email content integrity, and enforce trust policies. SPF checks if the sending IP is authorized by the domain. DKIM uses cryptographic signatures to detect any changes to the message body or headers during transit—any alteration to the b= field’s hex value breaks the signature. DMARC ties SPF and DKIM results together, specifying actions if either fails, like rejection or quarantine. All three work together: one weak link breaks the chain.

SPF: Checking the sender's IP legitimacy

SPF (Sender Policy Framework) lets you define which IP addresses are allowed to send emails on behalf of your domain. When an email arrives, the recipient’s server checks your published SPF record. If the sending IP isn’t listed, SPF fails. This stops spoofing by unauthorized servers.

DKIM: Integrity check via cryptographic signature

DKIM signs email content using a private key. The signature, stored in the b= field, is a hash of the message content and headers. If a single character changes in transit—like a space added, a header modified, or HTML wrapped in a new tag—the b= hash no longer matches. This breaks DKIM validation. This is why altering the b= hex value during transit always renders the signature invalid. It’s not a flaw in DKIM; it’s how it’s designed to work. RFC 6376 details the algorithm and the importance of unchanged content.

DMARC: Policy enforcement for failed checks

DMARC doesn't validate email itself—it enforces what to do when SPF or DKIM fails. You set a policy in your DMARC record (e.g. “p=reject”). If an email fails both SPF and DKIM, receivers can reject it. For partial successes, DMARC allows fallback rules. Without DMARC, failures go unnoticed. With it, you gain control and visibility.

These three protocols form a layered defense. SPF guards entry, DKIM protects content, and DMARC mandates outcomes. Break any one, and the email’s trustworthiness drops. Even if only the b= field value is altered by a relay, gateway, or header optimizer (like some ESPs), DKIM validation fails. This is not a bug. It’s a feature. MailTester helps you catch these issues early, whether during bulk verification or inbox placement testing. Use our bulk verification to identify invalid, risky, or non-deliverable addresses before sending. And with our inbox placement tool, see how your messages land in real inboxes across providers. Detecting issues upstream saves time, improves sender reputation, and prevents bounces. It’s better to verify than to guess.

Is it possible to fix a corrupted DKIM b= field after transit?

No, you cannot fix a corrupted DKIM b= field after email transit. Once the hash value in the b= field is altered—by any intermediary, filter, or transport process—the signature becomes permanently invalid. There's no way to reconstruct the original hash without access to the original, unmodified content and signing key. The only reliable fix is resending the email with a correct DKIM signature from the original sender.

Why intermediaries can't fix the signature

Let’s be clear: no email gateway, relay, or security filter can reverse-engineer the correct b= value from a corrupted one. The b= field is a cryptographic hash of the email’s content and headers, signed with the domain’s private key. If the content changes even slightly—say, a space is added or a line break is converted—hashing the new version produces a different result. There’s no algorithm to reverse this process. Without the original signing key and content, the hash cannot be reconstructed. This is why DKIM is designed to fail loudly: it ensures integrity, not repairability.

Resending is the only solution

If you’ve confirmed a DKIM failure due to a wrong b= field, the only working fix is to resend the message with a valid signature applied before transit. This resending must preserve the exact content and encoding—no changes to whitespace, line endings, or character encoding. Even minor differences in formatting, like converting Unix line endings to Windows (\r\n), can invalidate the signature if the original was signed with a different format. Tools like inbox placement testers can help you validate delivery and signature health before sending at scale.

How to prevent DKIM failure in the first place

DKIM signatures fail when the b= field’s hex values are altered during transit because even a single changed character—like a space, line break, or encoding difference—makes the signature invalid. To prevent this, use a reliable sending infrastructure that preserves message integrity from sender to recipient and validate signatures end-to-end. Let’s walk through the essentials.

Use a proven email sending stack with integrity guarantees

Choose platforms like SendGrid, Mailchimp, or Klaviyo that maintain message structure and avoid modifying headers or body content during delivery.
These systems are designed to preserve the exact byte stream required for DKIM validation, including proper formatting of the b= field.
Check their documentation for any mention of content rewriting or compression—avoid services that alter email content without explicit DKIM-aware handling.

Verify integrity before and after delivery

Test every outbound email using MailTester’s inbox placement tester to confirm the message reaches the inbox with headers and body unchanged.
Use the verification API to validate email addresses and detect issues like catch-all accounts or role-based addresses before sending.
Compare your original message’s headers and body with the delivered version using tools like MxToolbox or RFC 6376 to verify the exact content match.
Never assume a compliant sender is immune to content changes—some services compress or reformat email even when sending via SMTP.

Even a single character change in the b= field during transit invalidates the DKIM signature. If the original and delivered messages don’t match byte-for-byte, the signature will fail regardless of correctness.

DKIM is not just about signing—it’s about trust in the entire message lifecycle. When the content diverges from the original, the proof fails. The best defense is to eliminate unnecessary transformations, verify content consistency at every step, and validate through real-world delivery testing. If your emails must pass through intermediaries, ensure they are DKIM-aware and preserve the original payload.

Final takeaway: DKIM is fragile, but predictable

DKIM fails not because of poor design, but because it demands perfect content fidelity. Even minor changes—like line breaks, whitespace adjustments, or inconsistent encoding—can invalidate a signature.

The issue isn’t randomness; it’s predictability. Every transit step that alters the email body or header structure must be managed intentionally. The failure mode is consistent: a mismatch between the signed content and what arrives at the recipient’s server.

Prevention is simpler than recovery

Verify email addresses before sending to avoid invalid or misconfigured destinations.
Validate DKIM signatures in full, including the b= field hex values, before delivery.
Ensure transit systems (proxies, gateways, filters) preserve original formatting and encoding.

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

Can DKIM still pass if the email body is slightly reformatted?

No. Even small changes—like line-ending normalization or whitespace trimming—alter the hash and break DKIM. The signature is sensitive to every character.

Do all email services preserve DKIM signatures?

Not reliably. Many email gateways, CDNs, or filters modify content without DKIM awareness, breaking the signature.

Is it safe to use a third-party email service with DKIM?

Only if the service explicitly preserves DKIM signatures. Verify with DNS checks, testing, or tools like MailTester before sending.

How can I test if my DKIM signature is valid?

Use a real-time verification API or inbox placement tester to validate the b= field against the actual content. MailTester runs these checks automatically.

Can a failed DKIM signature be repaired by resending?

Yes—only if the new email has a correct, unaltered signature from the sender. Resending without fixing the root cause will fail again.

What does a mismatched b= field mean in DNS records?

A mismatched b= field means the email content changed after signing. It doesn’t indicate a DNS error—it means the message was altered during transit.

Does DKIM fail if the email uses HTML encoding?

Yes. If the encoding (e.g., quoted-printable or base64) is inconsistently applied or altered during transit, the hash will differ—breaking DKIM.

How does MailTester detect DKIM signature failures?

It simulates full SMTP delivery and compares the b= field hash against the actual content, flagging any changes or corruption.

Can a catch-all email account bypass DKIM failure?

No. A catch-all account receives the email, but DKIM validation still fails if the b= field is corrupted. The recipient server still checks the signature.

Do all modern email providers check DKIM?

Yes. Major inbox providers like Gmail, Outlook, and Apple Mail require DKIM validation as part of their spam and authentication filtering.

Is DKIM still reliable in 2026?

Yes. When properly implemented and preserved in transit, DKIM remains a core part of email authentication. Its failure is not a flaw—it’s a signal of tampering.

Can I use MailTester to verify DKIM before sending?

Yes. Its real-time API and bulk verification tools include DKIM signature integrity checks, helping prevent failed delivery before send.