Your MTA already has a web UI. Here's why that isn't deliverability monitoring.
An MTA console tells you what your server did. Deliverability work needs to know what the receiving mailbox providers decided — and why. Here's the gap, and how BigStats closes it.
Every serious MTA ships an operator console. GreenArrow Engine has one. So do the other engines teams run at scale. Those consoles are good at the job they were designed for: proving the sending machine is healthy — queues are draining, VMTAs are up, the last batch injected cleanly. If that were the whole job, nobody would need anything else.
Deliverability is a different job. It asks what the receiving side decided about your mail, at which mailbox provider, for which stream, starting when — and it asks that question across every send, every day, with enough history to prove a trend rather than a hunch. That is a reporting and analysis problem, not a queue management problem, and it is the reason a delivery reporting layer sits alongside the MTA instead of inside it.
What an MTA console is built to answer
An MTA console is operational and present-tense. It is optimized for the question "is the platform working right now?" — and it usually answers with live queues, per-VMTA throughput, recent log lines, and the current state of a mailing. That view is deliberately narrow, because operators need it to load fast during an incident and because retaining fully-indexed message history for months is expensive on a machine whose main job is pushing mail out the door.
The practical consequences show up the moment a deliverability question arrives. Log retention is short. Search is per-message rather than per-cohort. Comparisons across time are manual. And if you run more than one node, the answer lives in more than one console.
What deliverability work actually needs
- Receiver-side segmentation. Gmail, Microsoft, Yahoo, Apple and the large regional providers each enforce different policies. An aggregate bounce rate hides the one inbox provider that started throttling you this morning.
- Bounce forensics, not bounce counts. The SMTP code, the enhanced status (DSN) code and the remote MTA's diagnostic text are the sentence the receiver wrote you. Classifying those into reputation blocks, content or URL blocks, rate limits, authentication failures and genuinely invalid recipients is what turns a number into an action.
- Deferral trends. A 4xx deferral is not a failure — it is a warning that becomes a failure if you keep pushing. Deferral rate by provider, tracked hour over hour, is one of the earliest signals available to a sender.
- Engagement in the same timeline. Opens and clicks belong next to deliveries and bounces, because inbox placement problems and engagement collapses arrive together.
- Per-IP and per-stream attribution. Shared reputation across a pool means one bad stream can drag down a whole set of IPs. You need to see which IP and which campaign are moving the numbers.
- History long enough to prove a trend. Comparing this week to the same week before a change is how you demonstrate a fix worked — to your team, and to the provider's postmaster process.
- Data you can take with you. Analysts want the raw rows in a spreadsheet, a warehouse or a notebook, not a screenshot of a dashboard.
The gap, side by side
| Question | MTA console | BigStats |
|---|---|---|
| Are my queues draining? | Yes — this is its core strength | Not its job |
| Which ISP started blocking us, and when? | Manual log digging | Domain and ISP breakdown over any range |
| What exactly did the remote server say? | In the logs, if still retained | Bounce codes and diagnostics, grouped and ranked |
| Is this week worse than last week? | Rarely retained that long | Period-over-period on every metric |
| Which sending IP is dragging the pool down? | Per-VMTA throughput only | Per-IP delivery, bounce and complaint stats |
| Give me every hard bounce as a CSV | Log export and scripting | Configurable export in a few clicks |
| Tell me before it becomes an incident | Not typically | Threshold alerts by email |
Why BigStats is different from the monitoring tools you've already tried
Most deliverability products fall into two buckets. Seed-list and inbox-placement tools send test mail to panels of addresses and infer placement from the sample. Reputation dashboards read public or provider-shared signals about your domains and IPs. Both are useful. Neither sees your actual mail.
- It is built on your real event stream. BigStats ingests the events your MTA already emits for the mail you actually sent — deliveries, bounces, deferrals, opens, clicks, unsubscribes and complaints. Nothing is extrapolated from a seed panel, so there is no sampling error to argue about.
- It reads the whole bounce, not a category name. The SMTP code, DSN and the receiver's diagnostic text are preserved and grouped so you can see the exact phrasing that a provider is returning — the detail postmaster teams ask for.
- It is MTA-agnostic by design. GreenArrow Engine's Event Notification System is the first supported source, but the schema is a normalized event model, so multiple engines and multiple nodes roll up into one view instead of one console per box.
- It is engineered for ESP-scale volume. Ingestion is chunked and de-duplicated, and reporting runs off pre-aggregated hourly and daily rollups, so accounts sending hundreds of millions or billions of messages a day still get fast reports.
- The data is yours to move. Configurable CSV exports, a read-only JSON API with scoped tokens, and an MCP server let you pull the same numbers into BI tools, scripts, or an AI assistant like Claude or ChatGPT.
- It watches while you don't. Bounce-rate, complaint-rate and feed-silence thresholds trigger email alerts, and an Issues page ranks what is worth investigating first.
- You can ask it questions. The in-app analyst answers questions about your own delivery data in plain language, including from any chart, so you don't need to remember which report holds the answer.
They work together, not instead of each other
None of this replaces the MTA console, and it does not replace seed testing either. Keep the console for operations. Keep placement testing for the questions only a panel can answer. Add an event-based reporting layer so that when the bounce rate at one provider moves, you can see it within the hour, name the cause from the receiver's own words, and prove the fix worked afterwards.
That is the whole thesis behind BigStats: your MTA already knows everything that happened. It just was not built to tell you the story.