Multiple sending domains often share a mail platform while retaining different authentication histories and brand requirements. A successful BIMI deployment on one domain is a useful reference, not proof that copying its record will work elsewhere. Build a repeatable process that checks the actual identity used by each mail stream.
Inventory the visible sending identities
Start with the From domains recipients see in employee mail, marketing, transactional messages and support replies. Record subdomains separately when they are used as sending identities. Associate each with its mail systems, approved logo, certificate coverage, DNS administrator and hosting owner. Keep domain aliases and display names separate from the domain actually present in a message.
Provider workflows may impose domain-specific setup. Zoho's BIMI configuration guide instructs administrators to repeat configuration for each managed domain and separately configure sending subdomains. Treat this as Zoho's documented workflow rather than a universal description of every receiver's discovery behavior. For other deployments, verify the applicable discovery and receiver rules explicitly.
The core BIMI Internet-Draft revision 15, Appendix A.3 illustrates a different discovery detail: without a selector header, the receiver looks for default._bimi.foo.example.com and, if absent, default._bimi.example.com. Therefore, do not present Zoho's explicit per-subdomain setup workflow as a protocol-wide prohibition on fallback. This is an individual Internet-Draft, not an RFC; check the target implementation rather than assuming it follows every current draft provision.
Make the manifest the unit of release
For every domain, store the expected BIMI assertion, logo URL, evidence-document URL when required, intended certificate scope and asset digests. Templates should contain named placeholders that cannot silently retain the previous domain's values. Validate the completed configuration against the register before publishing anything.
Use a small first cohort containing both a straightforward identity and a representative complicated one. This exposes issues with different senders, delegated DNS or asset hosting before the entire portfolio changes. Preserve existing mail authentication and baseline observations so failures can be traced to the actual changed component.
Work through a copied-record error
A synthetic release has three domains: news.example, billing.example and help.example. News uses the campaign logo, while the other two use the corporate logo. A copied record makes billing.example refer to the campaign asset, and its certificate evidence covers only news.example. The manifest identifies two separate discrepancies: the wrong approved logo and unverified domain coverage.
The release should stop for that row while allowing independent reviewed rows to continue if the deployment process safely supports partial releases. Repair the inputs and rerun checks. Do not replace a specific mismatch with a blanket statement that every domain requires a separate purchased certificate; the issued coverage and issuer rules determine that question.
Verify traffic, not just DNS text
Collect authorised test messages from each sending system, preserving the From domain and authentication results. Observe selected receiving providers and clients, noting the exact surface and date. A domain used by both a marketing platform and a billing application may produce different outcomes if one path is not properly authenticated. A logo shown for one message does not validate every message using that domain.
Keep a release history per identity and maintain alerts for asset availability, certificate validity and ownership changes. BIMI Group's implementation guide warns that participating providers have their own display criteria, so report tested coverage without promising universal rendering. This article provides a planning and consistency example only. No domain records were changed and no real test messages were sent; public retrieval and receiver-specific evidence remain outstanding for any actual rollout.
Record both discovery policy and observed selection
For each identity, retain the policy or product instructions you are following, whether the message carries a selector header, the expected lookup owner and the actual receiver observation when available. The cited draft is an individual Internet-Draft published October 31, 2026, not an approved RFC or proof of implementation. Its fallback example must not silently replace a provider-specific setup requirement.
- From domain, sending platform and business workflow: pending.
- Applicable provider instructions and draft revision where relevant: pending.
- Intended selector, expected assertion owner and permitted fallback assumption: pending.
- Approved mark, certificate scope and public asset digests: pending.
- Pilot cohort, isolation boundary and failed-row disposition: pending.
- Receiver/client/date, observed outcome and remaining validation: pending.