DKIM Explained: Selectors, Key Length, Rotation and Alignment

What is DKIM?

DKIM (DomainKeys Identified Mail) is a method of signing email so a receiving server can verify which domain took responsibility for a message and that the signed parts weren’t changed in transit. The sending platform signs each message with a private key. The matching public key is published in DNS, and the receiver uses it to check the signature.

The standard is RFC 6376, with RFC 8301 updating the rules on algorithms and key sizes. Gmail and Yahoo expect every bulk sender to sign with DKIM, and Microsoft requires it for high-volume senders reaching Outlook.com.

Unlike SPF, DKIM is attached to the message itself rather than to the server that delivered it. That’s why it usually survives forwarding, and why it’s the more dependable half of DMARC.

What a DKIM signature contains

When a message is signed, the platform adds a DKIM-Signature header. Simplified, it looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mkt2026; h=from:to:subject:date:message-id; bh=…; b=…

The tags that matter most:

• d= is the signing domain. This is the domain whose reputation the signature attaches to, and the one DMARC compares with your From address.
• s= is the selector, which tells the receiver which public key to fetch.
• a= is the algorithm. You should see rsa-sha256. RFC 8301 says signers must not use rsa-sha1.
• h= lists the headers covered by the signature. From is always included.
• bh= is a hash of the body, and b= is the signature itself.
• c= sets canonicalization, the rules for how strictly whitespace and formatting changes are tolerated. relaxed/relaxed is the usual and more forgiving choice.

You may also see l=, which limits how much of the body is signed. Avoid it. It allows someone to append content below the signed portion while the signature still verifies.

Selectors and the DNS record

A selector is a label that lets one domain publish several DKIM keys at the same time. The receiver combines it with the signing domain to find the key:

mkt2026._domainkey.example.com

The TXT record at that name holds the public key:

v=DKIM1; k=rsa; p=MIIBIjANBgkqh…

p= is the base64-encoded public key. k=rsa is the default and can be omitted. A t=y flag marks the domain as testing DKIM. Remove it once you’re live. RFC 6376 tells receivers not to treat mail signed in testing mode any differently from unsigned mail, so a forgotten flag can leave your signature counting for very little.

Selectors are what make a multi-platform setup possible. Your staff email, your marketing platform and your helpdesk can each sign as example.com, each with its own key under its own selector. None of them needs access to another’s private key, and you can replace one without touching the others.

Many platforms don’t ask you to paste a key at all. Instead they give you one or two CNAME records, so s1._domainkey.example.com points to a hostname the platform controls. Microsoft 365 works this way with its selector1 and selector2 records, and so do many marketing and transactional platforms. The advantage is that the platform can rotate keys without you editing DNS. The trade-off is that you depend on the platform to do it.

How do I find my DKIM selector?

Open a message you’ve sent and view the original or raw source. In Gmail, that’s Show original from the message menu. Find the DKIM-Signature header and read the s= and d= values. The Authentication-Results header added by the receiver shows the outcome, for example dkim=pass header.d=example.com header.s=mkt2026. Check one message from each platform you use. They will usually have different selectors.

Which DKIM key length should I use?

Use a 2048-bit RSA key. RFC 8301 requires signers to use keys of at least 1024 bits and recommends at least 2048. Google sets 1024 bits as the minimum for Gmail and recommends 2048 where your DNS provider supports it. Yahoo asks for at least 1024.

A 1024-bit key still verifies today, so there’s no emergency if you find one. Replace it during your next planned rotation.

Two practical points come up with 2048-bit keys:

• The record is longer than 255 characters. A single DNS TXT string can’t exceed that, so the key has to be split into two or more quoted strings that receivers join back together. Most DNS providers handle this automatically. Some web interfaces don’t, and a key pasted with a line break or stray quote in the middle will fail every check.
• 4096-bit keys are rarely worth it. Receivers are required to verify keys up to 4096 bits, but the DNS record becomes large and some DNS setups struggle with it. The security gain doesn’t justify the operational risk for most senders.

There is a newer algorithm, Ed25519 (RFC 8463), which uses much shorter keys. Receiver support is still incomplete, so anyone using it signs with RSA as well. For most businesses, RSA 2048 is the right answer.

DKIM key rotation

Rotation means replacing the key pair periodically, so that a leaked or weakened private key can’t be used for long. A common recommendation, including from the industry group M3AAWG, is to rotate at least every six months. Many organizations haven’t rotated since the day DKIM was set up, which usually means a 1024-bit key that’s years old.

Selectors make rotation safe, because the new key goes under a new name while the old one keeps working:

If your platform uses CNAME-delegated keys, rotation is handled on the platform’s side. Your job is to confirm that it happens and that the CNAMEs still resolve. For Google Workspace and Microsoft 365, rotation is done from their admin consoles, and the selectors involved are visible in their DKIM settings.

DKIM alignment and why the signing domain matters

A DKIM pass is only useful to your domain if the signing domain aligns with the domain in your From address. This is the part most setups miss.

Many platforms sign every message by default, but with their own domain in d=. The signature is valid, the receiver records dkim=pass, and the platform’s dashboard shows a green tick. But the pass belongs to the platform. For DMARC, a pass from d=platform-example.net doesn’t align with From: news@example.com, so DKIM doesn’t count for you. Some receivers also show the platform’s domain next to your name, which recipients may find odd.

Alignment comes in two modes, set in your DMARC record:

• Relaxed (the default): the signing domain and the From domain must share the same organizational domain. d=mail.example.com aligns with From: hello@example.com.
• Strict: they must match exactly. d=mail.example.com would not align with example.com.

Relaxed alignment suits almost every business. Strict mode is mainly useful when subdomains are run by different teams or vendors that you want to keep apart.

To fix a non-aligned signature, set up custom DKIM in the platform, often labeled “branded sending domain”, “domain authentication” or “authenticated domain”. That publishes keys under your domain and switches d= to it. Our DMARC guide covers how alignment is evaluated alongside SPF.

Why does DKIM fail?

DKIM fails when the receiver can’t find the key, or when the message no longer matches the signature. The common causes:

• Wrong DNS name. Many DNS providers append your domain automatically, so entering s1._domainkey.example.com creates s1._domainkey.example.com.example.com. Enter only s1._domainkey in those interfaces.
• Broken key. A line break, missing character or extra quote inside p=. Long keys pasted into narrow web forms are the usual culprit.
• Body or header changes in transit. Mailing lists that add footers or tag subject lines, and some security gateways that rewrite links, alter the signed content. Relaxed canonicalization tolerates whitespace changes, not content changes.
• Key mismatch. The private key was regenerated in the platform but the DNS record wasn’t updated, or the reverse.
• Revoked or deleted key still in use by a forgotten system, such as an old server sending invoices.

One more pattern to watch for: a new tool sends as your domain but hasn’t been set up with DKIM at all. Messages arrive with only the tool’s own signature, or none. DMARC aggregate reports are the quickest way to spot this, because they show every source using your domain and whether each one’s DKIM is passing and aligned.

A short DKIM checklist

• Every platform that sends as your domain signs with your domain (or a subdomain of it) in d=.
• Every key is RSA 2048-bit with rsa-sha256.
• Each platform has its own selector, documented with its owner and the date it was last rotated.
• No t=y testing flags remain on live keys, and no l= tags in signatures.
• Old keys from retired platforms are revoked.
• DMARC reports show DKIM passing and aligned for each legitimate source.

Pair this with the SPF guide, because DMARC will use whichever of the two passes and aligns.