A tenant can contain several brands, acquired domains and staff addresses without signing all of them in the same way. DKIM works with the signing domain carried in each message, not with a tenant label in an administration portal. Establish which identities the service supports, then prove the result for every domain that matters.
This guide describes a provider-neutral verification workflow. It does not assert that a particular product or subscription supports custom-domain signing. Obtain current instructions for the actual service and route before publishing records or changing its configuration.
Build a domain and route inventory
Record the visible From domain, business owner, tenant, sending application, expected DKIM d domain, selector, DNS owner and signing state. Include webmail, authenticated SMTP, application APIs, delegated accounts and any gateway route actually used. A successful employee-mail test does not establish how an invoice application signs.
Separate a verified domain in the tenant from a domain configured for outbound signing. Also separate the DNS record being present from the sender actively using its corresponding private key. These are distinct states, and neither an ownership check nor a published key proves that a received message has a valid signature.
Map the identities in received mail
For each route, send a controlled message to an external mailbox you can inspect. Preserve its raw form and the receiver's trusted Authentication-Results. Read d and s from each DKIM-Signature. RFC 6376 defines the lookup name as the selector under _domainkey of the signing domain. A signature with d=brand.example and s=tenant1 therefore points to tenant1._domainkey.brand.example.
Evaluate signature verification and DMARC alignment separately. The domain in d is the relevant DKIM identity for DMARC. Strict alignment requires an exact domain match; relaxed alignment compares organizational domains under the applicable discovery rules. Having both domains in the same commercial tenant does not make unrelated domains align. RFC 9989 sections 3.2.10 and 4.4 explain that distinction.
Work through a two-brand example
Illustrative inventory: a tenant sends employee mail from brand.example using d=brand.example and campaign mail from second.example using d=provider.example. Assume both signatures pass. The first is an exact DKIM alignment match. The second does not provide aligned DKIM for second.example merely because the same tenant owns both workflows.
Add a separate result for SPF rather than declaring the second message a DMARC failure without checking it. With an applicable policy and no unresolved evaluation error, a passing, aligned SPF identity can still satisfy DMARC for the message. However, RFC 9989 sections 7.4 and 8 require a domain publishing p=reject not to rely solely on SPF for its DMARC pass and to apply valid DKIM signatures. Treat the missing aligned-DKIM path as a deployment gap for that policy, not a complete reject-policy design. The example demonstrates a missing DKIM path, not a complete receiver verdict. These are synthetic identities and assumed results, not tests of a real provider.
Configure only supported signing identities
Ask the provider how to enable each domain, whether aliases follow the primary domain's configuration, and whether SMTP and API routes behave differently. Follow its exact TXT or CNAME instructions. With a CNAME model, follow the delegation to the provider-managed verification data; do not substitute a guessed public key or copy another tenant's target.
Use separate selectors where the service requires them and maintain an ownership record. Reusing a selector label across different domains is not inherently a collision because the full DNS names differ. RFC 6376 section 3.6.2.2 requires the key TXT record to be unique for a selector name; multiple TXT records at that lookup name have undefined results. Do not publish competing keys there.
Close the inventory with evidence
Mark each row verified only when it has a dated received-message sample, expected identity, observed signature result and alignment assessment. Record any unsupported route as a limitation with an owner and alternative, rather than hiding it behind the tenant's enabled status.
Re-test after adding a domain, changing a routing rule or migrating a brand. Include delegated records in offboarding so that signing authority and provider dependencies do not outlive their purpose. The useful outcome is an explainable domain-to-signing map, not a screenshot of a global toggle.
Complete one evidence row per route
- Expected: business owner, From domain, application route, signing domain and selector.
- Published: exact selector DNS name, record type and delegated target if used.
- Observed: dated received message, each d=/s= pair and trusted verification result.
- Aligned: compare passing DKIM and SPF identities with From under the applicable policy.
- Decision: verified, unsupported or unresolved, with an owner and next test.
- Retirement: record when the route stops signing, queued-mail allowance and who removes obsolete delegation.