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 that each application does not have to solve deliverability again from scratch.
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 or 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 action links and webhooks
- Licence
- AGPL 3.0 · commercial available
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.
| Behaviour | What it means | Inter-message delay |
|---|---|---|
| Healthy domain | Deliveries succeeding, few bounces or complaints | 0 ms, with no artificial pacing |
| Slight degradation | Outcome ratio starting to slip | 500 ms |
| Warning | Bounce or complaint rate climbing | 1500 ms |
| Poor | Sustained negative outcomes | 3000 ms |
| Critical | Domain treating this stream badly | 6000 ms |
| New domain | No history yet, so it starts at a warmup score of 80 | Paced conservatively until evidence arrives |
Administrators can override the score and rate configuration per domain when they know something the data doesn't yet.
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 of 1 minute, 5, 15, 1 hour and 3 hours, six attempts in all. 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.
From API call to inbox
Your app posts the message
POST /v1/send or /v1/send/batch, authenticated with the sender's X-Trust-Token header.
DNS gate
A send from a domain without its SPF and DKIM records is refused with a 422 before anything is queued, and the send worker checks again before it relays. Mail cannot leave in the name of a domain that has not published them.
Suppression gate
Each recipient is checked against global and per-sender suppressions before anything is queued. Blocked addresses never reach the queue.
Queue in MySQL
Surviving messages are persisted, so a restart doesn't lose a batch halfway through.
SendWorker paces the stream
Transactional messages go first without delay. Marketing messages wait for the delay their destination domain's reputation currently earns.
Relay through your SMTP
Delivery is handed to the sender's own registered SMTP server, never direct to MX.
BouncePoller listens
DSN and ARF reports arriving by IMAP update suppression lists and adjust the domain score, closing the feedback loop.
WebhookWorker reports
HMAC-signed webhooks push status changes and action clicks back to your application.
Endpoints
Every /v1/* route requires the X-Trust-Token header, with one exception: on an empty database, the first POST /v1/senders needs no token and creates the admin sender. Action, unsubscribe and health routes are public by design. Domain and DNS routes are for the admin sender only.
- 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 message, transactional by default, optionally with a calendar invitation
- POST/v1/send/batchSend a templated batch (marketing by default)
- GET/v1/messagesList the sender's messages
- GET/v1/messages/:uuidMessage status and history
- GET/v1/batchesList the sender's batches
- 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
- POST/v1/domains/:domain/resetReset a receiving domain's reputation
- GET/v1/dns/:domainThe sending domain's stored DNS verdict
- POST/v1/dns/:domain/verifyRe-check a sending domain's records now
- 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","class":"transactional","text":"..."}'
Request shape is indicative. See the repository README for the full schema.
What it runs on
| Runtime | Node.js 18 to 22; the Docker image runs Node 22 LTS. |
|---|---|
| Database | MySQL 8. MySQL 5.7 is supported with limitations. |
| Outbound | Standard SMTP relays, one per sender, driven through nodemailer. |
| Bounce parsing | imapflow and mailparser, handling DSN (RFC 3464) and ARF (RFC 5965). |
| Cryptography | AES-256-GCM for stored SMTP passwords; HMAC-SHA-256 for action tokens and webhook signatures. |
| Workers | SendWorker, BouncePoller and WebhookWorker run alongside the API. |
| Testing | Node's built-in test framework, 73 tests in 12 files on 2026-10-12. |
| Licence | GNU AGPL 3.0 or later, with a commercial licence for products that cannot accept copyleft. Contributions welcomed. |
Struggling with deliverability?
Use Rutba MTA under the AGPL 3.0 licence, take a commercial licence if copyleft does not suit your product, or talk to us about deploying and operating it alongside your applications.