Unlike SPF, which allows only one TXT record per domain, DKIM is built to hold as many keys as you have senders. Each service you send mail through publishes its own public key under its own selector, a short label that lives in a dedicated subdomain of _domainkey.yourdomain.com. That means Google Workspace, SendGrid, Mailchimp and any transactional provider can each sign your mail with their own key at the same time, with no conflict, as long as no two of them share the same selector name.
Reads public DNS only. Nothing is stored unless you save the domain to an account.
If you have ever worried that adding a second email vendor would "break" your first one the way a second SPF include can, DKIM removes that fear entirely. The design goal of selectors is exactly this: many independent keys, one domain, verified separately by every receiver.
Why DKIM allows many records but SPF allows only one
SPF is published as a single TXT record at the root of your domain, and RFC 7208 says a domain must not have more than one SPF record. That single-record limit is why multi-vendor SPF gets painful and why the 10-lookup cap bites so quickly. Every sender has to be flattened into one line.
DKIM works the other way around. A DKIM key is not published at the root. It lives at selector._domainkey.yourdomain.com, and the selector is chosen by the signing service. Because each provider uses a different subdomain, their records never collide. A receiver does not guess which key to use. The signature in the email header carries a d= (domain) tag and an s= (selector) tag, and the receiver looks up exactly that one record.
That is the core idea worth internalizing: the email tells the receiver which key to fetch. Ten different services can sign the same message stream over a month, and each verifies against its own published key, independently. For the full relationship between the three protocols, see SPF, DKIM and DMARC explained.
What a DKIM DNS record actually looks like
A published DKIM key is a TXT (or sometimes CNAME) record. A typical raw key record reads like this:
google._domainkey.yourdomain.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
The p= tag holds the public key. The receiver combines it with the private key signature attached to the message to confirm the mail was not altered and really came from an authorized signer for that domain.
The one hard rule: never two keys under the same selector
There is exactly one way to break multiple DKIM records, and it is this: publishing two different public keys under the same selector name. DNS will happily return both TXT strings, the receiver cannot tell which is authoritative, and verification becomes unreliable. One selector maps to exactly one key.
In practice you almost never hit this by accident, because providers use distinct selector names. You hit it when you rotate a key and paste the new value into the existing record instead of using a fresh selector, or when two internal teams both pick default as their selector. Keep selectors unique per key and per service and the problem disappears.
Selector conventions by provider
Most services either tell you the exact selector to publish or hand you CNAME records that point back to their infrastructure. Here is what the common senders use.
Google Workspace
Google uses a selector you choose during setup, and the default it suggests is google. So your record lives at google._domainkey.yourdomain.com. Google publishes the key value for you to paste as a TXT record in the admin console under Apps, Google Workspace, Gmail, Authenticate email. You can pick a different selector name if you run more than one Google-signed stream, but google is the standard.
SendGrid
SendGrid uses two rotating CNAME selectors, typically s1._domainkey and s2._domainkey, which point at SendGrid-hosted keys (for example s1.domainkey.uXXXXXX.wlYYY.sendgrid.net). Because they are CNAMEs, SendGrid controls the underlying key and can rotate it without you touching DNS again. You publish both.
Mailchimp
Mailchimp uses the selector k1 (published as k1._domainkey.yourdomain.com as a CNAME to dkim.mcsv.net). Some legacy setups reference k2 and k3 as rotation slots. Mailchimp gives you the exact CNAME target in its domain authentication screen.
Microsoft 365
Microsoft 365 publishes two CNAME selectors, selector1._domainkey and selector2._domainkey, pointing at selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com and the selector2 equivalent. The two-selector design exists specifically so Microsoft can rotate between them. If you send through 365, also read DMARC for Microsoft 365.
Amazon SES
SES uses three CNAME records with long token-based selector names it generates for you (Easy DKIM), each pointing at dkim.amazonses.com. You do not choose these names, you copy them exactly.
Postmark, Mailgun and others
Postmark commonly uses a selector like 20YYMMDD (a date-stamped selector) or pm._domainkey. Mailgun uses selectors such as mx._domainkey or a k1 variant per sending domain. When a provider gives you a specific host and target, treat those strings as literal. Do not normalize or "tidy" them.
The practical takeaway: you will end up with several _domainkey records side by side, one family per vendor, and that is exactly how it is supposed to look.
Per-service key rotation without downtime
Rotation is where multiple selectors earn their keep. Because each service owns its own selector, you can rotate one vendor's key without touching any other stream. The safe pattern is to publish a new selector, let the provider start signing with it, confirm mail verifies, then retire the old selector once no in-flight mail still references it.
This is why providers like SendGrid, Microsoft 365 and SES ship two or three selectors from day one. They pre-stage the next key so rotation is a switch, not a scramble. For a full cadence and the reasoning behind key lifetimes, see the DKIM key rotation schedule.
CNAME-based providers make this even easier. Because the record on your side points at a host they control, they rotate the actual key on their end and your DNS never changes. That is the main reason so many services moved from raw TXT keys to delegated CNAMEs.
Verifying every stream signs correctly
Publishing the records is half the job. The other half is confirming each stream actually signs and that the signature aligns with your domain for DMARC. Send a real message through each provider and inspect the Authentication-Results header. You want to see dkim=pass with a d= value that matches your domain, not the provider's shared domain. If the d= shows the vendor's domain instead of yours, the signature will pass DKIM but fail DMARC alignment, which defeats the purpose.
To read those headers yourself, use the authentication results header guide. If DKIM passes but DMARC still fails, the culprit is almost always alignment, covered in fixing DKIM alignment.
A DMARC record ties it all together by telling receivers what to do when a stream is not authenticated:
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com
With every vendor signing under its own selector and aligned to your domain, you can move DMARC to p=reject with confidence that legitimate mail from all of them keeps flowing.
Frequently asked questions
Can I have multiple DKIM records on the same domain?
Yes. DKIM is designed for it. Each record lives under a unique selector at selector._domainkey.yourdomain.com, so you can publish one key per sending service with no conflict. The only rule is that two different keys must never share the same selector name.
How does a receiver know which DKIM key to use?
The email's DKIM-Signature header carries the domain (d=) and selector (s=) it was signed with. The receiver builds the DNS lookup from those two values and fetches exactly that one public key, so there is never ambiguity even with a dozen selectors published.
What are the DKIM selectors for Google, SendGrid and Mailchimp?
Google Workspace defaults to the selector google. SendGrid uses s1 and s2 as CNAMEs. Mailchimp uses k1 (with k2/k3 seen in some setups) as a CNAME to dkim.mcsv.net. Always copy the exact host your provider shows you rather than assuming.
Do multiple DKIM keys slow down email delivery?
No. A receiver only fetches the single key named in the signature it is verifying, not all of them. Publishing ten selectors adds ten DNS records but costs nothing at verification time, unlike SPF where every additional sender counts against the 10-lookup limit.