Every control has a boundary, and the boundary is where the next attack lives. Being able to state each one is what makes a posture assessment honest rather than a list of ticks.
Control by control
| Control | Leaves open |
|---|---|
SPF | Anything not using your domain as the envelope sender — which includes most spoofing, since the From header is what a reader sees. |
DKIM | Replay of a validly signed message, and anything sent by an authorised platform whose account is compromised. |
DMARC at reject | Lookalike domains, display-name spoofing, compromised mailboxes, compromised suppliers. Four of the five impersonation techniques. |
DNSSEC | Anything the zone owner publishes deliberately. It proves authenticity, never correctness. |
CAA | Issuance by a CA that does not check it, and issuance for names under a delegation you no longer control. |
MTA-STS | Senders that do not implement it, everything after the message is accepted, and your own outbound transport. |
DANE | The same, plus every receiver whose provider is unsigned. |
BIMI | Everything. It is a perception aid with no security property of its own. |
Registry lock | Compromise of your DNS provider, which is a different account entirely. |
Domain monitoring | Six of the seven impersonation techniques, because they involve no registration. |
Takedown | Everything that happened before it, and the next domain. |
The pattern
Read down the list and the same shape recurs: each control makes one kind of claim checkable, and an attacker moves to a claim nobody is checking. That is not a failure of the controls — it is what a working control does. The value is in how much it costs the attacker to move, and in whether you can see them when they do.
State these before anyone asks
A posture report that lists what is deployed invites the question “so are we safe?”. One that lists what each control leaves open answers it in advance, and it is the difference between a programme that is trusted after an incident and one that is blamed for it.