The dependency graph — Domain Trust Architecture

Some controls cannot be deployed until another is working. Drawing that graph once tells you what is available to you today and what is blocked behind something else.

The graph

reporting (rua, TLS-RPT)
   └── everything else, because every later decision
       is evidence-driven

SPF ─┐
DKIM ┴── DMARC ── enforcement ── BIMI
                       │
                       └── requires full enforcement,
                           pct absent or 100

DNSSEC ── DANE
   (TLSA records are only trustworthy under a
    validated chain, in the zone holding the MX hosts)

HTTPS + valid certificate ── MTA-STS
   (the policy is authenticated by the web PKI)

correct MX ── MTA-STS enforce
   (a policy listing the wrong hosts stops mail)

registrar account security ── everything
   (the account can replace the delegation and
    remove DNSSEC in one action)

Hard dependencies and soft ones

Dependency	Kind	What happens if you ignore it
DMARC enforcement before BIMI	Hard	BIMI does not work. The logo never renders and nothing says why.
DNSSEC before DANE	Hard	TLSA records cannot be trusted, so validating senders ignore them entirely.
HTTPS before MTA-STS	Hard	No policy can be served or authenticated.
Reporting before enforcement	Soft, and treat as hard	You can enforce blind. You will reject your own mail and not know which sender.
SPF and DKIM before DMARC	Soft	A DMARC record with nothing aligned fails everything. Technically deployable, operationally an outage.
Registrar security before anything	Soft, and it outranks everything	Every control below it can be removed by whoever holds the account.

Reading it as a plan

The graph answers two questions immediately. What can I do today? — anything with no unmet dependency, which is always reporting, registrar security and the free controls. Why can I not do X? — trace back until you find the unmet edge, and that is the actual piece of work.

A vendor proposing BIMI to a domain at p=none

It happens regularly, and it is the clearest test of whether somebody has read the graph. The domain cannot have BIMI until enforcement is reached, so the proposal is a proposal for a DMARC programme with a logo attached at the end — which may be a fine way to fund it, and should be described that way.

Knowledge check

An organisation wants DANE. Their MX points at a mail provider whose zone is unsigned. What is the actual piece of work?

There is none available to them — the TLSA records live under the provider’s hostnames, so signing is the provider’s decision rather than theirs.
Sign their own zone, then publish TLSA records under their domain.
Deploy MTA-STS first, then DANE will work.
Ask the provider to publish a CAA record.

Correct — There is none available to them — the TLSA records live under the provider’s hostnames, so signing is the provider’s decision rather than theirs. Tracing back the dependency finds an edge they do not control. The realistic options are MTA-STS instead, or changing provider — and naming that quickly is more useful than a project that cannot succeed.

Not this — Sign their own zone, then publish TLSA records under their domain. A sender looks for _25._tcp under the MX hostname it connects to. Records anywhere else are never queried.

Not this — Deploy MTA-STS first, then DANE will work. They are independent mechanisms. MTA-STS is the right answer here and it does not unblock DANE.

Not this — Ask the provider to publish a CAA record. CAA constrains certificate issuance and has no bearing on DANE.