Why improper DKIM header canonicalization breaks email deliverability

You sent an email that passed every check—valid SPF, correct DKIM signature, clean content. Yet it landed in spam or vanished without a bounce. Why? Chances are, your DKIM h= header list wasn’t canonicalized properly.

DKIM relies on strict formatting rules. If the headers listed in h= aren’t in the exact order, without extra whitespace, or with inconsistent casing, the receiving server fails the signature check—even if everything else is correct. One small mistake in the header list can trigger rejection.

It’s not a theory. Misconfigured DKIM—especially header canonicalization errors—is consistently among the top technical causes of email filtering and bouncebacks. Fixing it isn’t optional. It’s foundational for deliverability.

Key takeaways

  • DKIM header canonicalization must match RFC 6376 exactly: no extra whitespace, exact header order, proper case.
  • Even one non-canonical header in the h= list can invalidate the entire DKIM signature.
  • Canonicalization errors are a common, preventable cause of email rejections and poor inbox placement.

What does 'canonicalization' mean in DKIM header list processing?

Canonicalization in DKIM means defining exactly how headers in the h= tag are formatted and normalized before signing. It ensures the signature remains valid even if the email is slightly modified during transit. Without it, small changes—like whitespace or capitalization—could break the signature and trigger rejection by recipient servers.

Two canonicalization methods: simple and relaxed

DKIM defines two methods: ‘simple’ and ‘relaxed’. Simple enforces exact formatting—case, spacing, and order must match precisely. Relaxed is more forgiving and is the standard for modern email. It allows minor variations in formatting for certain headers, making it more practical for real-world email delivery.

How relaxed canonicalization works

Relaxed canonicalization normalizes specific headers like From, To, Subject, and Date. It ignores case (e.g., "From" vs "FROM"), normalizes whitespace (multiple spaces become one), and allows header order to vary. This means a signature remains valid even if the email client or MTA reorders headers or adjusts formatting.

For example, if a sender’s email client converts “From: [email protected]” to “from: [email protected]” or inserts extra line breaks, relaxed canonicalization ensures the DKIM check still passes. This is critical because email systems frequently modify headers during routing or filtering.

The behavior is defined in RFC 6376, the standard that governs DKIM. You can review the specification at ietf.org/rfc6376 to see how the process is formally defined, including the exact rules for header normalization.

Without proper canonicalization, your DKIM signature may fail during delivery, even if the email is legitimate. This leads to reduced inbox placement, higher spam scores, or outright rejection by receivers like Gmail or Outlook.

For senders using bulk or automated email systems, ensuring header list canonicalization aligns with relaxed standards is a baseline requirement for deliverability. Regularly validating email infrastructure—including DKIM setup—helps catch formatting mismatches early.

You can test how your domain’s DKIM setup holds up in real-world conditions using MailTester’s inbox placement test, which simulates delivery to major inboxes and checks for signature validity and header compliance.

How is the h= header list constructed during DKIM signing?

The h= header list in a DKIM signature must include every header used in the signature, listed exactly as they appear in the message, without values, separated by colons, and with no extra spaces. Omitting or misordering headers breaks the signature check, leading to deliverability failures. You're not just signing a few fields — you're signing the full, canonicalized header list as seen by the receiving server.

Canonicalization rules for headers

DKIM requires strict formatting. The header names in h= must appear in the exact order they occur in the message, with no duplicates or omissions. For example, if your message includes From, To, Subject, and Date, the h= value must read h=from:to:subject:date; and nothing else. Including extra spaces — like h=from : to : subject — will invalidate the signature.

Values are not part of the list. Never include header values — just the names. This includes headers like Content-Type, MIME-Version, or X-Feedback-ID, if they're included in the signature. A single misstep in order or formatting causes the verification process to fail, even if the rest of the email is correct.

Why correct header list construction matters

If your h= list isn’t canonicalized exactly as the receiving server parses it, the DKIM verification fails, and your email may be dropped, marked as spam, or rejected outright. This is especially critical when using third-party services like email service providers (ESPs), which may modify headers during delivery. Your signing process must anticipate this change.

According to RFC 6376 (the DKIM standard), the signing process must use the same canonicalization method (relaxed or simple) that the verifier expects. If your ESP applies relaxed header canonicalization but your DKIM signing uses simple, misalignment occurs. You can test this with tools that simulate real-world verification. RFC 6376 details how the canonicalization process works across both header and body content.

It’s not enough to sign headers. You must sign the correct ones, in the correct order, formatted exactly as specified in the standard. Misconfigured DKIM is a leading cause of email rejection by major providers like Gmail and Outlook — even with valid SPF and DMARC. Double-checking the h= list before sending is a routine step that protects deliverability. Use real-time verification tools to catch these issues early.

If you’re sending large volumes, bulk email list verification can help ensure that the DKIM configuration is consistent across all sends, catching invalid or poorly formatted headers before they hit inbox filters.

How to verify your DKIM h= header list is canonicalized correctly

You can confirm your DKIM h= header list is properly canonicalized by sending a live email through a tool that validates the full SMTP and DKIM chain, then checking its logs for explicit matching between the signed headers and the ones processed during delivery. Use real domains, real senders, and real inboxes to capture actual header normalization behavior—especially around case, ordering, and line folding.

Run a real-world DKIM validation test

  • Send a test email from your actual sending domain through a trusted delivery service with inbox-placement tracking.
  • Use MailTester’s inbox placement tester to send a message that traces the full delivery path, including SMTP handshake, DNS checks, and DKIM validation.
  • Check the delivery logs for explicit indicators like “DKIM signature verified” and “headers matched per canonicalization rules.”
  • Verify that the h= list in the DKIM signature exactly matches the order and naming of headers in the final message body after all normalization steps.

Validate header parsing and normalization behavior

  • Pay close attention to how your email client or provider handles whitespace, capitalization, and line folding—especially in headers like From, To, Subject, and Date.
  • Test with both standard and edge-case header values (e.g., long headers, multiple spaces, mixed case) to ensure consistent canonicalization.
  • Use RFC 6376 as your reference for DKIM canonicalization rules: header names are lowercase, and header values are folded and trimmed per specified rules.
  • Compare the raw DKIM signature’s h= list against the actual headers as delivered—any mismatch means canonicalization failed.

Don't rely on synthetic or pre-fabricated test messages—they won’t reflect the real-world transformations happening during actual delivery. The only way to confirm proper DKIM h= canonicalization is to test with live senders, real domains, and inbox placement tools that log the full SMTP and validation chain.

The difference between a failing DKIM check and a passing one often comes down to the exact spelling, order, and formatting of the headers in the h= list—and that only matters when tested under actual delivery conditions.

Common mistakes that break DKIM header canonicalization

You’ll lose DKIM validation if your h= list isn’t canonicalized correctly: duplicate headers, mixed case, extra spaces, or missing required headers—even invisible ones—can cause signature failures. A single misstep breaks authentication, leading to rejected or marked spam. Use a tool that checks real-world deliverability to catch these issues early.

Specific errors that derail canonicalization

  • Include duplicate headers in the h= list. DKIM treats each header name as unique; repeating one—even once—invalidates the signature.
  • Use inconsistent capitalization. The h= list must use lowercase for all header names, like from:to:subject—not From:To:Subject.
  • Add spaces where none belong. A space after a colon (like from : to) breaks the canonical format. It must be from:to with no spaces.
  • Omit headers that are signed but not visible in the message body. Headers like Message-ID or Date are often signed even if absent from the rendered content. If omitted from h=, signature verification fails.

Why these issues matter in real-world deliverability

Even if your message content is clean, failed DKIM often results in inbox placement issues. Many providers—like Gmail, Outlook, and Yahoo—use DKIM as a primary filter. A broken signature means your message gets flagged, delayed, or blocked outright.

Canonicalization isn’t optional. It’s defined in RFC 6376, the standard governing DKIM. Deviations, no matter how small, cause failures. That’s why tools designed for real-world testing matter—like sending a test message through a service that checks both headers and delivery behavior.

You don’t need guesswork. Use inbox placement testing to verify how your signed messages truly land in real inboxes. It checks not just syntax but actual routing and filtering outcomes—including DKIM compliance—before you send at scale.

How to test your DKIM h= list in a real-world inbox environment

You can validate DKIM header canonicalization in real inboxes by sending test emails through a service like MailTester’s inbox placement tester. This captures the actual header order and structure processed by major email providers, revealing whether your h= list matches what receivers expect. If the header list isn't canonicalized correctly, DKIM fails—even if the signature is mathematically valid. Use the full trace logs to confirm alignment with your sending system's output.

Step-by-step validation process

  • Send a test message using MailTester’s inbox placement testing service at inbox placement tester to evaluate delivery through real mail servers.
  • After the test completes, review the full email trace logs to see the exact header order and content as received by the receiving server.
  • Compare the h= list in the DKIM signature to the actual header order in the trace—especially the order of From, To, Date, Subject, and any custom headers.
  • Check for DKIM validation failures marked as "header mismatch" or "canonicalization error" in the trace. These signal that the receiver processed header names or values differently than your signing system expected.
  • Ensure your signing process applies the same header normalization rules as standard email practices: lowercase header names, trim whitespace, and order headers alphabetically unless you have a documented reason to deviate.
  • Refer to RFC 6376 (section 3.4) for authoritative guidance on header canonicalization, especially the distinction between "simple" and "relaxed" methods that affect how headers are processed during signature verification.

Why this matters for deliverability

Even minor deviations—like sending a header in a different order than listed in h=—can trigger DKIM validation failure. This isn’t just a technical detail; it directly affects inbox placement. Major providers like Gmail and Microsoft Outlook do not tolerate header mismatches, and repeated failures may degrade sender reputation.

MailTester’s trace logs include both the raw message and a parsed DKIM verification status. If your h= list includes from but the trace shows From, that’s a canonicalization gap—lowercase from is not valid; From must be lowercase in the header.

Let’s be clear: DKIM is not just about encryption—it’s about consistency. A single canonicalization error can cause a message to fail silently in the inbox. The only way to catch this is by testing in real environments.

How MailTester helps verify DKIM header list correctness

You can ensure your DKIM h= header list is properly canonicalized by testing the full delivery chain with MailTester’s inbox placement feature. It checks the exact headers included in the signature against what actually arrives in the inbox, catching issues like incorrect ordering, extra whitespace, or missing headers that break validation—errors that often go unnoticed until deliverability drops.

Testing DKIM in a real-world delivery path

SMTP delivery isn’t just about sending an email—it’s about delivering it intact. MailTester simulates real-world inbox delivery by sending test messages through major providers (Gmail, Outlook, Yahoo). During this process, it inspects the DKIM signature and compares the h= tag against the actual headers in the message body.

Unlike some tools that only scan metadata in a vacuum, MailTester evaluates DKIM in context. This means you’re not just checking if the signature exists—you’re verifying whether it matches the incoming message as seen by the recipient’s server. The DKIM specification explicitly defines canonicalization rules for header ordering and whitespace, and failing to follow them breaks validation.

Seeing the discrepancies that matter

When you run an inbox placement test, MailTester shows you the exact header list used in the h= tag—such as from:to:subject:date:content-type—and highlights any mismatches. You’ll see if a header was omitted, added incorrectly, or if whitespace was inconsistently applied (like extra spaces between headers).

For example, a common mistake is listing From but not from in the h= tag. DKIM is case-sensitive in header names, and even a single lowercase discrepancy breaks the signature. MailTester flags these differences clearly so you can fix the signature before it affects your sender reputation.

It also detects improper canonicalization of header values—such as folding long lines or inconsistent line endings—which can invalidate a signature even if the header list appears correct on paper. You get a detailed, real-time report showing exactly where and how the signature fails.

For teams that send bulk emails, this level of visibility prevents avoidable bounces and spam filtering. If you're using tools like Mailchimp, Klaviyo, or SendGrid, integrating MailTester lets you test your DKIM setup end-to-end, not just in isolation.

DKIM header canonicalization: the exact RFC 6376 requirements

You must canonicalize the DKIM h= header list exactly as specified in RFC 6376: all header names in lowercase, no duplicates, no extra spaces, and in the same order they appear in the original message headers. If relaxed canonicalization is used, you may reorder and normalize whitespace—but only if both sender and receiver agree. Fail to follow these rules, and your DKIM signature will fail validation, leading to deliverability loss.

Core canonicalization rules from RFC 6376

  • Header names in the h= tag must be lowercase. Uppercase or mixed-case names invalidate the signature.
  • Each header name must appear only once. Duplicates—like h=from:from—are not allowed.
  • No spaces are permitted before, after, or between header names. The list must be a bare, space-separated sequence: h=from:to:subject, not h= from : to : subject .
  • The order of header names must match the order they appear in the message's header section, unless relaxed canonicalization is applied. Changing the order breaks the signature.

Relaxed canonicalization: when it’s allowed

Relaxed canonicalization lets you reorder headers and normalize whitespace, but only if your domain and the receiving mail server agree on the use of this method. It's commonly used in practice, especially with large email providers like Gmail, Yahoo, or Microsoft, which accept relaxed formatting. Still, strict canonicalization is the default, and your alignment with RFC 6376 ensures consistency across all receivers.

According to RFC 6376, section 3.4.1, the header list must be processed in a way that preserves the original message structure unless relaxed normalization is explicitly used. This is not optional—it's a requirement if you're signing with DKIM.

When building your DKIM signature, it’s easy to skip or misapply these rules during automation. You’re better off testing your headers against actual receiving servers. Use tools that simulate delivery and validate DKIM signs in real-world conditions.

For a deeper look at how DKIM impacts deliverability, check how real emails land in inboxes using our inbox placement tester. It checks DKIM, SPF, and message content alongside actual provider behavior.

What happens when DKIM validation fails due to header canonicalization

If your DKIM signature’s h= header list isn’t properly canonicalized, the receiving server may silently reject the message or mark it as spam—without sending a bounce. This happens because DKIM validation requires exact header alignment during signing and verification. Even small differences in whitespace, order, or capitalization break the signature, leading to undeliverable emails or poor inbox placement. You might not know it’s happening, but repeated failures erode sender reputation, eventually triggering filters that block your mail altogether.

Why the failure goes unnoticed

Unlike a hard bounce, DKIM failure due to header canonicalization rarely generates a delivery error. Receiving servers often don’t notify you when signing fails, especially if the email is still accepted for delivery. That means your message may “arrive” but land in spam folders or be quarantined. Without visibility, it’s easy to assume deliverability is fine—when in reality, your reputation is quietly degrading.

How repeated failures hurt sender reputation

Mail receivers like Gmail and Outlook use sender reputation as a core factor in filtering decisions. Every DKIM failure—whether from misformatted headers, inconsistent canonicalization, or incorrect header order—adds to a rejection score. Over time, these small failures accumulate and cross thresholds that trigger automated blocks. Even if your content is clean, a poor reputation can prevent your emails from reaching inboxes. This is especially risky if you're running campaigns at scale.

One common cause: improper header list formatting in the h= tag. For example, failing to include all headers in the correct order or adding extra spaces can break signature validation. The SPF and DKIM standards defined in RFC 6376 are strict about header canonicalization, and servers enforce them precisely.

Let’s say you’re sending from a tool that doesn’t fully implement header canonicalization—like skipping the From header in the list, or using mixed case. The signing algorithm will process those headers one way, but the verifier expects another. Result? Silent failure. Even a single missing header can invalidate the entire signature.

To catch these issues before you send, test your email’s DKIM setup using an inbox placement tool that validates both headers and signing. MailTester’s inbox placement tool checks real email environments and surfaces hidden DKIM issues early—before you lose reputation or engagement.

How to prevent DKIM header issues before they cause delivery problems

You can prevent DKIM header issues by verifying domains and headers in advance, testing DKIM signing in staging environments, and confirming how your email service provider signs messages. Use a trusted tool like MailTester to catch invalid or improperly canonicalized headers before they impact deliverability.

Validate DKIM headers before scaling sends

  • Run a bulk verification on your email list using MailTester’s bulk verification tool to identify malformed or invalid addresses that may trigger DMARC or DKIM validation failures.
  • Test individual headers and DKIM signatures using MailTester’s real-time email checker to see if the h= header list matches what the receiving server expects.
  • Ensure your email service provider signs messages with a consistent header list—some tools add or reorder headers during delivery, which breaks DKIM unless the signing process accounts for canonicalization.

Test DKIM behavior across your stack

  • Check how your ESP (SendGrid, Mailchimp, Klaviyo, etc.) applies DKIM by sending test emails from staging environments and inspecting the raw headers using a tool like MxToolbox or DMARC Analyzer.
  • Compare the h= header list in the DKIM signature with the actual headers in the message body—it should match exactly, including ordering and whitespace.
  • Use MailTester’s inbox placement test to see how your emails perform in real inboxes—this confirms if DKIM, SPF, and DMARC are aligned and properly configured.
  • Never assume your ESP signs correctly. Even minor differences in header formatting can cause signing failures. Always validate signatures before sending to large lists.

DKIM canonicalization is rigid by design—what’s in the h= list must match the order and syntax in the actual message. A single missing or reordered header breaks the signature. The RFC 6376 specification defines this behavior clearly, and compliance is non-negotiable for inbox placement.

Even a single added space or reordered header in the h= list can result in DKIM signature rejection.

Prevent delivery problems by testing your entire email pipeline—from address validation to final delivery. Use MailTester’s API (real-time email verification API) to automate checks in your workflows and catch issues early.

Final takeaway: canonicalization isn’t optional—it’s mandatory for deliverability

Even one non-canonical header in the DKIM h= list can cause the entire signature to fail. This breaks authentication and triggers filters, reducing inbox placement across major providers.

Only real delivery traces—tests that simulate actual email transmission—can reveal these issues. Synthetic checks or static tools miss nuances like header reordering or whitespace normalization in transit.

Test your DKIM setup across providers with confidence

  • Verify DKIM alignment across domains and mail flows.
  • Use live inbox placement testing to catch normalization errors.
  • Ensure every header in h= is consistently canonicalized, regardless of sending environment.

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 does h= mean in a DKIM signature?

The h= tag in a DKIM signature specifies the list of email headers used to generate the digital signature. These headers must be canonicalized correctly to pass validation.

Can I use mixed case in DKIM header names?

No. DKIM header names in the h= list must always be lowercase. Using uppercase or mixed case causes canonicalization failures.

Why does DKIM fail even when the signature appears valid?

DKIM can fail due to header list misordering, non-canonical formatting, or duplicate entries—even if the cryptographic part checks out.

How do I know if my DKIM h= list is properly ordered?

The h= list must follow the exact sequence of headers as they appear in the raw email. Only relaxed canonicalization allows some flexibility.

Do all email providers check DKIM header canonicalization?

Yes. Major providers like Gmail, Outlook, and Yahoo enforce header canonicalization per RFC 6376 during DKIM validation.

Can a trailing semicolon break DKIM canonicalization?

Yes. A trailing semicolon in the h= list (e.g., h=from:to:) creates an invalid header list and causes signature validation to fail.

How often should I test DKIM header canonicalization?

Test every time you change email templates, update signing tools, or onboard new senders—ideally before every major send campaign.

Does MailTester check DKIM header canonicalization?

Yes. MailTester’s inbox placement testing includes full DKIM header validation, including canonicalization checks for the h= tag.

Can I use email verification to test DKIM correctness?

Not directly, but MailTester’s verification API and bulk list checks can identify invalid or malformed addresses that might trigger DKIM anomalies.

What happens if I sign the same header twice in h=?

It breaks canonicalization. Each header must appear only once in the h= list. Duplicate entries invalidate the signature.

Is relaxed canonicalization better than simple?

Relaxed allows some flexibility in case and whitespace but still requires correct header order and single use per header.

Why don’t I get any DKIM error messages when it fails?

DKIM validation failures are typically silent. Receiving servers don’t reject or notify senders—delivery failure may go unnoticed.