critical
The construct is simple: a block with a name, and inside it an address and a greeting name. Two things about it usually go unknown, and both are costly.
First: omitting inherits. A sending address without an smtp-source-host line (or its proxy form) takes the node’s general address set. It is neither an error nor a warning — messages leave successfully, but from the wrong address. The vendor notes this twice and advises setting at least one line in every definition. It also gives an instructive example: a block name that looks like a domain does not serve as the greeting name — the name needs a separate entry.
Second: several addresses in one definition are used round-robin. That is, a sending address is a group of addresses, not necessarily one. Before treating “identity” and “address” as synonyms, it is worth checking this: any per-address reputation model will be wrong if an identity turns out to be a set.
Definitions reload without stopping the node. And the directives inside apply only when this sending address is chosen for a message; the rest of the time they are simply not read — not an error, just silence.
The mechanism has no values of its own — the directives inside the block set them. What is required in a definition and what depends on circumstances:
| Line | Required | Why |
|---|---|---|
| smtp-source-host or the proxy form | yes | otherwise the node’s set is inherited — silently |
| the name as the second word of that line | yes | the block name does not serve as the greeting name |
| domain-key | practically | large receivers treat unsigned messages with distrust |
| max-smtp-out and receiver rules | depending on circumstances | they can be kept on the pool, shared by the group |
A one-line check for the configuration generator: every sending address has an address line with a name in it. The engine accepts a definition without one, and that is a hidden configuration error.
# a full definition: address, name, signing key, limits <virtual-mta shop-example-com> smtp-source-host 203.0.113.10 shop.example.com domain-key sel1,shop.example.com,/etc/pmta/keys/private_key_shop.txt <domain *> max-smtp-out 20 </domain> </virtual-mta> # incomplete: the engine accepts it, messages leave from the node's general set <virtual-mta broken> <domain *> max-msg-rate 100/h </domain> </virtual-mta>
what people get wrong and how it ends3 mistakes▶
§ 9.2
§ 9.2
§ 9.2
3 relations
The node takes the stream whose address matches the connection addressMatching is done against the stream’s own sending address — including its proxied form. § 9.4.5Change a sending address when messages are already queuedWhat changes is the definition itself — the sending address, the greeting name or both. § 9.5.1Do not send what will fail the check at the receiverThe sending address is taken from there; without an explicitly set address there is nothing to run the check with. § 10.2Running in an imageA related mechanism: they work together. inference
pmta show vmta-settings vmta1
3 articles
◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇Cloud restrictionsClouds restrict outbound mail on port 25 until you ask them to lift the limit, and mailbox providers treat their address ranges with suspicion.◇How to turn a sending plan into hardwareTwo constants for sizing any node: about 2 KB of memory per queued recipient and spool space proportional to the total size of the messages.