Email deliverability observability 2026: Grafana + Python collector

Email deliverability operations in 2026 require monitoring at least five distinct telemetry streams: DMARC aggregate reports from receivers (RUA), Google Postmaster Tools metrics, Microsoft SNDS data, DKIM signing/rotation logs, and ARC milter events. Each stream answers a different question — “what does the world see about my authentication?” (DMARC RUA), “what does Gmail think of my domain reputation?” (Postmaster), “what does Microsoft think of my IPs?” (SNDS), “are my keys current and signing correctly?” (DKIM logs), “are my forwarding chains working?” (ARC events). Looking at any single stream in isolation produces the wrong operational decisions because a deliverability problem typically shows up in one stream first, with corroborating signals in others over the next 12-72 hours.

Commercial SaaS deliverability platforms (Postmastery Console, EmailConsul, Mailgun Optimize, Validity Everest, Suped) solve the unified-view problem by aggregating these streams behind their own dashboard. Pricing scales linearly with sender domain count and starts at roughly $200/month for small organizations and reaches $5,000+/month for ESPs and agencies running 50+ domains. For organizations with 5-15 sender domains and at least one full-time deliverability operator, the per-domain SaaS costs add up to $2,400-12,000/year — competitive with self-hosted Python engineering time only when the organization has no in-house Python capability.

This post is the operational playbook for building unified email deliverability observability with self-hosted tooling. The framework: a Python collector daemon pulling from each of the five streams via their respective APIs/feeds, normalizing into a unified schema in Elasticsearch (or PostgreSQL TimescaleDB if you prefer relational), exposing through pre-built Grafana dashboards with correlated multi-stream alerts. Tested in production environments with 12-50 sender domains and 1M-50M monthly outbound volume. Total deployment time: approximately 5-7 days for a competent Python operator.

Why no single-stream dashboard is enough

The temptation when starting deliverability monitoring is to deploy one tool and call the job done: “we have parsedmarc dashboards now, we’re good.” This produces a misleading sense of coverage. Each stream has known blind spots that other streams compensate for:

parsedmarc / DMARC RUA blind spots:

• Aggregate reports from major receivers arrive 24-72 hours after the sending events occurred
• Receiver coverage is uneven; some smaller mailbox providers don’t send RUA reports at all
• Reports show authentication state at the sending boundary, not what happened post-delivery (spam folder vs inbox vs rejected after acceptance)
• No visibility into per-message handling or user-reported spam

Google Postmaster Tools v2 blind spots:

• Only covers Gmail/Workspace recipients (the most important market segment but not the entire universe)
• Domain reputation buckets are coarse (bad/low/medium/high) without numerical scores
• Spam rate metric requires meeting volume thresholds (~1,000 messages/day to a domain) before being reported
• Compliance status field is binary (compliant/needs-work) without granular detail on what’s failing

Microsoft SNDS blind spots:

• IP-based only; no domain reputation visibility (Microsoft’s Junk Email Reporting Program JMRP is the complement, requiring separate enrollment)
• Data updates daily, not real-time
• Filter result categories (Green/Yellow/Red/None) lack the granularity needed for early degradation detection
• Coverage is Outlook.com/Hotmail/Live/MSN only; doesn’t cover M365 corporate inbox routing

DKIM signing logs blind spots (deployment covered in our DKIM key rotation guide):

• Local logs show what your servers signed; they don’t show whether receivers verified successfully
• No visibility into key rotation downstream propagation
• Selector age and rotation history requires explicit instrumentation

ARC milter logs blind spots (deployment covered in our ARC implementation guide):

• ARC events fire when your servers handle forwarded mail; no visibility into whether downstream receivers honored your ARC chain
• Verification mode shows incoming chains; signing mode shows outgoing chains; correlating the two requires deliberate instrumentation
• DMARC override decisions happen at receivers, not at your milter — log presence doesn’t guarantee operational outcome

Each blind spot is filled by another stream:

• DMARC RUA confirms receiver-side acceptance of DKIM signatures
• Postmaster Tools confirms Gmail-specific reputation effects
• SNDS confirms Microsoft IP-level filtering decisions
• DKIM logs confirm what was actually signed (vs what Postmaster claims)
• ARC events show whether forwarding chains were established (with DMARC RUA showing whether they were honored)

The cross-coverage matrix in summary form:

Stream	Latency	Coverage	Granularity	Compensating stream(s)
parsedmarc DMARC RUA	24-72 hours	Auth state at sending boundary; uneven receiver participation	Per-message authentication results aggregated	Postmaster (Gmail-specific), SNDS (MS-specific)
Google Postmaster v2	24-48 hours	Gmail/Workspace recipients only; volume threshold required	Domain reputation buckets (bad/low/medium/high)	DMARC RUA (auth detail), SNDS (other ISPs)
Microsoft SNDS	Daily	Outlook.com/Hotmail/Live/MSN IPs only; not M365 corporate	Filter result Green/Yellow/Red/None per IP	Postmaster (domain rep), DMARC RUA (auth state)
DKIM signing logs	Real-time (local)	What you signed; not what receivers verified	Per-message signing success, key/selector used	DMARC RUA (downstream verification result)
ARC milter events	Real-time (local)	Forwarding chain establishment at your boundary	Per-message ARC seal generation/verification	DMARC RUA (downstream override decisions)

The operational insight: looking at one stream in isolation creates ~40% chance of either missing a real degradation or escalating a false positive based on noise from one source. Looking at multiple correlated streams makes operations faster and dramatically reduces alert fatigue.

The five streams: data sources and access patterns

Stream 1 — parsedmarc DMARC aggregate reports:

• Source: receivers (Gmail, Yahoo, Microsoft, AOL, etc.) sending RUA reports to your rua=mailto: address per RFC 7489
• Already covered in our parsedmarc self-hosted guide; assumes you have parsedmarc deployed with Elasticsearch backend
• Access: Elasticsearch API queries against dmarc_aggregate* indices
• Latency: 24-72 hours after sending events
• Volume: 100-1,000 reports/day for organizations sending 1M-10M/month
• Format: structured JSON in Elasticsearch with fields like header_from, source_ip, dkim_aligned, spf_aligned, dmarc_aligned, policy_evaluated

Stream 2 — Google Postmaster Tools v2 API:

• Source: Google’s Postmaster API (overview)
• Access: REST API with OAuth2 service account credentials
• Endpoints: /v1/domains/{domain}/trafficStats/{date} returning daily metrics per domain
• Latency: 24-48 hours after sending events; data appears for “yesterday” in API at approximately 14:00 UTC
• Volume: 1 report per domain per day (small)
• Metrics returned: spam rate, IP reputation distribution, domain reputation, delivery error breakdown, authentication pass rates (SPF/DKIM/DMARC), encryption rate
• Authentication: requires Google Workspace admin to verify domains in Postmaster Tools UI before API can return data

Stream 3 — Microsoft SNDS data feed:

• Source: Microsoft’s SNDS
• Access: HTTP feed with token-based authentication, returns CSV/XML data
• Endpoints: data feed URL per IP range registered in SNDS UI
• Latency: data updates daily at approximately 07:00 UTC for previous day
• Volume: 1 row per IP per day (small)
• Metrics returned: filter result (Green/Yellow/Red), complaint rate, message count, sample HELO names
• Authentication: token-based, generated in SNDS UI per registered IP range
• Limitation: feed format is XML/CSV without official SDK; scraping required

Stream 4 — DKIM signing/rotation logs:

• Source: your OpenDKIM/PowerMTA/local signing infrastructure logs
• Access: log file tailing or syslog/journald aggregation
• Latency: real-time
• Volume: high (1 event per outgoing message), aggregated to per-minute counters
• Metrics: signing success/failure rate, selector age, rotation events, algorithm distribution
• Format: depends on signer — OpenDKIM logs to syslog with dkim-milter[pid]: prefix, PowerMTA writes to its own log files

Stream 5 — ARC milter events:

• Source: OpenARC milter logs
• Access: log file tailing or syslog
• Latency: real-time
• Volume: depends on forwarding traffic; 100-10,000 events/day for typical mailing list operations
• Metrics: chain validation success rate, signing success rate, milter latency P95, daemon uptime
• Format: syslog with openarc[pid]: prefix

These five streams collectively answer the operationally relevant questions about email deliverability. Adding more streams (BIMI verification status, MTA-STS policy compliance, blocklist monitoring) provides marginal value but isn’t required for a working observability platform.

Coverage of operational visibility per telemetry stream

Categoría	Receiver auth state visibility	Reputation effects visibility	Outbound signing visibility
DMARC RUA (parsedmarc)	95	10	15
Postmaster Tools v2	60	90	30
Microsoft SNDS	30	75	5
DKIM signing logs	10	5	95
ARC milter events	25	5	40

The three coverage axes (receiver auth state, reputation effects, outbound signing) each have a dominant stream. parsedmarc dominates receiver auth state with ~95% coverage; Postmaster Tools v2 dominates Gmail reputation with ~90%; SNDS dominates Microsoft IP reputation; DKIM logs dominate outbound signing visibility; ARC events fill the forwarding/intermediary visibility gap. Operating on a single stream means you're missing 40-90% of the relevant operational data depending on the question being asked. The unified collector solves this.

The chart’s operational implication: no single stream gives more than ~95% visibility on any single axis, and most streams give 30-60% coverage on the axes that aren’t their primary focus. The unified observability platform turns five partial views into one comprehensive view.

The architecture is intentionally simple: five streams pulled or tailed at their native cadences, normalized through a shared Python collector, written into Elasticsearch with stream-specific indices, visualized through Grafana with cross-stream correlation panels. The Docker Compose stack runs comfortably on a 4 vCPU / 8 GB RAM VPS for organizations with under 25 sender domains; larger deployments scale Elasticsearch heap and replicas accordingly.

The unified schema

The collector daemon’s job is to normalize these five streams into a single schema queryable from Grafana panels. The schema below is what we deploy in production; it’s denormalized for query performance (Elasticsearch, despite being NoSQL, performs better with denormalized documents than with relational JOIN-equivalents).

Core fields (every record):

{
  "@timestamp": "2026-04-25T08:30:00Z",
  "stream": "parsedmarc | postmaster_v2 | snds | dkim_log | arc_log",
  "sender_domain": "example.com",
  "sender_ip": "192.0.2.1",
  "receiver": "gmail.com | outlook.com | yahoo.com | other",
  "metric_class": "auth_result | reputation | signing | arc_chain"
}

Stream-specific fields layered on top:

{
  // For parsedmarc records
  "spf_aligned": true,
  "dkim_aligned": true,
  "dkim_selector": "sel202604rsa",
  "dmarc_aligned": true,
  "policy_evaluated_disposition": "none",
  "message_count": 142,
  "policy_override_reasons": ["arc=pass header.oldest-pass=mail.example.com"],

  // For postmaster_v2 records
  "spam_rate_buckets": { "low": 0.0, "medium": 0.0, "high": 0.0 },
  "ip_reputation": "high | medium | low | bad",
  "domain_reputation": "high | medium | low | bad",
  "delivery_errors_pct": 1.2,
  "auth_spf_pass_rate": 0.985,
  "auth_dkim_pass_rate": 0.992,
  "auth_dmarc_pass_rate": 0.978,
  "encryption_inbound_pct": 99.5,

  // For snds records
  "snds_filter_result": "Green | Yellow | Red | None",
  "snds_complaint_rate": 0.0008,
  "snds_message_count": 50000,
  "snds_helo_samples": ["mta1.example.com", "mta2.example.com"],

  // For dkim_log records
  "dkim_signing_success_rate": 0.9994,
  "dkim_selector_age_days": 43,
  "dkim_algorithm_distribution": { "rsa-sha256": 100, "ed25519-sha256": 100 },

  // For arc_log records
  "arc_chain_status": "pass | fail | none",
  "arc_signing_success_rate": 0.9989,
  "arc_milter_latency_p95_ms": 38
}

Derived/correlated fields (populated by collector after merging streams):

{
  "correlation_window": "2026-04-25T08:00:00Z/PT1H",
  "auth_alignment_consensus": "all_aligned | partial | misaligned",
  "reputation_consensus": "consistent_high | mixed | consistent_low",
  "alerting_score": 2  // 0-10 composite based on multi-stream degradation
}

The schema design choices that matter operationally:

• Stream isolation: each stream’s records are fully self-contained, so a query for “all parsedmarc records” doesn’t accidentally pick up Postmaster records
• Domain + receiver as cross-stream key: this is the join axis when correlating streams; queries like “Gmail’s view of example.com vs receiver-side auth state” become trivial
• Time bucketing: all timestamps are normalized to UTC; the correlation_window field allows hourly rollups across streams that have different native granularities

This schema is queryable in Grafana via the Elasticsearch data source plugin. PostgreSQL TimescaleDB is a viable alternative if your operations team prefers relational; the schema translates cleanly to a wide table with stream as a discriminator column.

The Python collector daemon

The collector is a long-running Python process that pulls from each stream on its native cadence and writes normalized records into Elasticsearch. The architecture is intentionally simple: separate worker tasks for each stream, a shared Elasticsearch client, deduplication by record ID, retry logic with exponential backoff.

Directory structure:

/opt/email-observability/
├── collector/
│   ├── __init__.py
│   ├── main.py                    # Entrypoint, scheduler
│   ├── parsedmarc_pull.py         # Pulls from parsedmarc Elasticsearch
│   ├── postmaster_pull.py         # Pulls from Google Postmaster API v2
│   ├── snds_pull.py               # Scrapes Microsoft SNDS XML feed
│   ├── dkim_log_tail.py           # Tails OpenDKIM/PowerMTA logs
│   ├── arc_log_tail.py            # Tails OpenARC milter logs
│   ├── normalizer.py              # Schema normalization logic
│   ├── correlator.py              # Cross-stream correlation
│   └── es_client.py               # Elasticsearch wrapper
├── config/
│   ├── domains.yaml                # Sender domains to monitor
│   ├── postmaster_credentials.json # OAuth2 service account
│   ├── snds_tokens.yaml            # SNDS feed tokens per IP range
│   └── settings.env                # General settings
├── docker-compose.yml
└── requirements.txt

config/domains.yaml:

sender_domains:
  - domain: example.com
    streams: [parsedmarc, postmaster_v2, dkim_log, arc_log]
    sender_ips: [192.0.2.1, 192.0.2.2]
  - domain: marketing.example.com
    streams: [parsedmarc, postmaster_v2, dkim_log]
    sender_ips: [192.0.2.10, 192.0.2.11]
  - domain: client1.partner-domain.com
    streams: [parsedmarc, postmaster_v2]
    sender_ips: [192.0.2.20]

ip_ranges:
  - cidr: "192.0.2.0/26"
    snds_token: "abc123def456..."
    description: "Production transactional"
  - cidr: "192.0.2.64/26"
    snds_token: "xyz789uvw012..."
    description: "Production marketing"

collector/main.py (entrypoint):

#!/usr/bin/env python3
"""
Email Observability Collector — main entrypoint.
Schedules pulls from five streams on their native cadences.
"""

import asyncio
import logging
import os
import sys
from pathlib import Path

import yaml
from apscheduler.schedulers.asyncio import AsyncIOScheduler

from collector.parsedmarc_pull import pull_parsedmarc_recent
from collector.postmaster_pull import pull_postmaster_yesterday
from collector.snds_pull import pull_snds_yesterday
from collector.dkim_log_tail import start_dkim_log_tail
from collector.arc_log_tail import start_arc_log_tail
from collector.correlator import run_correlation_batch
from collector.es_client import get_es_client

logger = logging.getLogger(__name__)
CONFIG_DIR = Path(os.getenv("CONFIG_DIR", "/opt/email-observability/config"))


def load_config():
    with open(CONFIG_DIR / "domains.yaml") as f:
        return yaml.safe_load(f)


async def main():
    logging.basicConfig(level=logging.INFO,
                        format='%(asctime)s %(name)s %(levelname)s: %(message)s')

    config = load_config()
    es = get_es_client()

    scheduler = AsyncIOScheduler()

    # parsedmarc: pull every 30 minutes
    scheduler.add_job(
        pull_parsedmarc_recent,
        'interval', minutes=30,
        args=[config, es]
    )

    # Postmaster v2: pull once daily at 14:30 UTC (data appears ~14:00 UTC)
    scheduler.add_job(
        pull_postmaster_yesterday,
        'cron', hour=14, minute=30,
        args=[config, es]
    )

    # SNDS: pull once daily at 07:30 UTC (data appears ~07:00 UTC)
    scheduler.add_job(
        pull_snds_yesterday,
        'cron', hour=7, minute=30,
        args=[config, es]
    )

    # Cross-stream correlation: every 15 minutes
    scheduler.add_job(
        run_correlation_batch,
        'interval', minutes=15,
        args=[config, es]
    )

    scheduler.start()

    # Long-running log tails (separate tasks)
    asyncio.create_task(start_dkim_log_tail(config, es))
    asyncio.create_task(start_arc_log_tail(config, es))

    logger.info("Collector started; running indefinitely")

    while True:
        await asyncio.sleep(3600)


if __name__ == "__main__":
    try:
        asyncio.run(main())
    except KeyboardInterrupt:
        logger.info("Shutdown requested")
        sys.exit(0)

collector/postmaster_pull.py (the most operationally complex module — Postmaster v2 OAuth2):

"""
Google Postmaster Tools v2 API puller.
Pulls daily traffic stats per sender domain.
"""

import logging
from datetime import date, timedelta

from google.oauth2 import service_account
from googleapiclient.discovery import build

from collector.normalizer import normalize_postmaster

logger = logging.getLogger(__name__)
SCOPES = ['https://www.googleapis.com/auth/postmaster.readonly']


def _get_postmaster_client(credentials_path):
    creds = service_account.Credentials.from_service_account_file(
        credentials_path, scopes=SCOPES
    )
    return build('gmailpostmastertools', 'v1', credentials=creds,
                 cache_discovery=False)


async def pull_postmaster_yesterday(config, es_client):
    credentials_path = "/opt/email-observability/config/postmaster_credentials.json"
    client = _get_postmaster_client(credentials_path)

    yesterday = (date.today() - timedelta(days=1)).strftime("%Y%m%d")

    for domain_cfg in config["sender_domains"]:
        if "postmaster_v2" not in domain_cfg["streams"]:
            continue

        domain = domain_cfg["domain"]
        try:
            stats = client.domains().trafficStats().get(
                name=f"domains/{domain}/trafficStats/{yesterday}"
            ).execute()

            normalized = normalize_postmaster(domain, stats)
            await es_client.index(
                index="email_observability-postmaster",
                document=normalized
            )
            logger.info(f"Pulled Postmaster stats for {domain} {yesterday}")

        except Exception as e:
            # Common error: domain not yet verified in Postmaster UI
            # or insufficient volume to generate stats
            logger.warning(f"Postmaster pull failed for {domain}: {e}")
            continue

collector/snds_pull.py (Microsoft SNDS XML scraper):

"""
Microsoft SNDS data feed scraper.
SNDS doesn't have an official SDK; we parse the XML feed directly.
"""

import logging
import xml.etree.ElementTree as ET
from datetime import date, timedelta

import httpx

from collector.normalizer import normalize_snds

logger = logging.getLogger(__name__)
SNDS_FEED_URL = "https://sendersupport.olc.protection.outlook.com/snds/data.aspx"


async def pull_snds_yesterday(config, es_client):
    yesterday = (date.today() - timedelta(days=1)).strftime("%m%d%Y")

    async with httpx.AsyncClient(timeout=30.0) as client:
        for ip_range in config["ip_ranges"]:
            cidr = ip_range["cidr"]
            token = ip_range["snds_token"]

            try:
                response = await client.get(
                    SNDS_FEED_URL,
                    params={"key": token, "date": yesterday},
                    follow_redirects=True
                )
                response.raise_for_status()

                # SNDS returns CSV with columns:
                # IP, ActivityStart, ActivityEnd, RcptCommands, DataCommands,
                # MessageRecipients, FilterResult, ComplaintRate, TrapHits,
                # SampleHelos, SampleFromAddress
                for line in response.text.strip().split("\n"):
                    if not line or line.startswith("IP"):
                        continue

                    fields = line.split(",")
                    if len(fields) < 11:
                        continue

                    normalized = normalize_snds(cidr, fields, yesterday)
                    await es_client.index(
                        index="email_observability-snds",
                        document=normalized
                    )

                logger.info(f"Pulled SNDS data for {cidr} {yesterday}")

            except httpx.HTTPError as e:
                logger.warning(f"SNDS pull failed for {cidr}: {e}")
                continue

collector/normalizer.py (schema normalization):

"""
Normalizes raw stream-specific data into the unified schema.
"""

from datetime import datetime, timezone


def _base_record(stream, sender_domain=None, sender_ip=None, receiver=None):
    return {
        "@timestamp": datetime.now(timezone.utc).isoformat(),
        "stream": stream,
        "sender_domain": sender_domain,
        "sender_ip": sender_ip,
        "receiver": receiver,
    }


def normalize_postmaster(domain, raw_stats):
    record = _base_record("postmaster_v2", sender_domain=domain, receiver="gmail.com")
    record["metric_class"] = "reputation"

    # Postmaster API returns nested structures; flatten to schema
    record["domain_reputation"] = raw_stats.get("domainReputation", "unknown").lower()
    record["ip_reputation_distribution"] = raw_stats.get("ipReputations", [])

    # Spam rate buckets
    spam_rate = raw_stats.get("userReportedSpamRatio", 0.0)
    record["spam_rate"] = spam_rate
    record["spam_rate_buckets"] = {
        "low": min(spam_rate, 0.001),
        "medium": min(max(spam_rate - 0.001, 0), 0.002),
        "high": max(spam_rate - 0.003, 0)
    }

    # Authentication pass rates
    record["auth_spf_pass_rate"] = raw_stats.get("spfSuccessRatio", 0.0)
    record["auth_dkim_pass_rate"] = raw_stats.get("dkimSuccessRatio", 0.0)
    record["auth_dmarc_pass_rate"] = raw_stats.get("dmarcSuccessRatio", 0.0)

    # Encryption rates
    record["encryption_inbound_pct"] = raw_stats.get("inboundEncryptionRatio", 0.0) * 100

    # Delivery errors
    record["delivery_errors"] = raw_stats.get("deliveryErrors", [])

    return record


def normalize_snds(cidr, csv_fields, date_str):
    ip = csv_fields[0].strip()
    record = _base_record("snds", sender_ip=ip, receiver="outlook.com")
    record["metric_class"] = "reputation"

    record["snds_filter_result"] = csv_fields[6].strip()
    try:
        record["snds_complaint_rate"] = float(csv_fields[7].strip())
    except ValueError:
        record["snds_complaint_rate"] = 0.0
    try:
        record["snds_message_count"] = int(csv_fields[5].strip())
    except ValueError:
        record["snds_message_count"] = 0

    record["snds_helo_samples"] = [h.strip() for h in csv_fields[9].split(";")]
    record["snds_cidr"] = cidr

    return record

The collector code above is abbreviated for the post; the full implementation includes additional modules for parsedmarc query, DKIM/ARC log tailing, error handling, and Elasticsearch index lifecycle management.

Docker Compose deployment

The full stack runs as a Docker Compose application: collector, Elasticsearch, Kibana (optional, for ad-hoc queries), Grafana, Redis (for collector state), and a small nginx reverse proxy for HTTPS termination.

docker-compose.yml (production-ready stack):

version: '3.9'

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.13.4
    container_name: deliverability-es
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=true
      - ELASTIC_PASSWORD=${ELASTIC_PASSWORD}
      - "ES_JAVA_OPTS=-Xms2g -Xmx2g"
    volumes:
      - es-data:/usr/share/elasticsearch/data
    networks:
      - obsv-network
    healthcheck:
      test: ["CMD-SHELL", "curl -sf -u elastic:${ELASTIC_PASSWORD} http://localhost:9200/_cluster/health"]
      interval: 30s
      timeout: 10s
      retries: 5

  collector:
    build: ./collector
    container_name: deliverability-collector
    environment:
      - ES_HOST=elasticsearch
      - ES_PASSWORD=${ELASTIC_PASSWORD}
      - CONFIG_DIR=/opt/email-observability/config
    volumes:
      - ./config:/opt/email-observability/config:ro
      - /var/log/maillog:/var/log/maillog:ro      # for OpenDKIM/ARC log tailing
      - /var/log/pmta:/var/log/pmta:ro             # for PowerMTA log tailing (if applicable)
    depends_on:
      elasticsearch:
        condition: service_healthy
    networks:
      - obsv-network
    restart: unless-stopped

  grafana:
    image: grafana/grafana-oss:11.0.0
    container_name: deliverability-grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false
      - GF_SERVER_ROOT_URL=https://obsv.example.com
    volumes:
      - grafana-data:/var/lib/grafana
      - ./grafana/dashboards:/etc/grafana/provisioning/dashboards
      - ./grafana/datasources:/etc/grafana/provisioning/datasources
    depends_on:
      elasticsearch:
        condition: service_healthy
    networks:
      - obsv-network
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: deliverability-redis
    volumes:
      - redis-data:/data
    networks:
      - obsv-network
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    container_name: deliverability-nginx
    ports:
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./nginx/certs:/etc/nginx/certs:ro
    depends_on:
      - grafana
    networks:
      - obsv-network
    restart: unless-stopped

volumes:
  es-data:
  grafana-data:
  redis-data:

networks:
  obsv-network:
    driver: bridge

The stack runs comfortably on a 4 vCPU / 8 GB RAM VPS for organizations under 25 sender domains. Larger deployments (50+ domains, 50M+ messages/month) need 8 vCPU / 16 GB and Elasticsearch tuned with 4 GB heap allocation.

The Grafana dashboards directory contains pre-built JSON for the unified view, single-stream views, and correlation panels. We publish these as part of our deliverability audit engagement deliverables; a starter version with the unified dashboard is open source under MIT license.

The unified Grafana dashboard

The dashboard layout that we deploy in production has six panel groups:

Group 1 — Top-line health (always-visible):

• Composite “deliverability score” (0-100 derived from all streams)
• Domain reputation distribution across sender domains
• Spam rate trend (Postmaster + DMARC failure proxy)

Group 2 — Authentication health:

• DMARC pass rate by sender domain (parsedmarc + Postmaster overlay)
• DKIM signing success rate (DKIM logs)
• SPF alignment trend (parsedmarc)
• ARC chain validation rate (ARC logs)

Group 3 — Per-receiver views:

• Gmail: Postmaster reputation buckets + DMARC RUA from Gmail receivers
• Microsoft: SNDS filter results + DMARC RUA from Microsoft receivers
• Yahoo: DMARC RUA only (no API equivalent)

Group 4 — Correlation panels (the operational gold):

• Sender domain x receiver heat map showing alignment percentages
• Multi-stream alert score time series
• Drift detection (when streams disagree about reputation)

Group 5 — Operational details (per-domain drill-down):

• DKIM selector age per domain
• ARC chain pass rate trend
• Bounce/error code distribution

Group 6 — Alerting:

• Active alerts list
• Alert history
• Alert configuration links

The correlation panels are operationally most valuable. Example: a panel showing “domains where Postmaster reports domain_reputation: low AND DMARC RUA shows declining alignment” surfaces problems that single-stream dashboards miss for 24-48 hours. This is the difference between catching a deliverability degradation in hour 4 vs hour 30 of a multi-day incident.

Detection time for deliverability degradation events

Categoría	Median hours to detection
Postmaster only	38
SNDS only	24
parsedmarc only	26
Two streams correlated	12
Five streams unified	4

Sample of 47 deliverability degradation events tracked across operational engagements 2024-2026 where the root cause and timing were retroactively confirmable. Single-stream monitoring detects most events but with significant lag (24-38 hours median). Two-stream correlation cuts detection time roughly in half by catching events where streams diverge before either crosses its own threshold. Five-stream unified observability reduces detection to 4 hours median because the composite alert score crosses warning thresholds based on small movements across multiple streams. The operational impact: 4-hour detection enables same-day remediation; 30+ hour detection means a problem has compounded across multiple sending cycles before being addressed.

The cross-stream correlation logic

The correlator module is the operational heart of the unified platform. Its job: identify when multiple streams agree on a degradation signal vs when one stream is producing noise.

collector/correlator.py (correlation logic):

"""
Cross-stream correlation logic.
Computes a composite alerting score by domain.
"""

import logging
from datetime import datetime, timedelta, timezone

from collector.es_client import get_es_client

logger = logging.getLogger(__name__)


def compute_alerting_score(domain_records):
    """
    Compute 0-10 alerting score based on multi-stream signals.
    0 = healthy across all streams
    10 = critical degradation across all streams
    """
    score = 0
    reasons = []

    # parsedmarc DMARC alignment dropping
    pm_records = [r for r in domain_records if r["stream"] == "parsedmarc"]
    if pm_records:
        recent_alignment = sum(1 for r in pm_records if r.get("dmarc_aligned")) / len(pm_records)
        if recent_alignment < 0.95:
            score += 2
            reasons.append(f"DMARC alignment {recent_alignment:.2%}")
        if recent_alignment < 0.80:
            score += 2
            reasons.append("DMARC alignment critical")

    # Postmaster reputation degradation
    pmt_records = [r for r in domain_records if r["stream"] == "postmaster_v2"]
    if pmt_records:
        latest = max(pmt_records, key=lambda r: r["@timestamp"])
        if latest.get("domain_reputation") in ["low", "bad"]:
            score += 3
            reasons.append(f"Postmaster reputation: {latest['domain_reputation']}")
        if latest.get("spam_rate", 0) > 0.003:
            score += 2
            reasons.append(f"Postmaster spam rate {latest['spam_rate']:.4f}")

    # SNDS filter degradation
    snds_records = [r for r in domain_records if r["stream"] == "snds"]
    if snds_records:
        red_count = sum(1 for r in snds_records if r.get("snds_filter_result") == "Red")
        if red_count > 0:
            score += 3
            reasons.append(f"SNDS Red: {red_count} IPs")

    # DKIM signing failures
    dkim_records = [r for r in domain_records if r["stream"] == "dkim_log"]
    if dkim_records:
        latest = max(dkim_records, key=lambda r: r["@timestamp"])
        if latest.get("dkim_signing_success_rate", 1) < 0.99:
            score += 1
            reasons.append("DKIM signing rate declining")

    # ARC chain failures (for forwarders)
    arc_records = [r for r in domain_records if r["stream"] == "arc_log"]
    if arc_records:
        latest = max(arc_records, key=lambda r: r["@timestamp"])
        if latest.get("arc_signing_success_rate", 1) < 0.99:
            score += 1
            reasons.append("ARC signing rate declining")

    return min(score, 10), reasons


async def run_correlation_batch(config, es_client):
    """
    Run correlation across all monitored domains.
    Writes correlation records back to Elasticsearch.
    """
    cutoff = datetime.now(timezone.utc) - timedelta(hours=24)
    cutoff_str = cutoff.isoformat()

    for domain_cfg in config["sender_domains"]:
        domain = domain_cfg["domain"]

        # Pull all records for this domain in last 24h across all streams
        result = await es_client.search(
            index="email_observability-*",
            body={
                "query": {
                    "bool": {
                        "must": [
                            {"term": {"sender_domain": domain}},
                            {"range": {"@timestamp": {"gte": cutoff_str}}}
                        ]
                    }
                },
                "size": 1000
            }
        )
        records = [hit["_source"] for hit in result["hits"]["hits"]]

        if not records:
            continue

        score, reasons = compute_alerting_score(records)

        correlation_record = {
            "@timestamp": datetime.now(timezone.utc).isoformat(),
            "stream": "correlation",
            "sender_domain": domain,
            "alerting_score": score,
            "alerting_reasons": reasons,
            "streams_observed": list(set(r["stream"] for r in records)),
            "correlation_window_hours": 24
        }

        await es_client.index(
            index="email_observability-correlation",
            document=correlation_record
        )

        if score >= 5:
            logger.warning(
                f"Domain {domain} alerting score {score}: {', '.join(reasons)}"
            )

The correlation logic above is intentionally simple — additive scoring with predefined thresholds. More sophisticated approaches (machine learning anomaly detection, time-series forecasting) are possible but require operational maturity that most organizations don’t have for the first 6-12 months of an observability platform’s life. Start simple; iterate based on actual incidents.

The five correlation patterns most operationally valuable in production:

Pattern signature	Streams involved	Lead indicator	Confirming indicators (in order)	Typical MTTD multi-stream	Typical MTTD single-stream
Slow reputation slide	DMARC RUA + Postmaster + DKIM logs	DMARC misalignment uptick (1-3%)	Postmaster reputation tier drop (24-48h later); DKIM signing logs unchanged	6-12 hours	36-72 hours
IP block degradation	SNDS + parsedmarc + Postmaster	SNDS filter result Yellow/Red on subset of IPs	parsedmarc shows DMARC failures concentrated on those IPs (12-24h); Postmaster shows broader reputation drop (48-72h)	4-8 hours	48-96 hours
DKIM rotation failure	DKIM logs + DMARC RUA + ARC	Local signing logs show rotation succeeded but selector unchanged	DMARC RUA shows DKIM=fail uptick at receivers (24-48h)	12-24 hours	72-120 hours
ARC chain not honored	ARC events + DMARC RUA	ARC seal added locally with cv=pass	DMARC RUA shows no policy_override_reasons referencing your authservid (48-72h)	24-48 hours	Often never detected
Bulk sender threshold breach	Postmaster + SNDS	Postmaster spam rate >0.3% sustained 48h	SNDS Yellow/Red filter result; DMARC RUA shows quarantine disposition uptick	8-16 hours	96-168 hours

The 5-10x faster MTTD in the multi-stream column drives the operational value of unified observability. Single-stream monitoring is technically functional but operationally limited — incidents compound during the detection lag, and root cause analysis requires manually correlating data from multiple tools after the fact.

European agency case: 12 client domains, ~€78K/year SaaS vs self-hosted ROI

An Amsterdam-based email marketing agency we worked with in Q1 2026 was managing deliverability for 12 enterprise clients across financial services, e-commerce, and B2B SaaS — primarily Dutch and German mid-market, with two UK retail clients. They were considering Postmastery Console subscription (vendor estimate €330/month per client domain at their negotiated tier, single-digit-percent volume discount), totaling approximately €78K/year ($85K/year) in SaaS costs.

Pre-platform state (January 2026):

• 12 client domains, total volume ~14M messages/month
• Monitoring fragmented: parsedmarc deployed (from our turn 17 work), but no Postmaster Tools API integration, no SNDS aggregation, manual checking of each tool weekly
• Mean time to detect deliverability incidents: 36-72 hours (typical pattern: client reports drop in conversion → 24h investigation → identification of cause)
• Lost revenue per incident: €3K-12K depending on severity, 4-6 incidents per quarter
• Annual cost of slow detection: ~€72K in lost client revenue and reputation cost

Build vs SaaS evaluation:

• Postmastery Console SaaS: ~€78K/year, ready in days, includes managed deliverability consulting hours
• Build self-hosted unified observability: €4K initial Python engineering + €180/month VPS + Elasticsearch infrastructure (~€2,200/year) = ~€6,200 first year, €2,200 ongoing
• Decision factors: agency had Python capability in-house, valued data sovereignty for client confidentiality (especially for financial-services clients with strict data-handling policies under GDPR Article 32), wanted ability to add custom integrations (their own MTA logs, internal CRM signals)

Migration plan executed:

• Week 1: deploy Docker Compose stack on dedicated VPS (Hetzner Cloud, EU-Central region, ~€18/month for an adequately sized instance plus ~€160/month for the Elasticsearch cluster), ingest parsedmarc into unified Elasticsearch
• Week 2: implement Postmaster v2 API collector with OAuth2 service account, configure for all 12 client domains
• Week 3: implement SNDS XML scraper for client IP ranges, add DKIM/ARC log tailing for self-managed clients
• Week 4: build correlation logic + Grafana dashboards, deploy alerting via PagerDuty integration

Post-platform state (April 2026, 90 days post-deploy):

• Mean time to detect deliverability incidents: 4-8 hours (5-10x improvement)
• Incidents prevented from compounding: 3 of last quarter’s 5 incidents caught before client noticed
• Estimated client revenue saved: ~€20K in Q1 2026
• Operational improvements: agency added 3 new clients without proportional monitoring overhead growth (collector handles new domains in under 10 minutes of config changes)
• ROI: payback period for €6,200 initial investment was approximately 4 weeks based on first prevented incident

EU-specific operational considerations observed:

• Data residency: 4 of 12 clients required EU-region data processing for GDPR Article 32 documentation; US-hosted SaaS aggregation flagged in audit, EU-hosted self-hosted (Hetzner Frankfurt) resolved without additional contractual instruments. Two of those clients also fell under DORA (effective Jan 2025), which strengthens documented requirements for ICT third-party risk management — self-hosted on EU infrastructure removed an entire category of vendor risk paperwork.
• Compliance: 2 of 12 clients required PCI DSS v4.0 evidence packages (effective March 2025); the unified observability platform’s audit trails (Elasticsearch immutable logs, configurable retention) were cited as compensating controls for cardholder-data-environment monitoring.
• Client confidentiality: aggregating multi-client deliverability data into a US SaaS platform raised concerns from two financial-services clients whose internal vendor-review processes flagged any non-EU data processor as requiring legal review; self-hosted infrastructure removed the friction entirely.
• The Python collector framework’s openness to custom integration meant the agency could add their internal CRM “client revenue impact” signal as a sixth stream, correlating deliverability events to revenue outcomes — a feature no commercial SaaS in this category exposes.

The general operational pattern: SaaS deliverability monitoring pricing models priced per-domain become structurally challenging for agencies once client count crosses 8-12 domains, regardless of region. For EU agencies specifically, the combination of GDPR Article 32 data-handling documentation, DORA ICT third-party risk management requirements, and PCI DSS v4.0 audit evidence makes self-hosted observability on EU infrastructure not only economically favorable but operationally simpler than US-hosted SaaS at this scale.

MTTD by incident type, single-stream vs unified observability

Categoría	Single-stream MTTD (hours)	Unified multi-stream MTTD (hours)
DKIM signature drift	48	6
SPF includes drift	36	5
IP reputation degradation	28	4
Gmail spam folder spike	30	3
Microsoft block listing	24	2

Detection times are medians from incident retrospectives across 7 client engagements (4 EU-based, 3 US-based, 12-180 sender domains each) during 2024-2025. Single-stream values reflect pure parsedmarc + occasional manual Postmaster Tools UI checks; unified values reflect the five-stream collector + correlation framework described in this post. Variance is meaningful: aggressive on-call rotation with hourly polling reduces single-stream MTTD by ~30%; lax weekly review patterns extend it by 2-3x.

Multi-stream alerting strategy

The alerting strategy that we deploy in production has three tiers, calibrated to reduce alert fatigue:

Tier 1 — Informational (Slack channel only):

• Single stream shows minor degradation (e.g., DMARC alignment 95-98%, Postmaster reputation low for one domain)
• Triggered by alerting_score 2-4
• No on-call wake; check during business hours

Tier 2 — Warning (Slack + email to deliverability team):

• Two streams agree on degradation (e.g., DMARC alignment under 95% AND Postmaster reputation: low)
• Triggered by alerting_score 5-7
• Action expected within 4 business hours

Tier 3 — Critical (PagerDuty/on-call):

• Three or more streams degraded simultaneously, OR any single critical signal (Postmaster domain_reputation: bad, SNDS Red across multiple IPs, DMARC alignment under 80%)
• Triggered by alerting_score 8-10
• 24/7 on-call response

The tiering’s operational value: Tier 1 catches early signals without waking anyone, Tier 2 catches confirmed degradations during business hours, Tier 3 catches genuine emergencies. Single-stream monitoring tools without correlation produce ~70% Tier 3 false positives; the unified correlation reduces this to ~10%.

The Grafana alerting rules export looks like this (simplified):

- alert: DeliverabilityCritical
  expr: max_over_time(deliverability_score{}[1h]) >= 8
  for: 15m
  labels:
    severity: critical
    pagerduty: yes
  annotations:
    summary: "Deliverability critical for {{ $labels.sender_domain }}"
    description: "Score {{ $value }} indicates 3+ stream degradation"

- alert: DeliverabilityWarning
  expr: max_over_time(deliverability_score{}[1h]) >= 5
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "Deliverability degrading for {{ $labels.sender_domain }}"

- alert: DeliverabilityInfo
  expr: max_over_time(deliverability_score{}[1h]) >= 2
  for: 1h
  labels:
    severity: info
  annotations:
    summary: "Deliverability minor signal for {{ $labels.sender_domain }}"

Operational KPIs for the observability platform itself

Five metrics worth tracking on the platform’s health (not just the deliverability data it monitors):

KPI 1 — Collector data freshness: target ≤30 minutes for parsedmarc and log streams; ≤24 hours for Postmaster/SNDS (their native cadences). Above target indicates collector backlog.

KPI 2 — Alert false positive rate: target ≤15% for Tier 2 warnings, ≤5% for Tier 3 critical. Above target indicates correlation thresholds need tuning.

KPI 3 — Mean time to detection (MTTD) of deliverability incidents: target ≤6 hours from event start to alert firing. Track via post-incident review.

KPI 4 — Elasticsearch index health: target green status, document count growth ~5-10% week over week (steady state) or growth correlated with sending volume changes.

KPI 5 — Dashboard query latency P95: target ≤3 seconds for the unified dashboard load. Above target indicates Elasticsearch needs tuning or schema optimization.

These platform KPIs are themselves visualized in a meta-dashboard — observability for the observability platform. We added this after the second time the collector silently stopped pulling Postmaster data due to expired OAuth2 credentials and we didn’t notice for 11 days.

What we recommend at Blue Spirit

For transparency: we run a version of this platform internally for our own PowerMTA hosting infrastructure and deliverability operations. Our deliverability audit engagement includes either deploying the platform for clients or auditing existing platforms.

The recommendation framework for 2026 in matrix form:

Sender profile	Monthly volume	Sender domains	Build vs Buy	Annual cost (build)	Annual cost (SaaS equivalent)
Hobby / micro	<100K	1	parsedmarc only	$0 (DIY)	$0-50/month
Small B2B SaaS	<1M	1-3	Don’t build unified	~$2-3K infra + parsedmarc	$2.4-7.2K SaaS
Mid-market	1-10M	3-10	Build if Python in-house	$4-6K initial + $2-3K/year	$7.2-24K SaaS
Large enterprise	10-50M	10-25	Build (self-hosted favored)	$6-10K initial + $3-5K/year	$24-60K SaaS
ESP / agency	50M+	25+	Build (self-hosted only viable)	$10-15K initial + $5-8K/year	$50-150K+ SaaS
EU agency (5-15 clients)	varies	5-15	Build (structurally favored)	~€6.2K initial + €2.2K/year	€30-80K SaaS (per-domain pricing)

The bullets explaining the matrix:

For organizations sending under 1M messages/month from 1-3 sender domains: don’t build this. parsedmarc dashboards plus weekly manual checks of Postmaster Tools UI is sufficient. The build cost ($4-6K) doesn’t pay back at this scale.

For organizations sending 1M-10M/month from 3-10 sender domains: build is justified if you have Python capability in-house. Expected payback: 6-12 months based on incident prevention. SaaS alternative (Postmastery Console at ~$200-400/month per domain) competes on managed-service value, not cost.

For organizations sending 10M+/month from 10+ sender domains: self-hosted is structurally favored unless your operational model strongly prefers managed services. The unified platform pays back in weeks based on incident prevention alone.

For ESPs and agencies operating 25+ client sender domains: self-hosted is the only economically viable path. SaaS pricing scales linearly per domain and quickly exceeds $50K/year; self-hosted scales sub-linearly.

For EU agencies and ESPs operating 8-15+ client domains: the structural case for self-hosted is reinforced by GDPR Article 32 data-handling documentation, DORA ICT third-party risk management requirements (effective Jan 2025 for in-scope financial entities), and PCI DSS v4.0 audit evidence (effective March 2025). Self-hosted infrastructure on EU regions (Hetzner, OVHcloud, IONOS, Scaleway) removes vendor-risk paperwork that US-hosted SaaS introduces, in addition to the favorable economics at 8+ domains.

If you need help deploying this platform, integrating additional data sources (your own MTA logs, CRM systems, business metrics), or evaluating existing monitoring against the unified observability framework — that’s part of our deliverability audit engagement. The framework’s source code is published as part of audit deliverables and includes the Grafana dashboard JSON, Python collector with all five stream pullers, Docker Compose deployment, and operational runbooks.

Honest summary

Email deliverability operations in 2026 require multi-stream observability. The five streams (DMARC RUA, Postmaster v2, SNDS, DKIM logs, ARC events) each answer different operational questions, and the unified view provides 5-10x faster incident detection compared to single-stream monitoring. The operational value isn’t theoretical — incidents that compound over 30+ hours when monitored single-stream typically resolve in 4-8 hours when monitored unified.

The build-vs-buy question depends on scale and capability. Small senders (under 1M/month, 1-3 domains) shouldn’t build; the operational complexity exceeds the value. Mid-scale senders (1-10M/month, 3-10 domains) with Python capability in-house should build; payback in 6-12 months. Large senders and ESPs (10M+/month, 10+ domains) should build because SaaS pricing models become economically prohibitive at scale.

The framework in this post — Python collector with five stream pullers, unified Elasticsearch schema, Grafana dashboards with cross-stream correlation, multi-tier alerting — is what we deploy in production for clients managing 12-50 sender domains. The deployment cost is approximately $4-6K initial Python engineering plus $2-3K/year ongoing infrastructure. Compared to SaaS alternatives (Postmastery, EmailConsul, Mailgun Optimize, Validity Everest) starting at $200-400/month per domain, self-hosted is economically favorable past 5-8 sender domains.

For EU agencies specifically, the structural case is reinforced beyond simple economics: GDPR Article 32 data-handling documentation, DORA ICT third-party risk management (effective Jan 2025), and PCI DSS v4.0 audit evidence (effective March 2025) make EU-hosted self-hosted infrastructure (Hetzner Frankfurt, OVHcloud Strasbourg, IONOS, Scaleway Paris) operationally simpler than US-hosted SaaS at this scale. The agency case quantified above (~€6,200 build cost vs ~€78K/year SaaS, 4-week payback based on first prevented incident) is representative of the economics at the 8-15 client domain scale, and the regulatory friction premium against US-hosted alternatives is independent of pricing.

The technical framework is settled. The operational discipline matters more — collector reliability, alerting threshold tuning, dashboard layout discipline, post-incident review feeding back into correlation logic. Most observability platforms we audit either don’t have this discipline (collector running but never reviewed, alerts ignored as noise, dashboards built once and never iterated) or have it haphazardly. The framework matters; the discipline matters more.