DKIM Canonicalization Simple vs Relaxed

Why Does DKIM Canonicalization Matter for Email Deliverability?

You send a perfectly crafted email. It passes SPF. It has a valid DKIM signature. Yet it lands in spam or fails outright. Why?

The answer often hides in a small, overlooked detail: the c= tag in your DKIM signature. It controls how your message’s headers and body are normalized before signing—either strictly (simple) or more flexibly (relaxed). A mismatch here breaks authentication silently, even if everything else looks correct.

DKIM canonicalization defines how receivers reprocess your email’s content. If the sender uses relaxed canonicalization but the receiver expects simple, or vice versa, the signature fails—even with no errors in your setup. This isn’t a minor glitch. It’s a direct path to failed delivery, poor inbox placement, or outright rejection.

Key takeaways

The c= tag in DKIM signing determines how headers and body content are normalized before hashing.
Using "simple" canonicalization can cause failures when any line break or whitespace change occurs during transit.
Relaxed canonicalization is more forgiving and aligns with how most mail servers process headers, making it the default choice for production email.

What is the DKIM c= Tag, and Why Is It Important?

The c= tag in a DKIM signature defines how the email’s headers and body are canonicalized—standardized before hashing—during signing and verification. It controls how whitespace, line breaks, and capitalization are treated. If the signing and verifying servers use different canonicalization modes, the signature fails, even if the email content is identical.

How Canonicalization Affects DKIM Verification

When you sign an email with DKIM, the c= tag tells the receiving server how to reformat the email before checking the signature. The two common values are s=1 (simple) and r=1 (relaxed). Simple mode preserves all formatting exactly, so even a single space or line break change will break verification. Relaxed mode is more forgiving—it normalizes whitespace, ignores some line break variations, and treats header field names case-insensitively.

Most modern email systems use relaxed canonicalization because it better handles the real-world mess of email processing. Gateways, forwarders, and mail clients often tweak formatting without changing content, which would invalidate a simple-canonicalized signature. The DKIM RFC acknowledges this, specifying relaxed as the default and recommended mode for production use.

Why You Should Care When Building or Managing Mailstreams

If you’re sending bulk mail, setting up SPF/DKIM, or debugging bounces, the c= tag isn’t just jargon—it’s a control point. A mismatch between the signing and verifying canonicalization mode is a common reason why a valid DKIM signature fails to verify. This can hurt your sender reputation, even if the message is legitimate.

For example, if your email platform signs with relaxed canonicalization but your receiving server expects simple mode, the verification fails. This may look like a broken signature or a domain policy issue when it’s actually a mismatched c= setting. Using the wrong mode can lead to your messages being flagged as forged or rejected.

Tools like MailTester’s inbox placement testing or bulk email verification can help you catch these issues before they impact deliverability. They simulate real-world validation, including canonicalization checks. You can test individual messages or upload entire lists to see how they fare across major inboxes—before they ever leave your system.

Simple vs Relaxed: The Core Difference in DKIM Canonicalization

DKIM canonicalization determines how email headers and body are normalized before signing and verification. The c= tag defines the method: simple enforces exact matching of whitespace, line breaks, and capitalization, while relaxed ignores these differences by normalizing them — reducing excess spaces, treating line breaks uniformly, and ignoring case. This distinction impacts whether a signed email passes validation when sent through intermediaries.

Simple: Exact Matching, No Tolerance

When you use c=s (simple), every character must match exactly between sender and receiver. Spaces, line endings, and letter case are preserved and compared as-is. If your email client or gateway adds a single extra space or changes a line break format, the signature fails.

This method is strict, which is why it’s less common in production. It only works reliably when both signing and verifying systems treat the message identically — rare in real-world email routing where tools like forwarders, filters, or proxies alter formatting.

Relaxed: Normalization for Real-World Use

With c=r (relaxed), DKIM applies normalization rules. Excess whitespace is collapsed to one space, line breaks are treated the same regardless of format (CRLF, LF, CR), and header field names are case-insensitive. This makes DKIM more resilient to minor alterations during transit.

This is the default for most email providers. RFC 6376 describes relaxed canonicalization as a practical solution for the inconsistencies found in real-world mail flows. It’s not just convenient — it’s necessary for reliable deliverability across complex infrastructure.

Let’s be clear: if your signature uses c=s, and an intermediary rewrites a line break, your email fails DKIM validation. That’s why relaxed is not just common — it’s recommended. According to the IETF RFC 6376, relaxed canonicalization is designed to handle the inevitable transformations in email delivery.

You can validate your DKIM setup at scale using tools that check both signature alignment and canonicalization mode. MailTester’s verification API and inbox-placement tester help identify mismatches in signing configurations before they impact deliverability.

When to Use Simple Canonicalization in DKIM

You should use simple canonicalization in DKIM only if you control both the signing environment and the receiving systems, and can guarantee that the email text remains unchanged from signing to receipt. Any modification—like headers rewritten by a forwarder, a routing agent, or even a simple line break—will break the signature. It’s only safe in tightly managed internal systems where message structure is consistent and unaltered by intermediaries.

Use Cases Where Simple Canonicalization Makes Sense

Internal corporate email systems where messages are never routed through third-party gateways or forwards.
Transactional emails sent via a private SMTP relay with no intermediate processing or modifications.
Automated systems where header formatting and line endings are strictly controlled and duplicated exactly across all hops.
Systems with full end-to-end control over the email flow, including the receiving mailbox’s mail transfer agent (MTA).

Why Simple is Risky Outside Controlled Environments

Simple canonicalization treats every character change as a failure. Even something as minor as a line break reformatting, a header field order shift, or a routing agent adding a Received header can break the signature—unlike relaxed, which tolerates such changes. This means forwarding emails—common in enterprise, customer service, or collaboration tools—will usually fail validation if simple is used.

According to RFC 6376, which defines DKIM, the relaxed canonicalization mode is recommended for most real-world use because it accounts for common email transformations. RFC 6376 explicitly notes that relaxed is more resilient to header reformatting and line length adjustments during transit.

Let’s be clear: if you’re not in a closed system—where every step is monitored and unchanged—using simple canonicalization is a high-risk choice. It can cause sudden delivery failures, especially if users forward emails or if intermediaries modify content.

If you’re unsure whether to use simple or relaxed, audit your email flow. Use tools that test for DKIM signature validation across real inbox environments. MailTester’s inbox placement test checks how your messages are handled by actual providers—showing if DKIM breaks during transit.

For bulk list verification before sending, make sure your domains and signing keys are valid. Verify your list to catch invalid or improperly formatted addresses early.

Keep in mind: if you're using a third-party ESP like SendGrid, Mailchimp, or Klaviyo, they typically apply relaxed canonicalization by default. You can’t control that behavior if you’re not managing the signing environment directly. Use MailTester’s integrations to verify your email setup across platforms.

Simple canonicalization isn’t a misstep—it’s a precision tool for systems where no change is permitted. But if you’re using it anywhere else, you’re betting on perfection. And that rarely lasts.

When to Use Relaxed Canonicalization in DKIM

You should use relaxed canonicalization in DKIM whenever you're sending email publicly—especially through third-party providers like SendGrid, Mailchimp, or when your email passes through gateways. It’s the standard because it handles real-world changes to headers and body content without breaking the signature. Gmail, Outlook, and most major email services expect it. If you send email at scale, relaxed is not just preferred—it’s necessary for consistent deliverability.

When relaxed canonicalization makes sense

When your email passes through email forwarders, filters, or content transformers (like email marketing platforms).
When you're using a third-party sender or email service provider (ESP) that modifies header spacing, line breaks, or encoding.
When sending to recipients who use Gmail, Outlook, Yahoo, or other mainstream inboxes—most of them process signatures only if relaxed is used.
When your list includes addresses from multiple domains, especially those that use shared infrastructure or have inconsistent header formatting.
When you’re unsure whether the receiving server will tolerate strict canonicalization—relaxed is safer and more widely supported.

How it handles real-world changes

Let’s say you send a newsletter using an ESP. The provider adds a tracking pixel, rewraps lines, or converts spaces to tabs. With relaxed canonicalization, the DKIM signature still validates because it ignores minor formatting shifts. Strict canonicalization would fail if a single whitespace character or line break changed—even if the actual content didn’t. This is why relaxed is the norm for public-facing email.

Relaxed works by normalizing whitespace and folding long lines, while still preserving the semantic meaning of headers and body content. It’s designed for practical use, not theoretical purity. The DKIM RFC acknowledges this: relaxed canonicalization is intended for use in message transfers where modifications are common.

If you're managing a large email list, testing deliverability is essential. You can use MailTester’s inbox placement tester to simulate how your DKIM-signed messages land across major inboxes, including how signature validation behaves under real network conditions.

Most ESPs default to relaxed. If you’re configuring your own DKIM signing logic, be explicit about using c=relaxed. It’s the only choice that scales reliably across providers and inbox environments.

How DKIM c= Tag Mismatches Cause Bounce and Spam Issues

If your email signing system uses relaxed canonicalization and the receiving server checks using simple, the DKIM signature hash won’t match—leading to a DKIM fail. This can trigger bounces, spam filtering, or reputation damage, even if the rest of the message is valid. Even one failed header can degrade deliverability, especially with multiple headers involved.

Why the c= tag matters in DKIM validation

DKIM uses the c= tag to define how headers and body are processed before hashing. If you sign with c=relaxed but the verifier uses c=simple, even minor differences in whitespace or header order break the hash. The receiving server sees a mismatch and rejects the signature—even if the email content is correct. This isn’t a rare edge case; it’s a common source of silent delivery failures.

Receivers treat DKIM failures as signal of potential spoofing or misconfiguration. While some will bounce the message outright, others log the failure as a policy violation. Over time, repeated mismatches can lower your sender reputation—even if your domain passes SPF and DMARC. Many ISPs use this data in automated reputation scoring, which affects inbox placement.

How these failures show up in real-world sending

You may never see an explicit bounce, but you’ll observe reduced deliverability—especially in low-touch campaigns or high-volume sends. A RFC 6376 specification makes it clear that the c= tag must match exactly for validation to pass. Mismatches in header canonicalization are a known contributor to email filtering and are often missed during internal checks.

Even partial failures—like one header failing due to c= mismatch—can hurt performance. When multiple headers are signed (common with marketing emails or transactional flows), a single mismatch can cause the entire DKIM check to fail. This is especially critical for large-scale senders using automated tools that don’t enforce consistent canonicalization.

Let’s be clear: DKIM isn’t just a checkbox. A failed signature harms more than just visibility—it affects long-term sender health. You can’t rely on SPF and DMARC alone. If you're sending at scale, validating DKIM configuration across your stack is essential. Use tools that check actual deliverability, not just syntax. Try inbox placement testing with MailTester’s inbox placement tester to catch these issues before they impact your results. Or use the bulk verification tool to clean and validate sender-side data before sending. Always ensure your signing method matches your verifier’s expectations—simple or relaxed, consistently applied.

Real-World Example: Why Your Email Fails DKIM After Being Forwarded

When you send an email with simple canonicalization, a forwarded message from a webmail client can break DKIM checks—because the forward changes line breaks and headers, and simple canonicalization treats every change as invalid. Relaxed canonicalization tolerates such tweaks, so it still passes. The difference lies in how canonicalization handles whitespace and header normalization.

How the Failure Happens: A Step-by-Step Process

You send an email with simple DKIM canonicalization. The signature is computed based on exact byte-level formatting, including line endings and spacing in the body. Any deviation later causes the check to fail.
A user forwards it via Gmail or Outlook. Webmail clients normalize line breaks (convert CR-LF to LF), add a "Forwarded:" header, and may reformat text. These changes are harmless to humans but alter the message body's raw structure.
The receiver applies relaxed canonicalization to the forwarded message. This is the default behavior in most mail servers. Relaxed canonicalization ignores minor whitespace differences and normalizes headers, so the signature passes despite the changes.
Your original simple canonicalization no longer matches. Because the sender's DKIM signature was computed on the original byte stream, even small formatting changes—like a reflowed line—break the cryptographic match. The check fails.
Result: The email gets marked as invalid or rejected. Despite being legitimate, the DKIM signature fails due to formatting mismatch. This often leads to delivery issues, especially in automated or high-volume email systems.

Why This Matters in Practice

Simple canonicalization is more brittle. It assumes the message stays unchanged—rare in real-world handling. Relaxed canonicalization is more forgiving and aligns with how modern email systems actually process messages. According to RFC 6376, relaxed canonicalization is the recommended default for most use cases.

The 5 steps described in “How the Failure Happens: A Step-by-Step Process”, in order.

If you're sending bulk mail or rely on email forwarding in your workflow, simple canonicalization creates unnecessary failure points. Tools like MailTester’s inbox placement test help identify these delivery issues early by simulating real-world conditions and checking whether your DKIM-signed messages survive common client transformations.

When a message is forwarded, the body format changes—canonicalization decides whether those changes are tolerated or fatal.

Many systems now default to relaxed canonicalization. If you're unsure which your domain uses, check your DMARC reports or use a testing tool like MailTester’s API to verify DKIM behavior on real email paths. This avoids surprises when messages are shared or archived.

How to Verify DKIM Canonicalization Settings in Practice

You can verify DKIM canonicalization settings by inspecting the DKIM-Signature header in a real email’s raw source, checking the c= tag for relaxed or simple, then validating the result using a deliverability testing tool like MailTester. This confirms whether your signing setup matches what receivers expect, preventing alignment failures.

Step-by-Step DKIM Canonicalization Check

Retrieve a real email header from a message you’ve sent. Open the message in your email client, find the "Show Original" or "View Source" option, and copy the full raw header. This includes the DKIM-Signature field and all relevant headers.
Locate the c= tag in the DKIM-Signature header. It will read either c=relaxed or c=simple. relaxed is standard for email bodies and allows flexibility with whitespace and line breaks. simple is stricter and used less commonly.
Check your signing process against the receiving server’s interpretation. If you use relaxed but the server expected simple, or vice versa, the signature fails alignment. This mismatch is a common cause of DKIM failures, even with valid keys.
Run the raw message through a deliverability test like MailTester’s inbox placement tester. Upload the full header and body. The tool will replay the message through real email environments and report if DKIM alignment passes, fails, or shows canonicalization mismatches.
Review the result details. MailTester shows which header fields were included, how whitespace was normalized, and how the receiver processed each part. If the c= value diverges from your signing step, it flags the issue clearly.

Why This Matters

DKIM canonicalization is not just a technical detail — it’s a gatekeeper for inbox placement. Even a single trailing space in a header can invalidate a signature if the signing and verifying algorithms don’t agree on how to normalize the content.

As outlined in RFC 6376, the c= tag defines how the message body and headers are processed during signature verification. Misalignment here leads to hard bounces or messages marked as spam. Tools like MailTester help you catch these issues before sending to real users.

Regular verification ensures your emails follow industry-standard practices. The difference between relaxed and simple may seem minor — but it’s decisive in whether receivers accept your mail.

Why MailTester Helps You Catch DKIM Canonicalization Errors

DKIM canonicalization defines how email headers and bodies are normalized before signing. The c= tag specifies whether relaxed (more forgiving) or simple (exact) canonicalization is used. Mistakes here—like mismatched header order or unexpected whitespace—can break DKIM checks even if the signature is technically correct. MailTester’s inbox-placement tests simulate real-world delivery, catching these flaws before they cause bounces or spam filters.

Authentication That’s Tested, Not Assumed

When you send an email, receivers don’t just check if the address exists—they validate full authentication. SPF, DKIM, and DMARC must align. A common oversight? A DKIM signature that passes basic validation but fails due to relaxed vs. simple canonicalization mismatches. MailTester’s inbox-placement testing goes beyond address validity. It runs real SMTP transactions, verifying that DKIM signatures are not only present but correctly signed under the intended canonicalization rules.

Real-Time Feedback on Hidden Risks

Our 98.9% accuracy isn’t just about catching invalid or disposable addresses. It extends to subtle misconfigurations in authentication layers. For example, a header field with extra spaces or a body line ending with a carriage return can cause a relaxed canonicalization process to fail if the sender uses simple mode. MailTester detects these edge cases during verification, flagging them in detailed reports. You get specific feedback—not just "invalid" or "catch-all," but actionable insights like "DKIM canonicalization mismatch detected: simple mode expected, relaxed used."

Let’s say you’re sending a campaign through Mailchimp. Before sending, run your list through our bulk verification tool. It checks each address and tests its authentication chain. Want to integrate this into your workflow? The real-time API checks every new subscriber instantly, with full DKIM canonicalization validation baked in.

For full inbox placement confidence, use our inbox placement test. It simulates real inboxes across major providers. Even if your DKIM signature is mathematically correct, inconsistent canonicalization can cause delivery failures. The RFC 6376 specification (which defines DKIM) outlines these rules clearly — but implementation errors are common. Understanding the standard is step one; validating it in practice is where tools like MailTester add measurable value.

Authentication isn’t just about compliance. It’s about trust. And trust starts with a signature that holds up under real-world conditions, not theory. With MailTester, you get the clarity to fix issues before they hurt your sender reputation.

Common Mistakes with DKIM Canonicalization You Should Avoid

Using simple canonicalization (c=s) is not safer—it’s fragile. It breaks on minor header or body changes, like whitespace or line breaks. Even small modifications in templates or routing can invalidate DKIM signatures. Always use relaxed canonicalization (c=r) for production email delivery, especially when using third-party tools or cloud gateways. Test DKIM after every change to your email workflow.

Why Simple Canonicalization Fails in Practice

Simple canonicalization checks every character exactly. A single extra space or line break in your email body will invalidate the signature.
Many email clients and third-party platforms (like SendGrid, Mailchimp, or AWS SES) automatically alter message formatting. These changes break simple canonicalization, even if your content looks unchanged.
Using c=s with cloud email gateways is a guaranteed path to failure. It’s not a security feature—it’s a usability trap.
DKIM relaxed canonicalization (c=r) is designed to tolerate minor formatting differences. It’s the industry standard for good reason—see RFC 6376, Section 3.5.
Don’t assume your email tools handle canonicalization correctly. Even if they claim to, verify results using public tools like MXToolbox or DMARC Analyzer.

How to Avoid Common DKIM Oversight

Always test DKIM after changing a template, dynamic content block, or routing rule. One small edit can break signing.
Use your email verification service to catch invalid or weak DKIM signatures early. MailTester’s bulk verification detects malformed DKIM when scanning lists.
Check that your email infrastructure applies relaxed canonicalization consistently. Some systems default to simple, which causes silent failures.
Don’t rely on sender reputation alone. A high reputation won’t fix a broken DKIM signature.
Use the MailTester API to integrate DKIM validation into your build or send pipeline for real-time feedback.
Review DKIM results in post-delivery reports. If inbox placement drops, check DKIM validity before blaming content or sender reputation.

DKIM is not a failsafe. It’s a cryptographic checksum. If the message changes, the signature fails—no matter how trusted the sender.

Summary: Always Use Relaxed Canonicalization for Public Email

Relaxed canonicalization is the industry standard for DKIM signing. It tolerates minor changes in formatting, such as whitespace or line breaks, that commonly occur during email transit across different providers.

Why relaxed works better in practice

It ensures the signature remains valid after email clients or intermediaries modify message structure.
It’s supported by all major email services and widely adopted in production environments.
Simple canonicalization fails unpredictably when messages are reformatted, leading to authentication failures.

Simple should only be used in tightly controlled, internal environments where message formatting is guaranteed to remain unchanged. For public email, relaxed is the only reliable choice.

Use tools like MailTester to test your DKIM-signed messages and verify that canonicalization is applied correctly. Catching mismatches early prevents deliverability issues before they impact your sender reputation.

Sources

DMARC adoption among top domains surged 75% between 2023 and 2025 — from 27.2% to 47.7% — in the wake of Google and Yahoo's bulk-sender authentication requirements. — EasyDMARC 2025 DMARC Adoption Report (2025)
Since May 5, 2025, Microsoft Outlook requires SPF, DKIM, and DMARC from domains sending 5,000+ emails per day, rejecting non-compliant mail outright at the SMTP level with error 550 5.7.515. — Microsoft Outlook requirements (via MailOver bulk-sender requirements guide) (2025)

Keep reading

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

Frequently asked questions

What does DKIM c=relaxed mean?

It means the email was signed using relaxed canonicalization, which normalizes whitespace and capitalization during signing and verification.

Can DKIM fail if c= tags differ between sender and receiver?

Yes. If the signer uses relaxed and the verifier expects simple—or vice versa—the signature hashes won't match, causing DKIM failure.

Is it safe to use DKIM c=simple?

Only in controlled environments where no processing or forwarding occurs. It breaks easily under normal email delivery conditions.

How do I check if my email uses c=relaxed or c=simple?

Look at the DKIM-Signature header in the email’s raw source. The c= tag will say relaxed or simple.

Which canonicalization method is most widely supported?

Relaxed is the standard and is supported by every major email provider, including Gmail, Outlook, and Yahoo.

Can I fix a DKIM fail caused by canonicalization?

Yes. Correct the signature to use the same c= tag as the receiving system. Most providers expect relaxed.

Why does my email fail DKIM after being routed through a service like SendGrid?

SendGrid uses relaxed canonicalization by default. If your signing system uses simple, the mismatch breaks verification.

What happens if DKIM fails?

The email may be blocked, marked as spam, or have reduced sender reputation. It impacts inbox placement.

Does MailTester check DKIM canonicalization?

Yes. Our inbox-placement tests verify full DKIM authentication, including correct c= tag usage and signature integrity.

Can I test many emails for DKIM compliance at once?

Yes. MailTester’s bulk verification and real-time API allow you to test large volumes with detailed deliverability feedback.

What’s the default DKIM canonicalization in MailTester?

MailTester does not sign messages. It tests existing emails and provides feedback on DKIM alignment and canonicalization accuracy.

Is DKIM c= tag used in SPF or DMARC?

No. The c= tag is specific to DKIM. SPF and DMARC do not use canonicalization tags in the same way.