A group-wide email policy can describe the desired outcome while each subsidiary controls a different part of the implementation. One team may own registration, another may run DNS and a local vendor may sign application mail. Effective coordination starts by mapping those authorities and collecting comparable evidence, not by assuming headquarters can change every domain.
Build a domain and service map
For each subsidiary, identify the legal or business entity, domain, authoritative DNS operator, registrar contact, local business owner and incident contact. Connect each sending service to its account, purpose, criticality, From domain, envelope domain, DKIM domain, selector and last authorized test. Store exact names rather than relying on abbreviations that can be confused across similarly named companies.
DNS delegation divides administrative responsibility at zone boundaries. A centrally held parent domain does not mean every child zone is operated by the central team. RFC 1034 describes zones and delegation; use actual authoritative records and access records to determine your implementation. DNS concepts. Registration, DNS operation and service approval should be separate inventory fields.
Establish a common evidence contract
Ask every local team for the same minimum proof: current configuration, an authorized representative message, trusted receiver authentication results, the approval reference and the person accountable for the service. Record the observation time and route. Do not average away a missing subsidiary by reporting a group-wide success rate over only the domains that responded.
DMARC policy discovery and identifier alignment follow protocol rules, not corporate ownership diagrams. Distinct registered domains do not share policy merely because the same parent company owns them. Subdomain behavior must be assessed under the applicable policy-discovery rules and records. RFC 9989. Document the exact effective policy for each tested identity instead of copying a headquarters conclusion.
Keep two subsidiaries’ evidence separate
Suppose subsidiary A has a current authorized test for its billing route and subsidiary B supplies a copied A sample because both use the same provider. B’s business and DNS owners are named, but its actual customer account, identities and route remain unverified. The shared provider label does not make A’s message evidence apply to B.
Report one of two subsidiaries with a current billing-route sample, not group-wide verified coverage. Ask B’s authorized operator for its own configuration and representative message evidence. If B cannot produce it during the current window, retain a named evidence gap rather than counting missing data as failure or success. These are hypothetical report decisions, not real subsidiaries, signatures or ownership determinations.
Coordinate changes at the right boundary
Use one change record for the group objective and scoped local changes for each independently operated zone or service. Record approvers, deployment windows, recovery plans and verification owners. A supplier's ability to publish a record is not proof it has permission to choose your enforcement policy. Keep emergency contacts current and define how the central team receives evidence after an urgent local change.
Report progress by domain and critical service, with explicit exceptions and deadlines. Maintain a central view that preserves local ownership rather than replacing it with a shared mailbox no one watches. Review acquisitions, divestitures, supplier changes and service migrations as authority changes. Completion means each in-scope subsidiary has an evidence-backed state and a responsible operator, not merely a consistent-looking policy document.
Report missing coverage without hiding it
State the in-scope domains and critical workflows, the subset with current evidence and the specific gaps. A local owner’s name is not a substitute for the test artifact. Assign each gap to the operator who can actually collect or correct it.