What Causes DKIM c=s Canonicalization to Fail When Headers Are Not Sorted

Why does DKIM canonicalization fail when email headers aren’t sorted?

You sent an email that passed all checks—until the receiving server flagged the DKIM signature as invalid. You’re sure the key was right, the domain matched, and the body was untouched. So why did it fail?

The answer lies in one quiet detail: header order. DKIM signing depends on strict canonicalization—specifically, headers must be sorted alphabetically by field name. If any email relay, MTA, or middleware reorders or inserts headers, the hash changes. The signature no longer matches the verification hash. This is not a rare glitch. It’s a direct consequence of violating RFC 822 and RFC 6376 rules.

Key takeaways

• DKIM canonicalization requires headers to be sorted alphabetically by field name, as defined in RFC 822 and RFC 6376.
• Any change to header order—by a relay, MTA, or email processor—breaks the DKIM signature hash alignment.
• Even minor header reordering during transport can lead to DKIM verification failure, regardless of valid DNS records or keys.

What is DKIM canonicalization, and why does it matter?

DKIM signs an email by creating a cryptographic hash of its content and headers—after applying strict rules to format them consistently. This process, called canonicalization, ensures the signature remains valid only if the email is unchanged. When using c=s (simple) canonicalization, even a minor deviation—like a header appearing out of order or having extra whitespace—invalidates the signature. That's why sorting headers by name and preserving line folding exactly as per RFC 822 is critical.

How DKIM canonicalization works in practice

DKIM supports two modes: relaxed and simple. With c=s, every header must be sorted alphabetically by name, and no line folding should alter the field name. For example, a line break between From: and the address is allowed—but if the name is split with a space where the colon should be, the canonicalization fails. This strictness is intentional: it prevents malicious alterations that could bypass authentication.

Even a single misplaced header—say, X-Priority before From—breaks the signature validation in c=s mode. This isn’t a bug; it’s a feature designed to catch tampering. The signature is computed on a standardized version of the message, so any deviation during transit or rewriting by a mail server will invalidate the check.

For senders using custom or automated email tools, this means header ordering isn’t optional. A misconfigured script or misapplied merge tag can introduce whitespace or reorder fields—silent failures that don’t generate bounces but do trigger rejection by receiving servers. This is especially common when using older or poorly implemented libraries that don’t follow RFC 822 exactly.

Understanding this helps explain why some emails pass SPF but fail DKIM, even with correct keys. The failure isn't the key—it's the formatting. A RFC 822 reference confirms that header field names must appear in strict alphabetical order when using c=s. And while c=r (relaxed) allows more flexibility, many receivers still prefer or require c=s for stricter validation.

Let’s say you’re sending transactional emails via a platform that auto-generates headers. If you’re seeing consistent DKIM verification failures, it’s likely not your key. It’s how the headers were written. You can test this by simulating the exact header order and formatting used in your sent emails. Tools like MailTester’s inbox placement test can help verify real-world delivery results—showing whether a DKIM failure is stopping your email from landing in the inbox.

How does RFC 822 govern header order in DKIM signing?

DKIM signing fails when headers aren’t sorted per RFC 822 because the canonicalization process relies on a consistent, predictable order. If headers are out of sequence—like 'Date' appearing before 'From'—the signature hash won’t match the one the receiver computes, causing verification to fail. This happens even if the content is correct, just misordered.

Why order matters in the signing process

DKIM, defined in RFC 6376, requires that header fields be sorted lexicographically before hashing. This means 'Content-Type' comes before 'Date', and 'From' comes before 'To'—not by content, but by alphabet. The rule applies to header names only, not values. Even a trailing space in a header name can break this sort order, making the final signature invalid.

Let’s walk through it: suppose your message has 'To: [email protected]' above 'From: [email protected]'. The signer’s library might sort these alphabetically, placing 'From' first. But if your email client or mailer inserts a header with a typo like 'From:' with a trailing space, it sorts after 'From'—and breaks the entire canonicalization chain.

Where RFC 822 sets the standard

While RFC 822 itself is now obsolete (replaced by RFC 5322), its core principle remains: headers must be in a consistent order for reliable parsing and processing. The canonicalization method used in DKIM—c=s, or "relaxed" canonicalization—is rooted in this idea. It standardizes how headers are normalized, so no matter who signs or who receives the email, the hash remains the same.

For reference, the original RFC 822 specification states that header fields must be processed in a reliable, predictable way—something that’s still critical in today’s email ecosystem. Modern implementations follow this through the relaxed header canonicalization specified in RFC 6376, which explicitly says header names must be sorted lexicographically with case folding and line feed normalization.

When you’re building a system that signs emails, you can’t assume the mail server will sort headers correctly. The signing library must handle this. If you’re seeing unexpected DKIM failures, check the order of headers before hashing. Even minor inconsistencies—spaces, mixed case, or incorrect line endings—can cause failures.

To test whether your headers are in the correct order, you can use tools that simulate the DKIM signing process and validate the canonicalized output. For example, MailTester’s email checker verifies individual addresses and can expose anomalies in message structure that impact signing.

What happens when you send headers out of order?

When you send email headers in a different order than the receiving server expects—especially under DKIM's c=s canonicalization—your signature will fail. The receiving server reorders headers alphabetically before verifying the signature, so if your original header sequence doesn’t match that expected order, the computed hash won’t match, and your email may be rejected or marked as spam. This often happens when automated systems or poorly configured tools generate headers in non-RFC 822 order.

How canonicalization affects DKIM verification

DKIM uses a strict algorithm to generate the signature hash. When c=s (simple canonicalization) is used, the receiving server reorders your headers alphabetically by field name, strips any line folding, and uses exact field names. If your outgoing headers aren’t sorted this way, the signature verification fails—even if the content is correct.

For example, if your email includes From: and To: in a different order than To: and From:, the hash will differ. The receiving server expects the order to be consistent with the RFC 822 standard, which defines that headers be listed in alphabetical order. Any deviation breaks the canonicalization agreement.

Common causes and real-world impact

You’re likely to see issues like this when email platforms or SDKs don’t enforce header ordering during message construction. This is a frequent problem with custom email-sending scripts, certain bulk email tools, or poorly implemented middleware that rewrites headers without sorting them.

When DKIM fails due to header order, receiving servers may reject the email outright, flag it as suspicious, or deprioritize it into spam. Even if the email arrives, many mail providers use DKIM validation as part of their reputation scoring. A repeated signature failure can hurt your sender reputation, especially if combined with other deliverability red flags.

Testing for this issue is not just theoretical. Tools like MailTester’s inbox placement tester can show you if your emails pass DKIM validation in real-world inboxes, including header order checks. You can also use their real-time verification API to check how your headers are structured before sending at scale.

Common causes of unsorted or malformed headers in production

DKIM canonicalization fails when headers aren’t sorted per RFC 822 because the signing process relies on a consistent, predictable header order. If headers are inserted or reordered during transit—by email clients, middleware, or libraries—signatures become invalid. This breaks authentication and harms deliverability, especially when receivers validate DKIM using strict canonicalization rules. You can avoid this by ensuring headers are sorted before signing and by auditing how your email infrastructure handles them.

Custom or injected headers disrupt canonical ordering

Many applications add custom headers like X-Track-ID, X-Forwarded-For, or X-DMARC-Report without reordering the full header set. These headers often appear in arbitrary positions, breaking the strict lexicographic sorting required by DKIM's header canonicalization. The result? A valid signature gets rejected because the signed header list doesn’t match the received one. Tools like RFC 822 define the proper ordering, and real-world systems must follow it—not assume it’s auto-corrected.

MTAs and middleware inject or reorder headers during delivery

MTAs (Message Transfer Agents) often insert Received headers, authentication records, or perform header sanitization for compliance. These changes happen after signing, meaning the original canonical order is lost. Even if you sign headers in the right order, transit transforms can alter them. This is common with security gateways, ESPs, or enterprise email proxies that modify headers for tracking or filtering. The outcome is a signature mismatch—even if your code is correct. The fix lies in signing headers only after the final header set is known.

Libraries that skip RFC compliance during build

Libraries like NodeMailer or PHPMailer don’t always enforce header sorting before signing DKIM. They may collect headers in the order they’re added—randomly or via application flow—leading to inconsistent output. If headers aren’t sorted before signing, even a small deviation in order (like placing Content-Type before From) invalidates the signature. This isn’t uncommon, especially when developers assume the library handles canonicalization correctly. But it doesn’t. The responsibility is on you to ensure proper sorting or use a library that guarantees it.

How to verify header order before signing

DKIM canonicalization fails when headers aren’t sorted by RFC 822 rules because the signature is based on a deterministic, alphabetically ordered header list. If your headers are out of order, folded, or contain inconsistent line endings, the signature won’t match the recipient’s verification process. Use a tool that applies RFC 822-compliant sorting and line handling before signing—never after.

Verify header sorting and formatting

• Before signing, list all headers in your email payload, including From, To, Date, Subject, and any custom fields like List-Id or DKIM-Signature.
• Sort these headers alphabetically by field name using case-insensitive comparison—from and From should both be treated as from.
• Remove any trailing whitespace from header values. Trailing spaces can alter the canonicalization result, even if they’re invisible.
• Ensure all line endings are CRLF (\r\n) and not LF (\n) or mixed. Many systems expect CRLF, and deviation breaks the canonicalization process.
• Avoid line folding—do not wrap header values across multiple lines with indentation. If the header value is longer than 78 characters, the sender must not fold it. The entire header value must be on a single line.

Use correct signing order and tools

• Apply RFC 822 canonicalization before signing, not after. The signature must be created over the exact canonicalized header list.
• Use a library or tool that implements the RFC 822 header processing rules, particularly the “simple” or “relaxed” canonicalization methods used in DKIM (see RFC 6376, Section 3.4).
• Never rely on email clients or mail servers to "fix" header order during delivery. The canonicalization must be correct at the time of signing.
• Test your DKIM-signed messages with tools like MXToolbox or third-party DKIM checkers that validate both the signature and header canonicalization.
• If you're building a send system, validate your header handling process with inbox placement testing to confirm your messages are delivered and authenticated correctly.

How MailTester’s real-time verification API detects DKIM issues

DKIM canonicalization fails when headers aren’t sorted by RFC 822 order, causing the signature to mismatch the actual message. MailTester’s real-time verification API simulates delivery by parsing the full email envelope and headers, then validates the c=s (header) canonicalization step exactly as specified in RFC 6376 — checking both header order and the signature's integrity. If the headers are out of order or the signature is malformed, it returns a precise failure reason: ‘DKIM validation failed: header order mismatch’ or ‘DKIM validation failed: invalid signature’.

Testing DKIM in a simulated delivery environment

Let’s walk through what happens when you run a check. You send a sample email through MailTester’s API, and it mimics how a receiving server would process it — down to the wire. It doesn’t just spot-check a few fields. It examines the full email structure, including received headers, message-ID, and the order of all header fields. According to RFC 6376, the c=s canonicalization rule requires headers to be sorted in the exact order they appear in the message (not alphabetical). A single misordered header breaks the signature validation. MailTester checks this exhaustively.

Many tools skip this step or only validate the signature's presence. Instead, MailTester goes deeper: it extracts the DKIM signature, applies the header canonicalization rule using the actual message order, and compares it against the signature's expected digest. If there’s a mismatch, it flags the issue with context — not just “DKIM failed,” but why. Was it header order? A misaligned domain? A corrupted signature?

Making failure reasons actionable

When DKIM validation fails, you get a clear verdict, not a black box. For example:

• Header order mismatch: The headers weren’t sorted in the correct order, breaking canonicalization.
• Invalid signature: The signature digest doesn’t match the canonicalized content.
• Domain alignment failure: The signing domain doesn’t align with the From domain, common in forwarded or relayed messages.

You can then fix the root cause: reorder headers, regenerate the signature, or adjust the signing domain. This precision matters for deliverability — DMARC policies rely on successful DKIM verification. If a message fails DKIM, it’s often rejected or quarantined.

For teams using automation, the real-time verification API lets you detect these issues before sending at scale. It integrates with platforms like SendGrid, HubSpot, and Klaviyo to validate emails as they’re added to campaigns. You’re not guessing — you’re seeing what actual mail servers see.

Understanding the mechanics helps avoid failure. The requirement for strict header order is not negotiable — it’s defined in RFC 6376. Even a single header in the wrong position invalidates the signature. MailTester ensures you catch it before the email ever leaves your server.

Why bulk list verification matters for DKIM integrity

DKIM canonicalization fails when headers aren’t sorted per RFC 822’s order, causing signature mismatches even if the email content is correct. If one sender domain in a bulk campaign sends emails with unsorted headers, the DKIM signature won’t validate across thousands of messages, risking DMARC fail rates and inbox placement. You can’t rely on individual checks—only bulk verification catches widespread configuration flaws before you send.

One misconfigured domain can break an entire campaign

DKIM uses header canonicalization to hash the email’s header fields before signing. If those headers aren’t sorted alphabetically as defined in RFC 822, the resulting hash changes—even if the content is identical. A single domain sending with misordered headers can trigger a cascade of DKIM failures across your list.

DMARC enforcement doesn’t care whether one or 10,000 emails fail. If alignment fails across a significant portion of a campaign, receiving mail servers may reject the entire batch or flag your sender reputation as risky. This happens even if the rest of your list is clean and correctly formatted.

Automated bulk verification stops failures before they happen

MailTester’s bulk verification checks sender infrastructure at scale, including DKIM configuration, header ordering, and SPF/DKIM alignment. By catching canonicalization issues early, it prevents DMARC rejection and spam filter drops—before your first email lands in anyone’s trash folder.

Unlike tools that only check individual addresses, MailTester validates the full sending context, including whether your domain’s DKIM signing process is consistent across all messages. A real-time verification API or integration with Mailchimp, HubSpot, or SendGrid lets you catch issues during onboarding or list cleaning, not after delivery.

For example, if your campaign engine auto-appends headers without sorting, MailTester flags it as a risk. That’s not a guess—it’s a check against RFC 822’s specifications, which require header fields to be sorted alphabetically before canonicalization. The internet’s email infrastructure, including major ISPs and anti-spam engines like Spamhaus, enforces this rigorously.

Use MailTester’s bulk verification to find hidden DKIM risks across your entire list. It’s not about checking if an address is valid—it’s about checking if your domain can sign emails correctly at scale.

How DMARC uses DKIM canonicalization to enforce policy

DMARC relies on DKIM’s canonicalization — specifically the c=s (relaxed) or c=r (simple) method — to verify that the email headers were not altered in transit. If the headers aren’t sorted according to RFC 822’s canonical order, DKIM’s signing and verification process will fail, triggering DMARC to enforce its policy (quarantine or reject), even if your content is legitimate.

Why header order breaks DKIM and DMARC

Let's be clear: a single misordered header — like having Received: before Date: — can break c=s canonicalization. DKIM signs headers in a specific order, and verification tools expect that same order. If your email client or ESP rearranges headers (e.g., for debugging, routing, or header compression), DKIM fails. This failure is visible to email receivers through DMARC reports.

When DKIM fails due to canonicalization issues like incorrect header order, DMARC steps in. It evaluates the DMARC alignment between the domain in the From: header and the domain in the DKIM signature. If they don’t match — or if DKIM itself fails — DMARC applies your configured policy: quarantine (move to junk) or reject (block outright).

Reputation impact of a single misordered header

Even one flawed message can hurt your sender reputation. If your email fails DMARC because of a header sorting issue, receiving ISPs may classify you as unreliable. This can lead to increased filtering, reduced inbox placement, and even blocklist placement over time — especially if failures are repetitive.

While some systems use c=r (simple) canonicalization, which is more forgiving of header order, the majority rely on c=s (relaxed), which requires strict adherence to RFC 822 ordering. The difference is critical: relaxed canonicalization allows some header reordering, but only within defined rules. It’s not “random” — it’s still governed by structure.

DMARC’s strength lies in requiring alignment and validating signatures. But this also means that minor misconfigurations — like header sorting errors — can cause complete delivery failure. You can’t assume “it’s just a header.” Every header in the list matters.

For developers and senders, this means testing is essential. You can’t rely on human eyes to spot misordered headers. Automated tools that validate both header structure and DKIM signature alignment are necessary. Tools like MailTester’s email checker can catch these issues before you send, verifying that headers are properly sorted and signed. This avoids reputation damage from preventable technical failures.

For a deeper look at how headers impact deliverability, the original RFC 822 specification and later updates in RFC 5322 define header ordering rules. Understanding those rules helps you debug DKIM failures before they cost you deliverability.

Best practices to prevent DKIM c=s failures

DKIM canonicalization fails when headers aren’t sorted alphabetically by name before signing—this is required by RFC 822. If you skip sorting, even small differences in header order break the signature validation. Always enforce strict alphabetical ordering, use reliable libraries, and re-sign any modified headers to maintain integrity. Tools like MailTester help you test this entire flow end-to-end.

Key technical controls

• Sort all email headers alphabetically by name before signing—this includes standard headers like To, From, and Date, as well as custom ones. Deviation from this rule breaks DKIM signature verification.
• Use well-tested email libraries such as dkim-signer or Mailgun’s library that enforce RFC 822 header ordering by default. Avoid writing custom signing logic.
• Never edit a message body or headers after signing if you expect the DKIM signature to remain valid. If changes are necessary, recompute the signature using the correct c=s canonicalization (simplified) or c=relaxed rules.
• Test your full email delivery path—headers, body, and signing—with real-world tools that validate the entire structure. Many SMTP providers silently alter headers, making your signature fail even if your code is correct.

Proven validation workflows

• Check every outbound message before sending with a tool that evaluates the full DKIM signature path. MailTester’s inbox placement tester simulates real recipient servers and validates not just delivery, but signing integrity and content compliance.
• Use the real-time verification API to validate sender infrastructure during onboarding, especially when integrating with third-party tools or email gateways.
• Review your mailing system logs for dkim=permerror or dkim=fail results. These are direct indicators of canonicalization or signature mismatches in production.
• Ensure all email flows—transactional, marketing, and system alerts—pass through the same signing and validation steps. Inconsistencies in one lane introduce hidden failures.

Final takeaway: header order isn’t optional in DKIM signing

DKIM using the c=s canonicalization method demands strict adherence to RFC 822 header ordering. A single header out of sequence, even with no functional impact, will invalidate the signature.

Trivial issues—like trailing spaces, improper field names, or non-alphabetic header keys—can cause the signature to fail. There is no leniency in the algorithm; correctness isn’t a suggestion, it’s mandatory.

MailTester’s inbox-placement testing identifies these edge cases with 98.9% accuracy. Catching canonicalization errors early preserves sender reputation and ensures deliverability.

Sources

• Roughly one in six legitimate commercial emails (16.5%) never reaches the inbox globally — 6.7% is filtered to spam and 9.8% disappears without a bounce. — Validity 2025 Email Deliverability Benchmark Report (2025)
• Benchmark testing of 15 major email service providers found about 10.5% of legitimate emails land in the spam folder and a further 6.4% go undelivered. — EmailTooltester deliverability benchmark (via WarmForge) (2026)

Keep reading

• Anti-spam laws and compliance: CAN-SPAM, GDPR, CASL (complete guide)
• Dynamic IP and Round-Robin DNS Breaking SPF: A 2026 Fix
• DKIM b= Value Exceeding 4096: MUA/MUA Email Delivery Issue
• Prevent DMARC Failures by Including SPF ALL Mechanism
• SPF all:~all Not Aligned with DMARC Strict Enforcement Errors

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

Frequently asked questions

What does DKIM c=s mean in a signature?

c=s stands for 'canonicalization simple'. It requires headers to be sorted alphabetically and formatted exactly as defined in RFC 822 before hashing.

Can email clients affect DKIM header sorting?

No, email clients don’t sign emails. But if they alter the header order before sending via an MTA, it may impact the signature if not preserved.

Does DKIM c=s require all headers to be included?

Yes. All headers in the 'h=' list must be present and ordered exactly as signed. Missing or reordered headers invalidate the signature.

Why does my email pass DKIM verification in one test but fail in another?

Different servers or tools may perform canonicalization differently. Ensure your header order is stable and follows RFC 822 strictly.

Can I fix a DKIM failure caused by header order?

Yes. Reorder all headers alphabetically before signing, ensure no extra whitespace, and re-sign the message.

Is there a tool to check if my headers are sorted properly?

Yes. MailTester’s real-time API validates full email content, including header order, during inbox-placement tests.

Does DKIM c=s only affect authenticated domains?

Yes. It applies to all domains that use DKIM with the 'simple' canonicalization mode. Misconfiguration affects only that domain’s delivery.

What happens if DKIM fails but SPF and DMARC pass?

DMARC evaluates all three checks. If DKIM fails, it triggers DMARC policy enforcement—usually quarantining or rejecting the email.

Can a header like X-Message-ID cause DKIM failure?

Only if it’s included in the h= list but is not properly ordered. Header sorting affects all headers in the list, regardless of name.

Do all ISPs require DKIM headers to be sorted?

Yes. Major providers like Gmail, Outlook, and Yahoo perform strict canonicalization based on RFC 822 and DKIM standards.

Can MailTester detect DKIM c=s issues during bulk verification?

Yes. MailTester’s bulk verification includes full DKIM signature validation, including header order and canonicalization.

What’s the difference between DKIM c=r and c=s?

c=s is strict—headers must be sorted and formatted exactly. c=r (relaxed) allows minor formatting differences like spacing and line folding.