What the customer asked for
Every line here is the customer’s own answer. None of it has been checked against DNS — the checked facts are further down. The bare domain is the one thing this connection does not cover, and the row above says so rather than leaving it out.
Preflight snapshot
Taken from public DNS when the customer started, before they changed anything.
We record the nameservers, because a change there is exactly what this connection watches for. We don’t record what is in the customer’s mail records — only how many there are.
Check public DNS
A proposed capability. It reads public DNS — what any resolver on the internet can answer for this domain. That is not the customer’s provider account: we can’t see that from here, we can’t change anything in it, and this check doesn’t try to.
Mail baseline
The snapshot against the last check. This is a gate: if it doesn’t match, the connection stops here.
Finish the connection
The order is fixed: the domain has to resolve here before a certificate can be asked for, and the certificate has to exist before anything is promoted. Whether it could run the other way round is an open question in this study, not a capability — see the study landing page.
Certificate
Issuance runs as a job on the node. Its state is surfaced per hostname on the environment’s Hostnames tab.
Nothing here says how long a job takes.
Timeline
Newest first. Each entry carries where the fact came from, in the same four labels the customer sees.