Contents
Why the VMTA is the building block
Every message PowerMTA delivers goes out through a virtual MTA, and the VMTA determines the message's source IP, its HELO identity, and its DKIM signing. The virtual MTA is, in that sense, the fundamental unit of PowerMTA's sending architecture: understand the VMTA and how to configure it across multiple IPs, and the rest of PowerMTA's sending design, pools, routing, reputation strategy, builds cleanly on top.
This guide exists to cover VMTA configuration thoroughly, with the focus on the common real-world case of a deployment sending from multiple IP addresses. The structure of this guide: why the VMTA is the building block, what a virtual MTA actually is, configuring one VMTA per IP, the HELO hostname and its critical relationship with reverse DNS, attaching DKIM signing per VMTA, why an operation sends from multiple IPs at all, the operating system network configuration the IPs depend on, and the diagnostic workflow when a VMTA does not send from the IP the operator expects.
What a virtual MTA is
A virtual MTA, or VMTA, is a named configuration entity that defines a sending identity, most fundamentally by binding a specific source IP address.
PowerMTA runs on a server, and that server may have several IP addresses assigned to it. A VMTA is how PowerMTA associates outbound mail with one particular IP. Each VMTA is defined with a virtual-mta block, given a name, and configured with the directives that define its sending identity.
A VMTA carries three things that define how mail sent through it appears to receivers:
| Element | Set by | What it determines |
|---|---|---|
| Source IP | smtp-source-host | The IP the connection comes from |
| HELO hostname | smtp-source-host | The name PowerMTA announces in SMTP |
| DKIM signing | domain-key | How the message is DKIM-signed |
So a VMTA is, at its core, a sending IP plus the identity that goes with it, the HELO name and the DKIM signing. The reason VMTAs exist as a concept is that a real deployment wants to send from multiple IPs, for volume, reputation, and redundancy, and the VMTA is the unit representing each sending IP.
An operator configures one VMTA per sending IP, names them meaningfully, and routes mail to the appropriate VMTA, directly, through a VMTA pool, or via the X-Virtual-MTA control header. Every outbound message is delivered through some VMTA, and that VMTA decides the source IP, the HELO identity, and the DKIM signing.
One VMTA per IP
The standard pattern is one VMTA per sending IP. Each IP the deployment sends from gets its own virtual-mta block.
A VMTA block, with its central smtp-source-host directive:
<virtual-mta mta-ip-1>
smtp-source-host 203.0.113.10 mail1.example.com
domain-key sel1,example.com,/etc/pmta/keys/example.pem
</virtual-mta>
<virtual-mta mta-ip-2>
smtp-source-host 203.0.113.11 mail2.example.com
domain-key sel1,example.com,/etc/pmta/keys/example.pem
</virtual-mta>The smtp-source-host directive takes two values: the source IP address PowerMTA uses for outbound connections through this VMTA, and the HELO hostname PowerMTA announces. Here, mta-ip-1 sends from 203.0.113.10 announcing itself as mail1.example.com, and mta-ip-2 sends from 203.0.113.11 as mail2.example.com.
Naming the VMTAs meaningfully matters as the deployment grows. A name that indicates the VMTA's role, mkt-ip-1 for a marketing IP, txn-ip-1 for a transactional IP, warming-ip for an IP being warmed, makes the configuration readable and makes routing decisions clear. A deployment with a dozen VMTAs named after their purpose is far easier to operate than one with a dozen opaquely-named blocks.
Each VMTA's source IP must be an IP actually assigned to the server at the operating system level, a point the OS network configuration section returns to. The VMTA configuration tells PowerMTA to use the IP; the OS must actually have the IP for that to work.
The HELO hostname and reverse DNS
The HELO hostname in the smtp-source-host directive is not a free choice; it must align with the IP's reverse DNS, and this alignment is important for deliverability.
When PowerMTA delivers through a VMTA, it connects from the VMTA's source IP and announces itself with a HELO or EHLO hostname. Receiving servers perform a consistency check involving three things:
- The connecting IP. The IP the connection comes from, the VMTA's source IP.
- The reverse DNS (PTR record). The hostname the connecting IP reverse-resolves to.
- The HELO hostname. The name PowerMTA announces.
Receivers expect these to be consistent: the IP should have a PTR record, that PTR hostname should forward-resolve back to the same IP (forward-confirmed reverse DNS), and the HELO name should be consistent with this. A properly configured legitimate mail server has this alignment; a misconfigured or suspicious sender often does not.
For every VMTA, three things must align: the source IP has a PTR record set, that PTR record points to a hostname that forward-resolves back to the same IP, and the VMTA's HELO hostname is consistent with that reverse DNS. When they align, the VMTA presents a clean, legitimate identity. When they do not, a HELO that does not match the reverse DNS, or an IP with no reverse DNS at all, receivers treat the sender as less trustworthy and deliverability suffers. The reverse DNS is set with the IP's provider, not in PowerMTA; the HELO hostname is set in the VMTA's smtp-source-host directive. The operator's job is to set the HELO to match the reverse DNS the provider has configured, and to ensure every sending IP has proper forward-confirmed reverse DNS in the first place.
The practical workflow for each new sending IP: arrange the reverse DNS with the IP's provider so the IP has a PTR record pointing to a hostname, ensure that hostname has a forward DNS record back to the IP, and set the VMTA's HELO hostname in smtp-source-host to that same hostname. Every VMTA should have this alignment before it sends production mail.
DKIM signing per VMTA
A VMTA block also carries the DKIM signing configuration, through the domain-key directive, so mail sent through the VMTA is signed.
The domain-key directive in a VMTA block associates a DKIM selector, a signing domain, and a private key file:
<virtual-mta mta-ip-1>
smtp-source-host 203.0.113.10 mail1.example.com
domain-key sel1,example.com,/etc/pmta/keys/example.pem
</virtual-mta>This signs mail through mta-ip-1 with the selector sel1, the domain example.com, and the private key at the given path.
The DKIM signing being part of the VMTA configuration has a useful consequence: different VMTAs can sign differently if needed. A deployment sending mail for multiple domains can have VMTAs configured to sign with the appropriate domain for the mail they carry, so a message's DKIM signing domain aligns with its From domain, which is essential for DMARC alignment.
The key point for multi-IP, multi-VMTA configuration is consistency where it should be consistent and difference where it should differ. If all the VMTAs send mail for the same domain, they all carry the same domain-key configuration. If different VMTAs carry mail for different domains, each VMTA signs with the domain matching its mail. Getting the per-VMTA DKIM configuration right is part of ensuring every message, whichever VMTA it goes through, is correctly signed and aligned.
Why send from multiple IPs
The whole reason for configuring multiple VMTAs is that an operation sends from multiple IPs, and that serves three purposes.
| Purpose | What multiple IPs provide |
|---|---|
| Volume distribution | High volume spread so no IP is overloaded |
| Reputation separation | Streams isolated so one cannot drag down another |
| Redundancy | One IP can fail without halting sending |
Volume distribution. A single IP can only send so much before the volume itself is a reputation concern. A high-volume operation spreads its sending across IPs, each carrying a healthy share.
Reputation separation is often the more important reason. Sending IP reputation is built per IP, and different mail streams have different reputation characteristics. Transactional mail is highly engaged and rarely complained about; marketing mail has more variable engagement; cold outreach is riskier. Sending all of these from one IP means the riskier streams drag down the better ones. Separating the streams onto different IPs isolates their reputations: a marketing problem on the marketing IPs does not harm the transactional IPs, so critical transactional mail keeps delivering.
Redundancy. Multiple IPs mean that if one develops a problem, a blacklist listing, a reputation issue, the others continue, and the troubled IP can be taken out of rotation without halting the operation.
For PowerMTA, sending from multiple IPs means configuring multiple VMTAs, one per IP, and routing each stream to the appropriate VMTA or VMTA pool. The VMTAs for a stream can be gathered into a pool so the stream is distributed across its IPs; the streams are kept on separate VMTAs and pools so their reputations stay separate. This multi-IP, multi-VMTA architecture is standard for any serious sending operation because the volume, reputation, and redundancy benefits are real.
The operating system network configuration
A VMTA's source IP must actually be assigned to the server at the operating system level. The VMTA configuration tells PowerMTA to use an IP; the operating system must genuinely have that IP for PowerMTA to bind it.
This is a point operators sometimes miss: configuring a VMTA with an smtp-source-host IP does not create the IP. The IP must be:
- Allocated to the server. The IP must be one the hosting provider or cloud provider has assigned to the server.
- Configured on a network interface. The operating system must have the IP configured on an interface, so the OS knows the IP belongs to it and can use it as a source address.
- Routable. The IP must be able to send and receive traffic, with the network routing correct.
The OS network configuration to assign multiple IPs to a server is done with the operating system's network configuration mechanism, which varies by distribution, and is outside PowerMTA itself. On a modern RHEL-family or Debian-family system, the IPs are configured through the system's network configuration. Each IP PowerMTA's VMTAs reference must be present in that OS-level configuration.
The relationship is layered: the provider allocates the IPs, the OS network configuration assigns them to the server's interfaces, and PowerMTA's VMTA configuration then binds each IP via smtp-source-host. All three layers must agree. A VMTA referencing an IP that the OS does not have configured will not work, PowerMTA cannot use a source IP the operating system does not possess.
When setting up a multi-IP deployment, the sequence is: confirm the provider has allocated the IPs, configure the IPs on the server at the OS level, confirm the OS has them with the appropriate network tools, and then configure the VMTAs in PowerMTA to use them.
When a VMTA sends from the wrong IP
When a VMTA does not send from the IP the operator expects, the diagnostic workflow:
Step 1: confirm the VMTA configuration. Check the virtual-mta block's smtp-source-host directive. Confirm it specifies the intended source IP and HELO hostname.
Step 2: confirm the OS has the IP. Verify the source IP is actually configured on the server at the operating system level. An IP the OS does not have cannot be used as a source.
# Confirm the IP is present on the server
ip addr show | grep 203.0.113Step 3: confirm which VMTA is actually handling the mail. Verify the message is being routed to the VMTA the operator thinks. Check the domain block's VMTA assignment, the pool membership, or the X-Virtual-MTA header. Mail sending from an unexpected IP is frequently mail being routed to a different VMTA than intended.
Step 4: check the accounting log for the actual source IP. The accounting log records the source IP of each delivery. Confirm what IP the mail actually went out from, which tells the operator definitively whether the routing or the binding is the problem.
# Check the source IP recorded for recent deliveries
# (query the accounting log's source IP field)Step 5: verify the reverse DNS and HELO alignment. If the IP is right but deliverability is poor, check that the IP's reverse DNS is set and that the VMTA's HELO hostname matches it.
Step 6: check for a pool overriding the expectation. If the mail is routed to a pool rather than a single VMTA, the pool distributes across its members, so the mail goes out from whichever pool member PowerMTA's distribution selected. Mail from a pool sending from various IPs is expected behavior, not a fault; confirm whether the operator expected a single VMTA or a pool.
Step 7: reload and verify. If the VMTA configuration was just changed, confirm pmta reload was run and pmta show settings reflects the current VMTA definitions.
An operator we worked with was setting up a new sending IP for a dedicated stream. They added a new virtual-mta block to their PowerMTA configuration, with an smtp-source-host directive pointing at the new IP address, set up the DKIM signing, added the VMTA to the appropriate routing, validated the configuration, and reloaded PowerMTA. The configuration parsed cleanly and PowerMTA reloaded without error. But mail for the new stream was not delivering, the deliveries were failing, and the operator could not understand why, the VMTA configuration looked correct in every respect. The investigation went to the basics. The VMTA block was indeed correct: the right IP in smtp-source-host, the right HELO, the right DKIM. But when we checked whether the server actually had that IP, with ip addr show, the IP was not there. The new IP had been allocated to the operator by their hosting provider, the provider's control panel showed it assigned to the server, but the step of actually configuring the IP on the server's network interface at the operating system level had never been done. So the IP was, in the provider's records, assigned to the server, but the operating system did not have it configured on any interface and did not know it belonged to the server. PowerMTA's VMTA was instructing PowerMTA to use a source IP that the operating system did not possess, and PowerMTA could not bind a source address the OS did not have, so the deliveries through that VMTA failed. The fix was at the OS level, not in PowerMTA: configure the new IP on the server's network interface through the operating system's network configuration, so the OS knew the IP belonged to it. Once the IP was properly configured on the interface and confirmed present with ip addr show, the VMTA, whose configuration had been correct all along, worked, and the new stream delivered. The lesson is the layered relationship between the provider, the operating system, and PowerMTA. Configuring a VMTA in PowerMTA does not create the IP; the IP must be allocated by the provider and then actually configured on the server at the OS level before PowerMTA can use it. When a VMTA does not send, confirming that the operating system genuinely has the IP, with a simple ip addr show, is a basic check that catches exactly this common setup gap.
The virtual MTA is the building block of PowerMTA's sending architecture: every outbound message goes through a VMTA, which determines its source IP, its HELO identity, and its DKIM signing. The standard pattern is one VMTA per sending IP, defined with a virtual-mta block, the source IP and HELO set by smtp-source-host, the signing set by domain-key. The HELO hostname must align with the IP's forward-confirmed reverse DNS, an alignment that is a basic deliverability signal. An operation sends from multiple IPs, and therefore configures multiple VMTAs, for volume distribution, reputation separation between streams, and redundancy. And underlying all of it, each VMTA's source IP must genuinely be configured on the server at the operating system level, because PowerMTA cannot use a source IP the OS does not have. Operators who configure one well-named VMTA per IP, align each HELO with its reverse DNS, separate their streams across VMTAs, and confirm the OS network configuration matches the VMTA configuration, get a clean, reputation-sound multi-IP sending architecture.