Knowledge base
Knowledge base PowerMTA 6.0
Every directive, mechanism and setup scenario of the MTA — in plain words, with recommended values and a breakdown of the usual mistakes. What the Hub configures itself is marked; the rest is explained well enough to configure by hand.
853entries829 from the PowerMTA 6.0 manual
477directivesacross 28 configuration blocks
131mechanismshow the MTA works inside
24recipesready-made setups
23scenariosfrom a task to the directives
90directiveswritten by the Hub — you need not touch them
Start here
six mechanisms that make everything else easy to readAll 131 mechanisms →
The sending address — what it is made ofA named set of everything that is a property of the address: which IP the message leaves from, how the node introduces itself, what it signs with and how fast it sends.Six ways to choose a stream and the order among themA message's stream is set by a merge variable, an API call, a header, a pattern rule, a listener and a source default — the manual lists them by precedence.Backoff mode — the queue's second personalityA queue that a receiver has started refusing switches to a parallel set of limits, retries and routes — ten directives that act only in this mode.The bounce category in accounting — configurable, not vendor-fixedThe bounceCat string in every accounting record comes from a pattern list that can be extended with your own rules and your own category names.Warm-up built into the engineA warmed-up address hands the first N messages of the day for each receiver to its cold partner; the partner sends them itself and builds history.The telemetry contractOne block describes the accounting output in full: which record types, which fields, where they go, how files rotate and what gets anonymized.
By area
829 manual entries grouped by area; our recipes are collected separately
Security and TLS124 entriesAccounting and monitoring114 entriesDelivery and routing100 entriesLimits and pace88 entriesBounces and complaints71 entriesInstallation and core64 entriesSigning and DNS62 entriesMail submission55 entriesAPI and proxies52 entriesMessage content40 entriesDiagnostics37 entriesWarm-up and reputation22 entries
Key directives
showing 6 of 31 critical directivesAll critical (31) →All 477 →
| Directive | Block | Priority | In the Hub | |
|---|---|---|---|---|
| max-smtp-out
How many simultaneous connections the node keeps to one receiver
|
<domain> | critical | set by the Hub | → |
| max-msg-rate
How fast to hand messages to this receiver
|
<domain> | critical | set by the Hub | → |
| backoff-retry-after
At what intervals to retry after a refusal
|
<domain> | critical | set by the Hub | → |
| dkim-sign
Whether to sign messages to this receiver
|
<domain> | critical | set by the Hub | → |
| total-max-smtp-out
The ceiling of outgoing connections for the whole node
|
Global | critical | set by the Hub | → |
| http-access
Who gets into the web monitor and with what rights
|
Global | critical | set by the Hub | → |
By task
from what you need to do to the directives that do itAll 23 →
Ready-made setups
directives that work togetherAll 24 →
A node that really runs without root privilegesA node without root rights is three conditions at once: run-as-root false with a restart, listeners above port 1024 and node files owned by the pmta user.A management entrance open only to your ownMonitor access for the Hub only: a narrow http-access, the http-api-key key, https and protection against forged requests.A node that politely refuses instead of crashingOn a shared machine the node should refuse new mail with a temporary error before memory runs out: a memory threshold, a ceiling on queued recipients and a connection limit.