Virtual MTAs
Each “IP address + sender domain” pair is a separate vMTA with its own rules. Pools group them for one sending stream, and trouble with one address doesn’t affect the others.
MTAs and delivery · PowerMTA
PowerMTA is a commercial MTA (mail transfer agent) that powers bulk email: virtual MTAs, a queue for each recipient domain, rules for each mailbox provider and a gentle mode when bounces start. MTA-Hub installs it on your servers, builds the configuration, sets up domains, warms up IP addresses and watches every node.
<virtual-mta sender-a.com-vmta> domain-key s1,sender-a.com,/etc/pmta/dkim/private_key_sender-a.com.txt max-smtp-out 10 smtp-source-host 203.0.113.21 sender-a.com # address + HELO name </virtual-mta> <virtual-mta-pool pmta-pool> virtual-mta sender-a.com-vmta virtual-mta sender-b.net-vmta </virtual-mta-pool> <domain $gmail> use-starttls yes retry-after 30m # typical greylisting period bounce-after 3d smtp-pattern-list blocking-errors dkim-sign yes </domain>
01 / MTA
An MTA is the server that takes your campaign emails and delivers them to Gmail, Outlook, Yahoo and thousands of other domains. PowerMTA doesn’t just push mail out — it follows rules: each mailbox provider gets its own pace, and the MTA reacts to bounces on its own.
Each “IP address + sender domain” pair is a separate vMTA with its own rules. Pools group them for one sending stream, and trouble with one address doesn’t affect the others.
Gmail, Outlook and every corporate recipient domain get their own queue. One slow receiver doesn’t hold up the whole campaign.
Connections, messages per connection, pace, TLS and retries — set separately for each mailbox provider. What Gmail likes, Outlook may not.
When a provider starts bouncing mail, the queue goes into backoff: the pace drops and retries come less often. Once the provider accepts mail again, the MTA returns to normal by itself.
Every message is signed at send time with its own domain’s key. Without that, large mailbox providers treat the message with suspicion.
Deliveries, bounces and deferrals are written to accounting files. They show what happened to each message and why.
02 / The Hub and PowerMTA
PowerMTA is a tool for professionals: a text config, vMTAs, policies, DNS, keys. The Hub takes this work off your hands — from a bare server to a warmed-up address — and shows your whole fleet at once, not one server at a time.
PowerMTA 6 on a bare server over SSH — Ubuntu, Debian or Rocky — in about six minutes. Before anything changes, the server is checked, and the installation runs with a live console so you see every step.
The whole file is built from a template, with a preview before you apply it and a rollback to the previous version. The format is shared with Protosender: a node set up by the Hub connects to the PowerMTA module in Protosender, and the other way around.
Proven settings for fourteen major mailbox providers: TLS, retries, bounce categories and the responses that put a queue into gentle mode.
A, MX, SPF, DKIM and DMARC for each domain, plus reverse DNS (PTR) for each address. The Hub pushes them to your DNS provider or to its own name servers and checks that resolvers can see them.
A plan for each “address + domain” pair: a nightly cycle decides for each mailbox provider whether to grow, hold or step back. The Hub itself keeps the daily volume, and PowerMTA runs addresses under warm-up in gentle mode. An emergency brake watches the last few hours.
Traffic, queues, connections, spool, vMTAs and recipient domains — a live snapshot from every node. A health score on four levels: infrastructure, node, vMTA and address. Red is for spam only.
Pause and resume, gentle and normal mode, retry and delete a queue, take an address out of sending — on one node or across the whole fleet, with a preview and a log.
Accounting files are parsed by PowerMTA’s own utility on the node itself — only the result travels over the network, not gigabytes of CSV. Delivery speed, bounces, domains and vMTAs across the whole fleet.
Config check is a separate action for the whole fleet: the Hub finds nodes where the file on disk is not what it believes was applied.
03 / By hand vs in the Hub
A typical day for a PowerMTA admin — and the same tasks in the Hub. Numbers were measured on a live production setup.
| Task | By hand | In the Hub |
|---|---|---|
| PowerMTA on a new server | about an hour following a guide, every single time | about 6 minutes, with a server check before installing |
| A thousand-line config | edited in a text editor; mistakes show up during live sending | built from a template, with preview and rollback |
| DNS for 10 domains and 40 addresses | 90 records, one by one, in the registrar’s panel | pushed to your provider, with a propagation check |
| Warming up new addresses | a spreadsheet and three weeks of daily work | a plan for each pair, a nightly cycle and a brake on bounces |
| Why bounces are growing | digging through accounting files on every server | bounces by category, domain and vMTA for the whole fleet |
| Are configs the same on all nodes | log in to each server and compare | a fleet-wide check in one action |
← scroll the table sideways →
04 / Knowledge base
The catalog that lives inside the Hub is published in full: 477 directives, mechanisms, ready-made setups and scenarios. We checked it against the index of the official user guide, and it matches both ways.
Each directive has a description, a default value, links to related directives, failure modes and the gaps between the documentation and how the MTA actually behaves.
Where the directive appears in the configuration the Hub builds, and which value it sets.
Inside the panel, the catalog shows which directive is set to which value on your nodes.
05 / Questions
Didn’t find your answer? Write to site@mta-hub.com or on Telegram.
Servers from the deb family (Ubuntu, Debian) and the rpm family (Rocky). They have different dependencies and start services in a different order, and the Hub handles both. Running the installation again doesn’t break what’s already installed.
Yes. The Hub connects to the server over SSH and reads the addresses from the node itself. It builds the configuration in its own format — the preview shows exactly what will go to the node before you apply it.
Yes. The configuration is built in a format shared with Protosender — the same section layout and the same file names. A node set up by the Hub connects to the Protosender module, and the other way around.
PowerMTA reacts first — it puts the queue into gentle mode within seconds. Then the Hub’s rules take over: policies with a cool-down period and a limit on actions per hour, a nightly warm-up cycle for each mailbox provider and an emergency brake that watches the last few hours.
On the node itself, by PowerMTA’s own utility. The Hub receives the parsed result, not the accounting files. If one node fails, the run still goes on: the others are counted, and the log shows which node didn’t respond.
06 / Next step
The Hub runs on your own server and manages PowerMTA nodes from installation to warmed-up addresses. Don’t want to set it up yourself? We’ll do it turnkey: servers, PowerMTA, DNS, warm-up and the connection to your email platform.
What you’ll need
