Email sending dashboard.
All your sending
on one screen.

The top row of the Dashboard is a sending summary for the chosen period. The first tile is about the connection to the servers, the other five are about messages: speed, sent, delivery rate, not delivered and the queue. The tile color speaks for itself: green means all is well, yellow means there's something to look at. In the example, over 7 days 15 of 15 nodes are online, 187,647 messages were sent, and the delivery rate is 97.2%. On the right above the tiles you choose the infrastructure and the period. The average speed counts only the hours when mail went out, so a quiet night doesn't drag it down. If a tile turns yellow, look for the cause below: in the to-do list, in sending by provider or in the node table.

Enlarge

• The line above the tiles — all infrastructures, period Oct 13 → Oct 19, data as of Oct 19, 17:14.
• Nodes online — 15 of 15, MTA installed on 15.
• Messages per hour — 1,158.3 on average per sending hour, peak 2,499.
• Sent in 7 days — 187,647, plus 4,724 deferred.
• Delivery rate — 97.2% — 182,308 delivered; in the corner, the change from the previous period.
• Not delivered — 5,339 (2.8%): HARD 3,773, SOFT 1,566.
• Recipients queued — 1,149, going out at 884 messages an hour.

A server that misses three checks in a row is considered to have lost connection.

The “Needs attention” block is a to-do list the Hub puts together from its own checks: connection to the servers, DNS, reverse DNS, queues, warm-up, proxy gates. A line appears only when something needs to be done, and disappears as soon as the cause is fixed. In the example there are three housekeeping items and none that block sending: proxies without a reverse DNS record, an incomplete DNS set on one domain, and a gate out of service. The “Open” button takes you to where it gets fixed. The icon on the left shows urgency: red means it's blocking sending now, yellow means it hurts delivery or soon will, gray means it's not urgent. If there's nothing to do, the block isn't on the page at all.

Enlarge

• Counter — 3 items: blocking sending — 0, housekeeping — 3.
• Reverse DNS — missing on 9 of 9 proxies — FCrDNS doesn't match.
• DNS — 1 of 26 domains has an incomplete set.
• Gates — 1 of 2 gates is out of service.
• Open — goes to the screen where it gets fixed.

While all items are routine, the block stays collapsed; if something urgent appears, it turns red and opens by itself. If there's nothing to do, the block isn't there at all.

Two cards side by side: on the left, sending by day; on the right, the same messages by the recipients' mailbox providers. The chart shows which day the delivery rate dipped: each bar is split into delivered, deferred and rejected, and the green line is the delivered share. The provider card tells you who accepts worse: in the example, Apple 98.2%, Google 97.5%, Microsoft 96.3%. If one provider is noticeably lower than the rest, investigate it in “Analytics”. A provider here means the company that owns the domains: gmail.com and googlemail.com both count as Google. The five largest are shown by name and the rest are grouped into the last row, so the rows add up to what was sent.

Enlarge

• Bar — blue is delivered, yellow is deferred, red is bounced.
• Green line — the delivered share, scale on the right.
• Pale bar — the day is still in progress.
• How providers accept — Google 97.5%, Microsoft 96.3%, Yahoo 96.9%, Apple 98.2%, GMX 97.7%, others 96.6%.
• Color — green from 90%, yellow 70–90%, red below 70%.

A provider is the company that owns the domains: gmail.com and googlemail.com are Google. The rows always add up to what was sent over the period.

The node table shows the state of your sending servers: which ones are sending, through which MTA, how many messages are waiting in the queue and whether there are enough resources. Everything above is about messages; this table is about the machines themselves. This is where you look when the numbers at the top aren't what you expected and you need to find which server has the problem. The CPU, memory and disk bars turn yellow and then red near the limit, and the status column says plainly if the server or the MTA isn't responding. The disk threshold is stricter than for CPU and memory: when the disk is full, the MTA stops. A single server in full — MTA status, queues and controls — is shown in monitoring.

Enlarge

• Node and host — the name in the Hub, the address and the full host name.
• Role — sending, tracking or both.
• MTA — PowerMTA or MailerQ, with the version.
• Queue and messages per hour — for each server.
• Resources — CPU, memory and disk; the bar turns yellow and then red near the limit.
• Contact and status — “running”, “not responding”, “MTA not responding”, or “silent” for more than 15 minutes.

The disk threshold is stricter: when the disk is full, the MTA stops.

The message path is the sending chain from left to right, in the order a message passes through it: domains, nodes with an MTA, vMTAs, addresses and proxy gates. Each link shows how many are in use and what has been checked: DKIM for domains, reverse DNS for addresses. The block helps you spot the bottleneck: in the example only one gate is online, while there are 26 domains and 15 nodes. On the right is a link to the infrastructure diagram, where you see the whole chain. Only vMTAs that actually sent mail during the period are counted: in the example, 35 — 22 domain channels, 9 proxy channels and 4 per address. Major mailbox providers check reverse DNS first.

Enlarge

• Sending domains — 26 — DKIM on 25, on own NS — 24.
• Nodes with an MTA — 15 of 15 online.
• vMTAs in use — 35 — 22 domain, 9 proxy channels, 4 per address.
• Node addresses — 26 — all have reverse DNS.
• Gates online — 1, with 7 proxies in pools.

This way you see at once at which link the chain narrows.

The domains block: a mailbox provider decides a message's fate before it even reads the text — it looks at the domain, the signature and blacklists. The table lists the most active domains for the period: which server, where the zone is kept, whether SPF, DKIM and DMARC are in place and whether the lists are clean. The summary at the bottom covers all domains: in the example, 25 of 26 have a full DNS set, the softest DMARC is p=quarantine, and the oldest DKIM key is 74 days old. A domain that hasn't been checked isn't shown as clean. The zone is either “own NS” — kept by the Hub itself, which changes records in minutes — or an account with a DNS provider. A domain with an incomplete SPF, DKIM and DMARC set also appears in the to-do list at the top.

Enlarge

• Table — domain, node, zone, SPF · DKIM · DMARC, blacklists.
• Zone — “own NS” or an account with a DNS provider.
• Lists — “clean”, “listed” or “never checked”.
• Summary — full DNS set on 25 of 26, on own NS — 24, softest DMARC — p=quarantine, oldest DKIM key — 74 days.

If there was no check, the domain isn't shown as clean.

The proxy block answers two questions: are your proxies fit for sending, and does mail get through them better than directly? At the top: how many addresses are fit for mail, their grades, pools and gates; below: delivery through proxies, blacklists and reverse DNS. In the example all 9 proxies are fit, but none has a reverse DNS record, and delivery through them is 94.0% versus 97.2% across the whole fleet. A gap like that is a reason to look at the proxies more closely. Address grades mean: A — fast and clean, B — working, C — slow. A proxy is used for sending only through a pool assigned to a server.

Enlarge

• Fit for mail — 9 of 9 — port 25 open.
• Grades — 2 A · 5 B · 2 C.
• Pools — 2, with 7 addresses assigned.
• Gates — 1 of 2 in service.
• Through proxies in 7 days — 37,772 messages, 94.0%.
• Blacklists and reverse DNS — 2 of 9 listed, reverse DNS — 0 of 9.

The caption at the bottom compares: 94.0% gets through proxies versus 97.2% across the whole fleet.

The warm-up block shows whether IP warm-up is on plan — across all plans at once. Four tiles: how many warm-up messages went out today and over the period, their delivery rate, and whether any mailbox providers have stalled. In the example 2,218 of 2,560 messages went out today, the delivery rate is 99.2%, and none need attention. Below is a table of plans with the daily limit and an arrow compared with yesterday: you see whether warm-up sped up or backed off. If a provider is under “Need attention”, warm-up has stalled for it, and the plan should be looked at in the “Warm-up” section. Running plans are at the top of the table.

Enlarge

• Today — 2,218 of 2,560.
• In 7 days — 17,155 warm-up messages.
• Warm-up delivery rate — 99.2% — 16,640 of 16,769 delivered.
• Need attention — none — all providers are growing or holding pace.
• Plans table — limit with an arrow vs. yesterday, day, today, sent, delivery and status.

Running plans at the top; below them — paused, draft and finished.

The bounce block briefly answers which mailbox providers reject mail, for what reasons and from which sending addresses. That's enough to tell whether the problem is general or limited to one provider, and to go straight to the right place. In the example, over 7 days there were 3,773 hard bounces (HARD), 1,566 soft ones (SOFT) and 23 complaints, and Microsoft accepts worst — 3.7% bounces. The full breakdown of reasons and addresses is in “Analytics”. Only providers and addresses with at least 20 messages make the lists. FBL complaints are recipients who clicked “this is spam”. SOFT bounces improve with work on the message content, reputation and sending speed.

Enlarge

• HARD — 3,773 — no mailbox, the address leaves the list.
• SOFT — 1,566 — a spam filter or a provider rule.
• Deferred — 4,724 — the provider asks to retry.
• FBL complaints — 23.
• Worst acceptance — Microsoft 3.7% bounced, Yahoo 3.1%, Google 2.5%.
• Most common reasons — too many messages 36.7%, no such mailbox 33.8%, provider requirements 11.4%.

Only providers and addresses with at least 20 messages over the period make the lists.