DKIM explained: the signature that travels with the message

DKIM puts a cryptographic signature on every email you send, and publishes the matching verification key in your DNS so any receiver on earth can check it. A valid signature proves two things: the message was not altered after signing, and the signer controls the domain named in the signature. Where SPF vouches for the server that delivered a message, DKIM vouches for the message itself, and unlike SPF it keeps working no matter how many hops the message takes.

Signing, without the math

You do not need cryptography to understand DKIM. You need one property: there are key pairs where one key can create a signature and only the other key can verify it.

The sending server holds the private key. Before the message leaves, the server computes a compact fingerprint of the message (selected headers plus the body) and signs that fingerprint with the private key. The signature goes into a header called DKIM-Signature, and it travels inside the message like any other header.

The public key sits in your DNS as a TXT record, where anyone can read it. A receiving server pulls the key, recomputes the fingerprint from the message it actually received, and checks the signature. If a single signed character changed in transit, the fingerprints disagree and verification fails. If someone tries to forge a signature without the private key, verification fails. That's the whole machine. The standard is RFC 6376.

Two tags in the DKIM-Signature header matter enormously for everything that follows in this course. d= names the signing domain, the domain whose key verifies the signature and the domain that gets the credit or the blame. s= names the selector.

Selectors: where the key lives

The public key is published at a DNS name built from three parts:

<selector>._domainkey.<domain>

So a signature carrying d=example.com; s=k1 tells the receiver to fetch the key from k1._domainkey.example.com. The selector is just a name, a label that picks one key out of possibly many.

Selectors exist because one domain rarely has one key. Your newsletter tool signs with one key, your transactional service with another, your Google Workspace with a third, and each needs its own DNS location. Selectors also make rotation possible: publish a new key at a new selector, switch signing over, retire the old one, and no mail breaks in between.

Selector names are chosen by whoever does the signing, which is why they identify tools so reliably. Mailchimp asks you to publish k1._domainkey (some accounts get k2 and k3 as well); Klaviyo uses km1 and km2; beehiiv provisions s1 and s2 through SendGrid. (Our free checkers lean on exactly this: probing the selector names each provider documents is how we can tell, from public DNS alone, which tools are configured on a domain.)

Key length: 1024 is the floor, 2048 is the answer

DKIM keys are typically RSA, and RSA keys have a length in bits that decides how hard they are to crack. History here is unkind: keys of 512 bits, common in DKIM's early years, turned out to be breakable with rented computing power, which means an attacker could forge valid signatures for your domain. RFC 8301 responded by setting the rules that stand today: verifiers must accept keys of 1024 bits and up, must refuse anything shorter, and signers are advised toward 2048.

Treat that as: 1024 is the minimum that works, 2048 is what you should have. Any provider setting you up today should hand you a 2048-bit key; if you find a shorter one on a domain, it's old, and it's worth asking what else on that domain dates from the same era. When our domain checks probe DKIM keys, key length is one of the things we grade, precisely because weak keys sit in DNS for years without anyone looking.

Why your ESP gave you a CNAME, not a key

If you've set up Mailchimp or beehiiv, you may have noticed you never saw an actual key. You were asked to publish a CNAME, a DNS record that says "the answer for this name lives at that other name":

k1._domainkey.example.com  →  dkim.mcsv.net

This is delegation, and it is deliberate. The ESP hosts the real key record on their own DNS; your CNAME points your selector at it. The practical win is rotation. Rotating a key means generating a new pair and swapping the published public key, and it should happen periodically (a compromised or cracked key means forgeable signatures until it's replaced). With a CNAME in place, the ESP rotates keys on their side whenever they choose, and your DNS never needs touching.

Hold onto the flip side of that convenience, because it matters in the second half of this course: your authentication now silently depends on a record you don't host. If the ESP restructures their DNS, or your CNAME gets mangled, signing degrades with no change visible in your own zone. One concrete failure from our checker table: beehiiv domains where the CNAME was added behind Cloudflare's proxy (the orange cloud). The record must be DNS-only; proxied, verification fails and DKIM never signs, while everything looks fine in the dashboard where you pasted it.

The signature that survives forwarding

SPF has a structural weakness: it authorizes servers, so when a message is forwarded (a university address relaying to Gmail, a colleague auto-forwarding to a personal inbox), the forwarding server is the new connecting server, it isn't on your list, and SPF fails through no fault of yours.

DKIM doesn't care. The signature is inside the message, and the key is in public DNS, so verification works from anywhere, after any number of hops, as long as the signed content arrives unaltered. That last clause is doing real work: mailing-list software that rewrites subjects or appends footers alters signed content and breaks the signature. There's a standard called ARC that tries to patch that specific hole, and it gets covered in the last lesson of this module. But for ordinary forwarding, DKIM is the authentication that survives, and that resilience is a big part of why DMARC (next lesson) can lean on it.

What a DKIM pass actually proves

Time for the honest limit, because DKIM gets oversold. A valid DKIM signature proves the message was not altered since signing, and it names the signing domain. Full stop.

It does not prove the signer is trustworthy. Spammers sign their mail. It costs nothing: register a throwaway domain, generate a key pair, publish the public half, sign away. Every one of those messages passes DKIM perfectly, because DKIM is doing its job, which is identification, never endorsement.

The value sits one level up. Identity is the foundation reputation is built on. A verified d= domain gives mailbox providers a stable name to attach history to: this domain's mail gets read, that domain's mail gets reported as spam. Without DKIM, reputation has nothing solid to stick to. With it, your domain accumulates a track record that follows you across IPs and providers. Whether that identity also matches the From address your reader sees is a separate question, the alignment question, and it has its own lesson because it's the one everyone misses.

One more honest note from our side of the fence: probing DKIM from DNS alone, the way any domain checker does, can only confirm that plausible keys exist at known selector names. Proof that your mail is actually signed, with which key, and whether the signature verifies, only comes from inspecting a delivered message. That's why the health check reads your DNS and tells you what it can see, and says so plainly when a question needs a real email to answer.

The good news: when you do inspect a delivered message, the receiver has already done the work. On arrival it stamps a header called Authentication-Results recording its own verdicts, spf=pass, dkim=pass and so on, each naming the domain the verdict applies to. It sits in any message's raw source, and it is the closest thing email has to an authoritative scoreboard. Later lessons use it constantly.

What turns those separate verdicts into one decision about your mail is DMARC, the next lesson.

Terms from this lesson

• DKIM (DomainKeys Identified Mail) - the standard (RFC 6376) for signing email so receivers can verify the message wasn't altered and identify the signing domain.
• private key - the secret half of the key pair, held by the sending server, used to create signatures.
• public key - the shareable half, published in DNS, used by receivers to verify signatures.
• selector - the label that picks which key to use; the public key lives at <selector>._domainkey.<domain>.
• d= tag - the tag in the DKIM-Signature header naming the signing domain, which is the domain that earns the reputation.
• CNAME delegation - publishing your DKIM selector as a CNAME pointing at the ESP's DNS, so they host and rotate the actual key.
• key rotation - periodically replacing a signing key pair with a fresh one, so a compromised or cracked key has a limited useful life.

Check yourself

1. A signature carries d=example.com and s=mail2. Where does the receiver look up the public key?

example.com's root TXT record_dkim.example.commail2._domainkey.example.comexample.com's MX server

2. What does a passing DKIM signature prove?

The message content matches what the named domain signedThe sender is reputable and the message is safeThe sending server was authorized in the domain's SPF recordThe From address is genuine

3. Under RFC 8301, what is the minimum RSA key length a verifier will accept?

512 bits1024 bits2048 bits4096 bits

4. Why do most ESPs have you publish a CNAME for DKIM instead of the key itself?

CNAME records are checked faster than TXT recordsTXT records can't hold keys longer than 1024 bitsIt hides the public key from attackersIt lets the ESP host and rotate the key without you touching DNS