Do I need a DKIM record for every subdomain?

Only for subdomains that actually send email. A subdomain that never sends mail needs no DKIM key. Where you do send, give each sending subdomain its own selector so it authenticates and rotates independently.

What key length should I use?

At least 2048-bit RSA. It meets RFC 8301 guidance and the major mailbox providers' bulk-sender rules, while 1024-bit is now considered weak. Only adopt Ed25519 in addition to — not instead of — an RSA key, because receiver support is still uneven.

Can I test DKIM without sending real email?

Yes. A DKIM lookup tool fetches the public key for a given selector and domain and confirms it is well-formed, so you can validate a new record before any mail goes out. To confirm signing end to end, send a message to a seed address and inspect its headers.

How does DKIM interact with DMARC?

DKIM is one of the two ways a message can satisfy DMARC (SPF is the other). DMARC also requires alignment — the DKIM signing domain must match your visible From: domain. A message can carry a valid DKIM signature and still fail DMARC if the domains don't align, which is why per-service selectors that sign as your own domain matter.

How often should I rotate DKIM keys?

At least once every 12 months, and immediately after any suspected compromise. Rotating under a new selector, then retiring the old one after traffic moves over, keeps rotation completely downtime-free.

How to manage multiple DKIM records for your domain

Most organizations don't send email from a single system. Marketing goes out through one platform, invoices through another, and day-to-day mail through Microsoft 365 or Google Workspace. Each of those services signs with its own DKIM key, which means your domain ends up publishing several DKIM records at once. Managed well, that is a strength — each stream authenticates independently. Managed badly, it becomes the most common reason DMARC quietly fails for one sender while everything else looks fine.

This guide covers how DKIM selectors let one domain run many keys, how to keep them organized, how to rotate them safely, and how to catch a broken record before it costs you deliverability.

Why one domain needs more than one DKIM key

DKIM signs each message with a private key and publishes the matching public key in DNS. The receiving server fetches that public key and verifies the signature. The trick that makes multiple keys possible is the selector — a label in the DNS path at ._domainkey.yourdomain.com. Because each key lives under its own selector, a single domain can publish as many keys as it has sending services.

Giving every service its own selector and key buys you three things:

Isolation. A leaked or misconfigured key for one platform never touches the others.
Independent rotation. You can replace one service's key without coordinating a company-wide change.
Clear diagnosis. When a stream fails authentication, the selector tells you exactly which service is at fault.

Trying to share one key across every sender is the opposite: fragile, hard to rotate, and impossible to attribute when something breaks.

Give every service a unique selector

The selector is the nickname for a key, and picking good ones pays off later. Use names that identify the service — google, m365, mktg2026, billing — rather than opaque strings. When a DMARC report shows a failure for selector mktg2026, you know instantly it is the marketing platform, not your mail server.

Some providers manage the key for you through a CNAME record instead of a raw TXT record. Microsoft 365, for instance, has you publish two CNAMEs (selector1._domainkey and selector2._domainkey) that point into Microsoft's infrastructure so it can rotate the underlying key without you editing DNS. Either way, the selector is what keeps each service's key separate.

Checklist of details to document for each DKIM key: selector, service, key length, dates, rotation schedule, and DNS change log.

Keep this as a living document to speed up troubleshooting and onboarding.

Document every key

The single highest-value habit is keeping a living inventory. For each DKIM record, record:

The selector and the service it belongs to.
The key length (aim for 2048-bit RSA — more on that below).
The creation date and the planned rotation date.
A change-log entry for every DNS edit, with who made it and when.

This is what turns a 2 a.m. deliverability incident into a five-minute fix. Without it, nobody remembers which of six selectors belongs to the platform that just started failing.

Use the right key length

Publish 2048-bit RSA keys. RFC 8301 says signers should use RSA keys of at least 2048 bits and must use at least 1024; verifiers reject anything below 1024 outright. A 2048-bit key also satisfies the Gmail, Yahoo, and Microsoft bulk-sender rules. Ed25519 keys (RFC 8463) are defined but not universally supported, so if you adopt one, publish an RSA key alongside it rather than relying on Ed25519 alone.

Rotate keys on a schedule

Five-step DKIM key rotation workflow: schedule, generate a key pair, update DNS, switch the mail server, validate.

An automated rotation feature can run these steps without downtime.

Rotate each key at least once a year, and immediately if one is ever exposed. Because the selector is part of the DNS path, rotation is zero-downtime when you do it in this order:

Generate a fresh key pair under a new selector.
Publish the new public key in DNS and let it propagate.
Switch the sending service to sign with the new private key.
Verify that mail is signing and passing under the new selector.
Retire the old selector once no in-flight mail depends on it.

Never delete the old selector the moment you switch — messages already in transit still reference it. Wait until traffic has fully moved over.

Coordinate across teams

DKIM touches more than one team, and unclear ownership is why keys expire unnoticed. Assign it explicitly: IT owns the DNS changes, security reviews key length and the rotation policy, and marketing confirms that any new selector is wired into the campaign platform. A shared ticket or change request for every DNS edit keeps all three in sync and leaves an audit trail.

Common issues with multiple DKIM records

DMARC fails for one sender but passes for others

This is the classic multi-key symptom: five streams pass and one fails. The failing selector points straight to the culprit. Check that the service is actually signing with the selector you published, that the public key in DNS matches the private key the service holds, and that the signing domain aligns with your From: domain — DKIM can pass technically yet fail DMARC on alignment.

A published key is truncated or malformed

2048-bit public keys are long, and pasting one into a DNS panel often splits or truncates the p= value. A truncated key fails verification silently. Re-copy the full value, watch for stray spaces or line breaks, and confirm the record with a DKIM lookup after saving.

An expired or removed key is still in use

If a service keeps signing with a selector whose DNS record was deleted, every message fails DKIM. This happens when a key is retired before the sender is switched. Restore the record or move the service to a current selector, then align your rotation order so the switch always follows publication.

A new ESP won't use your selector

Some platforms insist on their own selector or a dedicated subdomain. Work with the vendor to publish the CNAME or TXT record they require, and add it to your inventory so it rotates and gets monitored like every other key.

How Palisade simplifies multi-key DKIM

Palisade centralizes DKIM key generation, DNS publishing, rotation, and monitoring so you don't track selectors in a spreadsheet by hand. It watches DNS for missing or malformed records, flags a truncated key before it hits deliverability, and reports DKIM alignment alongside SPF and DMARC as a single health score. Start with a free Email Security Score to see every selector on your domain and where each one stands.