What is DKIM? Signing, selectors and why it breaks silently

What is DKIM? DomainKeys Identified Mail is a way for a sending server to attach a cryptographic signature to every email it sends, and for the receiving server to verify that signature using a public key your domain publishes in DNS. If the signature checks out, the receiver knows two things: the message genuinely came from a server holding your private key, and the signed parts of the message weren't altered in transit. Unlike SPF, which checks the IP of the connecting server, DKIM travels with the message — which is why it survives forwarding and why it has become the more durable half of DMARC alignment.

How DKIM signing works

When your mail server or email provider sends a message, it hashes the body, builds a canonical form of selected headers, signs them with a private key, and adds a DKIM-Signature header. A trimmed example:

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

The tags that matter:

To verify, the receiver combines selector and domain and queries DNS for a TXT record at <selector>._domainkey.<domain> — here, mail2026._domainkey.example.com. That record holds the public key (v=DKIM1; k=rsa; p=MIIBIjANBg...). If the signature validates against the key and the body hash matches, DKIM passes. The private key never leaves the sender; only the public half lives in DNS.

Why selectors exist

The selector is just a namespace label, and it solves three real problems:

• Multiple senders, one domain. Your transactional provider, your marketing platform and your own MTA can each sign as example.com with its own key under its own selector (sendgrid, mailjet1, mail2026) without coordinating.
• Rotation without downtime. Publish a new key under a new selector, switch signing, and leave the old record in place while in-flight mail still verifies. Remove the old one days later.
• Delegation via CNAME. Most hosted providers ask you to publish CNAME records that point s1._domainkey.example.com into DNS they control. The verifier follows the CNAME to the provider's key. This is what lets a provider rotate keys on your behalf without filing a DNS change with you each time.

Selector rotation in practice

Keys sitting in DNS for years are a liability, so rotate them. New deployments should use 2048-bit RSA — 1024-bit no longer offers an adequate margin, and the old 512/768-bit keys are refused outright by modern verifiers. A safe rotation looks like:

1. Generate a new key pair; publish the public key under a new selector.
2. Wait for DNS propagation — confirm the record resolves from outside your network.
3. Switch the signer to the new selector.
4. Leave the old selector's record published for at least a week, then delete it and destroy the old private key.

If your provider signs for you via CNAMEs, rotation is their job — convenient right up until it isn't.

Why DKIM breaks silently

The defining property of DKIM failures is that they are invisible from the sending side. Your mail still goes out, your provider dashboard stays green, and the only evidence is in receivers' DMARC aggregate reports — or a customer mentioning your invoices went to junk. The failure modes we see again and again:

• A CNAME got "tidied up." Someone migrating zones drops the odd-looking s1._domainkey records. Nothing breaks immediately — the old key may still verify — and then weeks later the provider rotates, verification flips to fail or permerror, and DMARC alignment collapses.
• The key was copied, not delegated. Someone pasted the provider's public key as a static TXT record instead of using the CNAME. It works until the provider rotates, then fails permanently with no error on your side.
• A migration truncated the key. A 2048-bit public key is longer than the 255-char limit of a single TXT string, so it's split across multiple strings. A botched zone move mangles the split, p= stops being valid base64, and every verification fails.

The common thread: nothing on your side reports the failure. The only reliable defence is to monitor the DNS side directly — confirm each selector still resolves, the CNAME chain is intact, and the key parses.

Keeping DKIM healthy

DKIM is correct on the day you set it up and decays from there as zones get migrated, providers rotate, and old selectors linger. Treat it as monitored infrastructure, not set-and-forget DNS. Our email DNS docs cover how DKIM fits with SPF and DMARC, and the security docs describe what we watch.

DomainOps checks your DKIM selectors — alongside SPF and DMARC — as part of its DNS health monitoring and alerts you when a selector disappears or stops resolving. It does not send your mail or manage your zone; it watches your records so a silent break gets caught early. For a one-off look at your current setup, run the free email auth audit, and when you want continuous coverage, get started.