B= Value Issues: Email Auth Troubleshooting

Why does the b= value in DKIM signatures change during email delivery?

You sent an email. The DKIM signature passed validation. Then, suddenly, it failed. The b= value in the signature doesn’t match what you expected. Why?

DKIM works by hashing the email’s headers and body in a specific, predictable way. But that hash depends on the exact order of headers. When mail servers reorder headers—moving Received: lines, adding X-headers, or inserting routing metadata—the canonicalized content changes. Even a tiny shift in order alters the final hash, causing the b= value to mismatch.

Key takeaways

DKIM’s b= value is sensitive to header order because it’s derived from canonically normalized content, including header sequence.
Mail servers that reorder headers—especially during routing, filtering, or transformation—can break DKIM validation even if the message content is unchanged.
Header reordering is common and often unavoidable; it’s not always a configuration error, but a systemic artifact of email transport.

What happens when the b= value doesn't match the DKIM signature?

When the b= value in a DKIM signature doesn’t match the computed hash of the signed headers and body, the receiving server rejects the signature as invalid. This usually happens because headers were reordered during transmission—something that breaks DKIM’s strict hash calculation. A failed DKIM check harms sender reputation and increases the risk of emails being marked as spam or blocked outright.

How signing and verification work under the hood

DKIM signs specific headers and the body of an email using a cryptographic hash. The receiving server re-computes that hash using the same headers and body, then checks it against the b= value in the signature. If the values don’t match, the signature fails.

But here’s the catch: DKIM requires headers to be in the exact order they were signed. Any deviation—like a mailing system adding or moving a header—alters the hash. Even a single space change can break the match. This is why header reordering is one of the top causes of DKIM failures in production environments.

Why this matters for deliverability and sender reputation

A failed DKIM check doesn’t always result in immediate rejection, but it’s a red flag. Major providers like Gmail and Microsoft use DKIM results as a signal in their spam filtering and reputation scoring systems. Multiple failures over time can lower your sender score, push your emails into folders, or block them completely.

According to the DKIM specification (RFC 6376), the signature must be computed using the canonicalized form of the message, including header ordering. Tools that skip or misapply this step are essentially sending unverifiable mail.

Let’s say you’re using a third-party service to send emails. If it reorders headers before delivery—say, adding a tracking ID or changing the order of existing ones—it breaks DKIM. This isn’t a rare edge case. It happens routinely with poorly implemented or misconfigured email platforms.

Using tools like MailTester’s email checker lets you verify addresses and test how they’ll pass header validation before sending. For larger campaigns, bulk verification catches invalid or poorly formatted addresses and can surface patterns that might affect delivery—like common header issues tied to certain senders.

How does header reordering affect sender reputation and deliverability?

Reordered headers during email transmission can break DKIM signatures, causing repeated authentication failures. Even if the message arrives, providers like Gmail and Outlook track this history as a red flag—consistent DKIM issues degrade sender reputation over time, leading to throttling, lower inbox placement, or outright rejection. You can catch these issues early with real-time verification before they damage your deliverability.

DKIM fails when headers change

DKIM signs specific header fields in a fixed order. If your email routing or filtering step reorders these headers—say, moving From: below Received:—the signature no longer matches. The recipient server sees this as a validation failure, even if the message content is intact.

Most modern email providers treat persistent DKIM failures as a strong signal. According to authentication best practices published by RFC 6376, any deviation from the signed header structure invalidates the signature. Even a single message with a mismatched b= value can trigger a warning, and repeated failures signal misconfiguration—or worse, a compromised system.

Even valid messages face increased scrutiny

It’s not just about delivery. Providers run ongoing reputation assessments. If your domain has a history of DKIM mismatch errors, systems like Google's spam filters may apply additional checks, even for clean messages.

Let’s say you’re sending transactional emails. If the DKIM check fails every time because headers are reordered during routing, your domain will accumulate trust debt. Over time, this can lead to throttling—reduced sending volume—or placement in lower-tier folders like Promotions or Social, even when content is not spam.

Header reordering isn't always intentional. Poorly configured middleware, misbehaving routing rules in third-party email platforms, or automated tools that rewrite headers without preserving signature integrity can all be culprits. These issues are often invisible until they start affecting inbox rates. You can test the impact with a real-time inbox placement tool, like MailTester’s inbox tester, which simulates delivery across major providers while flagging authentication flaws.

Fixing header reordering requires checking your sending stack—especially if you're using APIs, third-party services, or custom routing. If your stack processes or filters emails after DKIM signing, ensure it only touches body content or headers that aren't part of the signature.

How to diagnose b= mismatches in real-time email deliveries

You diagnose b= mismatches by validating DKIM signatures against the actual headers used during signing, using a tool that applies standard header canonicalization. Compare the raw message trace—especially the canonicalized header set—to the signed headers. Look for anomalies like reordered Received: lines, duplicate headers, or missing Message-ID. Tools like MailTester’s inbox placement tester can replay real deliveries and show exact header alignment issues.

Step-by-step verification process

Use a tool that validates DKIM signatures on both inbound and outbound messages using RFC 6376’s standard header canonicalization rules. Tools like MailTester’s inbox placement tester simulate real delivery paths and expose canonicalization mismatches.
Always inspect the full raw email source, including all headers, in the message trace. Don’t rely on stripped or sanitized views—header order matters.
Compare the canonicalized form of headers (as used in the signature) to the actual headers in the message. A mismatch often shows as a b= value difference despite a valid signature.
Look for duplicate or reordered Received: headers—these commonly trigger canonicalization conflicts during DKIM validation.
Check for unexpected X-headers (like X-Mailer, X-Priority) or missing mandatory fields like Message-ID or Date. Missing or altered headers can break canonicalization rules.
Verify that the signature’s h= tag lists the same set of headers in the same order as the message’s actual canonicalized header set.
If your system adds headers during relay or processing (e.g., via ESPs, gateways, or internal filters), test with real-world delivery traces, not lab simulations.

When standard tools fall short

Some email testing tools only check the signature itself, not how headers were reprocessed. This leads to false positives. The real issue often isn’t the signature—it's how the message was modified or reordered before delivery.

For instance, a simple MTA reordering a Received: header can invalidate a DKIM signature, even with an otherwise intact key. Use message trace data from real delivery paths to catch these edge cases. RFC 6376 describes canonicalization precisely—refer to it when validating your logic.

Let’s say you see a b= mismatch in production but the same email passes in test tools. That’s a sign that header order or processing changed post-signing. Use a system that can replay the full lifecycle—like MailTester’s delivery simulation—to catch it.

Understanding the role of header canonicalization in DKIM

DKIM signs email headers and body using two canonicalization methods: header (h=) and body (b=). The receiving server applies the same rules to recompute the hash. If its implementation differs—even slightly—results may vary. This is why a "b= value differs" error often points to header canonicalization mismatches due to reordering or whitespace normalization differences.

How DKIM canonicalization works

When you sign an email with DKIM, the signing server applies canonicalization to both headers and body. For headers, it standardizes spacing, strips extra newlines, and arranges them in a predictable order—usually alphabetic by header name. This ensures the hash remains consistent regardless of how headers were originally formatted.

But here’s the catch: not all servers or tools implement the canonicalization rules the same way. The RFC 6376 standard defines these rules, but some older or custom systems may deviate—especially in how they order headers or treat whitespace. Even minor variations can change the final hash value.

Let’s say your sending system uses standard header canonicalization (alphabetical order, normalized whitespace), but the receiving server applies a non-standard order—like preserving the order from the original email. That difference will cause the b= value to differ during validation, triggering a DKIM failure even if content is identical. No typo, no tampering—just a mismatch in how the headers were processed.

Why header reordering matters

Header reordering is the most common cause of b= discrepancies. The DKIM standard allows for either "simple" or "relaxed" header canonicalization. "Simple" preserves the original order; "relaxed" sorts headers alphabetically. If the signing server uses one method and the verifier uses another, the result diverges.

Some email providers or security platforms may use non-standard implementations, especially those built in-house. These can introduce subtle parsing differences that break DKIM validation even when everything looks correct on the surface. This isn’t a bug—it’s just inconsistent behavior across systems.

For insight on real-world DKIM challenges, the IETF’s RFC 6376 remains the authoritative reference: https://tools.ietf.org/html/rfc6376. It details the exact rules for canonicalization. Still, implementation gaps are common in practice.

Preventing errors like this starts with consistent alignment in your sending stack. Use verified tools to validate your DKIM setup end to end. You can test whether your email headers and DKIM signatures remain intact during transit with an inbox placement test: test inbox delivery across multiple domains.

Common causes of header reordering during SMTP transmission

Header reordering during SMTP transmission usually happens when email gateways, clients, or security systems modify message headers after submission. This breaks DKIM signatures that rely on strict header order, leading to a b= value mismatch. Common culprits include ESP routing logic, client-added headers, and misconfigured signing tools. Let’s break down the main triggers.

Third-party systems that rewrite headers

Major email platforms (like Gmail, Outlook) and enterprise ESPs often insert or modify headers for routing, tracking, or spam filtering. These systems may reorder or insert fields like Received, Auto-Submitted, or DKIM-Signature after the initial send.
CDNs or email forwarding services (e.g., SendGrid, Amazon SES) sometimes rewrite headers during transit. While designed to preserve deliverability, this can disrupt DKIM’s canonicalization process if not handled consistently.
Industry-standard practices, documented in RFC 5322 and RFC 6376, expect header order to remain unchanged from signing to verification. When systems modify order without applying proper canonicalization, DKIM validation fails.
RFC 5322 defines header order as part of the message body hash; any deviation invalidates a signature unless the signing and verifying agents agree on reordering rules.

Client and system behavior

Some email clients add automatic headers like Delivered-To or Resent-* after submission. These are often inserted at the time of delivery, not during original submission, breaking DKIM integrity.
Plugins or email encryption tools (e.g., Microsoft Purview, Mimecast) may inject headers during inspection or encryption. If these headers aren’t accounted for in the DKIM signing process, they cause mismatches.
Internal security gateways or DLP systems can insert a X-Compliance-Header or similar field for auditing. These modifications often happen late in the chain, after DKIM signing, and are not visible to the original sender.
DKIM signing agents with inconsistent or missing canonicalization rules (e.g., simple list ordering without collapsing whitespace) are especially prone to failure when headers are reordered unpredictably.
Use the email checker to test individual addresses for validity and catch formatting issues early—preventing header mismanagement downstream.

Verification and prevention

Validate signed emails using tools that simulate end-to-end delivery, including header handling by major gateways.
Always use relaxed or simple canonicalization in DKIM (per RFC 6376), especially when sending through third-party services.
Monitor logs from your ESP to detect unexpected header changes during transit.
Test deliverability with inbox placement tools to see how your messages are rendered in real user inboxes.

Step-by-step: How to test real-world DKIM signature integrity

You can reliably test DKIM signature integrity by sending a real email through your SMTP setup, retrieving the full message source from the recipient’s inbox or a trace tool, then using a DKIM validator to recompute the signature using the exact same header and body with strict canonicalization rules. If the computed b= value doesn't match the one in the signature, the signature is invalid or the message was altered in transit—this is how you verify if your DKIM setup works end-to-end.

Send & Collect: Test with Real Mail Servers

Send a test email from your domain to a known mail provider like Gmail, Outlook, or ProtonMail. This ensures you're testing against real-world delivery conditions, not a lab environment.
Once delivered, open the message in the recipient’s inbox and retrieve the full message headers. Most webmail clients offer a "Show original" or "View raw" option. For Gmail, it’s under the three-dot menu; in Outlook, use "View message source."
Copy the entire message, including all headers and the body, into a text file or paste it into a DKIM validator tool. The goal is to preserve the exact content as it was received.

Validate: Recompute the Signature

Use a DKIM validator like the one at dkimvalidator.com or MxToolbox to input the full message source. Ensure the tool applies strict canonicalization—headers should be sorted and whitespace normalized exactly as required by RFC 6376.
Let the tool compute the expected b= value based on the signed header fields, body content, and your published DKIM selector and public key.
Compare the computed b= value to the one present in the received email's DKIM-Signature header. A mismatch indicates a problem: either your signing process isn’t consistent, headers were altered in transit, or your canonicalization settings are incorrect.
If the values don’t match, revisit your email server’s DKIM signing configuration. Check if you're using relaxed vs. strict canonicalization, and ensure the signing key and selector are correct.

Some tools, like MailTester’s bulk verification, can test deliverability patterns across multiple inboxes and flag alignment issues—useful when you’re debugging why emails are marked as suspicious despite valid DKIM.

The 3 steps described in “Send & Collect: Test with Real Mail Servers”, in order.

“DKIM signature verification fails when the canonicalized header or body differs from the signed version—this includes unapproved header reordering, even if it’s seemingly minor.”

Understanding header reordering is critical: even small changes—like additional trailing spaces or reordered headers—can break the signature. Use real message retrieval to avoid false positives from dev-only environments. Always test with live mail providers to catch real-world edge cases.

How to prevent b= mismatches before sending mail

You can prevent b= mismatches by signing emails with a consistent DKIM pipeline that enforces deterministic header order, avoids dynamic or non-standard headers in the signature scope, and ensures your email service provider doesn’t rewrite headers after signing. Test templates in real inboxes early using a trusted verification tool to catch issues before full campaigns launch.

Control your DKIM signing process

Use a signing pipeline that applies headers in a fixed, documented order—such as alphabetical by name, or using a standard like RFC 6376’s canonicalization method—to avoid inconsistent b= values.
Never let your system or email platform reorder headers after DKIM is applied. Post-signature changes break the signature unless properly accounted for.
Exclude non-standard or dynamic headers (like X-Tracking-ID, Timestamp) from the DKIM signature scope. Only sign headers that are static and part of the email content.

Validate before you send

Test your email templates and sending workflows using inbox-placement testing, such as MailTester's inbox tester, to confirm DKIM is validated properly in recipient mail servers before mass sending.
Verify that no third-party service (like Mailchimp, SendGrid, or an SMTP relay) inserts or rewrites headers after DKIM is applied. This is common in some platforms and a leading cause of b= mismatches.
If you use a service like MailTester’s bulk verification, include DKIM validation as part of your list hygiene workflow to catch problematic addresses or malformed headers early.

Why bulk email verification helps catch DKIM misconfigurations early

You can catch DKIM misconfigurations early by verifying large email lists at scale. MailTester’s real-time API checks not just syntax and existence, but also domain-level signals like DKIM, SPF, and DMARC. When a domain has inconsistent DKIM implementation—like a b= value that differs due to header reordering—it flags as risky or invalid, exposing infrastructure flaws before they hurt deliverability. This prevents bulk sends from being blocked or marked as spam.

Testing domain-level signals at scale reveals hidden issues

DKIM authentication relies on precise header ordering. Even small changes—like adding a BCC or changing how headers are appended—can alter the canonicalized header set, causing the b= value to differ from the expected signature. This breaks validation silently. Most tools only test whether a DKIM record exists, not whether it works consistently across variations in header order. MailTester goes further: it evaluates real-world behavior by simulating common delivery scenarios.

Because it analyzes thousands of addresses at once, MailTester detects patterns. Domains that consistently fail DKIM checks, especially under different header configurations, are likely misconfigured or use fragile signing setups. You can then audit your sending infrastructure or work with your email provider to fix root causes like header mangling, incorrect signing filters, or broken signing software.

Spamhaus and the IETF both confirm that consistent DKIM signatures are a key indicator of sender legitimacy. A misaligned b= value isn’t just a technicality—it’s a red flag for email filtering systems.

How to prevent header reordering issues before they hurt your sender reputation

Let’s say you're preparing a campaign and want to verify 10,000 addresses. Using MailTester’s bulk verification, you identify that 12% of your list fails DKIM checks—unusually high. Drilling in, you see those failures cluster on one domain. That domain uses a third-party email service that reorders headers during routing, making DKIM signatures invalid. Without bulk testing, these issues would only surface later via bounces or inbox placement drops.

By catching this early, you avoid sending to a domain whose inbound email system cannot validate your messages properly. This keeps your sender reputation intact and reduces the risk of being flagged by spam filters or blocked by recipient systems.

MailTester’s approach isn’t just about catching invalid addresses. It’s about revealing infrastructure weaknesses—like poor DKIM implementation—that impact deliverability long before the first email is sent.

Integrate MailTester to catch header reordering issues in your email workflow

You can prevent b= value mismatches caused by header reordering by validating email authentication setup at every step—before sending. Use real-time checks during signup, pre-send list verification, and inbox-placement testing to catch issues like misaligned DKIM signatures before they trigger deliverability failures.

Validate authentication in real time

Use the MailTester API to verify every email address during signup or onboarding—detect invalid domains, catch-all setups, or weak authentication before they become deliverability risks.
Integrate the API into your data ingestion pipeline to flag domains with inconsistent header ordering or missing authentication records, ensuring only properly configured addresses reach your sends.

Proactively audit your entire list

Run bulk verification via the MailTester bulk checker to identify domains with high bounce risk, missing or weak DKIM, or role-based addresses (e.g., admin@, sales@) that are often rejected.
Use the in-app AI assistant to analyze list health and surface patterns—like repeated b= value discrepancies or inconsistent DKIM alignment—that point to header reordering or flawed email formatting in your workflow.
Test final delivery with inbox-placement testing across real domains (Gmail, Outlook, Yahoo) to confirm your messages land in the inbox, not the spam folder—before launching wide-scale campaigns.

Header reordering during transit or processing can break DKIM’s cryptographic verification, leading to a mismatch in the b= value and a failed authentication. This is especially common when email templates are modified or routed through third-party platforms. Tools like MailTester help catch these issues early by validating the full email chain—not just the address.

As outlined in RFC 6376, DKIM relies on the integrity of header order; any change after signing invalidates the signature. Even minor alterations during routing or content injection can break authentication. You can’t always control how messages are handled downstream, but you can control what goes out the door.

Final takeaway: DKIM is not just about signing—it’s about consistency

The b= value in a DKIM signature is a cryptographic digest, not a fixed token. It depends entirely on the exact structure, order, and content of the email’s headers and body as they were canonicalized at the time of signing.

Even minor changes during transit—reordering of headers, insertion of tracking pixels, or misconfigured mail servers—can alter the canonicalized data and invalidate the signature. This is why inconsistent infrastructure, automated processing, or poorly managed relay chains are a primary source of DKIM failures.

Preventing these issues starts with consistent email formatting and transport rules. Verification tools like MailTester help you catch structural flaws early, ensuring your domain’s DKIM setup holds up under real-world conditions.

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 does 'b= value differs' mean in a DKIM failure?

The b= value in a DKIM signature is a hash of the email's canonicalized content. If it differs from the recipient server's computed hash, the signature is invalid—often due to header reordering during transit.

Can email clients add headers that break DKIM?

Yes. Client-added headers like Delivered-To or X-Original-To can alter the header order or content, leading to a mismatched b= value if not handled properly by the signing process.

Does DKIM fail if just one header is reordered?

Yes. DKIM canonicalization rules depend on header order. Even a single reordering—such as moving a Received: line—can change the hash and cause verification to fail.

How can I test if my DKIM signature is correctly applied?

Use a DKIM validator tool or retrieve the raw header from a test email. Compare the computed b= value with the one in the signature. Differences indicate misalignment in signing logic or header handling.

Can header reordering happen in SendGrid or Mailchimp?

Yes—both platforms may add headers for tracking or routing, especially in transactional workflows. If not properly excluded from DKIM signing, this can break the signature.

Do all email providers use the same DKIM canonicalization method?

No. While RFC 6376 defines standard rules, some providers apply minor variations. This increases the risk of mismatched b= values if not verified across recipients.

How does MailTester detect DKIM issues during verification?

MailTester checks for valid DKIM signatures during domain-level verification and flags domains with weak or inconsistent configurations, helping identify potential delivery risks.

Is DKIM failure always caused by header reordering?

No—but header reordering is a common cause. Others include incorrect key format, expired keys, missing DNS records, or improper header canonicalization during signing.

Can a domain pass DKIM verification but still be blocked?

Yes. A valid DKIM signature does not guarantee inbox delivery. Issues like poor sender reputation, spam trap hits, or blacklisting can still block delivery.

Are there tools that simulate real delivery with DKIM validation?

Yes—MailTester’s inbox-placement testing sends messages through real providers (like Gmail, Outlook) and checks DKIM, spam score, and inbox placement in real time.

Can using MailTester’s API help prevent DKIM issues?

Yes. By verifying email addresses and domains before sending, MailTester identifies domains with weak or misconfigured DKIM, allowing you to fix issues early in the workflow.

Is it safe to use a non-standard header in DKIM-signed emails?

No. Non-standard or dynamically added headers can alter the canonicalized data. Unless excluded from the signature scope, they can cause the b= value to differ and break DKIM.