Why ongoing SPF/DKIM/DMARC monitoring matters

Email authentication is not a one‑time checklist—it’s a living system. Your DNS providers update include: records, your ESPs add new sending ranges, your DKIM selectors rotate, and your templates inadvertently drop critical headers. These changes often happen silently, and their impact surfaces only after inbox providers throttle or reject your messages. A daily, verifiable audit turns incidents into notifications and arms you with evidence to fix issues fast.

The four pillars (and how they drift)

• SPF: single TXT record, ≤10 lookups (aim ≤8), no loops. Drift happens when new vendors are added or existing vendor includes expand. Flatten safely.
• DKIM: at least one dkim=pass daily, 2048‑bit keys, two selectors, zero‑downtime rotation. Drift happens when a selector expires or is mis‑applied on some paths.
• DMARC: staged policy (none → quarantine → reject) with reporting, child policy via sp= as needed. Drift happens when expectations evolve but policy lags.
• Alignment: relaxed vs strict; compute with PSL‑aware org‑domains. Drift happens when a route signs with vendor d= or uses a vendor envelope domain.
• One‑Click: headers present, endpoint safe (POST, idempotent, https). Drift happens when templates change or a new ESP route omits headers.

What to monitor—daily, with thresholds

1. SPF health: present+single; lookups ≤10 (warn ≥8); no recursion >3; no duplicate TXT.
2. DKIM health: at least one pass observed; both selectors valid; key length ≥2048; rotation calendar maintained.
3. DMARC policy: staging status; rua/ruf intact; child sp= applied where sub‑brands exist.
4. Alignment: relaxed pass (or strict if adopted) on SPF or DKIM; PSL rules up to date.
5. One‑Click: headers present; endpoint never auto‑requested by checks; HTTPS only.

Evidence you can ship: Proof‑of‑Scan

Every scan produces a canonical JSON snapshot (sorted keys, LF, UTC) and a sha256 hash. The proof tail page prints scanId, sha256, rulepackVersion, and Verify link. Anyone can call /api/verify to recompute via multiple public resolvers (1.1.1.1/8.8.8.8/9.9.9.9) and compare hashes. This makes your claims reproducible—internally, to clients, or to auditors.

Diagnosing with Authentication‑Results

AR summarizes how a receiver evaluated a message.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=return@mail.example.com;
  dkim=pass header.d=mail.example.com header.s=s1;
  dmarc=pass header.from=example.com

• SPF identity: smtp.mailfrom= (envelope)
• DKIM identity: header.d (signing domain), header.s (selector)
• Header From: visible From: domain

Compute relaxed alignment by comparing PSL‑derived org‑domains; for strict, require exact match. If alignment fails despite spf=pass or dkim=pass, check for vendor envelope domains or vendor d= signatures.

Playbook: from alert to fix

Architecture that scales

• Queue & de‑dup: Redis + BullMQ; one job per domain per 15 minutes
• Scanner: DNS + header parser; PSL‑aware alignment; score + suggestions
• Proof: canonical JSON + sha256; store rulepackVersion and resolver set
• PDF: render asynchronously (headless browser worker); signed 24h links
• Alerts: Email first; Slack/Lark optional; Markdown templates

Controls & retention

• JSON evidence: 90 days; PDFs: 30 days; proofs longer (or 1 year)
• No email bodies stored; .eml deleted immediately after parsing
• Download links are HMAC‑signed and expire in 24 hours

Frequently asked questions