Skip to content
RECURRING · CANCEL ANYTIME

Continuous reputation tracking,
so you find issues before customers do.

Reputation drifts before it crashes. RBL listings, Postmaster Tools shifts, complaint-rate climbs, content classifier changes. All of these accumulate signal hours or days before placement actually breaks. Continuous monitoring catches the drift, alerts you, and gives you time to act before the campaign that ships to thousands ends up in spam.

€49/month covers every IP and every domain you operate. Postmaster Tools and SNDS pulled daily. 84 RBLs polled every 15 minutes. FBL data ingested as it arrives. Content classifier estimates updated weekly. Telegram alerts when anything material shifts. Weekly summary report. Cancel anytime, no commitment.

price €49 / month
data sources 6 continuous
RBLs polled 84 every 15min
commitment none
data source coverage

What gets monitored, at what cadence.

Click any source to see what specifically gets pulled, what triggers alerts, and how it correlates with the others. Most deliverability issues correlate across 2-3 sources before becoming visible in any single one.

data source detail

Postmaster Tools (Gmail)

Pulled daily via authenticated API for every domain registered with your Postmaster Tools account. We capture domain reputation, IP reputation, authentication pass rates, encryption rates, spam rate, and feedback loop signals.

Trends compared day-over-day, week-over-week, month-over-month. The same metric viewed at three time scales surfaces patterns that single-day comparison misses. Reputation dropping 5% week-over-week looks fine on a single day but is the start of a downward trajectory worth investigating.

alert lead time and action

What alerts look like in practice.

Pick a scenario. The diagnostic shows typical alert lead time, severity, and recommended action. Lead time is the gap between when monitoring detects the issue and when actual deliverability breaks.

alert scenario

RBL listing appears

Detected within 15 minutes of listing publication. We poll all 84 RBLs at that cadence; new listings get picked up within one cycle.

Telegram alert fires immediately on detection. Investigation begins same hour: which IP, which RBL, what's the listed reason if available, what other signals correlate (recent complaint spike, content change, volume change). Findings included in the alert itself rather than just "listing detected, figure it out."

value vs incident cost

Cost-per-incident calculator.

Set your daily volume and how many deliverability incidents you encounter per year on average. Monitoring catches most incidents before they compound; the math usually favours subscription unless your volume is small.

50,000 daily

Total daily volume across all your sending streams. Larger volume = larger absolute impact when issues hit.

3 incidents/year

Past-12-month average. RBL listings, Postmaster downgrades, complaint spikes, content classifier issues. Most senders we see have 2-5 per year.

From when the issue starts to when it's diagnosed and fixed. Without monitoring, this is much longer because diagnosis starts after damage is visible to customers.

incident cost without monitoring

Annual deliverability cost

Volume affected per incident 250,000 messages
Annual affected volume 750,000 messages
Estimated lost revenue €7,500

Estimated lost revenue assumes 0.01€ per affected message based on typical commercial sending economics. Actual values vary; transactional senders have lower per-message value, marketing senders often higher.

with monitoring

Annual cost with monitoring

Monitoring fee €588 / year
Reduced incident impact ~80%
Estimated remaining cost €1,500

Monitoring catches most issues before they compound; ~80% impact reduction is typical because alert lead time gives you days to act before placement breaks visibly.

net result

Monitoring saves €5,412/year

Net annual savings €5,412
ROI 920%

For your sending profile, monitoring is strongly net positive. Subscription cost recovers within 3-4 weeks of avoided incident impact.

Math caveats: per-message revenue value is approximate; actual impact depends on your specific sending economics. The 80% impact reduction assumes you act on alerts when they fire (most customers do). For senders with very low incident rates (under 1/year) or very low volume (under 5K daily), the math shifts and DIY monitoring might be sufficient.

honest fit assessment

Who subscribes, and who shouldn't.

good fit
  • Sending operations past 20K daily volume where issues compound fast. The cost-per-incident at this volume justifies continuous monitoring.
  • Multi-domain or multi-IP senders where issues can be isolated to specific segments. Monitoring per-IP and per-domain catches segment-specific issues that aggregate metrics hide.
  • Cold outreach operators where reputation drift is constant pressure. Multiple domains across multiple IPs means manual checking is impractical.
  • Recent recovery customers who completed Reputation Recovery (€999) and want to catch future drift before another recovery is needed.
  • Compliance-driven sending where documented monitoring is required for SOC 2, ISO 27001, GDPR Article 32, or similar audit trails.
  • Senders without internal deliverability expertise who need an outside operator to do the watching. Monitoring is operational discipline; if your team doesn't run it, paying us to is rational.
poor fit
  • Low-volume sending under 5K daily. Issues at this scale rarely compound fast; manual checking weekly is sufficient. Free tools (Postmaster Tools direct, MXToolbox) cover the basics.
  • You already have an internal deliverability team. If you have someone whose job is watching this data, paying us for the same watching is duplicate cost.
  • Single-domain transactional under 50K daily. Lower complaint rate, simpler reputation profile; manual weekly checks usually catch what matters.
  • You won't act on alerts. Monitoring catches issues; you fix them. If alerts will sit ignored in Telegram, the subscription doesn't help. Honest pre-flight check: have you fixed the last 3 deliverability issues you knew about?
  • You want unlimited remediation included. Monitoring fee covers the watching, not the fixing. Each remediation (blacklist removal, audit, recovery) is separate. Some bundles exist (Recovery Pack); standalone monitoring doesn't include execution.
  • You only send during specific campaigns. If you go dark for 3+ weeks between campaigns, monthly subscription is wasted on inactive periods. Order on-demand audit before each campaign instead.
scope of monitoring

What's in the €49.

01

Postmaster Tools, daily

Authenticated API pull every 24 hours for every domain registered with your Postmaster Tools. Domain reputation, IP reputation, authentication metrics, spam rate, encryption rate, feedback loop signals captured.

Trends computed at three timescales: day-over-day, week-over-week, month-over-month. Same metric at three time scales surfaces patterns single-day checks miss. Reputation dropping 5% week-over-week is the start of a downward trajectory; same drop captured day-over-day looks like noise.

02

SNDS, hourly

Microsoft Smart Network Data Services pulled every hour per registered IP. Color rating (green/yellow/red), complaint rate, RCPT data, sample data ingestion, traffic data per IP captured.

SNDS lags Postmaster Tools by 24-48 hours typically (Microsoft updates color rating after observing trends), but hourly polling catches updates as soon as they appear. We correlate SNDS shifts with Postmaster Tools to confirm they're real reputation moves rather than single-receiver noise.

03

84 RBLs, every 15 minutes

Polling cadence faster than most competitors offer. RBL listings can appear within hours of triggering events; we detect within 15 minutes of listing publication. Coverage: Spamhaus (SBL, CSS, DBL, ZEN), Barracuda BRBL, SpamCop, UCEPROTECT levels 1-3, SURBL, Invaluement, Cloudmark, plus 77 more public and private RBLs.

Per-IP and per-domain coverage. Listings that appear are alerted immediately with context: which RBL, listing reason if available, correlation with other monitoring signals (recent complaint spike, content change, volume change).

04

FBL data, real-time ingestion

Feedback Loop complaint data ingested as it arrives from major receivers (Gmail, Outlook, Yahoo, Apple iCloud, AOL, Comcast, plus smaller FBLs). Per-domain segmentation. Per- campaign segmentation when traceable through campaign identifiers in headers.

Trending detection: complaint rate climb pattern over 3-5 day window triggers alert before reaching threshold-based limits at receivers. Lead time is the difference between "we caught the climb" and "Gmail throttled us."

05

Content classifier estimates, weekly

Sample messages from your typical sending evaluated through Bayesian classifier estimates that approximate Gmail's and Outlook's content scoring. Drift detection: when content patterns shift toward spam-classifier triggers, we flag before the live receivers do.

Estimates are inferred from receiver behaviour, not direct access. Useful for catching content drift early; not a substitute for actual placement testing (which is our Inbox Placement Test product).

06

DNS authentication, hourly

SPF record, DKIM key publication, DMARC record, MTA-STS policy, TLS-RPT companion verified hourly. Drift detection: unauthorised changes to authentication records get caught within an hour, well before they cause delivery issues.

Catches: accidentally-deleted DKIM records (more common than you'd think), DMARC policy changes by overzealous IT, MTA-STS policy expiry approaching, TLS certificate near expiration on receiving infrastructure.

07

Telegram alerts, immediate

Alert fires immediately on detection. Alert content includes: what was detected, on which IP/domain, severity level, correlation with other signals, recommended action (with link to the right ASH product if applicable).

Alert templates tuned to your operation profile during onboarding. Cold outreach operators get different alerts than transactional senders. Alert volume calibrated to actually-actionable signals; we don't fire alerts for normal noise.

08

Weekly summary reports + anomaly investigation

Weekly Telegram report. Trend snapshot across all monitored sources. Anomalies investigated and documented. Open items tracked across weeks.

Anomaly investigation: when alerts fire, we investigate the root cause before notifying. The Telegram alert includes findings rather than just "listing detected, figure it out yourself." Saves diagnostic time for you and reduces alert fatigue.

questions before you subscribe

Frequently asked.

What does this monitor that I can't monitor myself?

Same data sources you could check manually: Postmaster Tools, SNDS, RBL queries, FBL inboxes, DNS authentication. The difference is operational discipline. Most operators check sporadically, miss correlations across sources, and learn about issues from customer complaints rather than from monitoring. Our monitoring runs continuously, correlates across sources, and alerts before issues compound.

Honest framing: if you have someone on staff whose job is watching this data and acting on it consistently, you don't need us. Most operations don't have that role; the work falls between marketing, devops, and engineering, and consequently nobody actually does it.

How fast do alerts fire?

Depends on the data source. RBL listings: detected within 15 minutes (polling cadence). Postmaster Tools shifts: detected within 24 hours (daily pull). SNDS color shifts: detected within 1 hour (hourly pull). Complaint rate climbs: detected within real-time FBL ingestion. Content classifier drifts: detected within next weekly cycle.

Telegram alert fires immediately on detection. Investigation (what's the cause, what other signals correlate) happens same hour for high-severity alerts, within 4-8 hours for medium-severity.

How is this different from GlockApps Spam Tracker / 250ok / Inboxable?

Same category, different operating model. GlockApps Spam Tracker, 250ok, Inboxable are SaaS dashboards: you get access to data, you watch it. Our monitoring is managed service: we watch, we investigate, we alert with findings, we recommend action. €49/month vs $250-1500/month for comparable SaaS.

Tradeoff: SaaS dashboards give you direct access to raw data and self-service charts. Our managed service gives you outcomes (alerts with findings) but you don't have a UI to poke at. For teams that want to dive into the data themselves, SaaS fits better. For teams that want issues surfaced and explained, our service fits better.

Do you monitor my own infrastructure or just receivers?

Both. Receiver-side monitoring (Postmaster Tools, SNDS, RBLs, FBL data, DNS auth) is the visible product. Internally we also run monitoring on your sending infrastructure if we host it: queue depth, deferral rates, bounce categorisation trends, MTA process health.

For self-hosted sending we don't manage, we don't monitor your infrastructure unless you grant access. Most customers don't grant infra access; the receiver-side monitoring is sufficient signal for most issues.

What if you miss an issue?

Possible but rare. Monitoring catches what receiver-side data shows; some issues only appear in your application (broken transactional triggers, suppression list corruption, content errors not visible to receivers) that we wouldn't see. We don't promise comprehensive coverage; we promise consistent watching of the receiver-side signals that matter most.

If we miss an alert that should have fired (false negative from our monitoring rather than from receivers), we credit the missed-alert month free. We've issued one credit in 18 months of running this service. Honest disclosure.

What about false positives?

We tune for actionable signal rather than maximum coverage. Alert fatigue kills monitoring effectiveness; if half of alerts are noise, the real ones get ignored. Our calibration target: false positive rate under 5%, false negative rate under 5%.

New customer onboarding includes baseline calibration during the first 2-3 weeks. Some early alerts may be calibration artifacts; they smooth out as we learn your specific sending profile.

Can I add this on top of an active engagement?

Yes, common path. Customers who completed Audit, Setup, or Recovery often add monitoring to keep the gains. Discount applies for engagements completed in the last 90 days: €39/mo for the first 6 months instead of €49/mo. Mention at subscription if you qualify.

How does cancellation work?

Cancel anytime via Telegram. No notice period required; cancellation takes effect at end of current billing month. Final week typically delivered as final summary report so you have a clean handover state.

We don't have a "are you sure?" sales call. If monitoring isn't useful for your case, cancellation should be friction- free.

How does payment work?

€49 monthly, billed in advance on subscription anniversary. Payable in any of our 11 supported cryptocurrencies via self-hosted BTCPay. Pre-paid 6-month subscription: €269 (one month free). Pre-paid 12-month subscription: €499 (two months free). Discounts available for active customers as mentioned above.

Monitoring stack composition for production sending

Production sending monitoring requires visibility across multiple layers because issues can originate at any of them. The standard stack we deploy for monitoring customers covers: receiver-side reputation (Postmaster Tools for Gmail, SNDS for Microsoft, equivalent for other major receivers), authentication outcome monitoring (DMARC aggregate report ingestion), transport-layer monitoring (TLS-RPT aggregate report ingestion), feedback loop processing (JMRP, Yahoo CFL, smaller FBL programs), blocklist monitoring (Spamhaus plus major RBLs at minimum), internal sending metrics (delivery rates, bounce rates, queue depth, per-IP and per-domain breakdowns).

Each layer surfaces different information with different latency characteristics. Internal metrics produce real-time signal of operational health from the senders perspective. Receiver-side reputation produces 24-48 hour delayed signal of how receivers are evaluating the operation. Aggregate reports produce daily signal of authentication and transport outcomes. Feedback loops produce near-real-time signal of complaint events. Blocklist monitoring produces signal at whatever frequency the monitoring cadence supports.

The integration pattern that works for production: all monitoring streams flow into a single observability infrastructure (Prometheus plus Grafana for metrics, Elasticsearch or ClickHouse for log-like data, custom dashboards for receiver-specific data). Alerts route through standard production alerting paths (PagerDuty, Opsgenie, ticket creation depending on customer setup). The unified view catches correlation patterns that monitoring streams in isolation would miss.

Our managed monitoring includes the deployment of the stack plus ongoing tuning of alerting thresholds based on what we observe in customer operations. Most operators initially set alerting thresholds either too tight (alert fatigue) or too loose (issues escalate before alerts fire); ongoing tuning addresses the calibration that single-snapshot deployment cannot get right.

Alerting thresholds that produce actionable signal

Production alerting needs to fire on real issues and stay silent for noise. The threshold patterns below capture what produces actionable signal in practice across the customer operations we monitor.

Bounce rate thresholds: alert on 7-day moving average exceeding 2% for opt-in sending (above industry baseline), 3% for cold outreach (above the typical threshold), 5% for any sending category (likely list quality crisis). The moving average smooths daily noise; thresholds based on single-day rates produce too many alerts to be actionable.

Complaint rate thresholds: alert on 7-day moving average exceeding 0.2% (warning zone before the 0.3% compliance threshold), 0.3% (compliance threshold reached), 0.5% (substantial enforcement risk). Three-tier alerting catches the warning zone with informational alerts and the enforcement zones with urgent alerts.

Reputation status alerts: alert on any Postmaster Tools Pass-to-Fail transition (urgent), any SNDS green-to-yellow transition (warning), any SNDS yellow-to-red transition (urgent), any blocklist listing (urgent for Spamhaus, warning for others). The asymmetric weighting reflects the asymmetric operational impact: Spamhaus listings produce broad damage requiring immediate response, minor blocklist listings produce narrow damage with longer response windows.

Internal sending metrics: alert on queue depth exceeding baseline (typically defined per customer based on their historical operations), delivery rate drops below baseline (suggesting receiver-side rejection), per-IP volume anomalies (suggesting configuration changes that should be intentional). The internal metrics alerts catch issues before receiver-side impact materializes.

Monitoring service tiers and what they cover

Our monitoring service comes in three tiers reflecting different operational scales. The tier choice should match the senders volume and operational complexity rather than aspiring to the highest tier by default.

Standard tier (EUR 79 monthly): covers single-domain sending operations with one or two sending IPs, monitoring across the major reputation sources, daily aggregate reporting, alerting through email plus Slack integration. Suitable for operations sending 100K to 1M monthly with simple infrastructure.

Professional tier (EUR 199 monthly): covers multi-domain operations with multiple IPs, monitoring across major and minor reputation sources, daily reporting plus per-incident analysis, alerting through PagerDuty plus standard channels. Suitable for operations sending 1M to 10M monthly with multiple sending pools or categories.

Enterprise tier (EUR 599 monthly): covers ESP-style operations with many sending domains, comprehensive monitoring including custom integrations, real-time dashboards plus daily reporting plus quarterly business reviews, dedicated incident response on enforcement events. Suitable for operations sending above 10M monthly or running multi-tenant infrastructure with customer-facing reputation requirements.

For operators uncertain which tier fits their operation, the practical answer is starting at the standard tier and upgrading when operational complexity outgrows it. Most operators stay at standard tier for 6-12 months after deployment before either upgrading or determining they have stable operations that do not need higher tier.

Deployment timeline and customer involvement

Monitoring service deployment typically completes in 2-3 weeks from engagement start. The phases: initial discovery to understand current operational visibility and gaps, registration and access setup for receiver-side monitoring tools, integration with customer existing observability infrastructure where applicable, alerting threshold calibration based on customer historical operations, dashboard customization for customer-specific KPIs.

Customer involvement during deployment is concentrated in the discovery and threshold calibration phases. The integration work happens primarily on our side; customer-side coordination is required for credentials, access permissions, and threshold preferences. Total customer time investment during deployment typically runs 4-8 hours across the deployment window.

Ongoing operations require minimal customer involvement beyond responding to alerts. Customer review meetings happen monthly for standard tier, weekly for professional tier, daily check-ins for enterprise tier during incident response. Most operators settle into a routine where monitoring runs in the background and surfaces only when intervention is needed.

Ready to catch issues before customers do?

Telegram subscription takes 10 minutes. Onboarding completes within 24 hours (registering domains/IPs across data sources). First alerts can fire same day if pre-existing issues are active. Cancel anytime, no notice required.

# Median Telegram response: 12 minutes during operating hours