MTA-STS tells sending mail servers to require a valid TLS connection and to refuse delivery rather than fall back if they cannot get one. Turning that on without evidence is a way to lose mail quietly, so the reporting channel went up first, on its own, and collected for eleven days before the policy existed.
- TLS reporting was published alone and deliberately left alone. It is the instrument that says whether enforcement would break anything, so it has to be collecting before there is a policy to enforce. Publishing both at once discards the safety net that makes the rollout survivable.
- The policy is live in testing mode. Conforming senders fetch it, evaluate it and report what they saw, but they never refuse a delivery on it. There is no path to losing mail until the mode changes, which is a separate decision at least two weeks out and is gated on what the reports say rather than on the date reached.
- The baseline reads 99 successful sessions and zero failures across eleven contiguous days, counted from the raw reports rather than taken from a summary line. Three limits are recorded beside it, because the number invites a stronger claim than it supports: one organisation is the only reporter, the volume is about nine sessions a day, and every report predates the policy, so it describes opportunistic encryption and not the policy itself.
- The verification script reported the new record as missing while it was live on three other resolvers. It had been asking whichever resolver the machine happened to use, which inside the window after publishing still answered that no such record existed. Three of twelve queries came back empty against it and none of twelve against a pinned resolver. The script now pins one and prints which it used, because a verifier that intermittently calls a correct record absent fails in the exact way it exists to detect.