Why is DKIM canonicalization breaking your email delivery?

You sent a batch of transactional emails. They didn’t reach inbox, but bounced with a “DKIM signature verification failed” error. No spam filter warning, no clear logs — just silence.

Digital signatures like DKIM rely on precise header formatting. Even a tiny mismatch between the header the server sees and the one it signs breaks trust. The root issue? Canonicalization rules applied incorrectly during header processing. It’s not a flaw in the signature — it’s how the email’s headers were restructured before signing.

DKIM canonicalization is supposed to standardize headers so receivers can verify the same content you signed. But if the rule misapplies — say, collapsing whitespace inconsistently or stripping required fields — the signed header doesn’t match the received one. That’s why emails from known senders end up flagged as forged.

Key takeaways

  • DKIM fails when canonicalization alters headers differently than the receiving server expects.
  • Misapplied rules often stem from incorrect implementation of the "relaxed" canonicalization algorithm applied to headers.
  • Even valid emails can be rejected if header whitespace or field ordering are altered during signing.

What does 'applying incorrect rule to email headers' actually mean in DKIM?

When DKIM says "applying incorrect rule to email headers," it means the email’s signing server used a different canonicalization method (like relaxed) than the verifying server expected (like simple). This mismatch alters how header whitespace and line breaks are normalized before hashing, causing the signature to fail even if the email content is otherwise correct. The result? Your email gets rejected or marked as suspicious, often silently.

How canonicalization actually works in DKIM

DKIM defines two canonicalization methods: simple (s) and relaxed (r). For headers, relaxed rules allow you to ignore minor formatting differences — like extra spaces, line breaks, or header order — as long as the core content remains the same. Simple rules require exact matching, down to every space and newline.

Let’s say your email client adds a space before a header value, or reorders headers during transport. Relaxed canonicalization will ignore that change. Simple canonicalization won’t. If your server signs using relaxed but the recipient’s server checks using simple, the computed hash won’t match the signature. That’s why the check fails.

Why misalignment happens and how to catch it

This issue shows up in real-world setups where the sending system defaults to relaxed (common in modern platforms like SendGrid or Mailchimp), but the receiving system’s policy expects strict matching. There’s no universal default—different email providers apply their own rules. You might see this in DMARC reports or BIMI failure logs, often with vague messages like “signature validation failed.”

Diagnosing it requires checking both the signing process and the recipient’s verification setup. Tools like inbox placement testers can simulate how your email performs from real inboxes, capturing delivery behaviors that include signature validation. You can verify header canonicalization indirectly—by validating the signature's integrity across multiple receivers.

For deeper insight, refer to RFC 6376, the official DKIM specification, which details how the relaxed and simple algorithms process content. It’s the definitive guide on what “applying incorrect rule” actually means at the protocol level.

How DKIM canonicalization works in practice

When you send a signed email, your mail server applies canonicalization rules to headers and body—normalizing line breaks, trimming extra whitespace, and standardizing field order—before hashing them into the DKIM-Signature. The receiving server does the same. If the resulting hash doesn’t match, DKIM fails. This process ensures integrity, but misapplication of rules, especially to headers, is a common point of failure. Let’s walk through the steps.

Step-by-step: How DKIM canonicalization processes your email

  1. Header canonicalization begins as your mail transfer agent (MTA) prepares the DKIM-Signature header. It identifies all email headers, strips trailing whitespace, and normalizes line endings to CRLF (carriage return + line feed) regardless of the original format. This ensures consistent results across systems.
  2. Fields are reordered according to RFC 6376—specifically by the field name in ASCII sort order. This means "From" comes before "To" and "Subject" comes after "To". If your MTA applies a custom or arbitrary order, the hash will differ at the receiver’s end.
  3. Body canonicalization follows with line endings normalized to CRLF and trailing whitespace removed. Some MTAs also add a newline after the body, which is not required but can cause mismatch if not applied consistently. The body is then processed in chunks, and a single hash is computed per chunk.
  4. The canonicalized strings are hashed using SHA-256 (or SHA-1 in older setups). The resulting digest is included in the DKIM-Signature header, along with selector, domain, and signing algorithm.
  5. Receiving servers repeat the process using the same rules. They re-parse the same headers and body, apply the same normalization, and compute their own hash. A mismatch—no matter how small—leads to DKIM failure, even if the email content is otherwise valid.

Why header order and whitespace matter

Even a single extra space in a header line or a change in field ordering breaks the hash. This makes DKIM highly sensitive to how the MTA configures canonicalization. An incorrect rule—like applying body-only normalization to headers—will cause consistent failures. You can test this by checking if a valid email fails DKIM on a test server like Spamhaus.org or MXToolbox.

Use a tool like MailTester’s email checker to validate sender domains and verify that your DKIM setup applies the correct rules. It checks both syntax and behavior across real infrastructure, helping you catch misconfigurations before they impact deliverability.

Common cases where the wrong canonicalization rule is applied

You’re likely seeing DKIM signature failures because your email server is using relaxed canonicalization on headers when the receiving domain’s DMARC policy requires simple. This mismatch breaks alignment unless the header content is cleaned exactly as expected. Let’s walk through why this happens and how to fix it before sending.

Signature alignment fails due to mismatched canonicalization rules

  • Using relaxed canonicalization on headers when the domain’s DMARC policy expects simple canonicalization. This is a common cause of DMARC failure even when DKIM signs correctly.
  • Headers with inconsistent capitalization or extra whitespace (like Subject: Newsletter) not normalized before signing—relaxed canonicalization tolerates this, but simple does not.
  • Multiple headers with the same name (e.g., multiple Received: lines) being processed inconsistently—some mail systems concatenate these; others treat them as separate, causing different hash results.
  • Email clients or relays modifying headers (like inserting a Precedence: bulk line) without reapplying canonicalization, leading to signature mismatches later.

How to detect and prevent these issues

Many tools don’t surface this issue unless you inspect the raw message. When you see a “DKIM signature valid but not aligned” error, it’s often due to canonicalization mismatch. RFC 6376 (the standard for DKIM) defines the behavior clearly—relaxed and simple are distinct, and the signing and verification ends must agree on which rule is used.

You can verify the canonicalized output of your email headers using a DKIM validator like DKIM Validator to see how your headers are being processed. Compare the result with the expected output for your domain’s DMARC policy, especially if your domain uses asp=1 or adkim=1 in its policy.

When using third-party email delivery services (like those in our integrations), confirm their canonicalization settings. Some platforms default to relaxed, which may not work if your recipient’s DMARC policy enforces simple.

Before sending bulk campaigns, test your signed email headers with tools like MailTester’s inbox placement test to see if the DKIM alignment passes in real-world conditions. This catches issues early, before you hit deliverability problems or spam filters.

The impact of incorrect DKIM canonicalization on sender reputation

Incorrect DKIM canonicalization can disrupt email delivery and erode sender reputation, even if the rest of your email infrastructure is sound. A single failed DKIM signature—caused by misaligned header or body canonicalization—can trigger spam filters, reduce inbox placement, and prompt automatic suppression by mailbox providers. If ignored, repeated failures may lead to domain-level blocks, especially when aligned with a strict DMARC policy.

How DKIM failures affect deliverability

When a DKIM signature fails due to incorrect canonicalization, it signals to the receiving server that your email’s content may have been tampered with or is improperly formatted. This raises red flags even if the message is otherwise legitimate. Major mailbox providers like Gmail and Microsoft Outlook use DKIM validation as a core component of their spam screening. A consistent pattern of failures, even across a large campaign, can result in your IP or domain being flagged as untrustworthy.

Let’s say you send 100,000 emails and one fails DKIM due to a misapplied canonicalization rule. That single failure may not block the entire batch, but it can trigger automated filters that lower your sender score. Some providers apply real-time learning, so repeated failures—even minor ones—can degrade your reputation over time. This affects not just the specific message, but all future communications from your domain.

Reputation damage escalates with DMARC enforcement

When DMARC is configured with a reject policy, any message that fails either SPF or DKIM alignment is rejected outright. If DKIM fails due to incorrect header or body canonicalization, the entire message is blocked. This is especially impactful for domains with strict DMARC policies, as even one misaligned signature can result in a failed authentication chain.

According to the RFC 6376, the DKIM canonicalization process must consistently apply to both header and body fields. If your email system applies different rules—such as stripping whitespace in headers but not in body—your signature will not match the receiver’s calculation, causing failure. This is not a minor oversight; it undermines the entire cryptographic trust model.

Once a domain is marked as failing DKIM consistently, some providers begin withholding messages entirely to protect users. Recovery is slow. Even after fixing the canonicalization rule, it may take days or weeks for reputation signals to normalize. That’s why catching these errors early—before sending at scale—is critical.

MailTester’s email checker lets you verify individual addresses for authentication readiness, including DKIM alignment, before sending. For larger campaigns, use the bulk verification to catch issues across your list early.

How to verify DKIM canonicalization rules are correctly applied

You can verify DKIM canonicalization rules are correctly applied by inspecting the DKIM-Signature header for a proper h= tag listing only the headers you intended to sign, confirming the b= value matches a hash generated from the canonicalized header and body, and validating the signature using public tools like OpenDKIM’s validator. If the rules are applied incorrectly, the signature will fail during verification.

Use real-time validation to spot canonicalization issues early

Let’s start with the basics. You’re not just sending emails—you’re signing them. If the canonicalization rule is misapplied, even a small header difference can invalidate the signature.

Begin by checking the raw message headers in a delivered email. Use MailTester’s email checker to validate the full envelope and headers in real time. It checks for issues like incorrect field ordering, improper header folding, or unexpected fields included in the h= tag.

  1. Examine the DKIM-Signature header for a correct h= tag. The fields listed in h= should match exactly what you intended to sign. Common fields are from, to, subject, and date. If h=received appears without proper handling, it can break the signature. Use RFC 6376 (Section 3.4) to confirm valid header field names and canonicalization rules.
  2. Verify that the b= value corresponds to the canonicalized body and header string. The value after b= must be a SHA-256 hash of the full canonicalized body and header string. If the h= list includes unexpected fields, or if the body canonicalization differs between signing and verifying, the b= value will not match. Use tools like DKIM Validator to check if the signature is mathematically consistent with the input.
  3. Compare signing and verification side outputs using public validators. Different systems may apply different canonicalization rules—header or body. Use a tool like the one at RFC 6376 to simulate canonicalization and compare outputs. If your server signs with relaxed header canonicalization but the verifier expects simple, then the signature fails—even if all other fields match.

Ensure consistency across your email infrastructure

Multistep email pipelines often introduce mismatches. A gateway may modify headers before signing, or a third-party ESP might canonicalize differently. Use MailTester’s inbox placement test to simulate delivery and inspect signatures at the receiving end. If the signature fails in a real inbox, the canonicalization was likely applied incorrectly.

Finally, log the raw headers from both your signing endpoint and the receiving server. Compare the canonicalized strings step by step. If you see subtle differences—like a missing CRLF or a re-ordered header—track it back to the signing process.

Real-world example: A misapplied relaxed rule in a transactional email

Relaxed header canonicalization can break DMARC alignment when the receiving MTA expects strict header matching. A SaaS company using relaxed rules on their transactional emails failed DMARC checks after a receiving domain enforced strict policies, causing 30% of messages to be rejected without a bounce — only visible later in aggregate reports.

The hidden failure: why deliverability dropped silently

They signed emails with relaxed canonicalization, which ignores certain header differences like whitespace or order. This worked fine with most providers, but one enterprise customer used a strict DMARC policy — their MTA required exact header alignment, including case and order. The signature failed because the relaxed rule altered headers in a way that broke strict alignment, even though the content was unchanged.

Since the rejection wasn’t immediate, there were no bounce messages. Instead, the emails were silently dropped, leading to a 30% drop in inbox placement. It took weeks to trace the issue to the signing method, not sender reputation or content.

Fixing the root: aligning with the receiving MTA's expectations

They switched their signing library to use simple canonicalization for headers, which preserves exact header order and case. This matched the stricter validation rules used by enterprise MTAs. The fix was not about changing the content — just how the headers were processed before signing.

DMARC alignment now passed consistently. This case shows that a subtle difference in canonicalization rules can cause silent delivery failures, especially when sending to organizations with tight email policies. The fix required no changes to DNS, content, or sender IP — just selecting the right rule in the signing stack.

Headers must be canonicalized consistently across the entire delivery chain. The RFC 6376 specification defines both relaxed and simple methods, but implementation choices affect real-world deliverability. You can't assume “relaxed” is always safe. The receiving side’s policy dictates what works.

Use tools like inbox placement testing to catch alignment issues before scaling. They simulate real-world conditions, including DMARC and SPF checks, revealing silent failures that traditional bounce tracking won’t catch.

DKIM canonicalization rule reference: What each setting does

You're troubleshooting DKIM canonicalization because your emails are failing verification due to incorrect header processing. The canonicalization type—simple (s) or relaxed (r)—determines how DKIM signs and checks headers. Simple preserves exact formatting; relaxed normalizes whitespace and order. Use simple for strict environments. Use relaxed for high-volume transactional sends. Learn the real impact of each setting to fix your DKIM alignment issues.

Simple vs. Relaxed: When to use each

Let’s break down how each canonicalization rule affects header processing in practice.

DKIM Canonicalization Settings Reference

Header Canonicalization Type Effect on Header Processing Common Use Case
Simple (s) Preserves the original header order, line breaks, and capitalization exactly as sent. No normalization occurs. High-security domains, strict DMARC policies, or when sending compliance-sensitive emails. Used when header integrity must match exactly.
Relaxed (r) Merges folded header lines, collapses multiple spaces into one, and ignores header line order. All whitespace is normalized. Transactional or bulk email systems (e.g., newsletters, order confirmations). Common in high-throughput environments where minor header variations occur.

Simple (s) is more accurate for systems where every byte matters—such as financial or government email flows—but it's fragile. A single extra space or line break can break verification. Relaxed (r) is more forgiving and widely supported, which is why RFC 6376 specifies it for most mail transport scenarios. You can find the full technical definition in RFC 6376, which outlines both rules for header and body canonicalization.

If you're seeing inconsistent DKIM failures, check whether your email system applies simple or relaxed canonicalization and align it with your receiving domain's expectations. Misalignment here causes DKIM "fail" results even when the email is legitimate. Tools like MailTester’s email checker can help test individual addresses and analyze DKIM alignment issues in real time—without relying on guesswork.

How MailTester helps catch DKIM canonicalization issues before send

DKIM canonicalization applies rules to headers during signing and verification. If the header order or formatting differs between signing and checking, the signature fails. MailTester’s inbox-placement testing simulates real email delivery across major providers, validating DKIM signatures and detecting mismatches in header canonicalization before you send. This catches issues early, avoiding bounces and inbox placement drops.

Why this matters

DKIM relies on precise header handling. The signing process uses one canonicalization method; the verifying server expects the same. Even small differences—like extra whitespace or header reordering—can break validation. According to RFC 6376, canonicalization is a core requirement for DKIM integrity, and misapplication is commonly seen in automated systems.

How MailTester detects issues

  • Use inbox-placement testing to simulate delivery across Gmail, Outlook, Apple Mail, and others—each server checks DKIM using its own rules, exposing any canonicalization mismatch.
  • MailTester verifies DKIM signatures in context, comparing the signing headers against how they appear during delivery testing. If the header order or formatting doesn’t match, the tool flags it as a canonicalization failure.
  • Test individual messages via the real-time verification API or scan entire lists in bulk with bulk verification. Both processes check DKIM alignment during the delivery simulation.
  • The in-app AI assistant analyzes header formatting and alerts you to anomalies—like redundant headers, unexpected line breaks, or inconsistent capitalization—that can confuse canonicalization rules.
  • For developers, the inbox tester reveals exactly how each provider interprets your headers. You see the exact header order and structure used during DKIM validation, so you can adjust your signing process accordingly.
Even minor header changes during transport can invalidate a DKIM signature if canonicalization rules are applied inconsistently.

Final steps: auditing your email infrastructure for canonicalization drift

You’ve identified the root cause—incorrect canonicalization rules misapplying to headers—but fixing it requires a full audit of your email sources. Start by reviewing every sending system, validate header consistency across all platforms, and use real-world data testing with MailTester’s bulk verification to catch discrepancies before they hit inboxes. Proactively integrate checks into your deployment pipeline to stop drift before it starts.

Step 1: Map all email sources and their sending paths

Let’s not assume everything is consistent. Every transactional system, marketing platform, and notification service sends emails through different routes. Some might use a custom header, others rely on default library behavior. Identify every source sending email on your behalf—whether it's a CRM, an event trigger, or an automated support system—and record how they encode headers. Canonicalization issues often crop up where systems bypass standard email libraries, leading to inconsistent header formatting.

Step 2: Validate canonicalization rules across all platforms

DKIM signature generation depends on your canonicalization algorithm—both header and body—and if any platform uses a non-standard or inconsistent rule, the signature will fail verification. You need to confirm that all systems agree on the exact header ordering, whitespace treatment, and line ending handling. Use RFC 6376 (the standard for DKIM) as your reference [RFC 6376] to verify alignment. Even small differences—like whether a header is folded into multiple lines or collapsed—can break signatures.

Step 3: Spot-test with real-world data using MailTester

Run a bulk verification on 1,000+ email receipts from your actual sends. Let MailTester analyze the actual DKIM signatures, headers, and content. It checks whether signatures align with expected canonicalization rules, flagging anomalies such as incorrect header sorting or altered whitespace. This isn't hypothetical. You’re checking live traffic, including real-world headers sent through your infrastructure. Use MailTester’s bulk verification to test this at scale with no setup time.

Step 4: Automate validation at deployment time

Set up automated checks in your CI/CD pipeline or deployment processes. Before a new email system goes live, verify that any DKIM-signed messages comply with expected canonicalization rules. Use the MailTester API to validate configurations as part of your deployment script. This prevents the same misconfiguration from recurring across environments. It’s not just about fixing today—it’s about locking in consistency for every future change.

Conclusion: Stop treating DKIM errors as backend noise

DKIM canonicalization errors are not random artifacts. They reveal misaligned processing between your email system and the recipient’s mail server — often due to incorrect header normalization or signature alignment.

Resolving these errors directly lowers bounce rates, improves inbox placement, and maintains sender reputation. Ignoring them treats deliverability risks as inevitable, not fixable.

Use MailTester’s real-time verification and inbox testing to inspect headers in context, catch canonicalization flaws before sending, and ensure every message is correctly signed and aligned.

Sources

Keep reading

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

Frequently asked questions

What is canonicalization in DKIM?

It’s the process of normalizing email headers and body content to ensure consistent hashing. DKIM uses simple or relaxed rules to standardize whitespace, order, and case before signing.

Why is the 'relaxed' rule commonly chosen for DKIM?

It tolerates minor header changes during transit, like reordered Received: lines, reducing false signature failures on bulk emails.

Can the wrong canonicalization rule cause a DMARC failure?

Yes. If DKIM fails due to mismatched canonicalization and DMARC policy requires alignment, the email is rejected.

How do I know which canonicalization rule my domain expects?

Check your DMARC policy. If it requires strict alignment, test with simple rule. Most public domains expect relaxed, but verify using tools like MailTester.

Does MailTester detect DKIM canonicalization problems?

Yes. MailTester verifies DKIM signatures during inbox-placement tests and flags mismatches between signed and canonicalized headers.

Can an email client affect DKIM canonicalization?

Yes. Some clients rewrite headers (e.g., adding a 'Reply-To' or 'Precedence') without re-signing. This breaks the canonicalization unless reprocessed.

Are relaxed and simple canonicalization interchangeable?

No. They produce different hash values. The signing and verifying systems must use the same rule to pass validation.

How often should I audit DKIM canonicalization?

At least quarterly, or after any new email platform integration. Use MailTester’s bulk verification for ongoing checks.

Can a single malformed header break DKIM?

Yes. Unnormalized line breaks or multiple header fields can cause the canonicalized string to differ between signing and verification.

Does MailTester offer DKIM validation through its API?

Yes. The real-time verification API includes DKIM signature checks, including header canonicalization consistency, when processing email data.

Why are some DKIM failures invisible in bounce logs?

They’re often soft bounces or silently filtered. Only inbox-placement testing reveals delivery impact without a delivery failure.

What are the most common DKIM header issues outside of canonicalization?

Missing 'h=' tag, incorrect header field list, malformed 'b=' value, and incorrect algorithm selection (e.g., rsa-sha256 vs rsa-sha1).