Account control · Commercial-tier · multi-tenant
User Packages define what each User on your installation can do. Hourly / daily / monthly send quotas, contact caps, segment + trigger + evergreen limits, automation-monthly caps, additional email headers, pre-assigned sending infrastructure, force-DKIM authentication. The reseller / agency surface that turns one Mumara installation into a multi-tenant platform. Lives under the broader Team & Users system.
Sending limits
Resource limits
Sending domain restrictions
Three things a Package controls
A Package is the contract between you (the operator) and a User. Three categories of control sit inside every package — what they can send, what they can hold, and what authentication they must use.
Hourly speed, daily limit, monthly quota. Hard ceilings on how much a User can send across any time window. Hit the quota and the platform pauses their sends until the window resets. Enter -1 for unlimited. The fundamental cost-discipline lever for resellers — the difference between a 50k/mo user and a 500k/mo user is one number in the package definition.
Maximum contacts (across all lists), sending domains, sending nodes, segments, triggers, evergreen campaigns, trigger-action monthly limit, automation limits. Caps every dimension a User could grow into. Useful for tiered offerings — Starter gets 10 segments, Pro gets 50, Enterprise gets unlimited. Limits enforce themselves at the create/import action.
Pre-assign specific Sending Nodes / Bounce Addresses / Sending Domains to the package so Users see only the infrastructure they're entitled to. Force DKIM / tracking / bounce domain authentication so Users can't send unauthenticated. Add custom email headers embedded into every send. Tenant isolation by design.
The 2-step wizard
Package creation is a 2-step wizard. Step 1 captures every numeric limit — send quotas, resource caps, automation limits, Commercial-ESP toggles. Step 2 captures the qualitative configuration — custom headers, pre-assigned assets, sender-info rules, force-authentication toggles. The two steps map cleanly to the two questions: how much, and how.
Step 1 — Package Details. Pick the package name and the User Role (the permission profile every User on this package inherits). Below that, three blocks of limit fields: Sending Limits (hourly / daily / monthly), Resource Limits (contacts / sending domains / sending nodes / segments / triggers / trigger-actions monthly / evergreen), Automation Limits (reset / monthly actions / per-automation actions). Each field accepts -1 as the 'unlimited' value. Commercial-ESP-licensed installations get four extra toggles here: limit suppressed domains, auto-stop campaigns at a bounce-rate threshold, Enable credits for credit-based billing, Allow overuse beyond limits via credits.
Step 2 — Additional Settings. Add custom Additional Headers that the platform embeds into every email sent by Users on this package (X-Campaign-Source, X-Tenant-ID, anything that helps downstream attribution). Toggle on the Assign Pre-built Assets section to pin specific Sending Nodes, Bounce Addresses, and Sending Domains to the package — Users on this package see only those assets. Set sender-info policies (use sending-node defaults dynamically, use list defaults dynamically, allow custom sender info). Cap maximum threads if you want this package to use less of the platform's parallel-send capacity than the default.
Finally, the Sending Domain Restrictions toggles — Require DKIM Authentication, Require Tracking Domain Authentication, Require Bounce Domain Authentication. When ON, Users on this package can't send broadcasts via unauthenticated sending domains, must use custom tracking domains, must use custom bounce domains. The compliance-by-default mode every reseller needs.
What's inside a Package
Packages cover six categories of control. Each one prevents a different failure mode in multi-tenant operations. Cap what you'd otherwise need to monitor manually — quotas, resources, automation, billing discipline, brand headers, infrastructure assignment.
Hourly speed · Daily limit · Monthly quota. Per-package caps that gate how much each User can send. Enter -1 for unlimited. Hard-enforced at the sending layer.
Maximum contacts · sending domains · sending nodes · segments · triggers · evergreen campaigns · trigger-action monthly limit. Caps every dimension a User could grow into.
Reset Automation Limit · Monthly Actions Limit · Maximum Actions in a Single Automation. Specific caps for Automation-addon workflows so one runaway automation can't consume the User's entire quota.
Limit suppressed domains · auto-stop campaigns at bounce-rate threshold · Enable credits · Allow overuse. Commercial-ESP licence only. The reseller billing-and-discipline layer.
Custom email headers embedded in every send for Users on this package — X-Campaign-Source, X-Tenant-ID, X-Cost-Centre. Useful for downstream tracking and per-package routing.
Pin specific Sending Nodes / Bounce Addresses / Sending Domains to the package. Users on this package see only these assets. Critical for tenant isolation and infrastructure-tier separation.
Assign Package · the User detail
When creating or editing a User, step 2 of the User wizard is the Package picker. Choose the Package; the User inherits every limit from it. For each limit, an Inherit toggle controls whether the User uses the package value or has a custom override. Useful for the standard package + occasional VIP-tier user pattern. Sending Domain Restrictions inherit similarly — toggle off to override per User, toggle on to inherit the package policy.
Every numeric limit on the User's detail has an Inherit/Override switch. Inherit (default) uses the package value. Override unlocks the input — set a custom value just for this User. Useful for VIP clients on the standard package or testing higher caps for one tenant without changing the package for everyone.
Sending Domain Restrictions (Force DKIM / tracking / bounce) propagate from package to User by default. Override per-User when a specific tenant needs a different policy — but you usually don't want this, since the package-level policy is what makes the reseller setup consistent.
When you pin Sending Nodes / Bounce Addresses / Sending Domains to a package, Users on that package see ONLY those assets in their dropdowns — they can't accidentally pick infrastructure from another tier. Critical for tier-based deliverability separation (Starter tier on shared nodes, Enterprise tier on dedicated).
Network-level controls (IP allowlist, 2FA enforcement) live on the User Role, not the Package — every User on a given role gets the same network policy. Pair packages (quota/resource discipline) with roles (permission + network policy) for the full control surface.
Three package tiers, three usage shapes
Example packages from the Mumara docs. Start with these shapes, adjust to your audience. -1 means unlimited.
New / low-volume tenants
For trial-tier clients and small marketing teams. Conservative caps that scale up gracefully when the tenant grows. Pair with the Starter User Role (limited permissions).
The "most clients" tier
For regular business users. Big enough quotas that growth doesn't hit caps prematurely; small enough that no single tenant monopolises throughput. Pair with the Professional User Role.
High-volume tenants
For the biggest clients. Every numeric limit set to -1 (unlimited). Pre-assigned dedicated sending nodes for deliverability isolation, custom additional headers for downstream attribution, IP allowlist on the user.
Inherit vs override
The platform is intentionally not a strict hierarchy — Packages define the default for every User assigned, but per-User overrides are first-class. Use overrides sparingly (the whole point of packages is consistency) but freely when a real exception arises.
Default behaviour: every User on a Package inherits every numeric limit. If the Professional package has Monthly Quota 250K, every Professional User has 250K. Change the package value to 300K and every Professional User immediately has 300K. No per-User adjustments needed for changes that apply across the tier.
Per-User override: when a single User needs a different value, toggle Override on that limit in the User's detail. The input unlocks; enter the custom value. The platform now uses that value for this User specifically, regardless of what the Package says. Other Users on the same Package stay on the package value. Override is per-limit-per-User, so you can override Monthly Quota for one VIP client without changing anything else about them.
The trade-off: heavy override usage defeats the point of packages. If half your Professional Users have custom Monthly Quotas, you don't really have a Professional Package — you have a fleet of individually-configured Users. Best practice: define Packages for the 80% case and reserve overrides for genuine exceptions. When the override volume gets high, split into a new Package instead.
The reseller surface, in numbers
Packages occupy a specific niche in the multi-tenant surface — they're the cost-and-resource layer that complements permission roles and audience segments. Each system controls a different dimension.
What unmanaged multi-tenancy costs
Running multi-tenant sending without a Package surface is operationally expensive in ways that compound. Each User becomes a snowflake; consistency collapses; one runaway tenant can torch the whole installation's reputation.
No quota tiers means setting hourly / daily / monthly limits one User at a time. Forty Users = forty configuration sessions. Packages collapse this to one configuration per tier, then assign-tier-to-User at User creation.
One User running a stale list at 15% bounce rate poisons your installation's reputation. The Commercial-ESP auto-stop toggle pauses runaway campaigns at the per-package bounce-rate threshold you set, isolating the damage to one tenant.
Without Force DKIM on the package, a new User can create a Sending Domain, skip DKIM setup, and start sending. The first ISP that sees unauthenticated traffic from your installation hits your sender reputation. Force DKIM on the package prevents this from being possible at all.
If every User sees every Sending Node and every Sending Domain, a careless tenant can accidentally send via another tenant's branded infrastructure. Pre-assigned assets in packages give each tier its own asset pool — visual isolation enforced at the dropdown level.
“We run 40+ agency clients on one Mumara installation. Three packages — Starter, Pro, Enterprise — cover every client. New client signup is now: pick the package, assign, done. The package handles every quota, every force-DKIM policy, every pre-assigned node. We haven't manually configured a User's limits in months.”
Verified review
Mumara customer
Common questions
Packages control LIMITS and RESOURCES — how much a User can send, how many contacts they can hold, what infrastructure is pre-assigned to them. Roles control PERMISSIONS — what actions a User can perform inside their account (create broadcasts, edit lists, view billing, etc.). Most reseller setups pair a Package and a Role to define a tier — e.g., the Pro tier is the combination of Pro Package (limits) and Pro User Role (permissions). Roles must be created before Packages so they're available in the package dropdown.
Packages themselves work on any Commercial-tier Mumara Campaigns installation — Personal/Professional plans don't have User Management at all. Within Packages, some features are Commercial-ESP-only: Limit suppressed domains, auto-stop campaigns at bounce-rate threshold, Enable credits, Allow overuse. These four toggles are gated behind a Commercial ESP licence. Core Package functionality (quotas, resource limits, force-authentication, pre-assigned assets) works on every multi-tenant installation.
Yes. Every numeric limit on the User detail has an Inherit/Override toggle. Inherit (default) uses the Package value. Override unlocks the input — set a custom value just for this User. Useful for the 'standard Package + occasional VIP client' pattern. Heavy override usage defeats the point of Packages — if a Package needs many overrides, that's usually a signal to define a new Package for that variant tier.
Unlimited. The platform treats -1 as the sentinel value for 'no cap on this dimension'. Use -1 freely on Enterprise-tier Packages where you don't want to enforce a numeric ceiling. Empty fields default to the platform-wide value (often 0 or the installation default); -1 explicitly disables the cap. The difference matters when Users hit zero limits unexpectedly.
Only if it has no Users assigned. The platform blocks deletion when Users are still on the Package — reassign them to a different Package first, then delete. This is a deliberate guardrail; cascading delete would silently orphan every User on the deleted Package, breaking their quota enforcement until you manually reconfigured them. Reassign-then-delete keeps every User in a defined state.
Custom email headers (X-Tenant-ID, X-Campaign-Source, X-Cost-Centre) embedded into every email sent by Users on this Package. Useful for downstream tracking pipelines that consume your installation's outbound mail — you can identify which package (and by extension which tier/client) a given message came from without parsing the email content. Headers are arbitrary; the platform doesn't restrict the names except no spaces or special characters except hyphens.
When you toggle on Assign Pre-built Assets in step 2 of the Package wizard, three subsections appear: Sending Nodes, Bounce Addresses, Sending Domains. Each one shows a selectable list of every asset of that type on the installation. Check the ones this Package should expose. Users on this Package will see ONLY those assets in their dropdowns when creating broadcasts, configuring sender info, etc. Useful for tier-based infrastructure separation — Starter tier on shared nodes, Enterprise tier on dedicated.
Commercial-ESP-only feature. When enabled on a Package, every running campaign for Users on this Package is monitored against the bounce-rate threshold you set (typically 5-10%). If a campaign's live bounce rate crosses the threshold mid-send, the platform automatically pauses the campaign. The User must then investigate the list quality (probably stale contacts) before resuming. Critical for protecting the installation's sender reputation when one tenant's hygiene slips.
Quotas are NUMERIC — how many emails per hour / day / month a User can send. Sending Domain Restrictions are POLICY — whether a User MUST use authenticated sending domains, custom tracking domains, custom bounce domains. They're orthogonal: a User can have unlimited quotas and zero authentication requirements (unusual), or strict quotas and full authentication requirements (typical Enterprise tier).
Packages have three Automation Limits: Reset Automation Limit (cap on how many times an automation can reset/re-trigger), Monthly Actions Limit (total automation actions per month across all Users on this Package), and Maximum Actions in a single Automation (cap per automation workflow). These ensure one runaway automation can't consume the User's entire monthly quota. Pair with the [Automations addon](/campaigns/addons/automations/) for the full workflow surface.
Related
The parent surface — Administrators, Users, Roles, packages, IP allowlists, authentication logs. Packages live within this broader multi-tenant control system.
Read moreAdmins create and assign Packages. Per-admin permissions in the role builder control who can create Packages vs only assign them.
Read morePackage quotas (hourly/daily/monthly) are enforced at the sending layer. The throughput infrastructure that respects every tier's caps.
Read morePre-assign specific nodes to a Package to expose only those nodes to Users on that tier. The tier-based infrastructure separation surface.
Read morePre-assign domains and Force DKIM / tracking / bounce on the Package. Every User on the tier gets the same authentication discipline.
Read moreEvery Package edit, every limit override, every assignment shows up in the audit log — filterable by package, by admin, by date.
Read morePair Packages with the White Labeling addon to brand the entire User surface — Users on the Pro tier see your brand, not Mumara's. Addon.
Read moreSet a User Credit Markup % on AI Settings. You pay Mumara the flat AI rate, charge your Users on this Package the marked-up rate. Margin you control.
Read moreMumara Campaigns · User Packages
User Packages ship with Commercial-tier and above on Mumara Campaigns — Self-Hosted and Mumara Machine. Sending quotas, resource limits, pre-assigned assets, force-authentication, additional headers, Commercial-ESP credit/overuse/bounce-rate features. The multi-tenant operator surface.
