PowerMTA statistics.
A week of sending
from accounting files.

The data window shows what period the PowerMTA accounting covers: from the first accepted message to the last mailbox provider reply. Look at this screen first, before trusting the numbers below: it also says how many servers have data and whether the last collection went through. In the example the window is 7 days 2 hours, 13 of 15 servers have data, and the collection on Oct 23 at 00:21 was not accepted, so the earlier data is shown. You look for the reason a collection failed on the “Collection runs” tab. Open this screen when the numbers look odd or out of date: if a collection failed, the other screens show the previous week, not fresh data.

Enlarge

• First message accepted — Oct 15, 13:06.
• Last accepted — Oct 22, 15:42.
• Last reply — Oct 22, 15:50.
• Window — 7 days 2 hours.
• Nodes with a snapshot — 13 of 15 — no data for the rest.
• Last run — Oct 23, 00:21, not accepted — the earlier data is shown.

Collection details are on the “Collection runs” tab.

Five tiles hold the key figures of the week of sending: how many recipients, what share of messages was delivered, how many bounced, the median delivery time and peak load. It's the short answer to “how did the week go” — handy to open first and show to a customer. “Delivered” and “Bounced” are colored by bounce-rate thresholds: under 4% — green, from 4% — yellow, from 6% — red. In the example both tiles are green: 2.7% bounced. If a tile turns yellow or red, the next step is the bounce screen below and the “Bounces” tab: there you see whether the mailboxes don't exist or the messages were taken for spam. The peak is shown together with its server — tx-01, Oct 15 at 23:35.

Enlarge

• Recipients — 121,953, 3.4 GB sent.
• Delivered — 97.3% — 118,695 messages.
• Bounced — 2.7% — 3,258, of which 74.6% are 5.X.X.
• Median delivery — 0:00:05; 99% made it within 2:45:10.
• Peak — 23 messages per minute — tx-01, Oct 15, 23:35.

“Delivered” and “Bounced” are green: the bounce rate is under 4%.

The daily chart shows how deliveries and bounces changed over the eight days of the period: the bars are delivered messages and bounces, the line is the bounce rate with its own scale on the right. It shows on which day sending went worse and whether bounces spiked. Days are built in your profile's time zone, and incomplete days at the edges of the period are shown paler and never count as the best or worst day. In the example the bounce rate is steady — from 2.5 to 2.7% on full days. The best day here is Oct 19 with 2.5% bounced, the worst is Oct 16 with 2.7%. If days differ noticeably, look for the cause on the bounce and domain screens below.

Enlarge

• Full days — from 11.8 to 19.8 thousand recipients, 2.5–2.7% bounced.
• Oct 15 and Oct 22 — incomplete days — the bars are paler.
• Best day — Oct 19 — 2.5% bounced.
• Worst — Oct 16 — 2.7%.

Incomplete days don't count as the best or worst.

Peak load is the busiest stretch of the period: per minute, per five minutes and per hour. The Hub finds it across every record of the accounting file, not by whole clock hours, so a short burst doesn't get lost in an hourly average. The screen shows how many messages a server pushes through at the busiest moments of sending — it shows the real load. Peaks on different servers happen at different times and don't add up, so each row names its server: by number of messages — tx-01, by volume — tx-02. By volume, tx-02 leads in the example: 11.8 KB/s for a minute and 17.3 MB in an hour on Oct 21. A detailed look at speed is on the delivery speed tab.

Enlarge

• By number of messages — tx-01, Oct 15: 23 in a minute, 77 in five minutes; the best hour, 576, is tx-02 on Oct 21.
• By volume — tx-02, Oct 21: 11.8 KB/s for a minute, 17.3 MB in an hour.

Server peaks happen at different times and don't add up, so each row names its server.

This screen shows how long it takes a message to reach the recipient: the time from entering the queue to the mailbox provider's reply, for delivered messages only. A single average is misleading here, so you see the whole breakdown by interval with a running total. In the example 52% of messages arrived within five seconds, 90% within two minutes, 98% within an hour. The tail of slow deliveries — 36 messages took more than 12 hours — hints that some messages get stuck in the queue; a detailed look is on the delivery speed tab. Open this screen when recipients complain that messages arrive late: it shows what share arrived quickly and what share took hours.

Enlarge

• Within 5 seconds — 52%.
• Within half a minute — 77%.
• Within two minutes — 90%.
• Within an hour — 98%.
• Over 12 hours — 36 messages.

The “Cumulative” column reaches 100% only on the last row, and 33 messages are shown as “<0.1%”, not “0.0%”.

The bounce screen answers the question of why messages didn't arrive. 3,258 bounces are broken down by code type: permanent 5.X.X, where retrying won't help, and temporary 4.X.X, after which the MTA stopped retrying — such a message can be sent again. Below are the reason groups: no such mailbox, mailbox abandoned, mailbox full, taken for spam and others. If “no mailbox” is a large share, it's time to clean your list; if “spam” is growing, look into your reputation and message content. Look at the top groups first: in the example “no mailbox” is 44.0% of all bounces. The bar color shows the group, not the code type: red — no such mailbox or domain, pink — spam.

Enlarge

• 5.X.X — 2,429 — 74.6%, retrying won't help.
• 4.X.X — 829 — 25.4%, the MTA stopped retrying.
• Groups — no mailbox 44.0%, abandoned 11.0%, mailbox full and taken for spam — 8.9% each.

The bar color shows the bounce group, not the code type.

Here are the six most frequent mailbox provider replies, word for word, untranslated: they account for 2,608 of 3,258 bounces. You need the exact reply line to find the cause in the provider's help pages and quote it to your hosting provider. For example, 5.1.1 “…does not exist” — 1,108 times — means the address doesn't exist and should be removed from your list, while 5.7.1 from Gmail “likely unsolicited mail” — 260 times — means Gmail considered the messages unwanted. Start with the top rows: they make up most of the bounces. A detailed look at each category by reply text and by domain is on the “Bounces” tab, where replies are grouped by the MTA's own categories.

Enlarge

• 5.1.1 — “…does not exist” — 1,108 times.
• User unknown — 392.
• 5.2.1 “…is disabled” — 360.
• 4.2.2 “…over quota” — 291.
• 5.7.1 Gmail “likely unsolicited mail” — 260.
• 4.4.2 “Connection timed out…” — 197.

Untranslated: people search for these lines and quote them to the hosting provider.

The table shows the top ten recipient domains by volume — 106,830 of 121,953 recipients, each domain with its own bounce rate. It helps you spot a problem with a single domain: in “Analytics” recipients are grouped into 12 mailbox providers and “other”, while a customer's corporate domain is visible only here. In the example veltrano-group.com has 6,831 recipients and 5.8% bounced, and its row is highlighted in yellow. The “no mailbox”, “spam” and “other” columns immediately hint at why a domain's messages bounce. The full table of all domains, their delivery times and typos in your list such as gmail.con are on the “Domains” tab.

Enlarge

• gmail.com — 39,024, 1.7% bounced.
• outlook.com — 14,634.
• yahoo.com — 12,196, 3.8%.
• veltrano-group.com — 6,831, 5.8% — in yellow.
• Columns — “no mailbox”, “spam” and “other” split a domain's bounces.

In “Analytics” recipients are grouped into 12 mailbox providers and “other” — a customer's domain is visible only here.

The vMTA table shows every sending point — in the example 23 vMTAs on 13 servers — with the number of recipients and the bounce rate for each. You use it to compare sending addresses with each other and find the point that performs worse than the rest. The rate is colored by the same thresholds as the tiles above: from 4% — yellow, from 6% — red. In the example the bank's two points sent to 37 thousand recipients each with 2.2% bounced, while letters.dailyquill.net-vmta has 4,258 recipients and 4.4%, and its row is yellow. If one point is noticeably worse than the others with the same list, you dig into it on the “vMTA” tab: there you see its days, worst domains and hourly maps.

Enlarge

• The bank's points — secure and id.corvalis-bank.org — 37 thousand each, 2.2% bounced.
• letters.dailyquill.net-vmta — 4,258, 4.4% bounced — in yellow.
• Marketing points — 1.4–4.3 thousand each, 0.2 to 4.4% bounced.

The rate is colored by the same thresholds as the tiles.

The last block explains why the PowerMTA statistics don't match “Analytics” — the first question that comes up when you compare the two screens. There are three reasons: different data, different retention and messages removed from the queue by hand. The accounting file holds a week of deliveries and permanent bounces, while “Analytics” receives temporary bounces and complaints by webhook and keeps totals for years. The bottom line: both counts are correct, and the difference doesn't mean the data is wrong. This screen is handy to show a customer or a colleague who is comparing the two reports. Temporary bounces, complaints and totals over the years are in “Analytics”.

Enlarge

• Different data — temporary bounces and complaints arrive by webhook and are visible only in “Analytics”.
• Different depth — accounting files cover a week, “Analytics” covers years.
• Removed from the queue — the MTA records them as bounces, “Analytics” doesn't count them.

Both counts are correct — they count different things.