Knowledge base

smtp-source-host

<virtual-mta>criticalset by the Hub

Local address and greeting name for this sending address
in the configuration this is a linesmtp-source-hostinside the block <virtual-mta>
The same name 1:Global<virtual-mta>— some of them are other settings, some are the same one
The entry inside a sending address — here it is the main one

The syntax and rules are the same as at the node level. One thing changes, but it is decisive: the node’s address set for this stream is replaced entirely. Not supplemented — replaced.

This is what a sending address exists for. The line binds a specific address and a specific greeting name to the stream’s name; everything else that can be written in <virtual-mta> — limits, signing keys, receiver rules — is attached to this pair.

Omitting it is not “take the default” but silent inheritance. The manual dwells on this twice and advises setting the line explicitly in every sending address: without it, messages leave from the node’s general set, and the identity turns out to be an identity in name only.

It can be repeated here too — then the sending address becomes a group of addresses with round-robin rotation. For a fleet this is almost never what is wanted: warm-up and limits apply to the identity as a whole, while there are several addresses inside it.

The main trap. A CIDR range is allowed here too — and it turns one sending address into a group that can be neither warmed up nor limited individually. It looks compact, but it costs manageability: the plan is designed for one address, while the load is smeared across several.
What the Hub does. It writes one line for each sending address — right here, inside the block, not at the node level. The second word is the sending domain; a backup address has a different rule — there the address’s own name is presented if it has a reverse record, and the domain if it does not. The Hub never writes ranges.
Recommended values

The values are the same as in the definition — an address or range and a fully qualified domain name. What differs is only the choice made here:

How to write it What you get
one line the sending address is one address; warm-up and limits are counted for it
several lines an identity of several addresses with round-robin rotation
not writing it at all the node’s general set is silently inherited — the manual advises against this
The rules and the advice to set it explicitly come from the manual (§ 9.2). “A line per address” is our fleet rule.
Example configuration
# the sending address name looks like a domain name, but it does not serve as the greeting name
<virtual-mta mta2.port25.com>
    smtp-source-host 2.3.4.5 mta2.port25.com</virtual-mta>
The manual’s example was chosen on purpose: the block name looks like a domain, and yet the greeting name is taken from the line, not from the sending address’s name. Remove the line — and messages will leave from the node’s general set.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends2 mistakes▶

Relying on the sending address name as the greeting name

§ 9.2

What it costsThe block name is just an identifier. Even if it looks like a domain name, it does not get into the greeting: the name is taken from the second word of this line.
How to spot itEHLO shows a completely different name from the sending address name.
How to do it rightSet the name explicitly as the second word. The manual gives exactly this case as a separate example.

Omitting the line on the assumption that “the right thing will be inherited”

§ 9.2

What it costsThe node’s general set is inherited — that is, most likely an address nobody chose for this stream. On a node with several addresses this means messages that left from who knows where.
How to spot itIn accounting, the delivery address field of one sending address changes from message to message.
How to do it rightSet the line in every sending address. A check for this costs one line in the configuration generator.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
smtp-source-host <see-global>
Values
an address or CIDR range, followed by a fully qualified domain name
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<virtual-mta>
How many times
may be repeated
Everything here comes from the manual, with the section.
Inheritance
Here the entry overrides the general one: the node’s address set for this sending address’s messages is replaced. Between them there is also an intermediate level — <virtual-mta-pool>: what is written in the pool goes to each member, and a member’s own line overrides that too. The order is the usual one — the closer to the message, the stronger.
How to check on the node
What is actually tied to this sending address is visible on the node:
pmta show vmta-settings shop-example-com
The Source Host IP and Source Host columns show the pair that is in effect. If the address is not the one in the block, the block has no line and the node’s set is in effect.
In the Hub
Managed at
Infrastructure → Sending addresses
Value
The Hub picks it itself — pace, warm-up stage, metrics
Cost of a mistake
reversible: harms only while it is set
Scenarios
Sending address rotation
Priority
critical