DKIM Canonicalization: Simple vs. Relaxed and Why It Matters for DMARC

You've set up DKIM, published your DNS records, and maybe even started receiving DMARC reports. Good job – you're already ahead of many organizations. But sometimes, despite having a valid DKIM record, you might still see "DKIM fail" or "DKIM unaligned" in your DMARC reports. One of the most common, yet often misunderstood, culprits behind these failures is DKIM canonicalization.

This article will break down DKIM's "simple" and "relaxed" canonicalization algorithms. We'll explore what they mean, how they differ, and why choosing the right one is critical for ensuring your emails pass DMARC alignment, especially in today's complex email ecosystem.

What is DKIM Canonicalization?

At its core, DKIM works by signing specific parts of an email (headers and body) with a private key. The recipient's mail server then uses a public key (found in your DNS record) to verify that signature. If the email content has been altered after it was signed, the signature verification will fail.

The challenge is that email content can be subtly altered in transit by legitimate mail servers, mailing lists, CRMs, or other intermediaries without changing the meaning of the email. Things like:

  • Adding or removing whitespace at the end of lines.
  • Folding long header lines onto multiple lines.
  • Converting different line endings (CRLF vs. LF).
  • Adding or removing empty lines in the body.

If DKIM were to fail every time one of these minor, inconsequential changes occurred, it would be practically unusable. This is where canonicalization comes in. Canonicalization is the process of standardizing the email's headers and body into a predictable, consistent format before the signature is generated (by the sender) and before it's verified (by the receiver).

There are two primary canonicalization algorithms defined in the DKIM specification: "simple" and "relaxed". These apply independently to the header and the body.

DKIM Simple Canonicalization

The "simple" canonicalization algorithm is, as its name suggests, very strict. It aims to prevent any modification to the email content between signing and verification.

Simple Header Canonicalization (h=simple)

When using simple header canonicalization, the signing process expects the headers to remain exactly as they were when signed.

  • Whitespace: Any change to whitespace (including adding or removing spaces, tabs, or line breaks) will invalidate the signature.
  • Case Sensitivity: Header field names (e.g., Subject, From) are converted to lowercase before signing, but their values must remain exact.
  • Folding: Header field values that span multiple lines (folded headers) must remain folded exactly as signed. Unfolding them or refolding them differently will cause a failure.

Pitfalls of Simple Header Canonicalization:

This strictness is its biggest weakness. Many legitimate mail servers, especially those used by mailing lists, CRMs, or anti-spam filters, might:

  • Add a space at the end of a header line.
  • Re-wrap a long header line.
  • Reorder headers (though DKIM specifies which headers are signed, their order can sometimes be an issue if not handled carefully).

Example:

Consider a header signed as: Subject: Your important update

If an intermediate server modifies it to: Subject: Your important update (note the extra space at the end)

...simple header canonicalization will fail the DKIM signature verification.

Simple Body Canonicalization (b=simple)

Simple body canonicalization is equally strict about the email's body content.

  • Trailing Whitespace: Any whitespace at the end of a line is significant. Removing or adding it will invalidate the signature.
  • Empty Lines: All empty lines (lines containing only CRLF) are significant. Removing any empty line, or adding new ones, will cause a failure.
  • CRLF: The body must end with a CRLF. If it doesn't, one is added.

Pitfalls of Simple Body Canonicalization:

Again, this is highly susceptible to breakage by intermediate systems. Mailing lists are notorious for adding footers, removing excessive empty lines, or reformatting text, all of which would break a simple body signature.

When to use Simple?

Almost never, for general email. Simple canonicalization offers a slight theoretical security advantage by being less tolerant of any change, but in practice, it's far too brittle for the real world. Its use is generally limited to highly controlled environments where you have absolute certainty that no intermediary will touch your email content.

DKIM Relaxed Canonicalization

The "relaxed" canonicalization algorithm is designed to be more tolerant of common, legitimate modifications to email content that don't alter its meaning. It's the pragmatic choice for most organizations.

Relaxed Header Canonicalization (h=relaxed)

Relaxed header canonicalization allows for more flexibility without compromising the integrity of the message's core content.

  • Whitespace: All whitespace characters (spaces and tabs) at the beginning or end of header field values are ignored. Sequences of whitespace within a header field value are reduced to a single space.
  • Folding: Folded header lines are "unfolded" into a single logical line before hashing. This means an intermediate server can refold or unfold headers without breaking the signature.
  • Case Sensitivity: Header field names are converted to lowercase before signing, and their values are treated case-insensitively for comparison purposes (though the original case is typically preserved for display).

Example:

Consider a header signed as: Subject: Your important update

If an intermediate server modifies it to: Subject: Your important update (extra space) or Subject: Your important update (extra spaces within) or Subject: Your important update (folded)

...relaxed header canonicalization will still pass the DKIM signature verification because it normalizes these variations before hashing.

Relaxed Body Canonicalization (b=relaxed)

Relaxed body canonicalization is similarly forgiving for the email body.

  • Trailing Whitespace: All whitespace at the end of a line is ignored.
  • Empty Lines: Any sequence of two or more empty lines is collapsed into a single empty line. This means removing extra empty lines or adding them (as long as it's not the only empty line) won't break the signature.
  • CRLF: The body must end with a CRLF. If it doesn't, one is added.

Example:

Consider a body signed as:

Hello,

This is a test.


Regards,
Team

If an intermediate server modifies it to:

Hello,

This is a test.

Regards,
Team

(removed an extra empty line)

...relaxed body canonicalization will still pass the DKIM signature verification.

When to use Relaxed?

Almost always. Relaxed canonicalization is the industry standard and recommended default for both header and body. It strikes the right balance between security and practicality, ensuring your legitimate emails pass DKIM verification even after minor, innocuous modifications by intermediate systems.

Choosing the Right Canonicalization for Your DKIM Record

Your DKIM DNS record specifies the canonicalization algorithms to be used. This is done via the c= tag in your TXT record. The format is c=header_canonicalization/body_canonicalization.

For example: c=relaxed/relaxed (recommended for most) c=simple/simple (rarely used) c=relaxed/simple (possible, but less common) c=simple/relaxed (possible, but less common)

General Recommendation: Use c=relaxed/relaxed. This is what most major email service providers (ESPs) like SendGrid, Mailgun, Mailchimp, and Microsoft 365/Exchange Online Protection (EOP) use by default when they sign emails on your behalf. If you're managing your own email server (e.g., Postfix, Exim), ensure your DKIM signing module is configured to use relaxed canonicalization.

If you encounter DKIM failures, especially when sending emails through third-party services or mailing lists, the first thing to check is your canonicalization settings. If you're using simple, switch to relaxed and retest.

Real-World Impact and DMARC Alignment

Canonicalization failures directly impact your DMARC compliance. DMARC requires DKIM to "align" with your organizational domain. This means the domain in your From: header (the one users see) must match the domain in the d= tag of your DKIM signature. If the DKIM signature itself fails verification due to canonicalization issues, then DKIM alignment fails, and your DMARC policy (p=