The email sending governance layer: a new category of tool
Jean RubensUpdated August 202613 min read
An email sending governance layer sits on top of your sending tool and decides who can send, to which list, and how often. The category exists because no sending tool answers those three questions: their permissions are set per feature, never per list. This guide defines the category, documents the gaps it fills at Brevo and Mailchimp, and gives you the questions to ask when evaluating one.
The problem always arrives in the same order. An organisation grows, several teams start sending from one account, and nobody can say any more who wrote to whom last week.
Sending tools weren't built for that. They were built so a marketing team could send campaigns, not to arbitrate between five teams sharing one contact base. That mismatch is what produced a distinct category of tool.
Key takeaways
- The definition: the set of rules that decide who can send, to which list, and how often, on a shared sending account.
- ESP permissions are per feature, not per record. You open or close "Campaigns", never "the donor list".
- The gap is shared: neither Brevo nor Mailchimp scopes by list, caps cross-team frequency outside a high tier, or holds a send for approval.
- 43% of people unsubscribe first because the sender emails them too often (ZeroBounce, 2026).
- It isn't an ESP replacement. Your contacts stay in the sending tool, and there's no migration.
What is email sending governance?
Email sending governance is the set of rules that decide who can send, to which list, and how often, on a shared sending account. Mailchimp offers 5 user levels and not one of them can be restricted to an audience (Mailchimp, Manage User Levels in Your Account). A governance layer applies those rules on top of the sending tool, rather than in place of it.
Three questions define it, and all three are questions about access:
Who can send, and to which list?
Not "who is allowed to build a campaign", which is a question about a feature, but "which addresses can this person reach", which is a question about data.
How many times is one contact emailed?
The total per person, across every team. Each team knows its own sends; almost none knows the sum.
Who checks before it leaves?
And above all: what record of that check survives once the campaign has gone out?
The distinction between a permission and a governance rule is the heart of the subject. A permission is a switch on a feature: this person can create campaigns, or can't. A governance rule is a constraint on data: this person can reach these addresses, and no others.
Every sending tool does the first. None does the second.
Why call it a new category?
Because the need doesn't fit any existing box. In 2026, ZeroBounce's annual survey found that 43% of people unsubscribe first because the sender emails them too often, across 1,091 respondents (ZeroBounce, Email statistics report). No category of tool watches that total.
Look at the landscape tool by tool. The sending tool ships and measures. The CRM stores and qualifies. Deliverability tooling authenticates the domain and monitors reputation. None of the three answers "who can write to this list, and how many times".
The gap isn't an oversight, it's a consequence of history. These tools were designed for a single sender. One account shared between autonomous teams is a recent configuration at scale: charity networks, federations, franchises, multi-brand groups.
Most tool categories define themselves by what they add. This one defines itself first by what the vendors don't do, and document themselves. That makes it checkable page by page, which keeps the argument short.
We went through both major ESPs against their own documentation. The next section is the tally, without interpretation.
For the per-tool framing, see our two pillar guides: Brevo governance for multiple teams and Mailchimp governance for teams.
The three gaps every sending tool shares
The same hole shows up at both major players, and it's in their own documentation. The Brevo API enumerates 16 permission domains, from campaigns to SMTP keys, and none of them applies to a list (Brevo, Update permission for a user). Mailchimp's 5 levels cover the whole account, with no per-audience scope at any tier.
| The gap | At Brevo | At Mailchimp |
|---|---|---|
| Per-list or per-audience scope | Permissions per feature and per campaign folder, never per list | Absent at every tier: roles cover the whole account |
| Cross-team frequency cap | Enterprise plan only, and automations bypass it | No per-contact cap at all |
| Approval before sending | No approval circuit for email campaigns | Co-editing and comments, but no barrier |
| Programmable audit of rights | 16 permission domains in the API, none of them billing | A contact's signup source is absent from the export |
Tally taken from both vendors' help pages and API references, retrieved 2026-08-03. Each line is covered in depth in its own article on this blog.
The fourth line deserves a word, because it governs all the others. A right no API exposes cannot be inventoried, revoked in bulk, or monitored. It gets checked by eye, one user at a time, which in practice means it doesn't get checked.
We documented each of these gaps separately: per-audience scope on Mailchimp, Brevo permissions against a send to the whole base, the Mailchimp frequency cap, and approval before sending.
How does one uncontrolled send penalise everybody?
Through a chain that reaches the inbox of every other team. In 2026, ZeroBounce measured that 43% of unsubscribes come down first to over-frequent sending (ZeroBounce, Email statistics report). On a shared account, that frequency is a sum nobody calculates.
The link that surprises people is the third. Sender reputation doesn't attach to the team at fault, it attaches to the account and the domain. Suped puts it this way for shared address pools: "if the pool includes enough poor traffic, the IP reputation drops".
Which leads somewhere unwelcome: deliverability isn't an isolated technical problem, it's a consequence of governance. You can configure SPF, DKIM and DMARC perfectly and still watch your rates fall because of a send another team made without telling anyone. We cover that mechanism in our guide to deliverability on a shared account.
What a governance layer isn't
Four confusions come up repeatedly, and clearing them helps you decide whether the category concerns you at all. None of these four answers the three questions in the definition, even when it covers part of one.
It isn't a replacement sending tool
Your contacts, your statistics and your reputation stay in Brevo or Mailchimp. A layer that required a migration wouldn't be a layer, it would be a change of tool.
It isn't a CRM
It doesn't qualify contacts or track deals. It decides access to lists, which is an administration question, not a customer-relationship one.
It isn't deliverability tooling
It doesn't authenticate your domain or test inbox placement. It acts upstream, on the cause: the volume and the targeting of your sends.
It isn't just a review tool
A comment thread bounds nothing. The difference between commenting and governing is that a rule applies whether or not a person is available.
The fourth distinction is the one that fools most teams. They believe the problem is solved because they review each other's work, when all they've added is a fragile habit on top of an account that stays wide open.
What is a governance layer made of?
Five parts, three of which are missing from every mainstream sending tool. The table below sets them against what Brevo and Mailchimp cover natively, per their respective documentation retrieved on 3 August 2026.
The last two rows are partly covered, and "partly" is the expensive word. Both vendors offer templates, which frames the form without framing the recipient. Both keep logs, but retention is a setting: at Brevo a retention rule caps out at 24 months and applies retroactively to what already exists.
Note that the first part is also the most structural. A per-list scope makes the other four far less urgent, because it shrinks what a mistake can reach. It's the only one of the five that protects you when nobody is watching.
Who needs one, and who doesn't?
The threshold isn't company size, it's a configuration: several teams sending from one account, or contacts shared between teams. Below that threshold the category is useless, and that's worth saying out loud.
You don't need one if a single person sends, if your team fits in one room and talks to each other, or if each team has its own account and its own base with no overlap. In those three cases your tool's native roles are enough, and adding a layer would only add a tool.
The need shows up as three concrete signs. You can't answer "how many emails has this contact had this month?" without going round the teams. Somebody who left still has access that nobody inventories. And a drop in deliverability can't be traced to any identifiable campaign.
In the shared accounts we look at, the first sign is nearly always the same, and it isn't an incident: it's a hesitation. Somebody asks who is allowed to email a given list, and three people give three different answers.
The second sign is a spreadsheet. The moment an organisation keeps the list of who may do what outside the tool, it's because the tool isn't keeping it.
Sub-accounts deserve their own mention, because they look like an answer. Splitting the data into separate accounts does isolate it, but it fragments administration and costs the Enterprise plan at Brevo. We compared the alternatives in our piece on Brevo sub-accounts being Enterprise-only.
How do you evaluate a governance layer?
By asking 5 questions that separate real control from a display. The fourth is the most discriminating: at Brevo a log retention rule caps out at 24 months and applies retroactively to existing logs (Brevo, Configure a custom retention period). An erasable record is no proof at all.
Does anything have to be migrated?
If the contacts have to move, it isn't a layer. The right answer is that the base stays where it is and the tool connects to it for reading and writing.
Does the scope apply at send time?
A list hidden in the interface isn't a list that's off limits. Ask what happens when somebody targets a list outside their scope: the send should be refused, not merely discouraged.
Is frequency counted across teams?
A per-campaign cap is worthless: the contact doesn't receive a campaign, they receive the sum. The counter that matters is per contact, across every team.
What record survives, and for how long?
Ask about the retention period and whether it can be changed. A record the first busy administrator can erase doesn't work as evidence.
What happens if you stop?
The question people forget. You should walk away with your sending account intact and your contacts in place, with no residual dependency.
The fifth question is the most revealing and the least asked. A tool that sits on top of yours has to be removable; if it isn't, it has quietly taken the sending tool's place.
On the regulatory side, these same questions overlap with obligations on access and traceability. We cover them in our GDPR guide for marketing teams and, on the collection side, in GDPR by design.
Sendgate is a governance layer, placed on the tool you already run.
Sendgate sits on top of your existing Brevo or Mailchimp account, with no migration: your contacts, statistics and sender reputation don't move. Each team composes in Sendgate with only the lists and senders assigned to them, per-contact frequency stays visible from one team to the next, and sends go through an approval step before they leave. Brevo and Mailchimp are both supported today.
Start free →Email sending governance · Not affiliated with the brands mentioned
What to take away
Email sending governance answers three questions no sending tool handles: who can send, to which list, and how often. The difference comes down to one word: ESP permissions apply to features, governance applies to data.
The gap is the same at both major players, and documented by them. Neither Brevo nor Mailchimp scopes by list. The frequency cap is Enterprise-only at one and absent at the other. Neither holds a send until a manager has signed off.
It's not a replacement sending tool, not a CRM, and not deliverability tooling. And if one person does all your sending, you don't need one. The threshold is several teams on one account, or contacts shared between them.
Frequently asked questions
What is email sending governance?
How is this different from my sending tool's permissions?
Do you have to leave Brevo or Mailchimp?
Does a team of three need one?
Why is frequency a governance question?
Sources
- ZeroBounce, Email statistics report 2026 (43% of unsubscribes tied to frequency, 1,091 respondents), retrieved 2026-08-03. zerobounce.net
- Suped, How do shared IP pools and sending domains impact sender reputation, retrieved 2026-08-03. suped.com
- Mailchimp, Manage User Levels in Your Account, retrieved 2026-08-03. mailchimp.com
- Mailchimp, Collaborate on Emails, retrieved 2026-08-03. mailchimp.com
- Mailchimp, View or Export Your Contacts, retrieved 2026-08-03. mailchimp.com
- Brevo, Update permission for a user (API reference, 16 functional domains), retrieved 2026-08-03. developers.brevo.com
- Brevo, Add users and assign permissions in Brevo, retrieved 2026-08-03. help.brevo.com
- Brevo, Configure a custom retention period for your transactional logs, retrieved 2026-08-03. help.brevo.com
Native coverage at both vendors verified on 3 August 2026 against their help pages and API references. Tiers and permissions change: re-check your own account's users page before any org decision. No figure from a gated report is cited here, because its contents can't be verified at the source.
Jean Rubens
Co-founder, Sendgate
Jean is a co-founder of Sendgate. He writes about email sending governance for teams: access compartmentalization, per-list scope and deliverability across shared sending accounts.