Rutba MTA architecture — send request through the suppression gate and reputation-based pacing to the sender’s own SMTP relay, with bounce capture feeding back.
Rutba MTA — how it is put together
Email delivery

Rutba MTA

Open-source multi-tenant email relay middleware. It sits between your applications and their own SMTP servers, taking on reputation, pacing, suppression, bounces and reporting — so every application doesn't have to solve deliverability again from scratch.

Rutba MTA email relay middleware
Licence Apache 2.0 Runtime Node.js 18+ Store MySQL 8 Delivery Your own SMTP
What it is — and isn't

Middleware, not a mail server

Rutba MTA is not an MTA in the direct-to-MX sense, and doesn't pretend to be. Final delivery is always performed by the sender's own registered SMTP server — Mailcow, Postfix, SES, whatever you already run. Your sending identity and your IP reputation stay yours.

What sits in front of that is the part nobody enjoys building: a suppression list that actually holds, pacing that responds to how a receiving domain is treating you, a queue that lets a password reset overtake a newsletter, bounce parsing that understands DSN and ARF, and unsubscribe handling that satisfies one-click requirements.

It is multi-tenant by design. Several applications — or several customers — register as senders, each with their own SMTP credentials, trust token, suppression scope and reporting.

Tenancy
Multi-sender, each with its own SMTP and token
Credentials
AES-256-GCM encrypted at rest
Signing
HMAC-SHA-256 for tokens and webhooks
Licence
Apache 2.0
Hard bounces travel. A hard bounce or a spam complaint is promoted to a global suppression across every sender — because an address that doesn't exist for one tenant doesn't exist for the next one either.
Reputation & pacing

Send speed follows the evidence

Each receiving domain carries a live reputation score from 0 to 100, calculated from real outcome ratios. The score selects the delay between messages to that domain.

Reputation score bands and the resulting inter-message delay
BehaviourWhat it meansInter-message delay
Healthy domainDeliveries succeeding, few bounces or complaints0 ms — no artificial pacing
Slight degradationOutcome ratio starting to slip500 ms
WarningBounce or complaint rate climbing1500 ms
PoorSustained negative outcomes3000 ms
CriticalDomain treating this stream badly6000 ms
New domainNo history yet — warmup default of 80Paced conservatively until evidence arrives

Administrators can override the score and rate configuration per domain when they know something the data doesn't yet.

Capabilities

What it handles for you

Sender registration

Applications register a sending address plus SMTP credentials and receive a trust token. Passwords are encrypted with AES-256-GCM at rest, and both token and webhook secret can be rotated.

Suppression gate

Hard bounces, complaints, manual blocks and unsubscribes are checked before a message is queued. Hard bounces and complaints become global automatically; unsubscribes stay scoped per sender.

Priority queue

Transactional messages bypass pacing entirely so a password reset isn't stuck behind a campaign. Marketing mail remains rate-controlled.

Templated batch sends

Post a template plus a recipient array and get personalised messages grouped as a batch, with suppression checked per recipient.

Action interception

Embed calls to action as {{action_key}} placeholders. Rutba issues per-recipient signed tokens, records the click, calls your webhook, then 302s the visitor onward.

Retry & backoff

Transient 4xx failures reschedule on an exponential ladder — 1 minute, 5, 15, 1 hour, 3 hours. Permanent 5xx failures suppress the address globally.

Bounce capture

An IMAP poller reads the bounce mailbox and parses DSN (RFC 3464) and ARF (RFC 5965) reports, feeding both the suppression list and the domain scores.

Unsubscribe handling

List-Unsubscribe headers plus RFC 8058 one-click support, with a hosted unsubscribe page and per-sender scope.

Delivery reporting

Per-message status through the API, live batch-level reports including action click counts, and HMAC-signed webhooks for anything you'd rather not poll for.

How a send works

From API call to inbox

STEP 1

Your app posts the message

POST /v1/send or /v1/send/batch, authenticated with the sender's X-Trust-Token header.

STEP 2

Suppression gate

Each recipient is checked against global and per-sender suppressions before anything is queued. Blocked addresses never reach the queue.

STEP 3

Queue in MySQL

Surviving messages are persisted, so a restart doesn't lose a batch halfway through.

STEP 4

SendWorker paces the stream

Transactional messages go first without delay. Marketing messages wait for the delay their destination domain's reputation currently earns.

STEP 5

Relay through your SMTP

Delivery is handed to the sender's own registered SMTP server — never direct-to-MX.

STEP 6

BouncePoller listens

DSN and ARF reports arriving by IMAP update suppression lists and adjust the domain score, closing the feedback loop.

STEP 7

WebhookWorker reports

HMAC-signed webhooks push status changes and action clicks back to your application.

API

Endpoints

Every /v1/* route requires the X-Trust-Token header. Action, unsubscribe and health routes are public by design.

  • POST/v1/sendersRegister a sender with SMTP credentials
  • GET/v1/senders/meRead, update or delete the current sender
  • POST/v1/senders/me/rotate-tokenRotate the trust token
  • POST/v1/senders/me/rotate-webhook-secretRotate the webhook signing secret
  • POST/v1/sendSend a single transactional message
  • POST/v1/send/batchSend a templated batch (marketing by default)
  • GET/v1/messages/:uuidMessage status and history
  • GET/v1/batches/:id/reportLive batch report with action click counts
  • GET/v1/suppressionsList, add or remove suppressions
  • GET/v1/domains/:domainRead or override domain reputation and rate config
  • GET/action/:tokenRecord a click and redirect (public)
  • GET/unsubscribe/:tokenWeb and one-click unsubscribe (public)
  • GET/healthDatabase connectivity check (public)
# send a transactional message
curl -X POST https://mta.example.com/v1/send \
  -H "X-Trust-Token: $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"to":"customer@example.com","subject":"Your order","priority":"transactional"}'

Request shape is indicative — see the repository README for the full schema.

Stack

What it runs on

Rutba MTA technical specification
RuntimeNode.js 18 or later; Node 22 LTS recommended.
DatabaseMySQL 8. MySQL 5.7 is supported with limitations.
OutboundStandard SMTP relays, one per sender, driven through nodemailer.
Bounce parsingimapflow and mailparser, handling DSN (RFC 3464) and ARF (RFC 5965).
CryptographyAES-256-GCM for stored SMTP passwords; HMAC-SHA-256 for action tokens and webhook signatures.
WorkersSendWorker, BouncePoller and WebhookWorker run alongside the API.
TestingNode's built-in test framework.
LicenceApache License 2.0, with contributions welcomed.

Struggling with deliverability?

Use Rutba MTA under the Apache 2.0 licence, or talk to us about deploying and operating it alongside your applications.