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.
Product brochure
Rutba MTA — Product Brochure
Multi-tenant email relay middleware: reputation, pacing, suppression, bounces and reporting in front of your own SMTP.
Generated on request from the live content of this site — nothing about it is stored ahead of time. File name Tech-Style-Rutba-MTA-Product-Brochure.pdf.
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.
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 | AGPL 3.0 · commercial available |
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.
| Behaviour | What it means | Inter-message delay |
|---|---|---|
| Healthy domain | Deliveries succeeding, few bounces or complaints | 0 ms — 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 — warmup default of 80 | Paced conservatively until evidence arrives |
Capabilities
What it handles for you
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
Your app posts the message
POST /v1/send or /v1/send/batch, authenticated with the sender's X-Trust-Token header.
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.
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"}'
Stack
What it runs on
| Runtime | Node.js 18 or later; Node 22 LTS recommended. |
|---|---|
| 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. |
| Licence | Apache License 2.0, with contributions welcomed. |
Related
Other products
Media FileServer
The other half of the infrastructure pair.
Rutba ERP
Sends its order mail through this relay.
Open source
Our npm packages and Strapi plugins.
Contact
Talk to us
Tech Style Ltd is a UK technology company building enterprise software, procurement intelligence and AI platforms. Tell us what you are trying to do and we will tell you honestly whether we are the right people for it.
| This document online | www.tech-style.co/product-rutba-mta |
|---|---|
| Website | www.tech-style.co |
| Enquiries | hello@tech-style.co |
| Products | www.tech-style.co/products |
| Partner programme | www.tech-style.co/partners |
This document was generated on request.
It is built from the live content of tech-style.co at the moment you downloaded it, so it can never quote a price, a version or a status the site has since moved on from. Request a fresh copy any time at www.tech-style.co/downloads.
Take this away as a PDF
Rutba MTA — Product Brochure — typeset when you click, from the content above.