Many gateways. One rotation. Every send authenticated.

If you want Mumara on both sides of the pipe — meaning the same vendor operates the queue in Campaigns AND the MTA on the other side — pick **Mumara ONE** as your Sending Node. ONE is Mumara's own cloud ESP with dedicated IPs, Pools, Bridges (SMTP + API endpoints), and managed sending infrastructure. Connect a Bridge as a Sending Node in Campaigns and the entire pipeline operates inside one stack. For customers who already have established relationships with Amazon SES, SendGrid, Mailgun, or another major ESP, those integrations are still first-class — keep your existing provider and Mumara routes through them transparently. See the [Mumara ONE page](/one/) for the ESP side of the story.

A growing roster. The API-driver side includes Mumara ONE (the recommended path — see above), Amazon SES, SendGrid, Mailgun, Sparkpost, Elastic Email, Mailjet, SMTP2GO, Mandrill, SendinBlue, and Zeptomail today, with more drivers added as customers ask for them. The SMTP-family side includes generic SMTP (which works with literally any provider), Gmail with app password or OAuth2, Outlook, Yahoo, and AOL. If your provider isn't in the API-driver list, the generic SMTP option will almost always work — the platform isn't locked to a curated set.

Protocol. SMTP nodes talk SMTP directly to the provider — host, port, TLS, credentials. API nodes talk the provider's REST API — keys, regions, sometimes IAM identities. From your side, both are just "a node" with the same per-node settings (limits, headers, tracking domain, bounce domain) and the same rotation behaviour. The choice is dictated by what the provider offers — Amazon SES via API is faster and more idiomatic than SES via SMTP, for instance.

Per-broadcast. When you schedule a broadcast against more than one sending node, Mumara picks a rotation mode (random or round-robin) and assigns recipient batches to nodes from the active pool. Random picks uniformly at random per batch for natural smoothing; round-robin cycles A → B → C → A → B → C for predictable per-node load. If a node throws a connection exception during the campaign, it's pulled from the rotation for the rest of that campaign; the remaining nodes absorb the load.

Two layers of recovery. First, mid-flight: Mumara catches the connection exception, sets the node's status to inactive, records the exact error message in test_status, and timestamps the auto-deactivation. The rest of the campaign continues on the remaining active nodes — no emails wasted, no retries onto a known-bad gateway. Second, in the background: Application Settings has a re-check setting (every X minutes for up to XX hours). When a deactivated node returns to healthy on the scheduled re-check, any broadcasts that were paused because of its failure resume sending automatically. No silent failures, no broken nodes blocking active campaigns, no manual reactivation required when the gateway recovers on its own.

Settings → Application → Sending Nodes lets you configure the polling cadence: re-check every X minutes for up to XX hours. Within that window, Mumara probes deactivated nodes on the schedule. If a node's test passes (e.g. the upstream API key was rotated and is now valid again, or the SMTP gateway has come back up), the node returns to the active pool and any broadcasts that were auto-paused because of its failure resume from where they stopped. Past the configured window, the node stays deactivated until an admin investigates and reactivates manually — preventing perpetual retries on a permanently-broken gateway.

Hourly sending limit, daily sending limit, from-name + from-email defaults, reply-to, bounce return-path, attached tracking domain, mail encoding, SMTP encryption (TLS / SSL) with custom peer-verification options for self-signed certs, custom headers (array of header_label + header_value pairs), and provider-specific settings like AWS region for SES or Mailgun region (US vs EU). The headers attached at the node level merge with the global custom-headers list before delivery.

Yes — the REST API exposes full CRUD on sending nodes. POST /api/sending-node/add/{type} adds a node of the specified type. GET /api/sending-node/get-all lists every node. GET /api/sending-node/{id} fetches a single node. PUT /api/sending-node/update/{id} updates settings. DELETE /api/sending-node/delete/{ids} removes nodes by ID (batch-capable). Useful for fleet-managed installations where node configuration is treated as infrastructure-as-code.

Before saving, click Test Connection. For SMTP nodes, Mumara constructs the EsmtpTransport with your credentials, calls start() and stop() against the gateway, applies your SSL / TLS options exactly as a real send would, and reports back whether the handshake succeeded. For API nodes, Mumara calls a known-good endpoint on the provider's API (typically a credentials-validation endpoint) and checks the response. If the test passes, the node activates immediately; if it fails, the exact error message surfaces in the UI for you to fix before saving.

PowerMTA is a first-class addon. The base Sending Nodes feature treats PMTA as a separate concept that lives alongside the SMTP / API node list — same `smtps` table, but with a `pmta_id` foreign key into a parallel `pmtas` table that holds the PMTA-specific data (config-file generation, SSH deployment, accounting-file ingestion, advanced settings JSON). See the [PowerMTA addon page](/campaigns/addons/powermta-integration/) for the full surface — what it adds on top of base Sending Nodes.

Not from the UI — the codebase doesn't ship CSV import / export for sending nodes today. The REST API is the bulk path: write a small script that POSTs your node definitions in sequence, or call the batch-delete endpoint to wipe a set of nodes. For self-hosted installations, the `smtps` table is yours to seed directly with a migration if you really need fleet provisioning at scale.

Connections are managed at the transport layer per send batch. Mumara doesn't run a global pool by default; each batch establishes its connection, runs the send, and tears down — which matches how most major ESPs prefer their inbound SMTP to behave. For very high-throughput single-gateway setups, the multi-threaded send architecture means many connections run in parallel rather than one connection running serially.