Daily Monitoring Checklist for PowerMTA Email Infrastructure Operators

• February 2023
• Engineering Memo · External Release

Email infrastructure operates continuously, but its health signals accumulate across time windows that require structured daily review to catch problems before they affect delivery rates or reputation. Operators who check infrastructure health reactively — investigating only when a campaign underperforms — consistently discover problems at the worst possible time: when a campaign is actively sending to hundreds of thousands of recipients and intervention is most disruptive.

This note provides a concrete daily monitoring checklist for PowerMTA email infrastructure operators: what to check, from which data sources, with what thresholds for action, and in what order. The checklist is designed to take 20–30 minutes to complete, producing the situation awareness that prevents reactive incident response.

Check 1: DNSBL Status for All Sending IPs (5 minutes)

Data source: Automated DNSBL check results from the monitoring system, or manual queries against zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net for each sending IP.

What to look for: Any sending IP that was not listed yesterday and is listed today. New listings require immediate action — the IP should be removed from active sending pool rotation until the listing is investigated and a delisting request is submitted.

Action thresholds: Any new Spamhaus listing: P1 — pause sends from that IP immediately, investigate cause (spam trap hit, complaint volume, security incident), initiate delisting process. Any new Barracuda listing: P2 — investigate within 2 hours, pause from that IP if complaint rate evidence supports it, initiate Barracuda self-service delisting.

Why first: DNSBL listings produce immediate hard rejections at ISPs that check the list. A listing that occurred overnight produces campaign delivery failures from the moment the morning campaign is injected if not caught before injection. Checking DNSBL status is the first check of the day because it has the most binary impact — listed or not listed — and requires the fastest response.

Check 2: Gmail Postmaster Tools (5 minutes)

Data source: Gmail Postmaster Tools web interface or API for the sending domain.

What to check: Domain reputation tier (has it changed from yesterday or since last check?). Spam rate (current value and direction vs the past 7-day average). IP reputation for each registered IP (any changes from previous check?).

Action thresholds: Domain tier decline (High→Medium, Medium→Low): P2 — investigate FBL complaint data and recent campaign performance for the past 14 days to identify the cause. Spam rate above 0.08%: P2 — investigate immediately, hold pending campaigns for low-engagement segments until cause is identified. Spam rate above 0.10%: P1 — pause all promotional sends, investigate and remediate before resuming. IP reputation decline: investigate that IP's specific recent sends and consider rotating it out temporarily.

Recording: Note the domain reputation tier and spam rate value in the daily monitoring log, even when no action is required. The trend over 2–4 weeks is often more informative than any single day's value. A domain spam rate that has moved from 0.03% to 0.04% to 0.05% over three weeks is a trend signal even though no individual value has crossed an alert threshold.

Check 3: Microsoft SNDS (3 minutes)

Data source: SNDS portal or data export for all registered sending IPs.

What to check: IP status (Green/Yellow/Red) for each sending IP. Any spam trap indicator flags. Complaint rate values if visible.

Action thresholds: Any IP moving from Green to Yellow: P2 — investigate Microsoft complaint sources for that IP's recent sends, plan complaint rate reduction. Any IP moving to Red: P1 — pause sends from that IP to Microsoft addresses, investigate, submit postmaster delisting request. Any spam trap indicator: P1 — pause all sends from that IP, full list hygiene review, acquisition source investigation.

Check 4: Accounting Log Summary (10 minutes)

Data source: PowerMTA accounting log — the previous 24 hours of delivery data.

What to check: Overall delivery rate (250 OK / total attempts). Per-ISP delivery rate for the top 5 destinations by volume. Overall 4XX deferral rate and any ISP with an elevated deferral rate. SMTP attempts per delivered message (the retry pressure ratio). Queue depth at end of reporting period (messages still pending delivery from yesterday's sends).

Action thresholds: Any ISP delivery rate below 95%: investigate the SMTP response codes from that ISP for yesterday's sends. SMTP attempts-to-delivery ratio above 1.5: retry pressure is elevated — investigate whether it is greylisting (expected at some EU ISPs) or reputation-based throttling. Significant queue depth remaining from previous day's sends (above 1,000 messages for a normal-size programme): the previous day's throughput was insufficient — investigate ISP-side throttling or capacity constraints.

Check 5: FBL Complaint Rate (5 minutes)

Data source: FBL complaint processing log — complaints received in the past 24 hours from Yahoo and Microsoft JMRP.

What to check: Total FBL complaints received yesterday. Complaint rate (complaints / delivered messages for the same period). Campaign or segment attribution if complaint data includes X-header campaign identifiers.

Action thresholds: Complaint rate above 0.05%: investigate which campaign or segment generated the complaints. Complaint rate above 0.08%: P2 — hold low-engagement list segments from the next campaign pending root cause investigation. Sudden increase in complaint volume from a specific campaign: investigate that campaign's list segment before sending the next campaign to the same segment.

The Daily Monitoring Log: Making Trend Data Actionable

The daily monitoring checklist produces actionable outputs only if findings are recorded systematically. A daily log entry — even just a text file or spreadsheet row — should capture the date, the value of each key metric (domain reputation tier, spam rate, SNDS status summary, delivery rate, deferral rate, FBL complaint rate), any anomalies detected, and any actions taken or planned.

This log becomes increasingly valuable after 4–6 weeks of consistent entries. Trend analysis requires time series data: the spam rate that looks acceptable at 0.06% today is a problem signal if it was 0.03% four weeks ago and has been increasing steadily. Without the historical log, this trend is invisible. With it, the trend is immediately apparent and actionable at the point where it is still mild rather than severe.

The daily log also provides the historical record needed for postmaster communications. When an ISP postmaster requires evidence of deliverability improvements to process a delisting request or reputation remediation, the daily log demonstrating 30 days of declining spam rate, stable authentication, and clean sending is the most compelling evidence available. Operators who maintain consistent daily monitoring logs are consistently better positioned in postmaster communications than those who can only describe what they have been doing without documentary evidence of the metrics.

Daily monitoring is the operational discipline that converts infrastructure investment into deliverability performance. The best-configured PowerMTA deployment, most carefully warmed IP pool, and most correctly authenticated sending domain will underperform their potential without the monitoring that detects emerging problems before they compound into delivery incidents. The 20–30 minutes per day invested in the checklist described here is the maintenance discipline that keeps the infrastructure performing at its capability level consistently, rather than discovering it has drifted from optimal state only when a campaign underperforms and the investigation reveals problems that have been accumulating for weeks.

Automating the Checks: What to Build vs What to Review Manually

Not all five daily checks require manual review every day — some are well-suited to automation, while others require human interpretation that automation cannot reliably provide. The correct division: automate the data collection and threshold alerting, keep the interpretation and decision-making with the human operator.

Automate: DNSBL queries for all sending IPs on a 15-minute cycle — a script that queries each IP against each major DNSBL zone and alerts immediately on any new listing. Postmaster Tools API data collection (domain reputation tier, spam rate) pulled daily and compared against the previous day's values with alerting on tier changes or spam rate crossings. SNDS data export pulled on a scheduled basis with parsing and alerting on status changes. FBL complaint count and rate calculation from the processed complaint database, run nightly and compared against thresholds.

Manual review: Accounting log analysis requires interpretation that automated scripts can support but not replace. The accounting log data can be aggregated and summarised automatically (delivery rates, deferral rates, queue depths), but diagnosing why a specific ISP has an elevated deferral rate — reading the SMTP response message texts, correlating with campaign timing and list segment data, interpreting whether the pattern is greylisting vs reputation throttling — requires human assessment. The automation provides the aggregated metrics; the human operator interprets anomalies.

The monitoring automation investment: a DNSBL checking script, a Postmaster Tools API integration, an SNDS data parser, and an FBL complaint rate calculator can be built in 1–2 days of engineering time. These four automated checks run continuously and alert on threshold crossings, reducing the daily manual monitoring time from 30 minutes to 10–15 minutes — primarily the accounting log review and interpretation of any alerts the automated systems have flagged.

For programmes that cannot invest in custom monitoring automation, commercial email monitoring services (Validity, Return Path, EmailToolTester monitoring features) aggregate some of these signals and provide alerting, though with different granularity and latency than direct source queries. The combination of a commercial monitoring service and manual accounting log review provides adequate coverage for most high-volume programmes without requiring custom automation development.

Pre-Campaign vs Post-Campaign Monitoring: Different Focus

The daily monitoring checklist described above covers steady-state monitoring — the ongoing health of the infrastructure between campaigns. Campaign-specific monitoring has a different focus: real-time delivery rate during the active send window, complaint rate emerging in the first hours after send, and queue depth evolution as the campaign progresses.

Pre-campaign check (30 minutes before injection): Run the complete daily checklist if it has not been completed already. Pay particular attention to DNSBL status and FBL complaint rate from the previous campaign — any elevated signals should prompt consideration of whether to proceed with the planned campaign or hold pending investigation.

During-campaign monitoring (every 30 minutes): Monitor real-time accounting log for deferral rate increases at any ISP. Monitor queue depth evolution — should be declining as the campaign delivers. Check FBL complaint data for early complaint signals (first complaints typically arrive within 1–2 hours of send). If any metric crosses a threshold, have a decision protocol ready: pause injection, investigate, adjust, or proceed based on the specific signal and its severity.

Post-campaign review (within 4 hours of campaign completion): Calculate final delivery rate, deferral rate, complaint rate, and hard bounce rate for the campaign. Compare to the previous campaign's metrics. Record in the campaign monitoring log. If any metric is significantly worse than previous campaign, investigate the cause before the next campaign is scheduled — the post-campaign review is the mechanism that prevents one problematic campaign from compounding into a sustained deliverability problem by identifying and addressing its cause promptly.

Incident Response: What to Do When a Check Fails

The daily monitoring checklist is only valuable if it is connected to documented incident response protocols. A P1 alert without a documented response protocol produces improvised responses that are slower, less effective, and more likely to make the situation worse than documented protocols that have been reviewed and refined in advance.

The minimum incident response documentation: for each P1 and P2 threshold crossing in the daily checklist, a response protocol document that specifies: who is notified, what immediate action is taken (pause injection from which IPs, which campaigns are held), what investigation is conducted (which data sources, which queries, what evidence to collect), what the criteria are for resuming normal operations, and who has authority to approve resumption. This document should be reviewed quarterly and updated based on incident experience.

Operators who maintain documented incident response protocols consistently resolve deliverability incidents faster and with better outcomes than those who improvise. The documentation reduces the cognitive load of incident response (the operator follows a checklist rather than making decisions from scratch under pressure), ensures consistent response quality regardless of which team member responds, and provides the evidence trail that postmaster communications require. The investment in creating and maintaining this documentation is modest; the value during actual incidents is substantial.

The daily monitoring checklist is the sensor system; the incident response protocols are the response system. Both are necessary for a complete operational posture. The checklist without response protocols produces awareness without action. The response protocols without the checklist produce action without early detection. Together, they constitute the operational foundation that keeps a professional email infrastructure performing at its capability level through the inevitable adverse events that all email programmes experience over time.

Monitoring for Programmes in IP Warmup

During IP warmup, the daily monitoring checklist requires additional checks specific to the warmup programme. The steady-state checks remain, but warmup-specific metrics must be added to confirm the warmup is proceeding correctly and that IP reputation is developing as expected.

Warmup-specific daily checks: Per-IP delivery rate to Gmail and Yahoo (these are the primary reputation-building ISPs during warmup — delivery rate below 95% at either ISP for a warmed IP suggests a warmup pace that is too aggressive or a list segment quality issue); Gmail Postmaster Tools IP reputation for the warming IP (once volume exceeds the display threshold, the IP reputation tier should appear — if it shows Low or Bad after 3 weeks of warmup, the list segment used for warmup has elevated complaint rates that need investigation); per-IP queue depth (a warming IP should not have a queue that grows faster than it clears — if the warming volume exceeds what the IP can deliver within the campaign window at current reputation levels, the warmup volume is too aggressive).

The warmup monitoring log should record, for each warming IP and each day: the volume sent, the delivery rate to Gmail and Yahoo, the deferral rate and the primary SMTP response codes for deferrals, the complaint rate from FBL data for that IP's sends, and the Postmaster Tools IP reputation tier if visible. This daily record is the data that allows the warmup manager to confirm progress, adjust the volume ramp if metrics indicate problems, and document the complete warmup history for the IP as evidence of clean warming practices.

The Weekly Summary: Turning Daily Data into Programme Insights

Weekly summarisation of daily monitoring data converts individual data points into the trend analysis that drives strategic programme decisions. The weekly summary should aggregate: average and peak spam rate for the week, domain reputation tier at end of week vs previous week, SNDS IP status for all IPs, weekly complaint rate from FBL data compared to previous week, average delivery rate and deferral rate for the week, and any incidents that occurred with their resolution status.

This weekly summary is the reporting artefact that connects infrastructure health to programme strategy. When the marketing team plans the next campaign, the weekly monitoring summary provides the infrastructure context: "Domain reputation is stable at High, complaint rate declined this week from 0.06% to 0.04%, all IPs are Green in SNDS — conditions are good for the planned campaign volume." Or: "Domain reputation softened from High to Medium this week, complaint rate was elevated at 0.09% from the previous campaign's list segment, and Free.fr is showing higher deferral rates than normal — recommend delaying the next campaign to investigate and address the complaint source before adding more volume."

The weekly summary that includes this type of infrastructure-to-programme translation is far more valuable to the email marketing team than a technical report of metrics they cannot interpret. The infrastructure operator's job in the weekly summary is not just to report numbers but to translate those numbers into programme-level implications and recommendations that the marketing team can act on. This translation requires both the data (from daily monitoring) and the expertise to interpret what the data means for programme decisions — which is precisely the expertise that professional email infrastructure management provides.

Consistent daily monitoring, connected to a weekly summary that drives programme decisions, and supported by documented incident response protocols, constitutes the operational standard for professional email infrastructure management. It is not glamorous work — it is a routine, repeatable discipline. But it is the discipline that produces the consistently excellent deliverability outcomes that compound into programme performance advantage over the months and years that distinguish professionally managed email infrastructure from infrastructure that is technically correct but operationally neglected.

The daily checklist in this note is a starting point, not a ceiling. As programmes mature and infrastructure grows more complex, the checklist expands to cover additional ISPs, additional sending domains, additional IP pools, and additional data sources. The structure remains the same: binary checks first (DNSBL — listed or not?), then reputation checks (Postmaster Tools, SNDS), then performance checks (accounting log), then behaviour checks (FBL complaint rate). This hierarchy — from immediate blocking risk to trend signals — ensures that the most urgent potential problems are always checked first, regardless of how many checks the programme has added. The 20-minute daily discipline applied with this consistent structure is more effective than a longer but less structured monitoring practice that covers more data without clear prioritisation of what to act on first.

The programmes that never experience a preventable deliverability crisis are not lucky — they are monitored. The daily checklist is the mechanism that converts infrastructure investment into operational resilience, and operational resilience into the consistently excellent campaign performance that compounds into long-term programme advantage.