What is PowerMTA, and what does inbox placement really measure?

Ask a sending team how a campaign did and you will usually get a delivery rate: "98.7% delivered." It sounds like an answer. It is not. That number means the receiving mail servers accepted the mail and it did not bounce — it says nothing about where the message landed once it was inside. A message can be "delivered" and sitting in a spam folder no human will ever open, and the delivery report looks identical to the one for a message in the inbox.

The gap between those two states is where most deliverability problems live, and it is hidden by exactly the metric teams trust most. This guide defines the pieces — what PowerMTA is, what a VMTA does, and the real difference between accepted, delivered and placed — then shows why an averaged delivery figure conceals a single-provider collapse, and how we measure placement per ISP for the sending operations we run.

01What is PowerMTA (PMTA)?

PowerMTA is a commercial mail transfer agent — an MTA — designed to send large volumes of email while giving the sender fine-grained control over how that mail leaves the building. A general-purpose MTA like Postfix will relay mail perfectly well, but PowerMTA is built for the operator who is accountable for reputation: it exposes per-destination throttling, per-IP queues, detailed accounting logs, and the traffic-shaping controls that decide how fast you hand mail to each mailbox provider.

Two things make it the default in bulk sending. First, its accounting logs record every delivery attempt, response code and bounce class in a form you can parse, and that is the raw material for any honest reporting. Second, it lets you split one physical server into many independent sending identities — which is the whole job of the VMTA. Most serious operators now run PowerMTA 5 across a fleet of nodes, each signing with DKIM and each mapped to its own addresses; the version number matters far less than the discipline around it.

02What is a VMTA, and what is it for?

A VMTA — virtual MTA — is a named sending configuration inside PowerMTA that binds a specific source IP address to a queue, together with the HELO/EHLO hostname, DKIM signing and throughput rules that travel with it. One server with eight public IPs can host eight VMTAs, and each one is a distinct sender in the eyes of a mailbox provider. You point a campaign at a VMTA, and everything about how that mail presents itself on the wire is decided by that block of configuration.

VMTAs matter for placement because reputation attaches to the identity a VMTA defines, not to the server it happens to run on. A mailbox provider judges the IP address, the signing domain and the consistency of the traffic — all of which a VMTA pins down. Get the mapping wrong — an IP whose reverse DNS does not match the HELO name, or a VMTA signing with a DKIM key the DNS never published — and the provider distrusts the mail before content is even considered. This is why warming a new sending IP is really warming a VMTA: you are building a reputation for that specific identity, one provider at a time.

It also means a "bad IP" is a VMTA-level event, not a server-level one. When placement drops, the useful question is which VMTA — which IP-and-domain pair — is being throttled, because pulling one VMTA from rotation is surgery, while stopping the whole campaign is amputation.

03Accepted, delivered, placed — what is the difference?

These three words describe three different events, and collapsing them is the single most common mistake in deliverability reporting. Here is what each one actually means, and the evidence it comes from.

The jump from "delivered" to "placed" is the one the logs cannot make for you. A 250 is the provider saying "I have your message" — it is a transfer-of-custody receipt, not a verdict. What happens next — inbox, a Promotions tab, spam, or silently dropped — happens inside the provider and is never reported back in the SMTP conversation. That is not a gap PowerMTA can close, because the information simply is not in the protocol.

04Why does one averaged delivery number hide a single-provider problem?

Because averaging is built to smooth over exactly the variation you most need to see. Mailbox providers judge you independently — Gmail's opinion of your mail has nothing to do with Yahoo's — so your true deliverability is not one number but a vector, one figure per provider. Blend them into a single "97% delivered" and a provider that is deferring or foldering most of your mail disappears into the ones that are not.

The trap gets worse when the failing provider holds the largest share of the list. Picture a list that is half Gmail, a quarter Yahoo, a quarter Outlook. Gmail quietly starts foldering you — placement at Gmail falls toward zero — but acceptance stays high, because the mail is still being taken, just routed to spam. Your aggregate delivery rate barely moves. The average absorbs the problem; the provider does not, and neither does your revenue. A blended number told you everything was fine on the morning half your audience stopped seeing your mail.

Each provider also exposes a different surface to senders, so even the diagnostic data does not average cleanly. Google reports on the sending domain; Microsoft judges the IP address; Yahoo tells you almost nothing directly and leans on a complaint feed keyed to your DKIM signing domain. A dashboard that flattens those three into one row of green numbers is not simpler — it is less true. Reporting should be shaped like the thing it reports on, which in practice means one view per provider, not one average smeared across all of them.

05How do you actually measure inbox placement?

With seed lists — mailboxes you own at each provider, sent through the same IP and VMTA as the real campaign, then read to record where each message landed. It is the only measurement that reports placement rather than acceptance, because you are looking inside the mailbox instead of reading a transfer receipt. You send a copy of the campaign to your seeds, wait, then check each one: inbox, spam, or missing entirely.

Seed measurement only works if you own the mailboxes. A borrowed or rented seed list tells you where somebody else's mail landed, on somebody else's reputation. To read placement for your own sending you send through your own VMTA to addresses you control, then read those inboxes over IMAP or a provider API and record the folder. The catch is that the panel is inventory: mailboxes go dormant, get locked, need re-verification and credential rotation, and have to stay readable programmatically. A decaying seed panel quietly becomes a gap in measurement — which is worse than no panel, because you still trust it.

Two disciplines keep seed data honest. Keep the seed results stored apart from campaign statistics, so one bad IP shows up on its own instead of being diluted by everything else you sent. And keep the seeds representative — placement at ten Gmail mailboxes only predicts the list if those seeds behave like real Gmail users. Pair seed placement with the provider's own postmaster signals — Google's domain reputation, Microsoft's per-IP data — and with your bounce and complaint rates, and you have a picture the SMTP log alone can never give you. Authentication has to be solid underneath all of it: if SPF, DKIM and DMARC are not aligned, or you are missing the bulk-sender requirements Gmail and Yahoo enforce, a placement problem is only the symptom and authentication is the cause.

06How we measure placement per ISP for the clients we run

For the sending operations we run — clients including EMG and Relentia — placement is never a single averaged figure, and it is not read off the accounting log. It is measured against seed mailboxes we own, per provider, and kept separate from the campaign numbers on purpose. Mailflow, the control plane behind this work, warms new addresses as seed campaigns through one named IP and stores those seed statistics apart from campaign statistics, so a bad day on one VMTA is visible without being averaged away.

At Relentia, whose sending infrastructure we have run since January 2024, that conviction goes further: there are three separate per-ISP reporting applications — one for Yahoo, one for Outlook, one for Gmail — because the three providers do not agree on what a report even is, and one generic dashboard would throw away the signal each is actually good at. The seed panel behind that testing has its own internal tool, Creator, which builds and maintains the mailbox accounts the placement tests depend on, because a seed list is worth nothing without live mailboxes behind it. At EMG, run remotely since January 2025, Mailflow reports blacklist status alongside per-ISP delivery, bounce and complaint statistics — the same discipline, delivered without ever being in the room.

The thesis underneath all of it is simple. A 250 tells you a provider took your message, not what it did with it next; an averaged delivery rate tells you how the easy providers treated you while the hard one quietly foldered half your list. Measure placement, measure it per ISP, and measure it against mailboxes you own — then let that evidence, not a reassuring blended number, decide whether the mail is really landing.