Why does DKIM canonicalization matter for deliverability?

You’ve signed your emails with DKIM. Keys are in place. SPF and DMARC are configured. But your inbox placement still fluctuates — especially with Gmail and Outlook. Why?

Because DKIM isn’t just about signing. It’s about how that signature is validated. Canonicalization — the process of normalizing your message before signing — determines whether the receiver’s mail server sees your signature as valid. Even a single space difference can break it.

When you compare DKIM canonicalization methods — simple vs relaxed with sha256 — you're not just tweaking a technical detail. You're deciding whether your message passes the final gate. A mismatched canonicalization can turn a valid, well-intentioned email into a bounce, even with no fraud.

Key takeaways

  • Relaxed canonicalization reduces signature failures caused by minor formatting changes, improving deliverability with strict mailbox providers like Gmail and Outlook.
  • Simple canonicalization preserves raw message structure, making it more sensitive to cosmetic changes in headers or body, increasing failure risk.
  • Using sha256 with relaxed canonicalization is the modern standard for better alignment across mail systems and higher authentication success rates.

What exactly is DKIM canonicalization?

DKIM canonicalization normalizes an email’s headers and body before signing, so small formatting changes—like extra spaces or different line breaks—don’t invalidate the signature. It defines which parts are signed, how whitespace is treated, and whether capitalization matters. This ensures the signature remains valid even when the email is slightly modified in transit. You can use either simple or relaxed method, both with SHA256 or other hashing algorithms.

How canonicalization ensures consistent email signing

When you sign an email with DKIM, the signature is based on a specific version of the message. Without canonicalization, two identical emails with different line endings or capitalization could produce different signatures—breaking validity even if the content is the same. Canonicalization strips out these minor differences so the same email always signs the same way. It’s like standardizing the format before hashing, so the digital fingerprint remains reliable.

There are two main canonicalization methods: simple and relaxed. Simple treats all whitespace exactly as it appears, including line breaks and capitalization. Relaxed normalizes line endings to spaces and folds long header lines, ignoring case. Relaxed is more forgiving and commonly used in practice. Both can work with SHA256, the modern standard for hashing, or older algorithms like SHA1.

Simple vs. relaxed: When to use each

Simple canonicalization is strict—no changes to formatting. It’s useful when you control the entire email generation pipeline and need exact match validation. But it’s fragile: a single extra space or capitalized header can invalidate the signature. Relaxed canonicalization is more common and robust, especially for emails sent through systems that reorder headers or add line breaks.

For example, the RFC 6376 (the standard for DKIM) describes relaxed as the preferred method for most real-world use cases. It accounts for common delivery variations. While simple method might be used in tightly controlled internal systems, relaxed is the default in production environments.

When you sign an email, your server applies the chosen canonicalization method before computing the hash. The receiver applies the same method to verify. If the two don’t match, the signature fails. That’s why aligning your setup with how recipients expect to receive and validate emails is essential.

Want to ensure your outbound emails are properly signed and deliverable? Use an email verification tool to catch issues before they hurt your sender reputation. Test individual addresses with our email checker, check bulk lists with our bulk verification, or validate sender setup with our inbox placement feature.

How does simple canonicalization work?

Simple canonicalization treats every character in an email—spaces, line breaks, header order, and capitalization—as part of the signature’s math. Even a single added space or a restructured line breaks the signature, despite identical content. It’s strict, precise, and only practical in environments where message formatting never changes, like automated system emails with fixed templates. For real-world email flows, this rigidity makes it impractical. You can verify email syntax, structure, and deliverability with tools that check how signatures hold up under real-world variations.

The Role of Exactitude in Simple Canonicalization

Simple canonicalization works by using the raw, unmodified content of the email body and headers as input to the cryptographic hash function, usually SHA-256. RFC 6376, the standard defining DKIM, explicitly defines this method as "exact" in its treatment of whitespace and formatting. Every newline, every trailing space, and every capitalization difference matters. A change as minor as turning a single line break into a space modifies the hash value, causing the signature to fail validation, even if the message content is otherwise identical.

Let’s say you send a transactional email with a footer line written as "Sent on 2025-04-05". If your mailer restructures it to "Sent on
2025-04-05" due to a formatting update, the DKIM signature, generated under the "simple" method, will no longer match. This is why simple canonicalization is only viable in controlled systems—like backend-generated invoices or alerts where formatting is static. It’s not scalable for dynamic or user-generated content.

Why Simple Is Rarely the Right Choice

Most modern email systems use relaxed canonicalization because it tolerates common formatting changes during transit. But when you use simple, you’re saying: “This message must be identical, byte-for-byte, to what was signed.” That’s powerful—but brittle. If your email engine reflows text, adds padding, or adjusts indentation during delivery, simple canonicalization fails, even if all the content is correct. This leads to failed validations and poor inbox placement.

For systems that need to verify email formatting integrity or debug signing logic, simple canonicalization can be useful during testing. But for production email delivery, it’s effectively unusable. You’ll catch errors early, but only by sacrificing resilience to minor changes that happen at scale.

Tools that check how your emails behave in real delivery environments—like real-time inbox placement testers—can help you see how signature methods like simple or relaxed affect deliverability. Use inbox placement testing to see how your DKIM setup holds up in real mail clients.

How does relaxed canonicalization work?

Relaxed canonicalization normalizes email headers and body content by ignoring minor formatting differences—like extra whitespace, varying line breaks, or inconsistent capitalization—so the DKIM signature stays valid even after minor changes by email systems. This is especially useful in real-world sending, where intermediaries routinely modify messages. It’s the standard choice for most email campaigns and transactional systems.

What gets ignored or standardized?

Relaxed canonicalization treats all whitespace in headers and body as equivalent: multiple spaces become single spaces, and line breaks are normalized. Header names are treated case-insensitively, so "From:" and "FROM:" match. In the body, non-signature content—like HTML formatting—is stripped down and simplified, meaning small changes to alignment or spacing won’t break the signature.

Let’s say you’re sending a campaign through a service like SendGrid or Mailchimp. The email might be adjusted by a webmail client, cached by a gateway, or rewritten by a content filter. In most cases, relaxed canonicalization ensures the DKIM signature still validates, because it doesn’t require exact formatting.

Why it’s the default choice in practice

Because most email systems don’t preserve original formatting precisely, relaxed canonicalization is the industry standard. It’s defined in RFC 6376, the foundational document for DKIM, and used by nearly every major email provider and sending platform. You can find the full specification at RFC 6376, Section 3.4.

In contrast, simple canonicalization requires identical formatting, which is nearly impossible to maintain across real-world deliveries. If even one space or line break changes, the signature fails. That’s why simple is only used in very controlled environments, like internal systems with strict message generation, or when you have full control over the final delivery path.

For most senders, relaxed is the only practical option. It provides resilience to common transformations without degrading security. Even when using tools like MailTester to verify email lists or test inbox placement, relaxed canonicalization ensures your DKIM setup holds up under real-world conditions. Run your email sender alignment checks through our inbox placement tester to see how your DKIM signature performs across domains and inboxes.

What does SHA256 do in DKIM canonicalization?

SHA256 is the cryptographic hash function used in DKIM to generate a digital signature that verifies message integrity. It ensures that even a single character change—like a space or a capital letter—produces a completely different hash, making tampering obvious. The algorithm doesn’t affect how headers or body are canonicalized; it only secures the final signature output. SHA256 is now mandatory in modern DKIM implementations due to known weaknesses in SHA1.

How SHA256 Secures DKIM Signatures

When you send an email with DKIM, the server applies a hash function to the canonicalized content and headers. This hash is then encrypted using the sender’s private key. SHA256 ensures that the signature is both unique and tamper-proof. If the message is altered in transit—by a relay, spam filter, or malicious actor—the hash won’t match, and the receiving server will reject it.

Because SHA1 has known collision vulnerabilities, it’s no longer considered safe for digital signatures. The IETF formally deprecated SHA1 for this purpose in RFC 7525 and further reinforced it in RFC 8332. Today, SHA256 is the baseline standard. Tools like OpenSMTPD, Postfix, and modern ESPs like SendGrid enforce SHA256 by default.

Canonicalization and Hash Choice Are Separate Concepts

You might think the choice of SHA256 affects how DKIM canonicalizes headers or body, but it doesn’t. Canonicalization—whether simple or relaxed—controls how whitespace, line breaks, or header order are treated before hashing. The hash function just takes the resulting text and turns it into a fixed-size digital fingerprint.

Let’s say you sign an email with relaxed canonicalization. The sender might change the order of headers, but the receiver normalizes them before hashing. Then, SHA256 processes that normalized text. If the signature doesn’t match after this normalization, it’s a failure—not because of the hash, but because the message was altered.

Understanding this separation is key: relax vs. simple only affects the input to the hash, not the hash itself. Even with SHA256, improper header handling or relaxed body canonicalization can still break signature verification. For consistency, most senders use relaxed canonicalization for headers and simple for body, as defined in RFC 6376.

To keep your email verification process spot-on, ensure your sender infrastructure uses SHA256 with proper canonicalization. If you're testing deliverability or checking sender reputation, use tools that validate both signing and alignment. MailTester’s inbox placement tester can help detect if your DKIM setup is failing silently.

When should you use simple vs relaxed canonicalization?

You should use relaxed canonicalization in nearly every real-world scenario. It handles formatting changes from gateways, forwarders, and webmail clients—common in practice. Simple canonicalization only makes sense if you fully control every step of the message path and guarantee no transformation. In reality, relaxed is the right choice for 99% of email senders.

Use relaxed when you can’t control message formatting

  • Relaxed canonicalization normalizes whitespace and line breaks, making your DKIM signature resilient to changes from webmail apps (like Gmail or Outlook) that reformat content.
  • It’s essential when emails pass through third-party gateways, ESPs, or forwarding services—each of which may alter header spacing, line endings, or encoding.
  • Even minor changes in line breaks can break a simple canonicalization signature, causing verification failure and harming sender reputation.
  • According to RFC 6376 (the DKIM standard), relaxed canonicalization is designed specifically to accommodate these inevitable transit variations.
  • Using simple means you’re assuming perfect, unchanging delivery flow—something no real-world system can guarantee.

Use simple only in highly controlled environments

  • Simple canonicalization is only justified if you send every message directly from a single, known server with no intermediaries.
  • Even then, any change in the message body after original generation (like auto-signature insertion or content sanitization) will invalidate the signature.
  • Many modern email platforms and compliance tools apply mild formatting changes by default—these often break simple canonicalization.
  • If you're using a platform like SendGrid, Mailchimp, or AWS SES, you’re already in a relaxed environment. Don’t force simple unless absolutely necessary.
  • There is no measurable delivery advantage to simple; it offers zero benefit in real-world settings and increases failure risk.
DKIM works best when it’s resilient, not rigid. Relaxed canonicalization isn’t a compromise—it’s the standard for reliable email authentication.

For a real-time check on whether an email address will deliver, test your send setup with inbox placement testing—it simulates real-world conditions across major inboxes, including how signatures hold up under transit changes.

What happens if your DKIM signature fails due to canonicalization mismatch?

If your DKIM signature fails because of a canonicalization mismatch, the receiving server sees the message as unverifiable—even if you own the domain and sent the email legitimately. No bounce is returned. The email is silently dropped or marked as spam, reducing inbox placement. Over time, repeated failures hurt your sender reputation, increasing the risk of being blocked entirely, especially by major providers like Gmail or Outlook.

When canonicalization fails, the chain breaks

  • DKIM relies on strict formatting rules during both signing and verification. If the receiving server uses a different canonicalization method (e.g., "relaxed" vs. "simple") than the one used during signing, the signature fails validation.
  • The receiving server won’t reject the email with a bounce. There’s no notification like "Invalid signature." This is a silent delivery failure, making detection hard without proper logging.
  • Even with valid SPF and proper DMARC alignment, a failed DKIM due to canonicalization mismatch can override sender trust. Major providers treat DKIM validation as a core part of authentication checks.
  • Repeated failures on a domain correlate with lower sender reputation scores. For instance, email systems like those from Return Path and Oracle have shown that consistent DKIM failures are among the top red flags for spam classification.
  • Many tools don't catch canonicalization mismatches during pre-send checks. If your sending system applies "relaxed" canonicalization but your provider or receiving server expects "simple," the signature will not verify.

How to prevent silent delivery failure

  • Ensure your email provider, ESP, or SMTP system is configured to use the same canonicalization method (simple or relaxed) across all sending environments.
  • Test your DKIM signature integrity end-to-end using tools that validate both the signing and verification sides. Use a real email test service that checks how a message arrives in real inboxes.
  • When testing, verify that all parts of the message—headers and body—are treated correctly. A single altered whitespace or header order can trigger a mismatch under relaxed canonicalization.
  • Check your email logs and use a third-party inbox placement tester to see if your messages are landing in spam folders or disappearing without trace.
  • Use a tool like MailTester’s inbox placement tool to simulate how your messages appear across major mail providers, helping identify authentication failures that don’t generate bounces.

How can you verify your DKIM canonicalization setup?

Test your DKIM configuration in real-world conditions: send a message through your actual infrastructure, retrieve its full header after delivery, and validate that the canonicalized body and header match your signing settings. Use tools like MailTester’s inbox-placement test to check if receivers accept your signature. Even small changes—like header reordering or whitespace normalization—can break validation if they don’t align with your canonicalization method.

Step-by-step validation process

  1. Send a test message through your production pipeline. Use a real email service (like SendGrid, AWS SES, or Mailchimp) configured with your DKIM settings, not a sandbox. This ensures you’re testing the exact path your users’ emails take.
  2. Extract the complete header from a delivered message. You can find this in your email provider’s delivery logs or by using a tool like MxToolbox to retrieve full headers from a published message. Pay attention to the order and formatting of all headers and the body content.
  3. Check how your headers and body were canonicalized. If you use relaxed canonicalization, verify that the header names are lowercase and values are normalized (e.g., collapsing multiple spaces). For simple canonicalization, ensure the raw order and formatting are preserved exactly as signed. The DKIM spec (RFC 6376) specifies these behaviors in detail.
  4. Validate signature alignment. Use a DKIM debugger (like those at DMARC Analyzer or via MailTester’s inbox-placement test) to check if the signature passes. A failed validation often indicates misalignment between your signing method and the receiver’s canonicalization expectations.
  5. Ensure your infrastructure doesn’t interfere with signing. Many SMTP servers normalize whitespace or reorder headers before sending. If you’re signing before this step, these changes break the signature. Always sign after final header and body formatting is complete.

Common pitfalls to watch for

  • Using a "simplified" signing tool that pre-normalizes content before signing. These bypass your actual setup and give false confidence.
  • Assuming relaxed canonicalization is always safe. It allows flexibility but requires strict compliance with the rules—header names must be lowercase, whitespace normalized, and no added or removed headers.
  • Not validating against actual inbox providers. Some ISPs (like Gmail or Outlook) use their own DKIM validation logic, which may diverge slightly from RFC standards.

Let’s be clear: a passing DKIM test in a simulator doesn’t mean it will pass in the wild. The only way to know is to run a real message through your full delivery path and inspect the result. MailTester’s inbox-placement test lets you do exactly that—send a message, get the full delivered header, and see whether DKIM validation succeeded under real conditions.

How to test DKIM signature alignment using MailTester

You can test DKIM signature alignment by uploading your email’s raw header and body to MailTester’s inbox-placement tool. It checks signature validity, canonicalization method (simple vs relaxed), and receiver alignment—highlighting any mismatches in headers or body content. The report pinpoints issues like incorrect hashing, header omissions, or line-ending discrepancies that break alignment.

Step-by-step verification process

  1. Copy the raw email data—include both the full header and body, as received by your mail server. This includes all MIME parts, encoded lines, and the complete structure of the message.
  2. Go to MailTester’s inbox-placement tool at inbox tester. Paste the raw email into the input field. This tool simulates how major providers like Gmail, Outlook, and Yahoo process inbound mail.
  3. Run the test. MailTester parses the DKIM signature, extracts the canonicalization method (simple or relaxed), and applies the same rules that receivers use during validation.
  4. Review the alignment report. The system checks if the body and header canonicalization methods match the signing method. It flags mismatches—such as signing with relaxed but verifying with simple—common in misconfigured systems.
  5. Identify structural issues. The report shows line-ending problems, folded header lines, or omitted headers that break signature integrity. These are frequent causes of DKIM failures even with correct keys.

Testing relaxed vs simple methods

Use MailTester to compare how your email behaves under different canonicalization rules. You can test multiple messages—some with relaxed, others with simple—then validate consistency across your sending stack. This helps catch misconfigurations before you send to large lists.

For example, RFC 6376 defines the differences: relaxed uses normalized line endings and ignores certain whitespace, while simple preserves exact formatting. Tools like MailTester validate both methods in real-world conditions.

Test all variants in bulk using the bulk verification tool to ensure consistent alignment across your campaigns. This catches alignment issues early, especially when integrating with third-party platforms that may alter headers or body content.

Why relaxing canonicalization is the default in modern email systems

Modern email systems use relaxed canonicalization by default because real-world messages inevitably change during transit—line breaks, whitespace, or formatting tweaks occur naturally. Strict enforcement would reject valid, properly signed emails due to tiny, harmless changes, breaking delivery. The IETF acknowledges this, recommending relaxed methods for broad interoperability across diverse mail environments.

How real messages actually move through the internet

Let’s be honest: no one sends perfectly formatted email from a single source. You might forward a message, and the client adds a leading space or reformats a line. MTA software or webmail interfaces often re-wrap text or normalize spacing. Even legitimate automated messages—like shipping alerts or invoices—can differ slightly in structure between systems.

Relaxed canonicalization accounts for this. It ignores minor differences in whitespace and line breaks when verifying DKIM signatures. That means a message signed with a standard DKIM key can still pass verification even if it arrives with slightly different formatting than when sent. Strict canonicalization would reject such messages. That’s not error handling—it’s a failure to recognize how email actually works.

Why standards bodies and major providers agree

Standards like RFC 6376 (the DKIM specification) explicitly define both 'simple' and 'relaxed' methods for canonicalization. But they don’t treat 'simple' as required. Instead, they acknowledge that relaxed is better suited for the real world. Most modern platforms—including Google, Microsoft, and Yahoo—use relaxed by default for exactly that reason.

You can find this echoed in industry guidance from the IETF, which emphasizes that relaxed methods are the practical choice for interoperability. Without them, a wide range of otherwise valid, signed messages would fail to deliver simply due to formatting changes during transit. This isn’t a flaw—it’s a necessary design compromise.

For teams managing email deliverability, verifying DKIM alignment and canonicalization behavior early is critical. Use tools that test not just if a signature is present, but how it behaves under real-world conditions. MailTester’s inbox placement tests simulate real-world delivery and include DKIM validation, helping you catch alignment issues before sending to real users.

Conclusion: Stick with relaxed canonicalization, and verify with real tools

Simple canonicalization is rarely useful outside controlled testing environments. It breaks easily with minor header changes and is not aligned with how most mail servers process messages in practice.

Relaxed canonicalization with SHA256 is the industry standard for good reason. It tolerates common message modifications while maintaining strong cryptographic integrity across real-world email flows.

Static header checks alone won’t catch issues that appear in live mail delivery. Always test your DKIM setup in actual mail flows—especially with inbox-placement tools that simulate real-world conditions.

MailTester’s inbox-placement testing gives measurable insight into real-world deliverability, revealing whether your DKIM and SPF configurations hold up where it matters: in the inbox.

Sources

Keep reading

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

Frequently asked questions

Does DKIM use SHA256 by default?

SHA256 is required in modern implementations and is the default hash in standard DKIM specifications, though older systems may still use SHA1.

Can I use simple canonicalization for transactional emails?

No. Even minor changes in gateway processing will break the signature. Relaxed is the only practical choice.

What happens if my email body is reformatted before delivery?

If you use simple canonicalization, the signature will fail. Relaxed canonicalization handles this reliably.

How do I know which canonicalization method my provider uses?

Check your email service provider's documentation or test the full message header with tools like MailTester.

Is relaxed canonicalization less secure than simple?

No. It’s more resilient without compromising security. The hash function (SHA256) still ensures integrity.

Can I switch from simple to relaxed after signing?

No. The signing process must match the recipient’s expectation. You must re-sign with the correct method.

Why do some emails fail DKIM even with valid keys?

Because canonicalization rules don’t align. Message alterations during transit break simple signatures.

How often should I test DKIM signatures?

Test every new campaign, domain change, or email engine update. Use inbox-placement tools like MailTester monthly.

What does 'canonicalization mismatch' mean in an email report?

The message body or headers were processed differently than expected during signing, breaking the signature.

Can MailTester detect my DKIM canonicalization method?

Yes. It analyzes the full email structure and header to confirm the method used and whether it aligns with standard expectations.

Why does my email pass SPF but fail DKIM?

SPF checks sender identity; DKIM checks content integrity and signing. A failure at either step breaks authentication.

Do DMARC policies depend on DKIM canonicalization?

Yes. DMARC evaluates whether DKIM and SPF pass. A canonicalization mismatch causes DKIM to fail, triggering DMARC policy actions.