Each control in this course rests on something earlier. Adopting them out of order produces work that cannot be completed and, in two cases, failures that stop mail.
The sequence
| # | Step | Because |
|---|---|---|
| 1 | SPF, DKIM, DMARC at p=none with rua | Nothing later is verifiable without the reports. |
| 2 | TLS-RPT | One TXT record, no failure mode, and it establishes a baseline before you change anything. |
| 3 | Forward-confirmed reverse DNS, HELO names, outbound TLS | Free, expected, and independent of everything else. |
| 4 | DMARC to enforcement | Evidence-driven. The prerequisite for the two that follow. |
| 5 | MTA-STS in testing, then enforce | TLS-RPT from step 2 is what tells you it is safe to enforce. |
| 6 | DANE, if the MX zone is signed | Independent of 5, and both can run together. |
| 7 | One-click unsubscribe and list hygiene, if you send bulk | Not dependent on the rest, and easy to defer past the point it matters. |
| 8 | BIMI | Requires 4 to be genuinely complete, and costs real money. |
The two orderings that matter
TLS-RPT before MTA-STS Otherwise "enforce" is a guess. The reports are the only evidence that senders can satisfy the policy. DMARC enforcement before BIMI Not a recommendation — a hard requirement. p=none disqualifies, and so does pct below 100.
The rest is preference. Steps 3 and 7 can happen at any point, and step 6 can precede step 5 where DNSSEC is already solid and no web server exists.
Where it is reasonable to stop
Most domains should complete steps 1 to 4 and then stop until something changes. That is the whole of the spoofing protection, and it is where the benefit is concentrated.
Steps 5 to 8 are for specific reasons
MTA-STS and DANE protect against an on-path attacker, which matters if your inbound mail is worth intercepting. BIMI is a brand investment with a trademark prerequisite. None of them reduce spoofing, and a programme that reaches for them before finishing step 4 has the order exactly backwards.