Transactional Email

Transactional email is the one-to-one email your application sends when something happens: an order confirmation, a password reset, a sign-in code, an invoice or a shipping notice. In Mumara ONE you send it through a Bridge, which you create under Transactional → Bridges.

Your application connects to the Bridge over SMTP or the HTTP sending API. Mumara ONE checks each message, signs it for your domain and delivers it, and the results appear alongside the rest of your sending.

Bridge or campaign?

Send through a Bridge when...	Send a campaign when...
Your application decides who gets each email and when	You send the same content to a list or segment
The email is triggered by something the recipient did, such as placing an order or asking for a password reset	The recipients are contacts in your Mumara ONE lists
The content is generated by your application for one person	You want to design, schedule and report on the email inside Mumara ONE
Your application already speaks SMTP, or can make an HTTPS request	You want triggers and automations to react to contact behaviour

A useful rule of thumb: if the recipient would still expect the email after unsubscribing from your newsletter, it's transactional.

How a Bridge fits in

Every transactional message follows the same path:

1. Your application connects to a Bridge, over SMTP or the HTTP sending API, using that Bridge's credentials.
2. Mumara ONE checks the message. The domain in the From address must be one of your verified sending domains, the Bridge must be active, and your account must have transactional sending allowance left.
3. Mumara ONE prepares the message. It signs the message with your domain's DKIM key, sets the return path so bounces come back to your account, and adds open and click tracking if the Bridge has it switched on.
4. The message leaves through the Bridge's pool, from that pool's IPs.

Sending domains

The domain in the From address must be added and verified under Setup → Sending Domains. Any Bridge can send from any of your verified domains, so you don't need one Bridge per domain. See Sending Domains.

Pools

Each Bridge is bound to one pool when you create it, and every message it relays goes out through that pool's IPs.

• On plans with dedicated infrastructure, you can bind a Bridge to one of your Dedicated Pools. Keeping transactional mail on its own pool means a marketing campaign can never affect the reputation of your password resets. See Dedicated Pools.
• On other plans, Bridges use a shared pool that Mumara ONE manages for you.

You choose the pool when you create the Bridge, and it can't be changed afterwards. To move an application to another pool, create a new Bridge on that pool and switch the application over.

Tracking and results

Each Bridge has its own Track Opens and Track Clicks switches, so you can track engagement on, say, a notifications Bridge while leaving it off for password resets. Each Bridge also has its own Sending Stats: total sent, delivered, bounced and complaints.

For message-level detail across all your sending, including delivery logs, bounces and complaints, use Analytics. To push delivery and engagement events to your own systems, set up webhooks under Actions → Webhooks.

Two ways to send

Every Bridge supports both methods at the same time. Pick whichever suits each application; the checks, tracking and stats are the same.

	SMTP	HTTP sending API
Best for	Frameworks, plugins and applications that already have SMTP settings	Code you write yourself, serverless functions, anything that prefers HTTPS and JSON
Credentials	The Bridge's username and password	The Bridge's One Connect Key, sent as a Bearer token
Recipients	One or more per message	One recipient per request
Details	SMTP Settings	Sending API

Not the same as the REST API

The HTTP sending API only sends email through a Bridge. Managing lists, contacts and campaigns from your own code is done with the Mumara REST API and a key from Setup → API Keys, which is a different credential.

What Mumara ONE handles for you

You don't configure any of the following for transactional email. Mumara ONE does it for every Bridge:

• DKIM signing with your sending domain's key.
• Return path and bounce processing. Bounces come back to Mumara ONE and are recorded against your account.
• Complaint feedback loops from the mailbox providers that offer them.
• Sending servers. There's no mail server for you to run or maintain.

Next steps

• Bridges: create a Bridge, find its credentials and set up tracking.
• SMTP Settings: host, ports, TLS and code samples for SMTP.
• Sending API: the endpoint, request fields, responses and errors.
• Your first transactional email: a step-by-step walkthrough from domain to first send.