Demo
Demo

Knowledge base

PMTA knowledge base›Procedure§ 1.2

Prepare a machine for the engine

critical

Minimum Requirements
Six checks before installation, not after

Everything the manual requires before installing the engine. None of the requirements looks serious on its own, and each one left unmet shows up later and somewhere other than where people look for it.

A supported system and architecture. The list is finite, and trying to install the engine on something outside it does not produce a clear error.

A static address and domain name. The sending address is the foundation of reputation: a changed address means reputation from scratch. The name is needed no less — it is what the node introduces itself to the receiving server with.

A reachable resolver. It can be on another machine, but it must be recursive: the engine does not walk the chain of name servers itself.

Time synchronized via NTP. Clock drift breaks not sending but analysis: events in accounting and the log stop matching what receiving servers and the Hub see.

Sized hardware. Not “more is better,” but by two rules: memory from the number of recipients in the queue, disk from the volume of messages (capacity-sizing).

The license key is requested from the vendor’s support in advance — without it the engine will not work.

The main trap is a static address that is not quite static. At a cloud provider an address is usually pinned with a separate setting, and without it the address changes when the machine is recreated. A node set up “to try it out” and left in service one day wakes up with a new address: reputation, SPF and DKIM records, the reverse name record — all stop matching at once. This has to be checked before the address builds up any reputation.
What the Hub does. It checks some of the requirements itself before putting a node into service: NodePreflightRunner looks at system support and resources — less than a gigabyte of memory or ten gigabytes of disk means a refusal, less than two gigabytes or forty means a warning.

What the check does not cover: address stability, resolver recursion, clock synchronization and the presence of a license key. These stay with whoever sets up the node.

Our thresholds mean “suitable at all,” not a calculation for a plan: the Hub could size hardware from the planned volume — it has enough data — but there is no sending profile yet.

Recommended values

Six requirements and what each one checks:

Requirement What failing it threatens Checked
supported system installation without a clear error before installation
static address and name an address change resets reputation at the provider, not on the node
recursive resolver delivery failures that look like receiver problems by querying it
synchronized time accounting drifting from reality by comparing with an external source
sized hardware hitting memory or disk limits under load with two rules of thumb
license key the engine will not start in advance, with support

Check in order from the irreversible to the fixable. Changing the address and name after they have built up reputation is the most expensive; memory and disk can be added on the fly at most hosting sites.

Check the resolver with a query, not by a line in the settings. A resolver that is listed but not recursive looks configured and does not work.

The check order and the analysis of consequences are ours. From the manual here are the list of six requirements itself and the fact that the resolver can be on another machine.
Example configuration
# six checks on one page
hostnamectl && ip -4 addr show
dig +short @127.0.0.1 gmail.com MX    # the resolver answers and is recursivetimedatectl | grep -i 'synchronized'
nproc && free -m && df -h /var
The highlighted line checks what most often turns out to be configured only on paper. An empty answer means the resolver is either unreachable or not recursive — and delivery failures will later look like receiving server problems.
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 ends3 mistakes▶

Assuming the address is static without pinning it at the provider

§ 1.7

What it costsAt a cloud provider an address is pinned with a separate setting. Without it, the address changes when the machine is recreated — and with it reputation resets, SPF and DKIM records stop matching and the reverse name record breaks.
How to spot itAfter a restart or migration of the machine, deliverability dropped to the level of a new address.
How to do it rightPin the address at the provider before it builds up reputation, and check this separately from the machine’s own settings.

Listing a resolver without checking that it is recursive

§ 1.7

What it costsThe engine does not walk the chain of name servers itself and waits for a ready answer. A non-recursive resolver looks configured, but names do not resolve — and the delivery failures look like problems at the receiving servers.
How to spot itDelivery does not go to some domains, while the receiving servers are fine.
How to do it rightCheck the resolver with a query, and after installation with the engine’s own command.

Putting off clock synchronization

§ 1.7

What it costsClock drift does not break sending, which is why it is noticed late. What breaks is analysis: event times in accounting do not match what receiving servers and the Hub see, and any time-based correlation becomes unreliable.
How to spot itEvents in accounting and telemetry diverge in time by a constant amount.
How to do it rightSynchronize the clock before installation. Check the drift the same way as the other requirements — from the machine itself.
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.
⇄

Related entries

3 relations

Does not work without

The activation key is a prerequisite for installation, not a step after itThe activation key is requested from the vendor’s support in advance — without it the engine will not work. § 1.2

Depends on

How to turn a sending plan into hardwareProvides the two rules by which memory and disk are sized. § 1.7.1.2Cloud restrictionsIn the cloud the list gets an item of its own: the restriction on the outgoing mail port has to be lifted. § 1.7

Referenced from

What makes a virtual machine riskyThe procedure in which the mechanism is applied. § 2.5Installing on LinuxAll the machine requirements must be met before this step. § 1.2name-serverGlobalThe resolver is one of the requirements for the machine the node will run on. § 1.2thread-reuseGlobalThe only setting whose default depends on the architecture of the machine the node will run on. § 3.3.1.38

How to check on the node
After installation, the same requirements are checked with the engine’s own tools:
pmta show status
pmta show license
pmta resolve gmail.com MX
The first shows that the engine has started. The second shows that the license was accepted and until what date. The third checks the resolver through the engine’s own eyes: it is the final answer to whether the node resolves names.
◇

What else to read

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.

In the Hub
Cost of a mistake
safe: a wrong value breaks nothing
Scenarios
Capacity planning · Prepare a node for sending
Priority
critical