There are two ways a vendor’s key ends up under your domain, and they differ in who holds the private key, who can change the public one, and what happens when the relationship ends.
Publishing a TXT record
The vendor generates a key pair, keeps the private half, and gives you the public half to publish. You control the record; changing the key requires them to send you a new one.
mktg2026._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIj..."
Delegating with a CNAME
You publish a CNAME pointing at a name the vendor controls. They publish the key there and can change it whenever they like without asking you. This is what most large platforms now do, and what the live records show:
s1.domainkey.u51742174.wl175.sendgrid.net. dkim.mcsv.net. protonmail.domainkey.drfeyjwh4gwlal4e2rhajsytrp6auv2nhenecpzigu7muak6lw6ya.domains.proton.ch.
Note the third one. Proton gives each customer an unguessable label, so the delegation target is specific to one account. SendGrid gives GitHub an account-numbered name. Mailchimp gives everybody dkim.mcsv.net — which is a different arrangement entirely, and the subject of a later lesson.
Which to choose
| TXT you publish | CNAME you delegate | |
|---|---|---|
| Who holds the private key | The vendor | The vendor |
| Who can change the published key | You | The vendor, silently |
| Rotation | A ticket and a DNS change | Automatic, invisible |
| Revoking access | Delete the record | Delete the record |
| What you can audit | The exact key you published | Whatever is there today |
| Failure mode | Stale key after their rotation | Dangling CNAME after their teardown |
Delegation trades visibility for maintenance, and for most vendors that is the right trade: their rotations happen without a ticket, and a key you cannot see is not obviously worse than one you can see and would not have examined anyway. The cost is that you have no record of what was published when, and no notice when it changes.
Neither option gives you the private key
In both arrangements the vendor holds the key and can sign anything as your domain, for as long as the record exists. The choice is about who administers the public record. Removing the vendor’s ability to sign means removing the record — and that is the same action in both cases, which is why per-vendor selectors matter more than this choice does.
Two things that catch people
- A CNAME cannot coexist with other records at the same name. If a TXT already exists at that selector, the CNAME will not be accepted, or will be accepted and produce an inconsistent zone. Remove the TXT first.
- A CNAME outlives the vendor. When the account is closed, the target stops existing and the selector becomes a dangling record. Fastmail has one on its own domain:
mesmtp._domainkey.fastmail.compoints at a name that is NXDOMAIN today.