Nobody plans to over-mail. It happens because a campaign, a lifecycle automation and a product announcement each look entirely reasonable in isolation, and no single system counts the total.
A frequency cap is the thing that counts the total.
What a cap needs to be useful
It must apply across every send path. A cap that governs campaigns but not automations is not a cap — it is a suggestion, and automation is usually where the volume actually comes from.
It must be class-aware. Capping transactional mail would delay password resets. Marketing is what needs limiting.
It must resolve deterministically when rules overlap. A brand-level cap and a topic-level cap that both apply need a defined winner, which is what priority is for. Without it, behaviour depends on creation order, which nobody can reason about.
The suppression must be visible. When a cap withholds a message, the per-recipient record should say so. Otherwise you are debugging a delivery gap that has no explanation.
Setting one
Start looser than you think and tighten with evidence. A common starting point is a handful of marketing messages per contact per week, narrowed for topics people subscribe to expecting less.
The signal to watch is complaint rate, not unsubscribe rate. Unsubscribes are a healthy outcome — the person is telling you something and using the mechanism you provided. Complaints are the failure mode.
The portfolio problem nobody solves
Here is the case almost no platform handles: the same person is a subscriber to three of your brands.
Each brand caps at, say, five messages a week and considers itself restrained. The recipient receives fifteen. From their side there is no such thing as your brand architecture — there is just an inbox, and you are in it constantly.
Handling that requires caps that can be evaluated at tenant level as well as per brand. It is a genuinely unusual capability, and it is the entire reason portfolio operators end up with fatigue problems they cannot diagnose from within any single brand’s numbers.