What happens if I don't specify the 'c' tag in my DKIM signature?

If you don't explicitly include the 'c=' tag in your DKIM signature, its value defaults to relaxed/relaxed . This is generally the recommended setting for most senders, as it allows for minor, non-material changes to your email's headers and body during transit without invalidating the DKIM signature.

Why is 'relaxed/relaxed' the preferred canonicalization method?

'Relaxed/relaxed' is preferred because it's more tolerant of common, benign modifications that email messages often undergo when passing through various mail servers, mailing lists, or email clients. These modifications, such as changes in whitespace or line folding, would cause a 'simple/simple' canonicalization to fail, leading to unnecessary DKIM authentication failures for legitimate emails.

Can I use 'simple/simple' canonicalization?

While you can technically use 'simple/simple' canonicalization, it is rarely recommended for most environments. The 'simple' method is extremely strict and requires an almost byte-for-byte identical email from signing to verification. Even minor changes, which are common in email delivery, will cause DKIM authentication to fail, potentially leading to deliverability issues.

How does canonicalization impact DMARC?

Canonicalization is crucial for DMARC because DMARC policies rely on DKIM authentication to pass. If your DKIM signature fails validation due to an inappropriate canonicalization method (e.g., 'simple' being too strict), then the DMARC check for that email will also fail. This can result in your emails being rejected, quarantined, or sent to spam, depending on your DMARC policy for unauthenticated mail .

What is the default value for the DKIM 'c' tag? - DKIM - Email authentication - Knowledge base

Abstract illustration of a secure email with a lock and digital signatures, representing DKIM authentication

When delving into email authentication, you quickly encounter important acronyms like DMARC, SPF, and DKIM. DomainKeys Identified Mail (DKIM) is a crucial standard designed to detect email spoofing, and it does so by allowing the sender to digitally sign legitimate emails. This signature is then verified by receiving mail servers.

A DKIM signature is comprised of several tags, each conveying specific information about the email and its signature. These tags, such as the 's=' tag that represents the selector, or the 'd=' tag indicating the signing domain, play a vital role in the verification process. Among these, the 'c=' tag is particularly significant because it defines the canonicalization algorithm used for both the email's headers and body.

Canonicalization refers to the process of standardizing the email content before applying the cryptographic signature. This standardization ensures that minor modifications to the email, which don't affect its perceived content but might alter its raw format, do not invalidate the DKIM signature. Understanding the 'c=' tag and its default value is fundamental for anyone managing email infrastructure or aiming to improve their email deliverability rates.

Understanding DKIM canonicalization

The 'c=' tag specifies the canonicalization algorithms for the header and body of the message. These algorithms dictate how the email's content is prepared before the DKIM signature is generated and verified. If the message content changes in a way that doesn't match the canonicalization method, the signature will fail validation. This mechanism helps to ensure the integrity of the email during transit.

There are two main types of canonicalization for both headers and bodies: simple and relaxed. The choice between these two directly impacts how strictly the receiving server will check for modifications. The simple algorithm is very strict, requiring almost no changes to the headers or body, while the relaxed algorithm is more tolerant of common modifications made by mail transfer agents (MTAs).

Canonicalization is a fundamental aspect of DKIM, as detailed in RFC 6376, the standard for DKIM Signatures. Proper configuration of the 'c=' tag, therefore, is crucial for ensuring that your legitimate emails pass DKIM validation and reach their intended recipients without being flagged as suspicious or spam. It's a delicate balance between strict security and practical interoperability with various email systems.

The default value of the 'c' tag

The default value for the DKIM 'c=' tag is relaxed/relaxed. This means that if you omit the 'c=' tag from your DKIM signature, the receiving mail server will assume that both the header and body canonicalization methods are 'relaxed'. This default is generally preferred for most email senders because it offers greater flexibility in how emails are handled during transit.

The relaxed/relaxed default applies to both the header canonicalization (the first value) and the body canonicalization (the second value). This canonicalization method permits common, non-material changes that might occur when an email passes through various mail servers or mailing lists. For instance, it allows for alterations in whitespace, header field line folding, and other minor formatting adjustments without invalidating the DKIM signature.

While you can explicitly specify c=relaxed/relaxed in your DKIM signature, it is often omitted due to this default behavior. However, for clarity and explicit configuration, including it can be beneficial. It helps other administrators and systems understand your intended canonicalization method directly. It is how Microsoft Defender for Office 365 suggests configuring DKIM, for example, to ensure mail from your cloud domain is signed correctly.

Simple vs. relaxed canonicalization

Simple canonicalization

Strictness: Requires exact header and body content, with no modifications whatsoever. Even a single space or line break change can invalidate the signature.
Header changes: Whitespace at the end of header lines, changes in header field order, or folding long lines will cause authentication to fail. This relates to what the 'h=' tag is used for.
Body changes: Any alteration to the body, including changes in line endings or blank lines at the end, will result in a DKIM failure. This directly impacts the body hash tag.
Use case: Rarely used in practice due to its rigidity. Primarily for environments where no modifications are expected.

Relaxed canonicalization

Strictness: More tolerant of common modifications to headers and body, often introduced by intermediate mail servers or mailing lists.
Header changes: Ignores whitespace at the end of lines, converts all header field names to lowercase, and unfolds wrapped header lines before hashing. It still preserves the order of multiple headers with the same name.
Body changes: Reduces all sequences of whitespace to a single space, ignores trailing whitespace, and removes all blank lines at the end of the body.
Use case: Recommended for most senders as it minimizes false negatives due to minor, non-malicious email modifications.

Best practice for canonicalization

For nearly all email senders, using relaxed/relaxed is the recommended best practice. This approach ensures that your DKIM signatures remain valid even if the email undergoes minor formatting changes by intermediate servers, mailing lists, or email clients. It significantly reduces the chance of legitimate emails failing DKIM validation, which can lead to them being rejected or sent to spam folders.

Here's an example of a DKIM-Signature header with the c tag explicitly set:

DKIM-Signature header with c=relaxed/relaxed

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1; h=From:To:Subject:Date; bh=bodyhash; b=signaturehash

Impact on email deliverability and security

The choice of canonicalization algorithm directly impacts the effectiveness of DKIM in authenticating your emails. Using relaxed/relaxed helps prevent legitimate emails from failing authentication due to benign modifications. A DKIM failure can significantly harm your domain's reputation and increase the likelihood of your emails being delivered to the spam folder or even being blocked entirely. This is especially true with the new sender requirements from providers like Gmail and Yahoo.

For email security, DKIM works in conjunction with SPF and DMARC. DMARC relies on both SPF and DKIM passing authentication and alignment. If DKIM fails due to an overly strict canonicalization, it can lead to a DMARC failure. This is why tools like Suped, a leading DMARC monitoring platform, are invaluable. We provide AI-powered recommendations to fix issues, real-time alerts, and a unified platform for DKIM, SPF, and DMARC. Our generous free plan helps you get started.

An illustration comparing intricate and streamlined email authentication, symbolizing simple versus relaxed DKIM canonicalization.

Monitoring your DKIM authentication results through DMARC reports is essential to ensure your chosen canonicalization method is working effectively. Failures often indicate configuration issues, such as using simple canonicalization in an environment where emails are frequently altered, or a DKIM record published but not found. By leveraging the default relaxed/relaxed setting, or explicitly configuring it, you significantly enhance your email's chances of successful authentication and delivery.

Key takeaways on DKIM 'c' tag

The DKIM 'c=' tag, which specifies canonicalization, has a default value of relaxed/relaxed. This default is widely accepted as a best practice because it strikes a good balance between maintaining email integrity and accommodating the minor modifications that can occur when emails pass through various systems. By allowing for minor changes in whitespace and header formatting, relaxed canonicalization minimizes the risk of legitimate emails failing DKIM authentication.

Ensuring your DKIM records are correctly configured, whether relying on the default 'c=' tag value or explicitly setting it, is crucial for email deliverability and protecting your domain from spoofing. Consistent monitoring of your authentication results is key to maintaining a healthy email ecosystem and ensuring your messages reliably reach the inbox.