Separating DKIM keys by mail stream can make rotation, incident containment and troubleshooting easier. It does not automatically create separate domain reputations or confine a key to a category of messages. Design around the authority each signer receives and the actual services that use it.
Define the streams operationally
List the applications and providers behind transactional messages, campaigns and employee mail. Include scheduled jobs and low-volume critical messages. For each route record the From domain, expected signing domain, selector, private-key custodian, DNS owner and business recovery requirements.
Use distinct selectors where the platforms support them. Under RFC 6376 §3.1, a selector identifies verification data under the signing domain, so different selectors can keep independently managed keys from colliding at one lookup name. Do not assume that renaming a selector creates a new private key or that a platform permits independently rotating every stream.
Decide whether domains also need separation
Selectors organize key lookup, not message purpose. A private key authorized under d=brand.example is not restricted by the selector label to invoices or campaigns. If finer authority boundaries are needed, consider supported signing subdomains together with access controls and explicit From-domain choices.
DMARC alignment must remain part of that design. A signature from a subdomain can align with a parent author domain under relaxed rules when the organizational-domain relationship qualifies. Strict alignment requires the exact domain under RFC 9989 §3.2.10.2. Organizational-domain discovery must follow RFC 9989 §4.10.2 rather than a naive last-two-label comparison.
Work through an isolation example
Illustrative design: transactional mail uses selector tx1, campaigns use mk1 and staff mail uses emp1, all with d=brand.example but distinct private keys. Revoking mk1 need not remove tx1's or emp1's public keys. However, an attacker holding the mk1 private key can still sign messages under brand.example; the name mk1 does not enforce a marketing-only permission.
This means separate selectors reduce some operational coupling while leaving shared-domain authority. Separate credentials, approved sender controls and possibly signing domains are needed for the stronger boundary. These are proposed controls, not a claim that every provider exposes them.
Plan rotation and failure recovery by stream
Give each stream an independent change window and test set. Transactional tests should include time-sensitive account messages; campaign tests should include template and unsubscribe processing; employee tests should exercise relevant outbound gateways. Ensure content-changing components act before the final intended signer.
For ordinary rotations, preserve necessary old verification material until the approved queue and expiry conditions are satisfied. For compromised keys, let containment requirements determine retirement rather than blindly retaining overlap. A shared private key defeats much of the benefit of separate selector names.
Measure the boundary you built
Keep a route-to-key register and dated received-message evidence. Test whether rotating one stream affects another, but do not claim that this happened unless you actually ran the test. Review provider offboarding for both selector records and account permissions.
Success is an explainable set of independent custodians, changes and recovery paths. Reputation and inbox placement require their own evidence; a DKIM selector architecture cannot promise either.
Check a concrete isolation model
A synthetic register assigns tx1/key-T to the application team, mk1/key-M to the campaign provider and emp1/key-E to mail operations. All sign as brand.example. In this illustrative inventory model, removing mk1 leaves tx1 and emp1 in the retained set. This review did not execute a real rotation or inspect private keys. It does not prove private keys differ in a real tenant or that those routes still send. If all selectors instead used the same private key, this inventory-level separation would not provide independent key-material containment.
Timely receipt is not evidence of DKIM key isolation. Validate key custody, supported rotation controls and received-message results for each actual stream before treating the design as tested.
Evidence needed for the next decision
Before approving the example, ask whether tx1, mk1 and emp1 have distinct public verification material, separately controlled signing access and independent rotation support. Public fingerprints can compare material but cannot prove that a provider has isolated private custody or credentials. If administration is shared, document that remaining common failure path rather than calling the streams fully isolated.