A PowerMTA audit that reads the configuration, not just the dashboard.

None of these settings is exotic. The skill is in reading them together. A max-smtp-out value looks fine on its own; it looks very different when you notice it sits inside a wildcard <domain *> block that takes precedence over the carefully written Gmail policy two screens down. A backoff list looks thorough until you check it against the deferral strings the providers actually return today and find half of them unmatched. The audit is the act of holding the whole configuration in view at once, which is hard to do from inside a team that lives in it every day.

# A wildcard policy taking precedence over the specific Gmail one
$ grep -nE "<domain (\*|gmail)" /etc/pmta/config
412:<domain *>        max-msg-rate 5000/h   # wildcard wins by position
601:<domain gmail.com> max-msg-rate 90/min   # never reached

# Does the backoff list match the strings providers return today?
$ pmta show queues | grep -c "421"
1843
$ grep -c "reply-pattern" /etc/pmta/config
2          # only 2 patterns for a provider set that returns dozens

# Which streams are leaving unsigned right now?
$ pmta show domains | awk '$4=="no" {print $1, "UNSIGNED"}'
receipts.example.com UNSIGNED

The backoff trap, specifically

Backoff deserves its own paragraph because it is where the most expensive mistakes hide. Backoff protects deliverability and controls performance at the same time. When a provider returns a soft 4xx — a 421 deferral, a temporary rate limit — PowerMTA is supposed to slow that queue down and recover gently. Misconfigure it and the failure mode is not subtle: queues explode, or the engine drops into an effectively infinite retry loop that turns a brief rate limit into a sustained block. Practitioners who tune PowerMTA at volume are blunt about the cause. Providers throttle connections more aggressively than they throttle message rate, so exceeding connection limits is the fastest way to earn a 421 in the first place; and the correct way to scale is horizontal separation across VirtualMTAs, not vertical pressure on a single one. As one performance guide puts it, tuning PowerMTA well means respecting provider limits intelligently rather than pushing against them.

There is a quieter cost too. At high volume, PowerMTA is frequently limited by disk speed rather than CPU, because the spool and the famously detailed logging are both I/O-heavy. An audit that only looks at send rates misses this entirely. We check whether the spool, the accounting files and the log rotation are sized for the volume actually moving through the machine, because a queue that grows is a symptom, and the cause is usually upstream of where people look.

How is reputation and authentication checked against 2026 rules?

Configuration is half the picture. The other half is how the outside world sees the IPs and domains that configuration sends from, measured against the requirements that are now enforced rather than encouraged.

On authentication we check the things providers reject for. SPF has to resolve within its ten-DNS-lookup limit, a budget that large senders blow through more often than they realize once every sending service is included. DKIM has to be present on every stream, with a key of at least 1024 bits and 2048 recommended — Yahoo rejects 512-bit keys outright. DMARC has to exist and align against SPF or DKIM; even a policy of p=none satisfies all three providers as a floor, though the real protection arrives at p=reject. We confirm reverse DNS and HELO alignment, and we check whether MTA-STS and TLS-RPT are published, since encrypted transport is now an expectation rather than a nicety.

On reputation we read the signals the providers themselves expose, because they are the only honest source. That means Google Postmaster Tools, Microsoft SNDS and Yahoo’s Sender Hub — all free, and all showing your complaint rates from each provider’s own vantage point. The complaint thresholds are not advisory. The working rule is to stay below 0.1 percent and never reach 0.3 percent; cross it and you are in enforcement territory, where, as one 2026 guide framed it, a high complaint rate is treated as a trust failure rather than a content problem. We check blacklist status across Spamhaus and the major lists, but with perspective: the inbox providers increasingly weigh their own internal reputation over public blacklists, so a clean Spamhaus record is necessary without being sufficient.

Deliverability, engagement and the streams themselves

The last layer is what actually happens to your mail once it leaves. We run seed-list placement to see where messages land by provider, separate from what your own logs claim, and we look at the spam-folder and missing-mail rates that a delivery report alone will hide. Because engagement now drives placement, we examine the behavioral picture as much as the technical one: are your most engaged recipients getting the mail that keeps them engaged, and are dead segments dragging the whole sender down with non-opens and complaints.

This is also where stream separation matters most. The single most damaging pattern we find is transactional mail — password resets, receipts, shipping notices — sharing IPs and domains with marketing. One-click unsubscribe and the complaint thresholds exempt transactional mail, and that mail enjoys engagement rates that marketing cannot match. Mixing the two means a marketing complaint spike can push a password reset into spam, which is the kind of failure that quietly breaks a product. We check whether the streams are isolated at the VMTA, IP and domain level, and whether the configuration actually enforces that separation or merely intends it.

How does the PowerMTA audit run, and do you need server access?

The work moves in four passes, and you see all of it. First, discovery: we inventory the estate — every VirtualMTA, IP pool, sending domain, DKIM selector and domain policy — so what follows is read against the whole thing rather than a convenient sample. Second, the configuration read: we work through the directives and their precedence against your installed version, looking for the failure modes above and for the ones particular to how you send. Third, the outside view: seed-list placement by provider, the reputation signals from Postmaster Tools, SNDS and Sender Hub, blacklist status, and the authentication checks that decide outright rejection. Fourth, the write-up, where findings are ordered by impact and each one carries a verdict and a fix.

Across a typical estate that runs three to five business days, most of it spent reading rather than waiting. We work read-only throughout. Nothing changes on your servers during an audit unless you ask us to act on a finding, and even then only with your sign-off — the audit observes the estate, it does not rearrange it. If you would rather we did not hold credentials at all, we work from exports and a screen-share, and the depth of the assessment does not suffer for it.

What do you receive at the end of the audit?

The deliverable is a written assessment, ordered by impact. Each finding names the problem, says what it is costing in delivery terms, and classifies it honestly: a quick fix, a tuning project, or a structural issue that is worth weighing against migration. We do not hand over a numeric score and a calendar invite. The document is written to be read by an engineer and understood by the person who signs off the budget, and it is yours whether or not you ever work with us again.

Where the right answer is to keep PowerMTA and tune it, the assessment becomes the brief for that work. Where the configuration is sound but the roadmap is the real risk, it becomes the honest starting point for a conversation about KumoMTA — built by the architect behind the original PowerMTA engine, open source, and the path a growing number of senders are taking. Either way, the audit comes first, because no one should migrate, re-tune or re-platform an estate they have not actually read. One thing the ranking makes concrete is the cost of doing nothing. A backoff list that fails to match a provider’s current deferral strings is not an abstract misconfiguration; it is a measurable share of a send arriving late or not at all, every campaign, until it is fixed. Putting a delivery cost next to each finding is what turns the assessment from a list of technical observations into a decision document, because it lets the person holding the budget see which fixes pay for themselves in the first month and which can wait a quarter. That ordering is the part teams most often tell us they could not have produced from the inside, because triage is hardest on the system you operate every day.