Skip to main content

Understanding How DomainKeys Identified Mail (DKIM) helps protect your organization

· 7 min read
Hannes Palmquist
Hannes Palmquist
Senior Consultant Cloud

Overview​

DKIM (DomainKeys Identified Mail) is an email authentication method that allows an organization to claim responsibility for a message by affixing a digital signature to it. The recipient's email server can then verify that the signature matches the message and that it was sent by an authorized sender, helping ensure the email has not been altered during transit. DKIM's goal is to prevent email spoofing and ensure message integrity.

Workflow​

  1. The sending system takes specific parts of the email (typically the headers and sometimes the body) and generates a cryptographic hash, which represents the email content.
  2. This hash is encrypted using the domain's private key and appended as the DKIM signature to the email's headers.
  3. The DKIM signature contains metadata, such as which header fields were included in the hash and a reference to the DKIM DNS record for verification.
  4. When the email arrives at the recipient's system, the receiving mail server:
    • Extracts the DKIM signature from the headers.
    • Looks up the DKIM public key in the DNS using the domain and selector specified in the signature.
    • Decrypts the signature with the public key, retrieving the original hash.
    • Recomputes the hash using the received email's header and body.
    • Compares the two hashes. If they match, the email passes DKIM validation, confirming that it wasn't altered in transit and that it was authorized by the signing domain.

Pros​

  • Email Authenticity: DKIM confirms that the email was sent from a domain that has authorized the sender, enhancing trust.
  • Message Integrity: DKIM ensures that the email's content (headers and optionally the body) hasn't been modified after it was signed by the sending server.
  • Widely Supported: DKIM is widely adopted and supported by major email providers, including Google, Microsoft, and Yahoo.
  • Plays well with DMARC: When used in conjunction with DMARC, DKIM helps establish a domain's email authentication policy, ensuring that spoofed messages are more likely to be rejected.

Cons​

  • Does not protect "MAIL FROM": DKIM does not authenticate the "MAIL FROM" (envelope sender) address, which is often displayed in email clients. Spoofers can still manipulate this value to mislead recipients.
  • Forwarding Issues: Forwarded messages may cause DKIM verification to fail. This occurs because forwarding servers often modify parts of the email, such as headers or the body, that were included in the DKIM signature.
  • Key Management: Administrators must manage DKIM keys securely, rotating them periodically to prevent compromise.
  • Requires DNS: DKIM relies heavily on DNS infrastructure for the public key, meaning disruptions in DNS can lead to authentication issues.

Details​

DNS Record​

The DKIM DNS record is a TXT record published by the domain owner in the DNS zone file. This record contains the public key that receiving mail servers use to verify the DKIM signature.

DNS Record Name​

[selector]._domainkey.[domain].[topdomain]

  • Selector: A label (usually a short string) defined by the domain owner, used to differentiate multiple DKIM keys for the same domain.
  • Domain: The sender's domain (e.g., example.com).
  • Top Domain: The top-level domain (e.g., .com, .org).

Example Value​

v=DKIM1; p=[yourPublicKey]

Mandatory Tags​

TagDescription
vThe version of the DKIM record. This must be DKIM1 and should appear as the first tag.
pThe public key. This is the key used by receiving mail servers to validate the DKIM signature.
TagDescription
tTesting Mode: t=y indicates that the domain is testing DKIM. When testing is complete, this tag should be removed or changed to t=s to enforce DKIM signatures.
t=sStrict Matching: If the i= tag in the DKIM signature is used, this enforces that the "i=" domain must match the "d=" domain exactly, without allowing subdomains.

Optional Tags​

TagDescription
gGranularity: Defines which local-part of an email address (before the @ sign) can use the key. A wildcard * allows all users in the domain to use the selector.
hHash Algorithms: Specifies which hash algorithms are acceptable (sha1, sha256). DKIM requires that both the sender and the verifier support sha256.
kKey Type: Specifies the key algorithm (default: RSA).
nNotes: For administrative use, this can contain a human-readable note for admins. It does not impact DKIM functionality.
sService Type: Defines the service type the record applies to (e.g., email). By default, this applies to all service types (*).

Long DNS Records​

When the DKIM public key is too long (which is common for 2048-bit keys), the DNS TXT record may exceed the 255-character limit. To solve this, the key can be split into multiple quoted strings in a single DNS TXT record.

Example:

"p=string_part1"
"string_part2"
"string_part3"

DKIM Signature​

The DKIM signature is added as an email header when the message is sent. This signature contains metadata about the signature process and the cryptographic signature itself.

Example Value​

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938; h=from:to:subject; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Tags in the DKIM Signature​

TagDescription
vDKIM version. It should always be v=1.
aSigning algorithm (e.g., rsa-sha256).
dDomain name of the signing entity (e.g., example.net).
sSelector. This links to the correct DKIM public key in the DNS record.
cCanonicalization algorithms for the header and body. These determine how the email is normalized before signing. Common values are relaxed/relaxed and relaxed/simple.
qQuery method (usually dns/txt to retrieve the public key).
lLength of the canonicalized body that was signed.
tTimestamp indicating when the signature was created.
xExpiry time after which the signature is no longer valid.
hA list of the email headers that were signed (e.g., from:to:subject:date).
bThe actual digital signature of the email, generated using the private key.
bhThe hash of the canonicalized body. This is used to verify that the body has not been altered.

Canonicalization Algorithms​

The canonicalization process normalizes the email's header and body content before hashing and signing, ensuring that insignificant changes (like extra whitespace) don't break DKIM verification. The two common methods are:

  1. relaxed: Reduces whitespace and normalizes header field names, making the signature more resilient to minor changes.
  2. simple: Requires an exact match of the header and body, making it more prone to failure if even minor modifications occur (e.g., forwarding or adding extra headers).

Interplay with SPF and DMARC​

While DKIM verifies the integrity and authenticity of an email, it does not authenticate the sending server's IP address, as SPF (Sender Policy Framework) does. DMARC (Domain-based Message Authentication, Reporting & Conformance) combines DKIM and SPF, allowing domain owners to set policies for how emails that fail authentication checks should be handled (e.g., reject, quarantine, or accept).