DKIM Relaxed vs Simple Canonicalization (c= Tag Guide)

DKIM canonicalization is the setting most people never touch — and the one that silently decides whether your signatures survive the trip from your sending server to the recipient's inbox. If you've ever seen DKIM fail on forwarded mail with a "body hash did not verify" error, canonicalization was almost certainly the cause.

The c= tag in your DKIM signature controls it. It chooses between two algorithms: relaxed and simple. The names are misleading — simple is the strict one, and relaxed is the forgiving one. Getting this backwards costs you deliverability.

Here's what each does, why it matters, and which one to use.

What the c= Tag Actually Controls

When your mail server signs an email with DKIM, it doesn't hash the raw message bytes directly. First it runs the message through a canonicalization algorithm — a normalization step that prepares the message for hashing. The receiving server runs the same algorithm before verifying, so both sides need to land on the same canonical form even if the bytes changed slightly in transit.

The c= tag in the DKIM-Signature header declares which algorithm was used. It specifies two values separated by a slash — header first, body second:

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
    c=relaxed/relaxed; t=1234567890; bh=...; b=...

The four combinations are:

c=relaxed/relaxed    (relaxed header, relaxed body)
c=simple/simple      (strict header, strict body)
c=relaxed/simple     (relaxed header, strict body)
c=simple/relaxed     (strict header, relaxed body)

If only one value is given — c=relaxed — it applies to the header and simple is used for the body by default (per RFC 6376, Section 3.4).

If the c= tag is omitted entirely, the default is simple/simple — the strictest option. That's the RFC default, and it's the wrong choice for most senders.

Simple Canonicalization: Strict and Fragile

Simple is the conservative algorithm. It tolerates almost no modification.

Simple header canonicalization does not change the headers at all. The header field names, values, whitespace, line folding, and case must all arrive byte-for-byte identical to how they were signed. The only thing simple headers permit is nothing — the bytes must match.

Simple body canonicalization does exactly one thing: it removes empty lines at the very end of the body and ensures the body ends with a single CRLF. Everything else — every space, every tab, every line-wrap change, every modification to a line in the middle of the body — must match precisely.

With c=simple/simple, the only modification a relay can safely make is adding or stripping blank lines at the bottom of the message. Anything else breaks the signature.

Relaxed Canonicalization: Tolerant and Practical

Relaxed anticipates the common, meaning-preserving changes that mail infrastructure makes and normalizes them before hashing, so both sides produce the same hash even if the wire bytes differ.

Relaxed header canonicalization applies these rules to each signed header:

1. Convert the header field name (before the colon) to lowercase. Subject and SUBJECT both become subject.
2. Unfold the header so the whole value is on one logical line (remove the CRLF that line-folding inserted).
3. Convert any sequence of whitespace (spaces and tabs) within the value to a single space.
4. Remove all whitespace at the start and end of the value.

Relaxed body canonicalization applies these rules to the body:

1. Reduce any sequence of whitespace within a line to a single space.
2. Remove all trailing whitespace at the end of each line.
3. Remove trailing empty lines at the end of the body (same end-of-body handling as simple).

The result is a body that produces the same hash even if a relay re-spaced the text, trimmed line endings, or refolded a long header. That's exactly what relays do routinely — and exactly what simple treats as tampering.

Why This Breaks Real Email

The difference is not academic. These are the three most common scenarios where canonicalization choice determines whether your DKIM signature lives or dies:

Whitespace rewriting. Mail relays routinely strip trailing whitespace from lines, convert tabs to spaces, and rewrap plain-text bodies to a different line width. With simple body canonicalization, a relay that strips trailing spaces from each line breaks every signature. relaxed body canonicalization collapses internal whitespace and strips trailing whitespace before hashing, so the same logical content produces the same hash.

Header line folding. Long headers like Subject, References, and DKIM-Signature itself get folded across multiple lines, and different mail systems fold at different points. A Subject line folded by your sender may be refolded by a relay. Under simple header canonicalization, that refold changes the bytes and breaks the header hash. Under relaxed, the header is unfolded to one line and whitespace is collapsed first, so the fold position doesn't matter.

Header case normalization. Some systems lowercase or rewrite header field names in transit. relaxed lower-cases them before hashing, so From: versus from: is irrelevant. simple treats that as a mismatch and fails.

Which One Should You Use?

Use relaxed/relaxed for both header and body. Here's why:

• It removes an entire class of intermittent body-hash failures without weakening the protection that matters. It still detects genuine content changes — a mailing list adding a footer, a subject tag, or any real modification to signed content breaks the signature under any canonicalization.
• Nearly every major sending platform (Google Workspace, Microsoft 365, SendGrid, Mailgun, Amazon SES) signs with relaxed/relaxed by default. If your ESP doesn't, check their DKIM settings — some let you change it.
• It composes well with DMARC. When you're trying to keep DKIM aligned across forwarders so that DMARC passes, every fragile assumption you can remove helps. relaxed/relaxed removes the whitespace and folding assumptions entirely, leaving only genuine body modification as a cause of failure.

The one thing relaxed does not fix: real content modification. If a mailing list adds [list-name] to the subject (a signed header) or appends an unsubscribe footer to the body, that's a genuine change to signed content, and it breaks the signature under any canonicalization. The solution for that is DKIM alignment redundancy (DMARC passes if either SPF or DKIM aligns) and ARC, not a different c= value.

How to Check Your Canonicalization Setting

Look at the DKIM-Signature header in an email your domain sends:

1. Send a test email to a Gmail address.
2. Open the email, click the three dots in the top-right, select Show original.
3. Find the DKIM-Signature header.
4. Look for the c= tag.

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=google;
    c=relaxed/relaxed; t=1694500000; bh=...; b=...

If you see c=relaxed/relaxed, you're set. If you see c=simple/simple or no c= tag at all (which defaults to simple/simple), check your email provider's DKIM settings to switch to relaxed.

You can also run a free DKIM lookup on your domain — a good scanner will show you whether DKIM is published, whether the key is valid, and flag canonicalization issues alongside your SPF and DMARC configuration.

Check your grade free

Don't guess what's broken — see it. Scan your domain free at emailsecuritygrade.com and get an instant A–F grade on your SPF, DKIM, DMARC, and MX records, with a plain-language fix for anything failing. No signup, no install — it runs in your browser.

If your emails are still landing in spam after fixing the records, a deliverability tool like InboxAlly can train mailbox providers to trust your sending — worth a look once your grade is solid.