Map the decisions that mail systems actually make
A useful email dependency map connects a business sending service to the identities, DNS records and transport services it uses. A list of every TXT record is not enough. The map should let an owner answer what could break if a provider, hostname, key or policy changes, and identify the evidence needed before approving that change.
Keep outbound identity authentication and inbound transport policy as separate branches. They may share administrators and domains, but they do not protect the same decision. The map proposed here is an operational model that an organization must populate from its own authorized inventory and message evidence. It is not a claim that a DNS scan can discover every sender or determine all receiver behavior.
Start each outbound branch with a real sending route
Create one entry for each service and materially distinct route, including periodic billing, support systems and externally managed campaigns. Record its business owner, technical owner, visible Author Domain, envelope domain, sending infrastructure and observed DKIM signing domain and selector. Mark each value as observed, documented by the provider or still unknown. Do not turn a vendor's generic setup guide into evidence of this account's configuration.
The SPF branch begins with the evaluated identity and follows the policy terms actually relevant to that route. Include external policy references and the teams that control them. RFC 7208 sections 2.3 and 4.6.4 explain identity evaluation and DNS-dependent limits. A dependency map can show where external changes might affect evaluation, but a static count of nodes does not establish the result for every connecting address.
The DKIM branch begins with the signature's d and s values and leads to the selector's verification record. Add any alias target, target-zone owner and key-lifecycle owner. RFC 6376 section 3.6.2.1 defines this lookup namespace. Keep private keys out of the map; record secure operational ownership and reference an approved key-management system instead.
Connect authentication to the relevant DMARC decision
Add the Author Domain, applicable DMARC policy record and the evidence for how policy was discovered. Link passing authenticated identifiers to the alignment decision, with strict or relaxed mode identified. Under RFC 9989 section 4.4, a valid aligned SPF or DKIM identifier can satisfy DMARC; two unrelated authentication passes cannot establish alignment.
Record the specification and implementation context used for policy-discovery assessment. RFC 9989 describes a DNS tree walk, so an inherited spreadsheet assumption about discovery should be reviewed rather than silently carried forward. The map should retain uncertainty about receivers whose implementation has not been verified. Include reporting destinations and their ownership, but keep reporting availability separate from evidence that every legitimate sender has been observed.
Show the owner's requested policy and the receiver's observed handling in different fields. This makes it harder for a future reviewer to mistake a policy string for proof that a message was rejected, delivered or placed in an inbox.
Add the independent transport branch
For inbound mail, connect the recipient domain to its MX hosts and their address dependencies. If MTA-STS is deployed, add the discovery TXT record, HTTPS policy host, certificate maintenance owner, published mode, permitted MX names and policy lifetime. RFC 8461 sections 3 and 6 describe discovery and caching. Policy lifetime is not the same field as DNS TTL, and changing one does not directly rewrite the other.
Where DANE SMTP is deployed, map the DNSSEC chain, MX resolution, TLSA records and the corresponding TLS service. RFC 7672 section 2 makes authenticated DNS a central dependency. A TLSA record copied into inventory without its validation and certificate relationship is incomplete operational evidence.
Add TLS reporting as an observation channel, not as an enforcement mechanism. RFC 8460 section 3 defines reporting policy discovery. The reporting destination needs an owner and a review process, while the actual transport policy remains a distinct dependency.
Fictional worked example of a provider migration
The fictional organization Example Repairs plans to move invoice mail to a new vendor. Its proposed map links invoice service to billing.example.com as the Author Domain, a separate envelope domain and an old DKIM selector hosted through an alias. The migration owner notices that the retired provider still controls the alias target and that some queued messages may carry the old signature.
The review therefore proposes a staged signing change, verification of the replacement route and a separately approved retirement decision. Meanwhile, inbound MX and MTA-STS entries remain a different branch and are not automatically edited as part of an outbound vendor move. This example is invented; the identities, approvals and message results have not been obtained from a real account.
The benefit of the map is the question it exposes: what evidence permits retirement of that alias without breaking verification for legitimate messages? The map itself does not answer it. The service owner must supply queue and signing information, and the reviewer must connect those facts to the proposed change.
Maintain evidence and ownership with the map
Give each edge a last-verified date, evidence reference, owner and review trigger. Revisit it after a vendor migration, selector rotation, delegation change, transport-policy edit or unexplained authentication failure. Unknown owners and unverified edges should remain visible rather than being filled with guesses.
Before rollout, build the sender-by-sender readiness matrix, exact policy difference and approval record. After authorized execution, attach the relevant message and DNS observations. Those are the catalogue's required original artifacts and remain open here. This manuscript provides a map design and a fictional decision exercise, not a populated tenant inventory or verified rollout.