Queues instead of a spool
Every email is a RabbitMQ message. Your email platform can publish emails straight into a queue and pick up the results from the queue next to it.
MailerQ and MTA-Hub
MTAs and delivery · MailerQ
MailerQ and MTA-Hub queues under control, your whole fleet in one panel
MailerQ is an MTA (mail transfer agent, the server software that actually sends email) built on RabbitMQ queues: every email is a message you can control, and limits, pools and pauses change without a restart. MTA-Hub installs it together with its database and message broker, edits its configuration, runs the warm-up for you and shows what is happening in the queues on every node.
- Database, broker and MTA in one install
- The Hub runs the warm-up
- Changes without a restart
- Next to PowerMTA in one registry
01Process filebroker and database addresses, ports, paths — read at startup
02Control databaseIP addresses, pools, limits, DKIM keys, rules — shared by the cluster
03Management REST APIpauses, errors and suppressions — on the fly
04Message in the queueproperties of a single email: pool, tags, sending IP
01 / MTA
What MailerQ is
A commercial MTA built around the RabbitMQ message broker. Emails come in over SMTP, through a REST API or straight into a queue, go out under rules you can change live, and the result of every delivery comes back into a queue — and into your analytics.
Pace per “IP → domain” pair
Emails, connections and bytes per minute, the number of open connections and timeouts — for each pair of sending IP and recipient domain.
Reacting to responses
If a mailbox provider responds with “too many messages”, the flow slows down and resumes at a lower speed. Any response can change an email’s sending IP, tags or what happens to it next.
Rewrite rules
An email’s properties change right after it leaves the queue: a different sending IP, delivery through an outside server, edits based on conditions.
Pauses, errors, suppressions
Sending stops for a domain or a tag, chosen emails get a bounce you define, and a suppression list blocks addresses before any connection is made.
Cluster
Queues and the database are shared across several machines: if one node drops out, the others keep sending.
02 / The Hub and MailerQ
What the Hub does with every MailerQ node
MailerQ is easy to manage from its own console — as long as you have one cluster. The Hub manages many of them as one fleet, next to PowerMTA, and covers what MailerQ lacks: a complete install, a planned warm-up and a live snapshot without a status endpoint.
Install in parts
The PostgreSQL cluster database, the RabbitMQ broker and MailerQ itself are installed together or separately — any combination on one server. The Hub builds the configuration before the first start.
Configuration without stray edits
The MailerQ file has several hundred “key: value” lines. The Hub edits only its own, leaves the rest alone and can restart the MTA itself after a change.
Changes on the fly
DKIM keys, proxies and other control-database settings apply without a restart: the Hub reloads exactly the tables it changed and waits for confirmation in the node’s log.
The Hub runs the warm-up
The plan decides how many emails each IP sends per day: it knows the bounces, the manual brakes and the decisions for each mailbox provider. MailerQ’s built-in schedules are not used — two schedulers would mean two sources of truth.
A live snapshot without “status”
MailerQ has no way to report its state: over HTTP it offers only management commands. The Hub collects a snapshot in one SSH session — broker queues, service state, and pauses and suppressions from the cluster database.
Checking after every write
The management REST API returns “200” even when nothing changed. The Hub reads the state back after every write and shows what it read, not what it sent.
Shared operations with PowerMTA
Pause, resume, retry a queue, remove an IP — one list for both MTAs. What MailerQ can’t do is shown as inactive with the reason, not hidden.
Domains and proxies
DNS records and signing keys work the same as for PowerMTA, and the keys land on the node in the format MailerQ needs. Proxies connect through the Hub’s Proxy Gate on the node itself.
03 / Console and Hub
When the MailerQ console is enough, and when you need the Hub
The MailerQ console is live and convenient, but it covers one cluster. Fleet management starts when you have several nodes and PowerMTA running alongside.
| Task | In the MailerQ console | In the Hub |
|---|---|---|
| Install MailerQ | by hand: database, broker, the MTA itself and its config | as one task with a live console, in any combination of parts |
| Warm up new IPs | a day-by-day schedule, separate from the rest of the logic | a plan with decisions for each mailbox provider — shared with PowerMTA |
| What is happening right now | the console of one cluster | a snapshot of all nodes, next to the PowerMTA nodes |
| DKIM keys and IPs | edited in each node’s console | rolled out from one panel, reloading only the tables needed |
| Mixed fleet | two different management systems | one registry, one set of operations, one health score |
← scroll the table sideways →
04 / Knowledge base
473 entries on MailerQ 5.16 — free to read
The catalog from the Hub is published in full: 174 directives, and all of them pass the MailerQ validator. Most importantly, it clearly separates the four settings layers.
Four layers
Process file, control database, REST API and the message in the queue: where a setting lives, who reads it and when it takes effect.
Measured on a node
Where the documentation is silent or disagrees with how the MTA behaves, the entry says what a live node showed.
What the Hub does
Which settings the Hub writes, in which layer and how it applies them — and what it deliberately leaves to MailerQ.
05 / Questions
Questions about MailerQ and the Hub
Didn’t find an answer? Write to site@mta-hub.com or on Telegram.
Why doesn’t the Hub use MailerQ’s warm-up schedules?
So that the warm-up has one owner. The Hub’s plan knows the bounces, the manual brakes and the decisions for each mailbox provider; a MailerQ schedule would keep its own day count, and once the two drifted apart they would produce a volume nobody expects. So the Hub’s plan sets the daily volume, and MailerQ’s schedules stay empty.
Can I keep PowerMTA and MailerQ in one fleet?
Yes: both MTAs live in one registry, with shared operations and one health score. The Hub handles the differences itself — for example, accounting stats are built from PowerMTA accounting files and are available for its nodes.
Do I need a separate server for RabbitMQ and the database?
Not necessarily. The Hub installs the database, broker and MTA in any combination: everything on one server or each part separately — for example, the shared cluster database on its own node.
Do all settings apply without a restart?
No, only those that live in the control database: IP addresses, pools, limits, DKIM keys, pauses. The Hub applies them by reloading the tables needed. The process file is read at startup — after changing it a restart is needed, and the Hub can do that itself.
Which email platforms work with MailerQ through the Hub?
All four — Protosender, Interspire, Mumara and MailWizz. The Hub gives them sending points on MailerQ nodes just like on PowerMTA nodes, together with the warm-up limit.
06 / Next step
Put MailerQ under the Hub’s control
The Hub runs on your own server and manages MailerQ nodes together with PowerMTA — from installation to warmed-up IPs. Need a turnkey cluster? We’ll build it: servers, database, broker, DNS, warm-up and the connection to your email platform.
What you’ll need
- 01A server for the Hub panelThe panel is installed on it with a web installer.
- 02Servers for the nodesFor MailerQ, the database and the broker — on one machine or on several.
- 03A MailerQ licenseBought separately from the Hub.
- 04Sending domainsThe Hub sets up DNS records and signing keys itself.
- 05An email platformProtosender, Interspire, Mumara or MailWizz — it gets ready-to-use sending points.