PowerMTA virtual MTA (vMTA) configuration

The virtual MTA is the building block that lets one PowerMTA server send cleanly across many IPs. Each vMTA is a named identity bound to a specific outbound IP and HELO hostname, with its own reputation. Get these right and the rest of your reputation strategy has a foundation; get them wrong and every IP inherits a HELO/DNS mismatch. They’re the layer where “one server” becomes “many independent senders,” which is the whole reason a single PowerMTA box can run a serious multi-IP operation.

One identity per IP

The point of a virtual MTA is isolation. Mailbox providers judge reputation largely per sending IP, so if you send everything from one address, one bad campaign taints all of it. Split your sending across several IPs — each wrapped in its own vMTA — and each carries an independent reputation: your transactional stream isn’t dragged down by a rough marketing send, and a problem on one IP doesn’t sink the others.

A vMTA is how PowerMTA makes that practical on a single server. Each one binds a specific outbound IP and the HELO hostname that goes with it, and the engine can run as many as you have clean IPs for. That’s what lets one instance behave like a fleet of separate senders — the same machine, but a distinct, governable identity behind each address. Everything else in this page is about defining those identities correctly and choosing which one sends a given message.

Defining a vMTA

The core directive is smtp-source-host: the first value is the outbound IP, the second is the HELO hostname.

<virtual-mta vmta-1>
    smtp-source-host 203.0.113.10 mail.example.com
</virtual-mta>

<virtual-mta vmta-2>
    smtp-source-host 203.0.113.11 mail2.example.com
</virtual-mta>

Each <virtual-mta> binds exactly one outbound IP — that one-to-one mapping is what keeps reputations separate, so don’t share an IP across vMTAs. The second argument to smtp-source-host is the hostname PowerMTA announces in the SMTP HELO/EHLO; if you omit a per-vMTA hostname, it falls back to the global host-name (or the server’s hostname), which is rarely what you want once you’re running multiple IPs. Set it explicitly per vMTA so each IP announces a name that matches its own reverse DNS.

The HELO hostname and FCrDNS

The hostname half of smtp-source-host matters more than it looks, because it’s a trust signal receivers actively check. When PowerMTA opens a connection it greets the remote server with that name in HELO/EHLO, and well-run receivers verify it forms a consistent loop: the sending IP has a PTR record naming that host, and that host has a forward (A or AAAA) record resolving back to the same IP. That closed loop is forward-confirmed reverse DNS, and it’s a baseline expectation for any IP that sends mail.

A mismatch — a HELO host with no matching PTR, or a PTR that points somewhere the forward record doesn’t confirm — is one of the quietest deliverability penalties there is: nothing errors outright, but receivers trust the IP less. So every vMTA’s hostname should be a real name you control, with both the PTR and the forward record set to agree. This is the same alignment that matters for IPv6 sending and underpins clean TLS as well — the vMTA is simply where you declare the name that has to line up.

Selecting a vMTA per message

Two mechanisms, often used together:

Method	How	When to use
Header	X-Virtual-MTA: vmta-1 on the message	Your app/MailWizz picks the IP or pool per send
Source default	default-virtual-mta pool-main	All mail from a subnet uses one pool
By source IP	default-virtual-mta by-smtp-source-ip	Pick the vMTA matching the inbound IP

Scoping DKIM and policy inside a vMTA

A <virtual-mta> block isn’t limited to smtp-source-host — it can carry its own domain-key for DKIM and its own nested <domain> policy, scoped to just that IP. Because of the configuration’s scope cascade, settings inside a vMTA override the global defaults for mail sent through it, which lets you give one IP different signing or throughput from the rest:

<virtual-mta vmta-1>
    smtp-source-host 203.0.113.10 mail.example.com
    <domain *>
        max-cold-virtual-mta-msg 24000/day   # warm-up cap
        max-msg-rate 20/h
        dkim-sign yes
    </domain>
</virtual-mta>

Here the vMTA gets its own rate ceiling and a cold-start cap, independent of other IPs — useful when one address is newer or serves a different stream. Most setups keep policy at the global or pool level for simplicity, but the ability to drop down to a single IP when you need to is part of what makes vMTAs flexible.

Grouping into pools

Most setups don't reference single vMTAs directly — they group them into a pool and let PowerMTA spread traffic. That's covered in IP pools & rotation.

<virtual-mta-pool pool-main>
    virtual-mta vmta-1
    virtual-mta vmta-2
</virtual-mta-pool>

Verify

pmta reload
pmta show virtual-mta        # confirm each vMTA + bound IP

How selection actually resolves

It’s worth understanding the order PowerMTA uses to decide which vMTA sends a message, because the mechanisms combine. If the submitting source is allowed to choose (process-x-virtual-mta yes) and the message carries an X-Virtual-MTA header naming a vMTA or pool, that wins — this is how an application or MailWizz picks the IP per send. If there’s no header, the source’s default-virtual-mta applies, and the special value by-smtp-source-ip picks the vMTA whose IP matches the address the message arrived on.

One directive is easy to overlook and worth setting: fallback-virtual-mta. If a message somehow selects a vMTA that doesn’t exist — a typo in a header, a pool that was renamed — PowerMTA would normally bounce it; a fallback gives those messages a valid vMTA to use instead, turning a hard failure into a delivered message from a safe default. On a system where an upstream app sets the header, that safety net is cheap insurance against a mismatch you didn’t catch. Together these give you a clear chain: explicit header, then source default, then fallback — with the most specific instruction always winning.

vMTAs and warm-up

A brand-new IP starts with no reputation, and the vMTA is where you manage its warm-up. PowerMTA’s max-cold-virtual-mta-msg directive caps how much a cold vMTA sends per day, so a new IP can’t blast volume before it has earned trust. You set a starting cap, raise it as the IP ages, and the engine enforces the ramp rather than relying on you to throttle by hand.

Because each vMTA is a separate identity, you warm each new IP independently — adding a fresh address to a pool means warming that vMTA from cold even though the pool’s other IPs are established. This is the per-IP side of the broader warm-up discipline (start small, send to engaged recipients first, increase gradually) described in dedicated vs shared IP, and it’s exactly what our IP warm-up service automates across a pool of vMTAs. The vMTA gives you the control point; warm-up is the discipline you apply through it.

IPv4 and IPv6 vMTAs

A vMTA binds one IP, and that IP can be IPv4 or IPv6 — so a dual-stack setup means defining separate vMTAs for your IPv4 and IPv6 addresses, each with its own matching reverse DNS. You then route deliberately: send to providers that reward IPv6 (Google especially) over the IPv6 vMTA, and keep IPv4 vMTAs for everything else and for failover.

The vMTA model makes this clean, because each address is already an independent identity with its own HELO and PTR. The one thing to respect is that IPv6 is stricter: an IPv6 vMTA must have a correct PTR, forward-confirmed reverse DNS, and SPF that authorises the IPv6 range, or strict receivers reject outright rather than filter. The full set of IPv6 requirements — including pinning a static address and disabling privacy extensions — is covered in sending email over IPv6; the vMTA is where you bind the address that has to meet them.

How many vMTAs, and naming them

The usual ratio is one vMTA per sending IP — that’s the granularity at which reputation is judged, so it’s the granularity worth controlling. The practical ceiling on how many you run isn’t the configuration but your licensed capacity and, more importantly, how many clean, warmed IPs you can actually keep busy. Ten idle IPs build no reputation; a few well-fed ones build a lot, so size the vMTA count to real volume rather than to how many addresses you happen to hold.

Naming is a small thing that pays off later. A scheme that encodes the IP’s role or stream — say, separating transactional from marketing addresses in the name — makes the config and the logs readable, and makes header forensics straightforward when you’re tracing which IP sent what. Avoid cryptic names you’ll have to decode in six months; the vMTA name shows up throughout your accounting data, so a clear one is documentation you get for free.

The same idea in KumoMTA

KumoMTA has no <virtual-mta> block, but the concept is identical under a different name. There it’s an egress source — a named binding of a sending IP and its HELO/EHLO hostname — and egress sources are grouped into egress pools, exactly as vMTAs group into virtual-mta-pools. Routing logic in Lua chooses which egress source or pool a message uses, playing the role PowerMTA’s X-Virtual-MTA header and default-virtual-mta play.

So the mental model carries straight over: a named identity per IP, with matching reverse DNS, grouped into pools, selected per message. Only the syntax differs — declarative blocks in PowerMTA, Lua bindings in KumoMTA. If you’ve understood vMTAs, you’ve understood KumoMTA’s egress sources; the Auto PMTA Configurator sets up either, so the engine choice doesn’t change the shape of your sending identities.

Common vMTA mistakes

A few errors recur. The most damaging is a HELO/DNS mismatch — a vMTA whose hostname doesn’t line up with the IP’s PTR and forward record — which quietly costs trust at every receiver. Close behind is sharing an IP across vMTAs or otherwise blurring the one-IP-per-identity rule, which defeats the isolation that vMTAs exist to provide.

The rest are operational: no fallback-virtual-mta, so a mistyped header bounces mail instead of routing it safely; skipping warm-up on a fresh vMTA and blasting a cold IP at full volume; and spreading volume too thin across more vMTAs than you can keep warm, so none builds a strong reputation. Each is avoided by treating every vMTA as a real sender that needs a clean identity, a warm-up, and enough volume to matter.

vMTAs and pools

Most sending doesn’t name a single vMTA directly — it names a pool, and PowerMTA spreads the traffic across the vMTAs inside it. The division of labour is clean: the vMTA defines an identity (this IP, this hostname), while the pool defines how a set of identities is used together (rotated, balanced). You reference a single vMTA when you deliberately want one IP — a dedicated transactional address, say — and a pool when you want PowerMTA to distribute across several.

That’s why the two pages pair up: this one is about defining the identities, and IP pools & rotation is about how to group and cycle them. A well-built setup usually has a small number of purposeful pools — by stream, by reputation tier — each made of vMTAs that belong together, rather than a flat list of IPs used at random.

Monitoring per-vMTA health

Because each vMTA is a distinct identity, you monitor it as one. pmta show virtual-mta lists each vMTA and its bound IP, and the queue and status views let you see deliveries, deferrals and bounces per sending address rather than as one undifferentiated stream. That per-IP visibility is what lets you catch a single address going bad — a rising bounce or deferral rate on one vMTA — before it drags down a pool.

The accounting logs carry the vMTA name on each record too, so you can attribute every delivery and complaint to the exact identity that sent it. Pair that with provider dashboards (Postmaster Tools, SNDS) keyed to each IP and you get a per-vMTA reputation picture — the granular view that makes a multi-IP operation manageable instead of a black box. When something’s wrong, per-vMTA data tells you which IP, which is most of the way to the fix — you can pause or drain a single misbehaving vMTA, investigate its reverse DNS or its recent sends, and warm it back up, all without touching the healthy addresses sharing the server. Diagnosing one identity at a time is far easier than untangling a single blended reputation, and it is precisely the visibility that running separate vMTAs buys you, the difference between knowing an IP is in trouble and knowing only that “deliverability dropped” somewhere across an undifferentiated server with no way to tell which of a dozen addresses is the one dragging the rest down.

A multi-stream example

Putting it together, a common shape separates a high-trust transactional stream from a marketing stream on different identities:

<virtual-mta tx-1>
    smtp-source-host 203.0.113.10 tx.example.com
</virtual-mta>

<virtual-mta mkt-1>
    smtp-source-host 203.0.113.20 mkt.example.com
</virtual-mta>
<virtual-mta mkt-2>
    smtp-source-host 203.0.113.21 mkt2.example.com
</virtual-mta>

<virtual-mta-pool marketing>
    virtual-mta mkt-1
    virtual-mta mkt-2
</virtual-mta-pool>

Now transactional mail can target tx-1 directly while marketing targets the marketing pool, so a heavy promotional send can never pull password resets into spam — the two reputations are physically separate. Each hostname matches its IP’s reverse DNS, each new IP is warmed from cold, and the streams stay insulated. It’s the stream-separation principle made concrete in a handful of blocks.

Binding, not merely labelling

It’s worth being clear that smtp-source-host does something real at the network level: it binds the outbound connection to that specific source IP, so mail from the vMTA genuinely leaves the server from that address. A vMTA isn’t a label PowerMTA stamps on a message — it determines which IP the TCP connection originates from, which is exactly why the receiving server sees that IP and judges its reputation.

That has a prerequisite people sometimes miss: the IP has to actually be configured on the server’s network interface for PowerMTA to bind to it. On a multi-IP box, each address you reference in a vMTA must be assigned to the host at the OS level first; PowerMTA can only send from IPs the operating system already holds. If a vMTA won’t send, an unbound or mis-assigned IP at the network layer is a common cause — the config can name an address, but only the OS can make it available. Get the interface configuration and the vMTA definitions agreeing, and the binding does what it promises. This is also why moving a vMTA to a new IP is a two-part change — reassign the address at the OS level and update smtp-source-host together — rather than a config edit alone; the network layer and the configuration describe the same physical fact and have to stay in step.

The bottom line

A virtual MTA is a named outbound identity — one sending IP plus its HELO hostname — and it’s how a single PowerMTA server runs many independent senders, each with its own reputation. Define each with smtp-source-host, make the hostname agree with the IP’s forward and reverse DNS, optionally scope DKIM and domain policy inside it, group related vMTAs into pools, and select one per message via the X-Virtual-MTA header or a source default — with a fallback-virtual-mta as a safety net.

Warm each new vMTA from cold, keep one IP per identity, and respect the stricter reverse-DNS rules for IPv6 addresses. KumoMTA expresses all of this as egress sources and pools in Lua — same model, different syntax. If you’d rather not hand-map IPs, hostnames and pools, the installer creates a vMTA per IP with aligned reverse DNS and groups them into pools, and the Auto PMTA Configurator keeps the mapping correct as you add IPs, including the interface-level binding and the reverse DNS that have to agree with each definition — for legitimate, opt-in sending.