Email Infrastructure Digital Twin

What the model is built from

The analysis queries the public control plane for the domain: mail exchangers and their priorities, the SPF policy and its recursive dependency chain, discoverable DKIM selectors, the DMARC policy that applies to the domain, transport-security policy at MTA-STS and TLS-RPT, BIMI where present, and the authoritative nameservers that serve all of it.

Each record is then interpreted in context rather than reported in isolation. An SPF include that authorizes a marketing platform means something different when that platform has no corresponding DKIM selector and no traffic in DMARC reporting. The output describes the control plane as a system of dependencies, not as a list of TXT values.

• Everything queried is public DNS; no mailbox or account access is involved.
• Nameserver delegation is included because DNS hosting is itself a dependency.
• Records that are absent are reported as absent rather than silently skipped.

Where infrastructure weakness usually hides

The most common structural problems are not malformed records. They are accumulated authorizations that nobody owns, an SPF chain approaching the ten-lookup evaluation limit, a DMARC policy left at monitoring years after deployment, and mailbox and sending providers that changed without the DNS being cleaned up behind them.

Concentration risk is equally important and rarely measured. When mail routing, DNS hosting, transport-security policy and the sending platform all resolve to the same operator, a single vendor incident affects every layer at once. The model surfaces that concentration so it can be an accepted decision rather than an accident.

Find duplicate policy and unowned authorizations · Inventory the third-party senders a domain authorizes

Use it as a baseline, not a one-time report

The most useful application is comparative. Capture the model before a migration, a vendor change or an authentication rollout, then capture it again afterwards. Differences that would be invisible in a change ticket — a selector that stopped resolving, an include that quietly expanded, a policy that reverted — become obvious against a recorded baseline.

Public DNS also describes intent rather than behaviour. The model shows what a domain authorizes and publishes; it cannot show which authorized senders actually send, or how a specific receiver treated a specific message. Pair it with DMARC aggregate reporting and real message headers to close that gap.

Compare two DNS snapshots · Read the infrastructure audit guide

Example: a domain with an unmaintained sending surface

Known limits

• Only public DNS evidence is used; internal relays and private routing are outside the model.
• DKIM selector discovery is heuristic, so a domain can use selectors the analysis does not observe.
• Resolver caching and split-horizon DNS mean another vantage point can legitimately see different values.

Common questions