DKIM|External Vendors

If a vendor signs mail on your behalf but doesn’t control your DNS zone, you don’t have to hand them your DKIM private key to keep signing working: DNS lets you delegate just the public key, while you keep the CNAME reference (and the ability to redirect it) yourself.

Why it matters

A DKIM signing gateway needs its public key published under your domain’s DNS zone, at the selector the gateway signs with. If the gateway operator doesn’t have direct access to your DNS, you’d otherwise need to manually copy their public key into your own zone every time they rotate it. A CNAME reference avoids that: it points your selector at a record the gateway operator controls directly, so they can rotate keys on their own schedule without ever needing access to your DNS.

How it works

Set up a CNAME record for your DKIM selector that points at a hostname the gateway operator controls in their own DNS zone. The gateway operator then publishes the actual DKIM public key (as a TXT record) at that hostname. Because your selector‘s CNAME just points there, any rotation the gateway performs takes effect automatically, with no further DNS changes needed on your end.

Good to know

This is the same CNAME-delegation pattern covered briefly in DKIM | Guidelines; this article walks through the full worked example.

Worked example

Say Sample Corp (sample.com) hires an email gateway service, Example Net (example.net), to send and sign its newsletters with DKIM. DKIM works by publishing a small piece of verification data in DNS (the internet’s address book) so that mailbox providers like Gmail can check a message’s signature is genuine.

Rather than Sample Corp manually copying that verification data into its own DNS every time Example Net updates it, Sample Corp instead sets up a forwarding entry (a CNAME) that always points to wherever Example Net currently publishes its data. That way, whenever Example Net changes its keys, Sample Corp’s DNS follows along automatically, with no extra work on Sample Corp’s side. Sample Corp keeps ownership of that forwarding entry and can redirect it elsewhere at any time, while the day-to-day key management stays Example Net’s responsibility.

In practice, two such forwarding entries are usually set up side by side, so Example Net can switch smoothly from an old key to a new one without any downtime.

For reference, here is what the actual DNS records look like:

On sample.com‘s DNS: <vendor>-selector1._domainkey.sample.com (CNAME) → sample-com-selector1.dkim.example.net
On sample.com‘s DNS: <vendor>-selector2._domainkey.sample.com (CNAME) → sample-com-selector2.dkim.example.net
On example.net‘s DNS: sample-com-selector1.dkim.example.net (TXT) → v=DKIM1; k=rsa; p=<...>; n=<keysize>,<publication date>
On example.net‘s DNS: sample-com-selector2.dkim.example.net (TXT) → v=DKIM1; k=rsa; p=<...>; n=<keysize>,<publication date>

With this in place, the gateway operator owns DKIM key management end to end, including rotation, without ever needing further DNS changes on the customer’s side.

References & further reading

RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures: rfc-editor.org/rfc/rfc6376, updated by RFC 8301 and RFC 8463.
M3AAWG DKIM Key Rotation Best Common Practices, and M3AAWG’s best practices for implementing DKIM to avoid key-length vulnerabilities.