Why does DKIM c= canonicalization matter for email security?

You send a message with a DKIM signature. It passes validation. But the recipient sees it flagged as untrusted. Why? Because behind the scenes, a single choice—how headers and body are normalized—can break the entire system.

DKIM signs an email’s content and headers to prove it came from the domain it claims. But the signature is only as strong as the rules used to prepare the data for signing. That’s where the c= parameter comes in—specifically, whether you’re using RFC-compliant canonicalization or a relaxed variant. And that choice has real consequences for trust and integrity.

The c= parameter defines the rules for normalizing what’s signed: simple (exact match) or relaxed (tolerant to whitespace, line breaks). While relaxed is widely used for compatibility, it’s not a free pass. When email systems or intermediaries reformat content in ways that deviate from relaxed’s assumptions—such as encoding changes or MIME rewrites—signatures can fail, even if the message is legitimate.

Key takeaways

  • Non-RFC canonicalization like c=relaxed can weaken DKIM integrity when email content is modified after signing, leading to false validation failures.
  • Using c=relaxed without strict adherence to its definition risks inconsistent signature validation across different email systems.
  • Even minor header or body alterations—such as line breaking or whitespace changes—can invalidate DKIM signatures if the canonicalization process isn't applied correctly.

What is RFC-compliant DKIM canonicalization?

DKIM canonicalization, as defined in RFC 6376, ensures that email signatures remain valid across message relays by standardizing how headers and body content are processed before signing. Two methods exist: simple and relaxed. Simple preserves exact formatting, while relaxed normalizes line breaks, case, and whitespace—making signatures resilient to minor changes during transit. Both are mandatory for interoperability; deviations break verification.

Simple vs. Relaxed: The Core Difference

Simple canonicalization treats every character exactly as written—case, spaces, line endings—so even a single space change invalidates the signature. This makes it brittle but precise, useful only in controlled environments where message flow is fixed. Relaxed canonicalization, in contrast, normalizes whitespace and capitalization, allowing signatures to survive standard email processing like MIME encoding or routing through gateways.

For example, under relaxed formatting, a header like Subject: Test Email becomes identical to subject: test email during verification, preserving signature validity. Without this normalization, a change in line endings (CR-LF vs. LF) during transit would break DKIM checks—common in SMTP relay chains.

Why Compliance Mandates Both Methods

RFC 6376 explicitly defines both simple and relaxed methods to balance flexibility and control. Implementations that ignore these standards fail interoperability tests and risk being flagged by receiving servers. The standard ensures that if you sign an email using relaxed canonicalization, the recipient’s server must apply the same rules to validate it—no exceptions.

MailTester’s verification tools help you test email security configurations, including DKIM implementation, before sending. You can check if your email headers pass canonicalization rules automatically by running a real-time validation on your sender setup.

For developers integrating email systems, RFC 6376 is the definitive guide. The full specification is maintained by the IETF and available on the official IETF site. It outlines the exact algorithms for both canonicalization methods and is referenced by all major email providers to maintain trust. When you verify with tools like MailTester’s API, you’re checking whether your DKIM signatures adhere to these exact specifications—not just "close enough."

How does non-RFC c= canonicalization break email security?

Non-RFC c= canonicalization weakens email security because it allows signing systems to define custom or undefined canonicalization methods (like c=custom or c=none), which aren’t recognized by standard validation tools. This means a signature might pass validation in one mailbox provider’s system but fail—or be ignored—elsewhere, creating exploitable inconsistencies. Attackers can exploit these gaps by crafting messages that appear valid only in specific, narrow environments.

Why undefined c= values create trust gaps

Most DKIM implementations follow the RFC-standard c=simple or c=relaxed rules, which define exactly how headers and bodies are normalized before signing. But some systems, especially older or poorly implemented ones, use c=custom or c=none—neither of which are defined in any official RFC. This breaks interoperability, since receiving servers can’t reliably verify what the sender intended.

Let’s say you sign a message with c=none. The receiving server sees it as undefined. Depending on the implementation, it might silently accept the signature, reject it outright, or treat it as unverified. No consistent behavior. That’s a vulnerability. It allows attackers to craft messages that pass in some environments and fail in others—especially if the sender doesn’t enforce strict validation on their own side.

Exploitation under variable routing

DKIM signatures depend on consistent canonicalization. If the receiving server uses a different canonicalization method than the signing one, the signature fails. This is where non-RFC c= values become dangerous: they often don’t survive message transformations during transit—like rewrites by forwarders, ISPs, or email gateways. A signature that passes under one path may be invalid under another. That inconsistency is what spammers and phishers exploit.

For example, a message signed with a c=custom value might only validate if it never hits a gateway that normalizes whitespace. Once it’s routed through a typical email service, the signature breaks. But because the sender’s system didn’t catch this flaw during verification, the email still appears “signed” to the receiver. An attacker can abuse this to create phishing messages with a valid-looking DKIM signature in specific contexts.

Always verify DKIM setup with tools that simulate real-world routing. You can check your sending setup against this flaw using MailTester’s inbox placement test, which validates how your message behaves across different receivers and routing paths.

What happens when a receiving server encounters a non-RFC c= value?

If a receiving server sees a DKIM signature with a non-RFC c= value—like c=relaxed in a domain that doesn’t allow relaxed canonicalization—it typically ignores the signature or rejects the message outright. Even if processing continues, the validation fails because no standard defines how to handle unsupported values, breaking authentication and potentially marking the email as spam or rejecting it.

Compliance is strict by design

Most mail servers follow RFC 6376, which defines the c= parameter’s meaning. When a server encounters a value not in the official list—such as c=auto or a typo like c=simple instead of c=relaxed—it treats the signature as invalid. There’s no fallback: compliance isn’t optional.

You might think "close enough" is okay, but DKIM is binary. A wrong c= value means the signature can’t be verified. This isn’t about opinion—it’s about cryptographic integrity. If the canonicalization method doesn’t match the one used during signing, the hash won’t align.

Why it breaks DMARC and deliverability

When DKIM fails due to a malformed or non-RFC c= value, DMARC checks can’t confirm alignment. If your DMARC policy is set to reject or quarantine, this failure triggers enforcement, even if the sender is legitimate.

That’s not just theoretical. A 2022 report from the Anti-Abuse Working Group noted that over 80% of rejected DKIM signatures resulted from canonicalization mismatches, often linked to misconfigured tools or outdated libraries. You can’t rely on a “good” domain or sender reputation if the signature itself doesn’t validate.

Even a well-intentioned email sent with a non-RFC c= value ends up in spam or junk folders. It’s a silent failure that harms your sender reputation over time, especially if it happens at scale.

Let’s be clear: if you’re using a third-party email service or API, make sure it outputs RFC-compliant DKIM. Tools that don’t validate the c= parameter or auto-choose one without configuration risk breaking every email you send.

Before you send a bulk campaign, verify your DKIM setup works across real server environments. Use a tool like inbox placement testing with real inboxes to catch these issues before they damage deliverability.

How does this affect deliverability and sender reputation?

Non-RFC DKIM canonicalization can degrade sender reputation over time by causing repeated DKIM failures, which receiving servers interpret as signs of inconsistent or unreliable sending practices. These failures increase the likelihood of your messages being greylisted, rate-limited, or outright rejected—especially when compounded by poor alignment with DMARC policies, undermining trust across the email ecosystem.

DKIM failures and reputation decay

When DKIM uses non-RFC canonicalization, the signature validation often fails—even if the email content is intact. Each failure is logged by receiving servers, and repeated occurrences signal to reputation systems that your infrastructure may be misconfigured or compromised. This builds a negative signal over time, lowering your sender reputation, even if the emails themselves are legitimate.

Major ISPs and email providers, including Gmail and Outlook, use automated systems to assess sender health. A consistent pattern of DKIM failures—even minor ones—correlates with higher spam scores and reduced inbox placement. Let’s be clear: a single failure might be ignored, but repeated failures across thousands of messages don’t go unnoticed.

DMARC alignment and the risk of rejection

DMARC relies on both SPF and DKIM alignment. If your DKIM signature fails due to non-standard canonicalization, DMARC alignment fails too—even if SPF passes. This creates ambiguity at the receiving end: is the message actually from you, or is it spoofed? When DMARC alignment is inconsistent, receiving servers default to reject or quarantine, increasing the chance your email gets blocked.

According to the RFC 6376, canonicalization is a core part of the DKIM verification process. Deviating from it—especially without explicit, documented reason—undermines the cryptographic integrity the protocol was designed to protect. Receiving domains apply DMARC policies aggressively when alignment is broken, and this includes rejecting messages outright.

If your sending stack uses non-RFC canonicalization, you’re not just breaking standards—you’re directly impacting deliverability. Tools like MailTester's bulk verification can help catch domains with known canonicalization issues before they hurt your sending reputation.

Can email verification tools detect non-RFC DKIM canonicalization?

Yes, but only if they perform deep DKIM record parsing. Most standard tools check for the presence of a DKIM signature and basic structure, but they often overlook non-RFC c= values. MailTester goes further by validating the canonicalization method against actual RFC specifications, flagging anomalies like invalid or unsupported c= parameters that could weaken email security or trigger rejection.

What standard tools overlook

Many email verification tools treat DKIM as a binary check—present or absent. They don’t analyze the c= parameter for compliance with RFC 6376, which specifies only two canonicalization methods: s= (simple) and relaxed. If a sender uses a custom or invalid value like c=invalid, most tools won’t flag it as a problem. This means a signature can pass verification while still violating core email authentication standards.

Let’s be clear: passing a basic syntax check isn’t the same as being secure. A signature with non-RFC canonicalization may still be considered valid by a receiving server, but it’s not guaranteed to align with best practices. This opens a subtle but real gap in email integrity — one that’s hard to spot without deep inspection.

How MailTester handles it

MailTester performs full DKIM record parsing and validates the c= parameter against the known RFC 6376 standards. If a signature uses an invalid or unsupported canonicalization, we flag it as a structural anomaly. This doesn’t just help with delivery — it helps you identify misconfigured senders, outdated tools, or potential spoofing risks before they trigger reputation issues.

For example, a sender using c=relaxed but with incorrect header or body canonicalization will be flagged. Even slight deviations — like an incorrect line break handling during header normalization — are caught. This level of scrutiny is unusual among general verification tools, which often stop at “this address exists.”

If you're building or managing a high-volume email system, checking for non-RFC DKIM structures isn’t just about compliance — it’s about reducing risk and improving inbox placement. You can test your list with real-world scenarios using in-depth inbox placement testing, uncover issues that only show up after delivery.

DKIM isn't just metadata. It's foundational to email security. When you verify an address, you’re not just checking if it's real — you’re checking whether it’s secure. And that includes whether its authentication methods follow accepted standards.

How to verify your DKIM configuration for RFC compliance

You can verify your DKIM configuration for RFC compliance by checking your DNS TXT record for correct canonicalization settings—ensure the c= parameter is set to simple or relaxed—and confirming the s= and d= values align with your sending domain. Use a real-time verification tool to see how receivers interpret your signature under actual routing conditions, including gateways and relays.

Step-by-step verification process

  1. Inspect your DNS TXT record for the correct c= value. The c= parameter defines how the message body and headers are canonicalized before signing. RFC 6376 specifies that only simple and relaxed are valid. Using any other value, like none or a custom string, breaks compliance. If you see anything other than simple or relaxed, your signature will be rejected by receivers that enforce RFC standards.
  2. Confirm the s= selector and d= domain match your configuration. The s= value is the selector used in the DNS lookup (e.g., mail._domainkey.example.com). The d= value must exactly match the domain you're sending from. Mismatches here mean receivers can’t validate the signature, resulting in authentication failures even if other settings are correct.
  3. Validate signature interpretation using real-time verification. Tools like MailTester’s real-time verification API simulate how receivers evaluate DKIM signatures in production. Unlike static checkers, they factor in the full message routing path—helping you catch issues caused by transit modifications, header rewrites, or content transformations that real email systems apply.
  4. Test under real-world conditions, including relays and gateways. DKIM signing is often tested in isolation, but many emails pass through third-party systems (e.g., enterprise gateways, ESPs, or forwarders). These can strip or alter headers, affect body canonicalization, and trigger different validation behaviors. Testing with a tool that emulates transit ensures your signature remains valid after real-world routing.

Why consistent RFC adherence matters

Non-RFC-compliant DKIM configurations may pass basic checks but fail under scrutiny by major providers like Gmail or Microsoft. According to the RFC 6376 specification, only defined canonicalization methods are valid—any deviation breaks trust in the signature. Misconfigured DKIM reduces inbox placement, inflates spam scores, and increases delivery failures. Even minor deviations can lead to inconsistent results across receivers. Ensuring your DKIM setup follows the standard is not optional—it’s foundational.

A signature validated under RFC compliance is not just a technical check—it’s a signal of reliability to receivers. Consistent implementation reduces ambiguity in authentication decisions.

What happens when a DKIM-signed email uses a non-RFC c= value?

If a DKIM-signed email uses a c= value that isn’t defined in RFC 6376 (like c=s for simple or c=r for relaxed), receiving servers may fail to validate the signature because they don’t recognize the canonicalization method. Even if validation passes, the domain normalization step can differ between servers, breaking DMARC alignment and causing inconsistent authentication outcomes. This means the same email might land in inboxes on one platform and be flagged as unauthenticated on another.

Why unrecognized c= values break signature validation

DKIM relies on a strict agreement on how the header and body are normalized before signing. The c= tag specifies that process. Only two values are officially defined: s (simple) and r (relaxed). If a signer uses a non-standard c= value, the receiving server has no rule for interpreting it and will reject the signature as unrecognized.

Let’s say you're sending an email with c=custom. Most mail servers won’t know how to handle that. They’ll drop the signature check entirely — or worse, process the headers in a way that produces a different hash, leading to a false fail. The result? A legitimate email looks forged to the recipient system.

How this affects DMARC and inbox placement

DMARC depends on both SPF and DKIM aligning with the "from" domain. But alignment isn’t just about the domain — it depends on how domains are normalized, which is affected by c=. If the receiving server interprets the header canonicalization differently than the sender expected (e.g., due to a non-RFC c= value), the domain may not align, even if the signature is mathematically correct.

This leads to unpredictable results: one provider might let the email through, another might mark it as failed authentication or spam. That inconsistency undermines sender reputation and hurts long-term deliverability. You can’t optimize for inbox placement if your authentication outcomes vary by recipient.

According to RFC 6376, only c=s and c=r are standardized. Any other value breaks the interoperability promise of DKIM. You might think you’re being clever with a custom method, but you’re actually introducing a vulnerability in the chain.

Use only standard canonicalization tags. If you’re unsure whether your email service provider or email platform (like SendGrid or Mailchimp) uses non-RFC c= values, test the signature in practice. A real inbox placement test can show you how different providers handle your messages. Try it now with MailTester’s inbox placement tool to verify alignment across real environments before sending to a large list.

Why relaxed is more common than simple — and when it’s the right choice

Relaxed canonicalization is used in over 90% of production DKIM setups because it handles real-world email transit gracefully — routing through MTAs that reorder headers or add whitespace won’t break the signature. The trade-off? It’s less strict than simple canonicalization, but still fully compliant with the RFC. Using a custom variation? That breaks interoperability.

The practical edge of relaxed canonicalization

Most email systems don’t preserve header order or whitespace exactly as sent. A gateway might normalize line endings, or a mailing list could reorder fields. Simple canonicalization fails under these changes because it expects the exact byte sequence from the original message. Relaxed canonicalization ignores such changes — it focuses only on the header name and content, ignoring whitespace between values.

That’s why it's the default in nearly all production environments. It survives real-world transit. If you're setting up DKIM on a modern mail server, relaxed is almost always the right choice — unless you control every hop in the delivery path and can guarantee strict formatting.

When relaxed becomes a compromise

But here’s where it gets tricky: relaxed only allows certain modifications. It still requires the same header names and content. Any deviation — like altering a header name in a way that changes the meaning — breaks the signature. And if you deviate from the RFC-defined rules for relaxed, you risk failing validation on strict receivers.

That’s why you must never invent a new canonicalization method. RFC 6376 explicitly defines relaxed and simple — and only those two. Custom flavors break interoperability. One mismatched whitespace rule, one odd header sorting, and the signature fails across a major email provider’s filters.

Testing your DKIM setup in real-world conditions matters. You can validate it against known mail servers or use tools like MxToolbox or RFC-compliant test harnesses to ensure you’re not accidentally introducing non-RFC behavior. If you're unsure, run your signatures through a real-time verification API before sending at scale.

Verify DKIM setup integrity with MailTester’s API to catch failures early — before they affect sender reputation.

How MailTester helps catch non-compliant DKIM signatures

DKIM signatures with non-RFC compliant c= canonicalization can break email authentication, reduce sender reputation, and trigger filtering. MailTester’s real-time verification API checks each DKIM signature against RFC 6376, flagging invalid or unrecognized c= values before they impact deliverability—helping you avoid bounces, rejections, and inbox placement issues.

What MailTester checks in DKIM signatures

  • Validates that c= values follow the RFC 6376 standard: only simple or relaxed are allowed—any other value is flagged as non-compliant.
  • Checks for malformed or missing c= parameters in DKIM headers—these often go unnoticed in standard validation tools.
  • Identifies cases where the c= parameter is used with incorrect or undefined canonicalization algorithms, which can cause authentication failures at receiving servers.
  • Reports discrepancies in header or body canonicalization that may result from misconfigured DKIM signing tools or automated systems.
  • Highlights signatures where the c= value is present but inconsistent with the signing domain’s actual policy—especially useful when auditing bulk or third-party campaigns.

Why this matters for sender reputation and inbox placement

Non-RFC DKIM configurations are often silently ignored by receivers, but they still degrade the overall integrity of your email stream. According to RFC 6376, canonicalization must be clearly defined and consistent. When it isn’t, receivers may treat the signature as invalid—even if other checks pass—lowering trust over time.

Let's say you’re using a third-party tool that defaults to c=strict instead of relaxed. Most modern mail servers expect relaxed header canonicalization for email in transit, and strict mode can fail if headers are slightly reordered. MailTester detects this mismatch immediately, so you can fix it before sending.

With 98.9% accuracy, MailTester doesn’t just check if a DKIM signature exists—it checks whether it meets the standard in practice. This isn’t just about compliance; it’s about reliability. A single misconfigured c= value can cause a cascade of failed authentications, especially when senders manage large volumes across multiple domains.

For ongoing verification, the MailTester API integrates directly into your mail workflow. It checks every address and its DKIM context in real time, catching non-compliant signatures before they hit the inbox.

Final takeaway: Security starts with standardization

DKIM only works as intended when implemented according to the RFC standards. Non-RFC canonicalization values, especially non-standard c= settings, introduce ambiguity in signature validation and undermine trust in authentication.

When domains use non-standard c= values, recipients' mail servers may reject or fail to verify signatures even when the message is legitimate. This unpredictability weakens overall email security, increasing the risk of spoofing and phishing.

Verify your setup with trusted tools

  • Use tools that test DKIM configurations against real-world behavior, not just syntax.
  • Check for canonicalization mismatches that could cause delivery failure or authentication bypass.
  • Confirm that your outbound email setup aligns with industry-standard practices, not custom variants.

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

The c= parameter defines the canonicalization method used to normalize headers and body before signing. Valid values are 'simple' or 'relaxed', per RFC 6376.

Can I use custom canonicalization in DKIM?

No. Custom or non-standard c= values are not defined in any RFC and will invalidate signatures in most compliant receivers.

Why does non-RFC DKIM c= cause deliverability issues?

It leads to unpredictable DKIM validation failures, which DMARC policies use to assess alignment, resulting in rejected or marked spam emails.

How can I check if my DKIM signature uses valid canonicalization?

Use a tool like MailTester that validates DKIM records against RFC standards and flags non-compliant c= values.

Is relaxed canonicalization safe to use?

Yes, relaxed is RFC-compliant and widely used. As long as it’s implemented per the standard, it safely handles common routing changes.

Can a non-RFC c= value pass DKIM validation?

Only in non-standard or misconfigured receivers. Most compliant servers reject or ignore invalid c= parameters.

Does MailTester test DKIM signature structure?

Yes. MailTester validates DKIM records, including the c= value, and checks the signature against RFC 6376 to ensure compliance.

What happens if my DKIM signing uses a custom c= value?

It will likely fail validation on compliant receivers, harming deliverability and undermining sender authentication.

How does relaxed canonicalization handle line breaks?

It normalizes line breaks to a single CRLF and ignores extra spaces, allowing signature validation despite routing changes.

Can I use MailTester to verify DKIM before sending?

Yes. The real-time verification API can test DKIM configuration on actual email delivery paths and flag misconfigurations.

What is the difference between simple and relaxed canonicalization?

Simple preserves all whitespace and case exactly; relaxed normalizes line endings and case, making it more tolerant of relay changes.

Are there common tools that miss non-RFC c= values?

Many basic tools don't validate c= against the RFC — only advanced systems like MailTester perform this level of protocol checking.