Skip to content
Mumara

Account control · multi-admin · multi-user

Administrators, users, roles, packages. Built for teams and resellers.

Multi-administrator accounts with granular role permissions. User accounts with package-based quota inheritance. IP allowlists. Force DKIM / tracking / bounce domains per user. Full authentication audit log. The platform underneath every marketing team and every reseller / agency.

  • Multi-admin with custom roles
  • User accounts with quota packages
  • 2FA + IP allowlist + audit log
  • Force DKIM / tracking / bounce per user
team hierarchy

Administrators · staff users

Sarah Lin

Super Administrator · 2FA on

Global

User roles · reusable permission profiles

Marketing

full broadcast

Read-only

audit access

Users · scoped tenants · Commercial+

acme-marketing Professional
beta-client Starter
enterprise-corp Enterprise
Force DKIM enforced audit · live

Multiple audiences. One platform.

Same account-control surface. Different setup, different scale.

Mumara's account-control surface serves distinct customer shapes. Marketing teams use the Administrators surface for internal access control — available on every plan. Resellers and agencies use the User Management surface (Commercial-tier and above) to operate isolated client accounts on shared infrastructure.

Internal team · every plan

Administrators (staff users)

Multi-admin accounts with custom roles — Marketing Lead, Compliance Officer, Deliverability Lead, Read-only Auditor, or anything you build. The role decides what an admin can do; the admin tier itself decides the data scope is global, so admins see across every record their permissions allow. 2FA enforceable per role. Authentication logs on every sign-in. Available on Personal, Professional, and above — for any team larger than one person.

  • Multi-admin with custom roles
  • Global data scope when permitted
  • 2FA enforceable per role
  • Authentication audit log

Reseller / Agency · Commercial+

User Management (tenant accounts)

User accounts with their own logins, package-based quota inheritance, hourly / daily / monthly send limits, contact limits, trigger-action limits. Force DKIM authentication, force custom tracking and bounce domains. IP allowlists per user. Users are hard-scoped to their own data — no admin-style global visibility — making them the right shape for client isolation. Commercial plan and above only.

  • User accounts with package-based quotas
  • Hard data isolation per tenant
  • Force DKIM / custom tracking / bounce domains
  • Per-user IP allowlist

Administrators · the inner circle

One account. Many admins. Each with their own role.

The Administrators page lists every admin on your account with their assigned role, last sign-in time, and 2FA status. Add new admins with name, email, password, and role assignment in one form. Pre-built roles cover the common shapes — Super Administrator, Marketing Lead, Compliance Officer, Deliverability Lead, Read-only Auditor — or build custom roles with the granular permissions tree.

  • Per-admin send quotas

    Each admin can have their own send-quota caps (hourly rate, daily limit, monthly limit, maximum threads, plus any the platform adds) — useful when one admin handles bulk and another handles transactional from the same installation.

  • 2FA status visible at a glance

    The Administrators list shows 2FA enabled / disabled per admin. Compliance teams use this to enforce 2FA across the org — and the audit log catches any sign-in attempts that bypass.

  • Authentication audit log

    Tools → Authentication Logs tracks every login event — admin name, IP, activity, details, timestamp. Useful for compliance reviews, security incident investigation, and 'who edited that broadcast last week.'

  • Roles are reusable

    Define a role once; assign it to as many admins as need it. When the role definition changes (added a permission, revoked one), every admin in that role inherits the change.

Mumara Administrator Details form — name, email address, password, role fields plus per-admin send-quota toggles for hourly rate, daily limit, monthly limit, and maximum threads

Custom roles · granular permissions

Pick the actions. Not the role.

Mumara's role builder is a tree of permissions across Contact Lists, Contacts, Campaigns, Settings, and every other section. Check the actions this role can perform — add list, edit broadcast, delete contacts, manage administrators, billing access — uncheck the rest. Search the permission tree for a specific action. Apply 'Check All' for a power-user role; uncheck for a read-only auditor. Save once; assign to as many admins as need it.

  • Hierarchical permission tree

    Parent nodes (Contact Lists, Contacts, Campaigns, Settings) expand to show every action inside. Mix-and-match — let the Marketing role manage broadcasts but not delete lists; let the Compliance role view contacts but not edit campaigns.

  • Searchable

    The role builder has a "Search permissions..." input. With hundreds of granular actions across the platform, searching beats scrolling.

  • "Check All" for power roles

    One click checks every permission for the role — useful when you want a Super-Admin-equivalent role with the convenience of a button.

  • Per-resource scoping (advanced)

    Beyond actions, custom roles can scope to specific lists, specific campaigns, or specific sending domains. The Marketing role might have full access to the 'Newsletter' list only, with no access to the 'Transactional' list. Useful for teams sharing infrastructure across brands.

Mumara Add Admin Role page — Role Name input, search permissions box, hierarchical checkbox tree for Contact Lists / Contacts / Campaigns / Settings sections

Users · the reseller surface

User accounts inherit packages. You stay in control of the limits.

Reseller and agency setups create Users beneath the admin level. Each User has their own login, IP allowlist, and a Package assigned — packages define hourly send rate, daily and monthly limits, trigger-action limits, suppressed-domains limits, and contact limits. Toggle Inherit per limit to use the package values, or override per-user. Plus Sending Domain Restrictions: force DKIM authentication, force custom tracking and bounce domains for users who shouldn't share the platform's defaults.

  • Package-based quota inheritance

    Define packages once at the admin level (e.g., 'Agency Standard' with 100k/month, 'Agency Pro' with 1M/month). Assign packages to users. Per-user toggle which limits inherit and which override.

  • IP allowlist per user

    Each user has an optional list of allowed IPs (newline-separated, supports ranges and CIDR). Login attempts from outside the allowlist are blocked. Critical for enterprise / regulated-industry deployments.

  • Force DKIM / tracking / bounce domains

    Force-toggles per user. Force DKIM Authentication ensures the user can't send with unauthenticated domains. Force Custom Tracking Domain ensures their tracking links use their own brand. Force Custom Bounce Domain ensures their bounce processing is isolated from the platform default.

  • Maximum threads cap (optional)

    When you want to cap a user's parallel-sending threads independently of the package default, the per-user toggle does it. Useful for high-volume users sharing infrastructure with smaller customers.

Mumara Add User step 2 (Package) — package picker, inheritance toggles for hourly/daily/monthly/triggers/contacts, Sending Domain Restrictions section with force DKIM / tracking / bounce toggles

The security pillars

Account control means several things at once.

Beyond roles and quotas, three security layers harden every Mumara account. Each fixes a specific failure mode.

Authentication Logs

Every login (and logout) is logged with admin/user, IP address, activity type, and timestamp. Tools → Authentication Logs. Indispensable when answering 'who signed in from where, when' — for compliance reviews, security investigations, and post-incident timelines.

Per-user send quotas

Hourly rate, daily limit, monthly limit, and contact limit per user. Inherited from packages or overridden per-user. The administrator caps the resource pool every user has access to — no user can monopolise the platform.

IP allowlists + 2FA

Each user has an optional IP allowlist (newline-separated, CIDR-aware). 2FA is enableable per role and per user. Together: an attacker needs the credentials, a TOTP code, AND to be on the allowlisted network. Defence in depth.

What unmanaged team access costs

The cost of one shared admin login.

Most teams start with one admin account. By month six they're sharing the password across five people. By month twelve there's no audit trail, no way to revoke access cleanly, and someone has accidentally deleted a list.

  • Shared logins kill the audit trail

    When five people log in as the same admin, the question 'who changed this' becomes unanswerable. Every action looks like the admin's action. Mumara's per-admin roles + audit log restore the answer at zero cost.

  • Offboarding is impossible without per-user accounts

    When the marketing intern leaves, you need to revoke their access — not change the shared password and email it to the remaining four. Per-user accounts make offboarding a one-click action with no ripple effect.

  • Reseller setups need quota walls or one client breaks everything

    If you're running clients on shared infrastructure without per-user quotas, one runaway send from one client can saturate the queue for everyone else. Package-based quota inheritance prevents the noisy-neighbour problem at the platform layer.

  • Compliance teams need granularity, not binary admin access

    Your Compliance Officer needs to read contact data and review audit logs — but not edit broadcasts or manage billing. The two-role model (admin or not admin) doesn't fit; the granular permissions tree does.

“As an agency we manage 40+ client accounts on Mumara. The package-based quota inheritance and Force DKIM toggle changed our operations entirely — clients can't accidentally send unauthenticated, and we can isolate their quotas without spinning up separate infrastructure.”

Verified review

Mumara customer

Trustpilot

Common questions

What buyers usually ask.

What's the difference between an Administrator and a User?

Administrators are top-level accounts on the Mumara installation — they can manage settings, create roles, and (importantly) create Users beneath them. Users are accounts created by an admin — they have their own login, package, and quota limits, and typically operate as isolated tenants. Marketing teams primarily use Administrators with custom roles for internal access control. Resellers / agencies use Users for client-isolation. Both surfaces exist on the same account; use whichever fits your structure.

How granular are custom roles?

Very. The Add Admin Role page exposes a tree of permissions across every section — Contact Lists (add / edit / split / merge / delete / delete bulk), Contacts (add / view / edit / import / delete), Campaigns (add broadcast / edit / schedule / delete), Settings (manage roles / manage administrators / billing access), and more. Mix-and-match any combination. Use 'Check All' for power roles or build minimal-permission read-only auditor roles. Each role can be reused across as many admins as need it.

How do Packages and quotas work?

Admins define Packages with quota limits — hourly send rate, daily limit, monthly limit, contact limit, trigger-action limit, suppressed-domain limit. Assign a Package to a User when creating them. By default the User's limits inherit from the Package; per-limit toggles let you override individual values for specific users (e.g., a VIP client with a higher monthly limit on the standard package). Useful for tiered reseller offerings.

Can I enforce 2FA across the team?

Yes. 2FA is enableable per role (so a Compliance Officer role can require 2FA while a Read-only Auditor role doesn't), per user (force a specific user to enable 2FA on next sign-in), or account-wide. The Administrators list shows 2FA status per admin so you can spot stragglers. The 2FA addon adds the underlying Google-Authenticator-style TOTP support.

Are user actions logged?

Yes — every sign-in and sign-out, every admin action, every user action. The Authentication Logs page (Tools → Authentication Logs) lists ID, name, IP address, activity type, details, and timestamp. Used for compliance reviews, security incident investigation, and tracing 'who changed this and when'.

What does Force DKIM Authentication actually do?

It prevents a User from sending broadcasts via a sending domain that hasn't passed DKIM verification. The User can configure as many sending domains as they want, but Mumara won't accept a Send command from them unless the domain's DKIM record is verified. Critical for reseller setups where you want every client's sends to be authenticated as a platform-wide policy.

Can users have different IPs allowed?

Yes. Each User has an optional 'Allowed IP addresses to access the account' textarea — paste IPs (one per line), supports ranges (192.168.1.0-20) and CIDR (192.168.1.0/28). Login attempts from outside the allowlist are rejected. Useful for enterprise customers who only want their user accounts accessible from corporate VPN ranges.

Can a user have multiple administrators above them?

Mumara's hierarchy is admin → user, single-parent. A user belongs to one administrator (the one who created them). For multi-admin oversight, admins can share roles or use the Authentication Logs to monitor every user's activity. The single-parent model keeps the responsibility clear — if a user does something problematic, it's clear which admin owns the account.

Mumara Campaigns · Team & Users

Multi-admin. Multi-user. Reseller-ready out of the box.

Team & User Management ships with every Mumara Campaigns plan — Self-Hosted and Mumara Machine. Custom roles, packages, 2FA, and authentication logs are all included. The White Labeling addon takes reseller setups one step further; the 2FA addon adds Google Authenticator support.