Skip to main content

Key Concepts

This page explains the ideas that come up throughout the Mumara ONE guide. Each section is short and links to the page that covers the topic in full.

Two sites, one account​

Your Mumara ONE account lives in two places:

  • account.mumara.com is where you sign up, sign in, choose your plan and pay your invoices.
  • one.mumara.com is the app itself, where you build lists, send campaigns, set up Bridges and read your reports.

When you sign in at account.mumara.com, you're taken into the app automatically. See Sign Up and Onboarding for the details.

Marketing and transactional email​

Mumara ONE sends two kinds of email, and it counts them separately.

Marketing emailTransactional email
What it isMessages you send to your contact listsOne-to-one messages your own application sends
ExamplesNewsletters, promotions, drip sequencesReceipts, password resets, account alerts
How you send itCampaigns in the app, or triggers and automationsA Bridge, over SMTP or the HTTP sending API
Where it's countedNewsletter limits and email creditsTransactional limits and transactional credits

Some screens, such as the Dashboard, label marketing email Newsletter. It's the same thing.

Sending domain​

A sending domain is the domain your email comes from, for example example.com. You add it under Setup → Sending Domains and publish the DNS records Mumara ONE gives you. The records let Mumara ONE sign your mail with DKIM, show links on your own tracking domain and handle bounces for you. Mailbox providers use them to confirm that the mail really comes from you.

Every message you send, marketing or transactional, goes out from a verified sending domain. A new account also comes with a small sandbox domain for testing, but you need your own domain to reach your real audience.

See Sending Domains.

Bridge​

A Bridge is how your application sends transactional email through Mumara ONE. Each Bridge is an endpoint with its own credentials. Your application connects to it over SMTP or calls the HTTP sending API. You create and manage Bridges under Transactional → Bridges.

Each Bridge sends through one pool, and you can switch open and click tracking on or off for each Bridge. Using several Bridges lets you keep traffic apart, for example one for each application or each customer you send for.

See Transactional overview, Bridges, SMTP settings and Sending API.

Shared and dedicated infrastructure​

Email leaves Mumara ONE from IP addresses, and mailbox providers judge each IP by the mail that comes from it. That judgement is its reputation.

  • Shared infrastructure. Every account starts here. Your mail goes out through pools of IPs that Mumara runs and shares among customers. There is nothing for you to configure, and Mumara looks after the reputation of these IPs.
  • Dedicated infrastructure. On plans that include it, you can add IPs that only your account uses. Their reputation depends on your sending alone, and you decide which traffic uses them.

See Mumara ONE pricing for which plans include dedicated infrastructure.

Dedicated IP​

A Dedicated IP is an IP address reserved for your account. You order Dedicated IPs from inside the app under Setup → Dedicated IPs, and your plan sets how many you can have. Mumara ONE warms new IPs up for you and keeps watching their reputation.

See Dedicated IPs and, for the settings of each IP, IP Settings.

Dedicated Pool​

A Dedicated Pool is a named group of your Dedicated IPs. You create pools under Setup → Dedicated Pools and assign IPs to them. Mail sent through a pool goes out from the IPs in that pool.

Pools are how you separate traffic. A common setup is one pool for marketing and one for transactional email, so a problem with a newsletter never affects your password resets. You choose the pool for each Bridge when you create it, and for each campaign when you schedule it.

See Dedicated Pools.

How a message travels​

Every message follows the same path, whether it starts as a campaign or as a call from your application:

Campaign in the app            Your application
          |                           |
          |                     Bridge (SMTP or API)
          v                           v
     Plan limits and credits are checked
                    |
                    v
     Signed with DKIM for your sending domain
     Links and opens tracked on your tracking domain
                    |
                    v
     Pool: shared, or one of your Dedicated Pools
     (sent from one of the pool's IPs)
                    |
                    v
     Recipient's mail server
  1. The message starts. You schedule a campaign in the app, or your application hands a message to a Bridge.
  2. Limits are checked. Mumara ONE checks the message against your plan's sending limits and credits. See Plan limits below.
  3. It's authenticated. The message is signed for your sending domain. When tracking is on, links and the open pixel use your tracking domain.
  4. It leaves through a pool. The message goes out from an IP in the pool you chose: a shared pool, or one of your Dedicated Pools.
  5. The result comes back. The recipient's server accepts, delays or bounces the message. Mumara ONE records the result, processes bounces and spam complaints for you and updates the affected contacts.
  6. You see the numbers. Campaign results appear under Statistics, and everything you send, marketing and transactional, appears under Analytics.

Plan limits and usage​

Your plan sets the limits for your account. They include:

  • Contacts, lists and segments you can store.
  • Sending volume: an hourly rate plus daily and monthly limits, with separate limits for transactional email.
  • Credits, on plans that use them: a monthly allowance of email credits and transactional credits.
  • Features you can create, such as sending domains, triggers, evergreen campaigns, webhooks, Bridges and Dedicated IPs.

The Dashboard shows your usage at a glance. The Plan & Usage page shows every limit in detail and when it resets.

When you reach a limit, the result depends on your plan:

  • Plans without overuse, such as Essential, pause sending at the cap until the limit resets or you upgrade.
  • Plans with Allow Overuse, such as Professional and Business, keep sending past the allowance. The extra is invoiced on your billing date.

To change plans, see Subscription and Plans.

Funds, credits and tokens​

These three words mean different things in Mumara ONE:

  • Funds are a prepaid money balance in your account. You add funds under Manage Funds in the user menu (also Setup → Funds).
  • Credits are sending allowance. Plans that use credits give you a monthly allocation of email credits and transactional credits. You can convert funds into extra email credits at any time.
  • Tokens are bought with funds, and they top up the AI credits that Mumara AI features use, such as the AI email builder and the AI Assistant.

See Funds and Billing and Invoices.

Reputation protection​

Mumara ONE keeps watching the bounce and complaint rates of your contact lists and your account as a whole, and checks your Dedicated IPs and sending domains against blocklists. If a rate rises above a safe level, or an IP or domain is listed, it can act on its own to protect your reputation and everyone else's:

  • warn you with a notification or an email
  • suspend a contact list or a sending domain
  • disable a Dedicated IP
  • in serious cases, suspend sending for the whole account

Some of these actions are lifted automatically once the problem clears. See Sending Reputation for the details. The Health gauge on the Dashboard gives you an early view of how your bounces and complaints are trending.

Next steps​

Last updated on