DKIM Explained: Selectors, Canonicalization and Key Rotation for Security+

DKIM — DomainKeys Identified Mail — adds a digital signature to outgoing email so a receiving server can verify two things: that the message really came from the domain it claims, and that it has not been altered in transit.

SPF asks whether the sending server was authorized. DKIM asks whether the message itself is authentic and unmodified. They answer different questions, which is why both exist.

This article goes deeper than the overview in the SMTP post, into how the signature is actually produced and the things that break it.

How the Signature Works

DKIM uses public key cryptography. The domain owner generates a key pair, keeps the private key on the sending mail server, and publishes the public key in DNS.

1. The sending server hashes selected headers and the message body.
2. It signs that hash with the private key and inserts a DKIM-Signature header into the message.
3. The receiving server reads the signature header to find the signing domain and the selector.
4. It fetches the public key from DNS at selector._domainkey.domain.com as a TXT record.
5. It recomputes the hash and verifies the signature. If they match, the message is authentic and unaltered.

Selectors

The selector is the part people find confusing, and it is genuinely useful. It is an arbitrary label — s1, google, mail, k1 — that lets one domain publish multiple DKIM keys simultaneously.

Two reasons this matters. First, an organization typically sends mail through several services — a mail platform, a marketing tool, a helpdesk, a billing system — and each needs its own key. Different selectors let all of them sign as your domain without sharing a private key.

Second, selectors make key rotation possible without downtime. Publish the new key under a new selector, switch the signing server to it, wait for mail signed with the old key to clear, then remove the old record. Without selectors you would have to swap the key and break every message in flight.

What Gets Signed

The h= tag in the signature lists which headers were included. Typically From, To, Subject, Date and Message-ID. The From header is effectively mandatory — a signature that excluded it would prove nothing useful about who sent the message.

Headers not listed are unsigned and can be added or altered without breaking verification. That is a deliberate trade-off, because mail servers legitimately add headers in transit.

Canonicalization — Why Signatures Break

Mail servers en route make small changes: folding long header lines, adjusting whitespace, appending a footer. Any of those alter the bytes, and a naive signature would fail on every message.

Canonicalization defines how much change is tolerated, specified in the c= tag as header/body:

• simple — almost no tolerance. Any modification breaks the signature.
• relaxed — tolerates whitespace normalization and header case changes.

The common setting is relaxed/relaxed, and the reason is practical: strict canonicalization produces failures from entirely benign handling. This is the single most common cause of mysterious DKIM failures — and mailing lists are the classic culprit, because they add subject prefixes and footers that break the body hash.

That mailing list problem is real enough that ARC (Authenticated Received Chain) was created to preserve authentication results across intermediaries that legitimately modify messages.

Key Length and Rotation

DKIM keys are RSA, and 1024-bit is the practical minimum while 2048-bit is the current recommendation. Anything shorter is considered weak and some receivers ignore it entirely. Note the constraint that shaped practice here: a 2048-bit key produces a long TXT record, and some DNS providers historically struggled with strings over 255 characters, which is why split TXT records appear in DKIM configuration.

Keys should be rotated periodically — annually is a common policy — using the selector mechanism described above.

Where DKIM Fits With SPF and DMARC

	SPF	DKIM	DMARC
Validates	The sending IP address	The message signature	Alignment of the visible From domain
Mechanism	DNS list of permitted senders	Public key cryptography	Policy tying SPF and DKIM to the From header
Survives forwarding?	No — the forwarding server's IP is not listed	Usually yes, if the message is unmodified	Depends on the underlying results
Detects tampering?	No	Yes	No, but relies on DKIM's answer

DKIM surviving forwarding is its key advantage over SPF, and it is a likely exam point. A forwarded message fails SPF almost by definition, because the forwarder's IP is not in the original domain's record. The DKIM signature travels with the message and still verifies.

DMARC then ties both to the domain the recipient actually sees, and this is the crucial gap: DKIM alone proves a message was signed by some domain, not that the signing domain matches the From address a human reads. Without DMARC alignment, an attacker can sign with their own domain and pass DKIM while displaying yours.

Security+ (SY0-701) Exam Tips

• DKIM signs messages with a private key; the public key is published in DNS as a TXT record.
• It provides authentication and integrity, not confidentiality. It does not encrypt anything.
• SPF authorizes the sender's IP; DKIM authenticates the message; DMARC aligns them to the visible From. Know all three and what each adds.
• DKIM survives forwarding where SPF does not.
• Know the record location: selector._domainkey.domain.com.
• Selectors allow multiple keys and clean rotation.
• DKIM alone does not stop lookalike domains, because the attacker signs validly for a domain they own.

CySA+ and SecurityX Angles

CySA+ (CS0-004) expects header analysis: reading the Authentication-Results line, interpreting a DKIM pass against a mismatched From domain, and recognizing that a passing signature on a lookalike domain is still hostile mail.

SecurityX (CAS-005) covers rollout across an organization — inventorying every service that sends as your domain, assigning selectors, moving DMARC from monitoring to enforcement without losing legitimate mail, and reading aggregate reports.

Key Takeaways

• DKIM adds a cryptographic signature proving the message came from the domain and was not altered.
• The public key lives in DNS at selector._domainkey.domain.com.
• Selectors allow multiple sending services and zero-downtime key rotation.
• Canonicalization decides how much en-route modification is tolerated; relaxed/relaxed is standard, and mailing lists still break it.
• 2048-bit keys are the current recommendation.
• DKIM survives forwarding; SPF does not.
• It proves the signing domain, not the visible From domain — that alignment is DMARC's job.