Email Frequency Caps: Count Across Campaigns and Product Events

TL;DR

• Make the cap reflect the recipient’s real inbox across producers: define the cap’s scope (topic, sending identity, product group) and keep a small inventory of participating workflows versus separately governed ones.
• Choose clear counting mechanics and concurrency controls: decide when a slot is consumed (authorization, provider acceptance, or later reconciliation) and use atomic reservations to prevent race conditions.
• Validate the policy with real scenarios and measurable signals: test failed submissions, midnight boundaries and exemptions, and monitor which workflows frequently hit the cap to reveal needed redesigns.

Count the recipient's experience across producers

A frequency cap is useful only if it sees the communication the recipient actually receives across the workflows it covers. Three teams each obeying their own limit can still create excessive combined traffic.

Start by defining the scope: one topic, one sending identity, one product or a broader group of optional notifications. State whether the cap covers only campaigns or also relevant product events.

Keep a small producer inventory showing which workflows participate in the shared counter and which are governed by a separate reviewed policy. Revisit that inventory when a new campaign service or integration is introduced.

Do not imply a global limit when the implementation counts only one workflow. The user-facing promise and the counting boundary need to match.

Define what consumes a slot

Decide whether a slot is reserved when the application authorizes a message, consumed at provider acceptance or adjusted after a later outcome. Each choice has operational tradeoffs.

For an illustrative optional-message cap, reserving before dispatch can prevent concurrent workers from exceeding the limit. If submission definitively fails before acceptance, the application may release the reservation under a documented rule. An uncertain outcome needs reconciliation rather than an automatic refund of the slot.

Keep the decision independent of ambiguous engagement signals. A message that was not opened can still contribute to inbox fatigue.

Choose the window and explain its boundary

A calendar-day cap and a rolling-window cap behave differently. A recipient could receive messages just before and just after midnight under a calendar policy, while a rolling policy considers elapsed time across that boundary.

Use the policy that fits the product's promise and record the relevant timezone when calendar boundaries matter. Do not label the setting “per day” without defining what day means.

For a hypothetical limit of three optional messages, explain whether that is three in a local calendar day or any rolling 24-hour interval. The number is illustrative; the appropriate limit requires product and audience judgment.

Coordinate concurrent producers

Two campaigns can check the same remaining allowance at nearly the same time. If both read one available slot and then send, the cap can be exceeded despite each worker appearing to follow the rule.

Use an atomic reservation or equivalent concurrency mechanism appropriate to the datastore. The PostgreSQL transaction-isolation documentation provides context for why separate reads and writes require deliberate coordination.

Test the actual dispatch path across producers, not only the cap-calculation helper. A bypassing workflow can undermine the policy even when the helper itself is correct.

Decide what happens to capped work

A capped message can be deferred, aggregated or dropped according to its purpose. Do not put every item back into a queue indefinitely.

For an illustrative product tip, dropping the stale message may be reasonable. For a daily summary, aggregation into the next useful digest may fit. For a time-sensitive service workflow, the product may need a separately reviewed category rather than ordinary optional-message handling.

Record the outcome and reason. This lets support distinguish a deliberate cap decision from a delivery problem and prevents retries from accidentally evading the limit.

Related reading: Scheduled Email Delivery: Store the Time, Content and Cancellation State.

Keep exceptions from swallowing the policy

If some service messages are exempt, define the categories narrowly and control who can assign them. A marketing workflow should not become exempt merely because its owner considers the announcement important.

The SendDart consent-record guide helps frame the distinction between permission and communication policy. A frequency cap reduces volume; it does not create permission to send, and an exception to the cap does not erase an opt-out.

Keep preference eligibility, priority and frequency as separate decisions with an explainable order.

Handle multiple addresses and account relationships carefully

A person may have more than one address or belong to several workspaces. Decide whether the cap follows a person identity, a delivery destination or a specific account relationship.

Do not merge identities simply to enforce a broader limit. Shared mailboxes and separate people can make that assumption unsafe. Use the application's verified relationship model and be transparent about the scope the system can actually enforce.

For a multi-workspace product, the recipient may need controls that distinguish workspace notifications from general product campaigns. One unexplained global counter may not match that expectation.

Review the policy with real decision records

Test concurrent sends, a failed submission, an uncertain provider response, a midnight boundary, a retry and an explicitly exempt category. Verify that the final counts and reasons are consistent.

Monitor which workflows frequently hit the cap. That pattern may reveal redundant communication that should be redesigned rather than a reason to raise the limit automatically.

SendDart delivers the messages the application authorizes, while the application must coordinate the cross-workflow counting policy. A well-designed cap protects the recipient's experience because every covered producer follows the same clear rules and every exception remains visible.