DMARC Analyzer

TL;DR

• DMARC monitoring is the operational discipline that follows the policy rollout. Once your domain reaches p=reject, DMARC is not deploy-and-forget. Senders rotate keys, SaaS providers change infrastructure, marketing teams add new transactional sources, and attackers probe for spoofing opportunities. Without monitoring, alignment regressions appear as silent inbox failures days or weeks before users report them.
• Track 8 core KPIs daily: authenticated volume, alignment pass rate, SPF pass rate, DKIM pass rate, combined SPF + DKIM pass rate, distinct sending sources, disposition distribution (none / quarantine / reject), and reporter coverage. All eight surface from RFC 7489 §7.2 aggregate (rua) reports.
• Set 5 alert thresholds: authenticated volume drop >20 percent day- over-day, alignment pass rate drop below 95 percent for an enforced domain, new sending IP with >100 messages from a not-seen-in-30d IP, reporter coverage drop below 5 reporters per day, and forensic (ruf) report volume spike of 10x or more.
• Three-tier review cadence: DAILY for the first 90 days of any sender onboarding or policy ramp; WEEKLY in steady state for trend review and inventory drift; MONTHLY for executive disposition reports and subdomain (sp / np) policy decisions.
• Sender-inventory drift is the single most common operational anomaly: a new marketing platform or transactional provider starts sending on behalf of your domain without registration in SPF / DKIM. Diff the weekly source-IP list against an explicit authorized-sender inventory.
• 72-hour post-change observation is the standard regression-detection window for any SPF / DKIM / DMARC configuration change. Capture the 7-day pre-change alignment baseline; alert if any of the 3 post-change daily values drops more than 5 percentage points below it.
• Reporter coverage is a meta-KPI. A drop in distinct reporters means your rua= mailbox is bouncing, your DMARC record is malformed, or your sending volume to that receiver has dropped to zero. Healthy enterprise senders see 10+ distinct reporters per day.
• Six canonical aggregate-report action patterns map every data point to an operational action: onboard new sender, investigate suspected spoofing, check upstream DKIM rotation, check sender reputation, capture pre-change baseline diff, validate sp= / np= subdomain policy. See Section 10.

1. The monitoring discipline

Most DMARC programs treat the journey to p=reject as the destination. The rollout deep dive (DMARC policy rollout) covers the migration from p=none through p=quarantine to p=reject — typically a 12-week journey. But the OPERATIONAL discipline begins on the day enforcement goes live and never ends.

Three reasons DMARC requires ongoing monitoring:

• Sender estates drift. Marketing teams onboard new SaaS providers (SendGrid, Mailgun, Postmark, Mailchimp, Constant Contact, Klaviyo). Engineering teams spin up new transactional senders. Product teams launch surveys, NPS tools, and webhook-triggered notifications. Every new sender is a potential alignment failure unless registered in SPF and signed with custom-domain DKIM. The DMARC troubleshooting guide documents the canonical SaaS-sender-alignment failure (Pattern 1) caused by drift.
• Infrastructure changes break authentication. DKIM key rotation is normal hygiene (DKIM explained covers cadence and key sizes). SPF records grow with each new include: directive, approaching the RFC 7208 §4.6.4 10-DNS-lookup ceiling. SaaS providers change IP ranges. Forwarding services modify bodies. Each change is a potential regression visible only in aggregate reports.
• Attackers probe for spoofing opportunities. A spike in forensic (ruf) reports or a new IP sending with failing alignment can indicate a spoofing wave. The DMARC forensic reports page documents the signal-rich RUF samples that surface targeted phishing campaigns.

The monitoring discipline answers four questions on every operational shift: Is authenticated volume normal? Is alignment pass rate stable? Are there new senders to onboard or investigate? Are reporters still reporting? The remaining sections of this page operationalise each question.

2. The 8 core KPIs every DMARC dashboard tracks

Eight metrics, all derivable from the daily aggregate-report stream defined in RFC 7489 §7.2. Every metric should be tracked per day, per organizational domain, with a 7-day rolling average overlaid on the daily series to smooth weekend / holiday volume dips.

DMARC Analyzer's dashboard (index.php) surfaces all 8 metrics: the headline cards expose KPIs 1, 2, 5, 6, and 7; the Top Source IPs panel exposes KPI 6 with per-IP alignment results; the Reporters chart exposes KPI 8; the Authentication pass-rate trend chart overlays KPIs 3 + 4 as time series. Backed by includes/DmarcParser.php which parses every rua XML report into the canonical schema described on the aggregate reports page.

3. Alert thresholds and escalation paths

Alerts convert KPIs into operational signals. Five thresholds catch the most common DMARC program regressions:

Threshold tuning is per-program. The values above are starting points for a typical enterprise sender; small-business domains tune down (the 100-message new-IP threshold becomes 20, the 5-reporter threshold becomes 2). Alert noise from over-tight thresholds is operationally worse than missed alerts from loose thresholds — start conservative and tighten as the operational team builds intuition.

4. Operational review cadence

A three-tier review cadence covers the full operational surface without over-investment:

Tier 1 — Daily review (first 90 days + post-change)

Triggered during the first 90 days of any new sender onboarding, any policy advance (p=none → p=quarantine, p=quarantine → p=reject), or any infrastructure change. Daily review:

• Yesterday's authenticated volume vs the 7-day moving average — flag >20 percent deviation.
• Yesterday's alignment pass rate vs the 7-day moving average — flag drop >5 percentage points.
• New IP sources in the past 24h not in the authorized-sender inventory — file for investigation.
• Reporter coverage for yesterday — flag drop below 5 distinct reporters.

Cadence terminates after 90 days of stable metrics or when the change-driven trigger expires.

Tier 2 — Weekly review (steady state)

Once daily review terminates, weekly review handles the operational surface in steady state:

• 7-day alignment-trend chart per organizational domain — look for slope changes or step functions.
• Sender-inventory diff (this week vs baseline) — onboard new senders or file spoofing probes.
• Reporter-coverage rolling average.
• Top failing source IPs by message volume — drill into per-IP failure breakdown via the dashboard's source-IP detail view.
• Disposition distribution per receiver (Google vs Microsoft vs Yahoo) — receivers sometimes apply different effective policies via policy_evaluated.reason.type overrides (local_policy, mailing_list, forwarded).

Tier 3 — Monthly review (executive + strategy)

Monthly review feeds quarterly business reviews and informs strategic decisions:

• Month-over-month authenticated volume trend.
• Disposition distribution by organizational domain (the executive headline).
• Subdomain policy decisions: are any subdomains ready for an sp= upgrade or an np= override?
• Pending BIMI / VMC deployment readiness check (BIMI deployment requires p=quarantine or p=reject + 100 percent alignment).
• SPF lookup-count audit per organizational domain (refresh the Domain Security Checker output to verify headroom under the 10-DNS-lookup ceiling).

5. Anomaly detection patterns

Five recognisable patterns surface in aggregate-report data when something is operationally wrong. Each pattern has a canonical signal shape — recognising the shape collapses diagnosis time from days to hours.

Pattern A — Step-function drop in alignment

Signal shape: alignment pass rate was stable at 99 percent for weeks, then dropped to 70 percent overnight. Almost always a single infrastructure change — a DKIM key rotation that did not propagate, an SPF record edit that broke a sender, a SaaS provider's IP range change. Diagnose by correlating the drop date with the change-management log; capture the failing IPs via the source-IP detail view and check upstream.

Pattern B — Slow alignment decay

Signal shape: alignment pass rate gradually declines from 99 percent to 92 percent over 4-6 weeks. Usually sender-inventory drift — new senders being added without DMARC alignment work. Diagnose by diffing the weekly source-IP list against the authorized-sender inventory; the drift senders surface as new entries.

Pattern C — Volume spike with failing alignment

Signal shape: a single new IP appears with 1000+ messages in a day, all failing alignment. Either a legitimate new sender that needs urgent onboarding (a marketing campaign launched today) or a spoofing wave. Diagnose by checking whether the IP belongs to a known SaaS provider (whois / Google's known-IP-ranges JSON) and correlating with internal change tickets.

Pattern D — Reporter coverage collapse

Signal shape: reporter coverage drops from 10 reporters/day to 2 reporters/day overnight. The rua= mailbox is bouncing, quarantining, or the DMARC record was edited and receivers no longer recognise the rua= destination. Diagnose by sending a test message to the rua= address from an external account; check the DMARC record via dig +short TXT _dmarc.example.com and the Domain Security Checker.

Pattern E — Forensic-report flood

Signal shape: forensic (ruf) reports go from 5/day to 500/day. A spoofing or phishing campaign is hitting the domain. The forensic reports page covers the signal-rich RUF sample structure. Diagnose by extracting the spoofing pattern (sender display-name spoofing, cousin-domain spoofing, lookalike-domain spoofing) and escalating to security for takedown + blocklist enrichment.

6. Regression detection after a configuration change

Any change to SPF, DKIM, DMARC, or the sending infrastructure has potential to break authentication. Standard mitigation: a 72-hour observation window with explicit pre-change and post-change KPIs.

The 72-hour post-change protocol

1. Before the change: capture the 7-day pre-change alignment pass rate per organizational domain. Capture authenticated volume, SPF pass rate, DKIM pass rate, and distinct sending sources.
2. Day of change: deploy the change. Annotate the dashboard with a change marker (date + change ID + change owner).
3. Day 1 post-change: review 24h aggregate-report data. Compare daily alignment, SPF pass, DKIM pass against the pre-change baseline. Alert if any KPI drops more than 5 percentage points.
4. Day 2 post-change: repeat Day 1 review. Two consecutive bad days triggers a rollback decision.
5. Day 3 post-change: repeat. Three consecutive good days closes the observation window. Three consecutive bad days triggers rollback.

Common regression triggers

• SPF record changes — adding a new include: that breaches the 10-DNS-lookup ceiling causes universal permerror. See the DMARC troubleshooting Pattern 2.
• DKIM key rotation — public key not published, signing not updated, selector typo. See DKIM explained.
• DMARC policy advancement (p=none → p=quarantine → p=reject) — previously-passing alignment failures now surface as visible bounces. See the policy rollout page.
• SaaS provider migration — new provider IPs not in SPF, new DKIM selectors not configured.
• Internal SMTP relay reconfiguration — DKIM signing host changed without updating signing infrastructure.

7. Sender-inventory drift

The single most common DMARC operational anomaly. Email is permissionless within an organization — marketing buys a new tool, product launches a new survey vendor, engineering wires up a webhook-triggered sender. None of them ask the email-platform team for permission to use the company domain in the From: header. The first you learn of the new sender is when its messages appear in aggregate reports.

The inventory artefact

Maintain a single authoritative document listing every authorized sender:

Sender name        | Service          | SPF include          | DKIM selectors       | Volume tier
-------------------+------------------+----------------------+----------------------+------------
Google Workspace   | Corporate email  | _spf.google.com      | google, google-2     | High
SendGrid           | Marketing        | sendgrid.net         | s1, s2               | High
Mailgun            | Transactional    | mailgun.org          | k1                   | Medium
Postmark           | Transactional    | spf.mtasv.net        | 20240101             | Medium
Mailchimp          | Newsletter       | servers.mcsv.net     | k1, k2               | Medium
HubSpot            | Marketing CRM    | _hubspot._spf...     | hs1, hs2             | Low
Internal SMTP      | App notifications| (ip4:198.51.100.0/24)| selector1            | Low

The weekly diff

Once a week, extract the distinct source-IP list from the past 7 days of aggregate reports. Resolve each IP to its owning organization (whois + reverse DNS + known SaaS IP-range lists). Diff against the inventory. Each new entry routes to one of three outcomes:

• Onboard — legitimate new sender. Add to SPF (or refactor to a higher-tier include: if you are approaching the 10-DNS-lookup ceiling), enable custom-domain DKIM, add to the inventory artefact. Verify alignment within 72 hours of activation.
• Investigate — sender does not match any known business relationship. Could be shadow IT, could be spoofing. Engage business stakeholders before declaring it spoofing.
• File spoofing — confirmed unauthorized sender. Document, escalate to security, monitor forensic reports for targeted recipients.

The DMARC Analyzer source-IP detail view (source_ip_detail.php) is the canonical interface for this workflow — it surfaces per-IP message volume, alignment breakdown, reporter coverage for that IP, and geolocation.

8. Volume-based compromise signals

Authenticated volume itself carries operational signal beyond the simple stability check. Three volume patterns deserve specific monitoring:

• Sudden 10x volume spike from a single source IP. Either a legitimate marketing campaign launch (correlate with the marketing change calendar) or an account compromise — the attacker is using a legitimate sender's authenticated channel to push phishing or commercial spam at scale.
• Sustained volume from an authenticated sender to an unusual geographic recipient set. Track the record/identifiers/header_from domain combined with the receiving organization (the report's org_name at the receiver side). A sudden expansion to a new TLD set (e.g., previously you sent only to .com and .de, now suddenly 30 percent of your volume targets .ru and .cn) is a compromise signal even if alignment passes.
• Volume drop to a single receiver only. If Google reports drop to zero but Microsoft and Yahoo continue normally, you may have hit a deliverability block at Google (sender reputation, spam complaint rate, content trigger). Check Google Postmaster Tools.

9. Reporter coverage as a meta-KPI

Reporter coverage — the count of distinct receiving organizations sending you aggregate reports — is a META-KPI: it measures whether your monitoring data itself is intact. Low reporter coverage means every other KPI on this page is potentially measured on a partial sample.

Expected reporter set

A healthy enterprise sender sees reports from at least these 10 organizations per day:

• Google (google.com)
• Microsoft (outlook.com)
• Yahoo (yahoo.com / yahooinc.com)
• Mail.ru (mail.ru)
• La Poste (laposte.net)
• Comcast (comcast.net)
• AT&T (att.net)
• Apple iCloud (apple.com)
• Fastmail (fastmail.com)
• Cloudflare Email Routing (cloudflare.com)

Plus reporting-as-a-service operators (Postmark, DMARC Analyzer itself when configured as a rua= target, OnDMARC, Valimail, EasyDMARC, etc.) if your rua= list delegates to them.

Diagnosing low reporter coverage

Three root causes for sudden drops:

1. The rua= mailbox is bouncing. Check the mailbox for bounce messages, delivery quotas, or DMARC policy that rejects inbound reports (the chicken-and-egg failure where your report-receiving address itself fails DMARC). The aggregate reports page documents the rua= mailbox failure modes.
2. The DMARC record is malformed. Receivers stop sending reports when the DMARC TXT record becomes syntactically invalid. Verify with dig +short TXT _dmarc.example.com and parse against RFC 7489 §6.3.
3. Sending volume to that receiver collapsed. No mail means no reports. Check sender-side delivery logs for the affected receiver.

10. From aggregate-report data points to operational actions

The reporting-analysis half of this guide: every aggregate-report data point maps to one of six canonical actions. Recognising the pattern collapses minutes of dashboard navigation into seconds of muscle-memory routing.

11. DMARC Analyzer dashboard integration

The 8 KPIs and 5 alert thresholds described on this page map directly to the DMARC Analyzer operational surface:

• Authenticated volume / alignment pass rate (KPIs 1, 2, 5) — the dashboard headline cards on index.php, plus the Authentication pass-rate trend chart (added in loop 2026-05-18kf) which overlays per-day SPF + DKIM pass counts as a time series with hover and keyboard navigation. Backed by includes/DmarcParser.php.
• Distinct sending sources / per-IP alignment (KPI 6) — the Top Source IPs panel on the dashboard plus the per-IP drill-down at source_ip_detail.php. The drill-down surfaces per-IP message volume, SPF / DKIM breakdown, reporter coverage for that IP, and the alignment evaluation — the inputs to the sender-inventory diff workflow.
• Disposition distribution (KPI 7) — the per-record drill-down at reports_detail.php exposes every policy_evaluated.disposition value along with the reason.type override codes when present.
• Reporter coverage (KPI 8) — the Reporters panel on the dashboard plus the per-reporter drill-down at reporter_detail.php which groups all reports from a single receiver organization.
• Single-message diagnosis — the Email Header Analyzer (header_analyzer.php, built on includes/EmailHeaderParser.php) decodes Authentication-Results headers for individual failing messages caught via the 72-hour post-change observation window or user-reported missed mail.
• DNS-side validation — the Domain Security Checker (domain_checker.php, built on includes/DnsChecker.php) runs live DNS queries for the SPF lookup-count audit (the Tier 3 monthly task) and the DMARC-record validation for reporter- coverage diagnosis.
• Forensic-report ingestion — RUF samples land via upload.php through includes/ForensicReportParser.php for the Pattern E forensic-flood detection path. See the forensic reports page for the per-sample breakdown.

12. Monitoring best practices

• Annotate every infrastructure change on the dashboard. A small marker on the alignment trend chart at the date of every SPF / DKIM / DMARC change pays off the next time an anomaly appears — the operator can immediately rule in / rule out change-related causes.
• Maintain a canonical authorized-sender inventory artefact. The single document that the weekly source-IP diff is compared against. Per Section 7 — without the artefact, sender-inventory drift goes invisible.
• Track per-organizational-domain KPIs, not just a global rollup. A 5-percentage-point drop in the global alignment pass rate might be 50 percentage points concentrated on one subdomain. Per-domain visibility surfaces it.
• Run 7-day rolling averages as the primary trend. Daily values are noisy (weekends, time-of-day, campaign launches). The 7-day rolling average is the operationally-useful trend signal.
• Set alert thresholds before enforcement. Do not wait for the first p=reject incident to discover that you have no alerting. Tune thresholds during the p=none observation phase using the established baseline.
• Maintain a runbook per alert. When alert 1 (volume drop) fires at 3am, the on-call should not have to figure out what to do from first principles. A per-alert runbook codifies the diagnostic and remediation steps.
• Run the weekly inventory diff on a calendar reminder. Diff-on-detection is reactive; diff-on-schedule is proactive and catches drift before it becomes a regression.
• Reconcile rua= mailbox health monthly. The single point of failure that makes every KPI on this page disappear silently.

13. Common monitoring mistakes

1. Treating DMARC as deploy-and-forget after reaching p=reject. The single most expensive operational mistake. Sender estates drift, infrastructure changes break authentication, attackers probe — every week brings a potential regression.
2. Reading aggregate reports manually from email attachments. The XML format is machine-readable for a reason. Manual reading captures volume but misses alignment trends, source-IP drift, and reporter coverage. Use a parser (includes/DmarcParser.php or equivalent).
3. Alerting only on alignment pass rate. The five-threshold set catches regressions that a single alignment-pass-rate alert would miss (reporter coverage, forensic floods, new-IP probes).
4. Setting alert thresholds without a baseline. A "20 percent drop" threshold means nothing without a stable pre-change baseline. Capture 7-day rolling-average baselines per organizational domain BEFORE relying on deviation alerts.
5. Ignoring reporter coverage because reports are arriving. Some reports arriving is not the same as the right reporters arriving. A drop from 10 to 2 reporters/day still satisfies "reports are arriving" but means 80 percent of your sending volume is now unmeasured.
6. Treating new IPs as anomalies without inventory context. A new IP from a sender you onboarded last week is not an anomaly. The weekly inventory diff against an explicit authorized-sender list separates legitimate drift from unauthorized sending.
7. Failing to diff per-domain. Global rollups hide concentrated regressions. A 100 percent failure on a low-volume subdomain might be invisible in a global alignment-pass-rate chart.
8. Forgetting that policy_evaluated shows receiver behaviour, not your policy. Receivers apply local_policy / mailing_list / forwarded overrides that can disposition mail differently from your p= tag. The aggregate reports page walks through the reason.type override codes.
9. Never validating the rua= mailbox is alive. The chicken-and-egg failure where your report-receiving address itself fails DMARC, bounces, or hits quota. Reporter coverage catches it eventually; monthly validation catches it sooner.
10. Confusing aggregate-report data with deliverability data. DMARC passing does not mean inbox placement. Use Google Postmaster Tools / Microsoft SNDS for deliverability — they answer different questions. See the DMARC troubleshooting guide for the "DMARC pass but mail to spam" scenario.

14. Frequently asked questions

What is DMARC monitoring and why does it matter once enforcement is enabled?

DMARC monitoring is the ongoing operational discipline of reading aggregate (RUA) reports, tracking authentication KPIs, watching for sender-inventory drift, and detecting regressions or anomalies after a DMARC program is live. It matters because DMARC is not a deploy-and-forget control. SaaS senders rotate keys without telling you, marketing teams add new transactional providers, internal infrastructure changes break DKIM signing, and attackers probe for spoofing opportunities. Without active monitoring at p=reject, legitimate mail starts failing silently and inbox complaints arrive from users you do not yet know are affected.

What are the core DMARC KPIs every program should track?

Eight metrics define a healthy DMARC dashboard. (1) Authenticated message volume per day, the headline number. (2) Alignment pass rate, the percentage of authenticated messages that align with the From: header. (3) SPF pass rate. (4) DKIM pass rate. (5) Combined SPF + DKIM pass rate (a message can pass DMARC via either). (6) Distinct sending sources count, the inventory of IPs claiming to send as you. (7) Disposition distribution (none / quarantine / reject applied by receivers). (8) Reporter coverage, the count of receivers actively sending you reports. Every metric should be tracked per day and per organizational domain, with 7-day rolling averages to smooth weekend dips.

How often should I review DMARC aggregate reports?

A three-tier cadence works for most programs. (1) Daily review during the first 90 days of any new sender onboarding or policy ramp, looking at the previous-day authenticated volume, alignment pass rate, and any new IP sources. (2) Weekly review in steady state, focused on the 7-day rolling alignment trend, sender-inventory drift, and reporter coverage. (3) Monthly review for executive reporting, focused on disposition distribution by domain, quarterly trend changes, and any subdomain (np / sp) policy decisions pending. The DMARC Analyzer dashboard surfaces all three cadences via per-source-IP failure rates, reporter breakdowns, and 7-day moving averages.

What alert thresholds should I set for a DMARC program?

Five operationally useful alert thresholds. (1) Authenticated volume drops by more than 20 percent day-over-day, indicating an authentication or deliverability regression. (2) Alignment pass rate drops below 95 percent for an enforced domain, indicating an alignment regression. (3) A new sending IP appears with more than 100 messages in a single day from an IP not previously seen in the past 30 days, indicating an inventory drift or spoofing probe. (4) Reporter coverage drops below 5 distinct organizations per day, indicating a rua= delivery failure. (5) Forensic (RUF) report volume spikes by more than 10x, indicating a spoofing wave. Thresholds tune per program; the values above are starting points for a typical enterprise sender.

What is sender-inventory drift and how do I detect it?

Sender-inventory drift is the gradual addition of legitimate senders (a new marketing platform, a new transactional provider, a new internal tool) to your DMARC-aligned estate without those senders being registered in your SPF record or DKIM signing infrastructure. It surfaces in aggregate reports as new IP addresses claiming to send as your domain, with high message volume but failing alignment. Detection workflow: maintain an explicit inventory list of authorized senders, diff weekly against the unique-source-IP list from aggregate reports, and route each new IP to either onboarding (add to SPF and enable custom-domain DKIM) or spoofing investigation. The DMARC Analyzer dashboard surfaces this via the source-IP detail view.

How do I detect a DMARC regression after a configuration change?

A DMARC regression is when an SPF / DKIM / DMARC configuration change accidentally breaks authentication for legitimate mail. Standard mitigation is a 72-hour observation window: deploy the change, watch the next 3 days of aggregate reports for alignment pass rate dropping below the pre-change baseline, and have a rollback plan ready. Specifically: capture the 7-day pre-change alignment baseline per organizational domain, capture the same metric for each of the 3 days post-change, alert if any post-change daily value drops more than 5 percentage points below the pre-change 7-day baseline. The most common regression triggers: SPF record change (10-DNS-lookup limit exceeded by a new include), DKIM key rotation (public key not propagated), DMARC policy advancement (p=quarantine reveals previously-passing alignment failures).

What does it mean if reporter coverage drops?

Reporter coverage is the count of receivers (Google, Microsoft, Yahoo, La Poste, Mail.ru, plus reporting-as-a-service operators) actively sending you aggregate reports. A healthy enterprise sender sees 10+ distinct reporters per day. If reporter coverage suddenly drops, three causes are typical. (1) The rua= mailbox is full, bouncing, or has DMARC policy that breaks the reporting flow (a chicken-and-egg failure where your report-receiving address itself fails DMARC). (2) The DMARC TXT record is malformed and receivers stopped sending. (3) Your sending volume dropped to zero for that receiver (no messages means no reports). Diagnose by checking the rua= mailbox bounces and by inspecting the DMARC record with the Domain Security Checker.

How do I map aggregate-report data points to operational actions?

Six canonical action patterns. (1) New IP with high volume and failing alignment, action: investigate whether legitimate (onboard) or spoofing (file). (2) Established IP suddenly failing alignment, action: check upstream sender for DKIM key rotation or SPF change. (3) Established IP with declining authenticated volume, action: check sender for deliverability throttling. (4) Receiver showing 100 percent quarantine despite policy_evaluated.reason override, action: check sender reputation at that receiver. (5) Alignment pass rate dropping below 95 percent across all receivers, action: capture full-domain configuration and run pre-change baseline diff. (6) Subdomain showing different alignment behaviour than parent, action: check whether sp= or np= overrides are firing as expected.

15. Related guides

• DMARC explained — the central DMARC primer covering the DMARC ecosystem, the RFC 7489 specification, and the policy progression p=none → p=quarantine → p=reject.
• DMARC record tags explained — every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) with syntax, defaults, and interaction rules.
• DMARC alignment explained — identifier alignment (the SPF/DKIM-domain-matches-From: rule) that determines DMARC pass/fail. The cornerstone concept underpinning KPI 2 (alignment pass rate).
• DMARC policy rollout — the operational migration from p=none through p=quarantine to p=reject. Monitoring formally begins on the rollout's day-1 and continues indefinitely.
• DMARC deployment checklist — the PRE-FLIGHT GREEN-PATH companion to this steady-state monitoring discipline. Where THIS page documents the STEADY-STATE operational discipline that sustains the eight-KPI monitoring posture (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) AFTER a DMARC deployment has reached enforcement, the deployment-checklist spoke documents the PRE-FLIGHT phases whose final phase (Phase 4 post-publication monitoring cadence) IS the operational discipline this page is the steady-state reference for. Concretely: Phase 4 of the deployment checklist ESTABLISHES the monitoring cadence (daily KPI review, weekly trend analysis, monthly cumulative posture review, the alert-threshold baseline this page documents the steady-state tuning of), and once the deployment-checklist's Phase 4 exit- criteria are met THIS page takes over as the ongoing operational reference for the indefinite steady-state KPI tracking period. The bidirectional relationship: operators arriving at this monitoring page WITHOUT a prior deployment-checklist Phase 4 baseline need the deployment-checklist spoke to ESTABLISH the eight-KPI baseline this page documents the steady-state tuning of; operators finishing the deployment-checklist's Phase 4 exit-criteria need THIS page to carry the monitoring discipline forward into the indefinite steady-state operational period. Read the deployment-checklist spoke when a brand-new operator arrives at this steady-state monitoring page WITHOUT a deployment-checklist Phase 4 baseline already in place — the checklist is the FIRST-STEP entry point that establishes the monitoring infrastructure this page is the ongoing operational reference for.
• DMARC policy modes — p=none vs p=quarantine vs p=reject — the head-to-head COMPARISON of the three DMARC enforcement values. Steady-state monitoring (this page's Tier 1/2/3 KPIs) requires recognising what each disposition value MEANS when it appears in the daily aggregate feed: the COMPARISON page documents the per-mode enforcement floor for BIMI eligibility and CISA BOD 18-01 compliance — the two operational claims monitoring needs to verify every reporting interval.
• DMARC aggregate (RUA) reports — the RFC 7489 §7.2 XML schema, the canonical data source for every KPI on this page.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the STEADY-STATE-MONITORING-PER-KPI- PERMERROR-DETECTION companion to this ongoing operational monitoring reference. Where THIS page documents the eight-KPI steady-state operational discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) operators sustain AFTER deployment reaches enforcement, the SPF-lookup-limit spoke is the PER-KPI PERMERROR-DETECTION REFERENCE documenting how each of the eight KPIs surfaces evidence of SPF-record budget saturation BEFORE the per-message spf=permerror rate ramps to a catastrophic deliverability floor. The MONITORING-DISCIPLINE-VS-SPF- LOOKUP-LIMIT cross-reference establishes FOUR structurally-distinct steady-state monitoring contexts where SPF-budget evidence MUST surface in the daily aggregate-report feed: (i) KPI 3 (SPF-pass-rate) per-receiver-interval decomposition by spf=fail / spf=permerror / spf=temperror / spf=none — the SPF-pass-rate KPI's spf=permerror sub-category is the canonical leading- indicator that the apex SPF record has breached the 10-DNS-lookup budget at the receiver-side evaluation boundary; the SPF-lookup-limit spoke documents the per-receiver `permerror` enforcement algorithm AND the canonical operator-side decomposition (per-ESP-vendor, per-source- IP, per-receiver-organization) the operator applies to localise which include-cascade sub-record triggered the budget breach; (ii) KPI 6 (DMARC failure rate) cascade-effect from SPF-permerror-driven alignment-failure — a sustained spf=permerror rate cascades DIRECTLY into DMARC-fail because RFC 7489 §4 evaluates DMARC pass ONLY when at least one of SPF or DKIM aligns AND passes; an SPF-record budget breach cascades into SPF-side alignment loss, then into the DMARC failure rate KPI if DKIM also fails — and DKIM frequently fails independently due to forwarder body modifications surfaced on the next KPI below; the SPF-lookup-limit spoke documents the per-percentage budget-breach cascade timeline (sustained spf=permerror > 5% drives DMARC-fail above the per-operator-floor within 7–14 reporting intervals); (iii) KPI 4 (distinct sending sources) per-ESP-vendor inventory drift detection for SPF-budget-impact — when the operator's per-ESP-vendor sending-source inventory adds a new ESP (a marketing- team-initiated SaaS-ESP onboarding the operator did not coordinate at the SPF- record-edit boundary), the SPF-lookup- limit spoke documents the per-ESP-vendor measured-cost matrix the operator uses to budget the additional include-cascade cost BEFORE the new ESP triggers a receiver-side `permerror`; the cross- reference here is bidirectional — monitoring KPI 4's per-vendor inventory drift detection is the EARLY-WARNING signal that the SPF-record's 10-budget is about to be exceeded; (iv) KPI 7 (forwarder population) per-receiver- interval void-lookup-accumulation detection — RFC 7208 §4.6.4 also imposes a void-lookup cap of 2 (TXT lookups that return NXDOMAIN or no records); sustained spf=permerror rows where the per-source-IP attribution is to FORWARDER egress (Google forwarder, Outlook.com forwarder, mailing-list-MTA) signal that a legacy include: token in the operator's SPF record has accumulated void-lookups against a retired ESP-authorisation-sub-record; the SPF- lookup-limit spoke documents the void- lookup cap enforcement contract AND the canonical aggregate-report-driven operator-side detection pattern (cross- reference spf=permerror rows against spf=pass forwarder rows for the same source IP — a per- message-rate divergence indicates the operator's published SPF record has gone stale relative to a sender-side ESP retirement). Pair this page (the steady- state monitoring discipline reference) with the SPF-lookup-limit spoke (the per- receiver enforcement-contract reference) when designing the per-receiver-interval KPI thresholds and the per-KPI alert-rule catalogue — the spoke documents the per-percentage budget-breach cascade timeline and the per-ESP-vendor measured- cost matrix the operator's monitoring baseline MUST track to detect SPF-record regression BEFORE the 10-budget saturates and breaks SPF evaluation across the entire operator domain.
• DMARC forensic (RUF) reports — the per-message failure-sample format that surfaces spoofing campaigns in Pattern E.
• DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery — the end-to-end transport-and-ingestion path that turns published rua= / ruf= mailboxes into the daily aggregate XML and per-failure ARF documents this monitoring discipline depends on. Every KPI on this page (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) is downstream of the pipeline's completeness — if the pipeline is degraded the KPIs read low or zero without an upstream mail-flow problem. Read the pipeline page when KPIs go dark unexpectedly (typical causes: published rua= mailbox bouncing, receiver-side report-generator throttled by rate-limits, operator-side IMAP-fetcher credentials rotated, gzip decompression failure on a malformed report, XML schema-validation rejecting a non-conformant aggregate document) — the pipeline page catalogues the seven failure modes and the diagnostic sequence to localize each.
• MX records explained — the STEADY-STATE-MONITORING-MAILBOX- DELIVERABILITY-FOUNDATION-AS-EVERY-KPI- INPUT-PREREQUISITE-AND-REPORTER-COVERAGE- META-KPI-CAUSAL-LINK companion to this DMARC monitoring discipline. Where THIS page documents the eight-KPI operational dashboard discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source-IP distribution, DMARC failure rate, forwarder population, time-to-detection) plus the Reporter-Coverage meta-KPI documented in §9 (the per-receiver-domain aggregate- report-emitter coverage breadth that determines KPI confidence intervals), the mx-records spoke documents the apex MX RR object whose continuous availability on the rua=mailto:dmarc-rua@example.com mailbox domain is the STRUCTURAL PRECONDITION for every receiver-emitted aggregate-report stream the eight KPIs aggregate against. Four MX-RR-AVAILABILITY- VS-MONITORING-KPI causal-link axes the mx-records spoke documents: (i) MX RR continuous availability as the EVERY-KPI-INPUT-COMPLETENESS- PREREQUISITE — every one of the eight core KPIs THIS page documents is computed against the per-source-IP-per-day aggregate-report row population the receiver-emitted RUA stream produces; if the MX RR on the rua=mailto: mailbox domain becomes unavailable (TTL- bounded propagation gap, EXCHANGE-host port-25 outage, mailbox-quota-exhaustion bounce), the per-day RUA-row population DROPS — masking every KPI as a per-day anomaly that the operator might mis-attribute to a real DMARC-deployment regression rather than the more fundamental MX-RR availability gap; the mx-records spoke documents the per-MX-RR availability monitoring discipline (probe the MX-EXCHANGE host port 25 every N minutes, monitor the dmarc-rua@ mailbox quota, alert on per-day RUA ingestion-count drop) that closes the meta-KPI gap; (ii) MX RR preference-ordering as the REPORTER- COVERAGE-META-KPI-CAUSAL-DRIVER — the Reporter-Coverage meta-KPI documented in §9 of THIS page measures per-receiver-domain breadth (the proportion of the publisher's sending- receiver population that emits per-day aggregate reports against the publisher's DMARC record); when the lower-preference MX-EXCHANGE host falls offline, receivers attempting fallback delivery experience SMTP connection failures and abandon the report delivery — degrading the per- receiver-domain RUA breadth without triggering an obvious per-day-total RUA ingestion-count drop because the higher- preference primary MX continues to receive the bulk of reports; the mx- records spoke documents the per-MX- EXCHANGE-host reachability + fallback- behaviour probe that catches the per-receiver-domain-breadth degradation the Reporter-Coverage meta-KPI surfaces; (iii) MX RR migration discipline as the STEADY-STATE-MONITORING-CONTINUITY- PREREQUISITE — the operator's steady-state monitoring discipline depends on per-week consistent RUA-row population to detect anomalies against the §5 anomaly-detection patterns and the §6 post-configuration-change regression detection THIS page documents; an MX-RR migration during steady-state (e.g. migrating the RUA mailbox to a new receiver host, retiring an old MX RR, rolling out a new lower-preference MX for failover) introduces a per-DNS-TTL evidence-discontinuity gap that masks anomaly-detection signal-to-noise and leads to monitoring-discipline false positives; the mx-records spoke documents the rollover-with-TTL-overlap procedure (publish new MX RR at parallel preference, verify ingestion on new MX during TTL window, retire old MX after TTL+slack expiry) that sustains the per-DNS-TTL continuity the monitoring discipline depends on; (iv) MX RR as the SENDER-INVENTORY-DRIFT-DETECTION- FOUNDATION-LAYER — the §7 sender-inventory-drift detection THIS page documents (per-day enumeration of new sending sources, retired sending sources, IP-range shifts at known senders) STRUCTURALLY DEPENDS on the per-source-IP- per-day RUA-row population the apex MX RR's continuous availability sustains — without continuous MX availability, the sender-inventory drift surface becomes noisy (the "is this sender NEW or did we MISS a per-day aggregate-report row from a known sender?" question becomes unanswerable because the per-day RUA ingestion was incomplete); the mx-records spoke's per-MX-RR availability discipline is the foundation-layer prerequisite for the per-source-IP drift-detection signal the monitoring discipline reads. Pair this monitoring page (the eight-KPI operational dashboard discipline) with the mx-records spoke (the apex MX-RR- availability-and-rollover-discipline reference) for the complete monitoring- discipline-AND-MX-RR-availability- foundation posture every operator needs to sustain steady-state p=reject observability with a continuously- available RUA-ingestion stream feeding each per-KPI per-day data point.
• DMARC troubleshooting — the diagnostic loop for any DMARC failure surfaced via monitoring. Maps each canonical failure pattern to a remediation.
• Email authentication explained — the cluster-intro pillar covering the full SPF + DKIM + DMARC + ARC + BIMI + MTA-STS + TLS-RPT + CAA ecosystem.
• Email authentication glossary — definitions for every term-of-art used on this page (alignment, organizational domain, PSL, aggregate report, forensic report, policy_evaluated, disposition, auth_results, local_policy override).
• Email security glossary — KPI-CATEGORISATION-THREAT-VOCABULARY for KPI 6 unknown-source incident-response escalation — the KPI-CATEGORISATION-THREAT-VOCABULARY companion to this DMARC monitoring discipline for the operator population reaching the KPI 6 unknown-source-volume escalation decision point. Where THIS page documents the KPI framework in infrastructure-agnostic protocol terms (KPI 1 DMARC-pass rate, KPI 2 alignment-pass, KPI 3 SPF-pass, KPI 4 DKIM-pass, KPI 5 forwarder-leakage, KPI 6 unknown-source volume), the email-security glossary documents the THREAT-CLASS TAXONOMY the operator needs to categorise KPI 6 unknown-source rows into incident-response priority tiers: spoofing (exact-domain spoofing rejected at receiver via p=reject — the KPI 6 baseline attack class), lookalike-domain phishing (header_from organizational-domain typo-squatting — KPI 6 entries that DO NOT appear in operator's RUA because they use a different organizational domain, requiring out-of-band threat-feed monitoring), account- compromise BEC (legitimate-sender authentication-pass with attacker-content — KPI 6 false-negative class invisible to DMARC-fail KPIs), spear phishing / whaling (targeted social-engineering — KPI 6 escalation tier 1 because high-loss outcome), vendor invoice fraud / supply-chain BEC (compromised-partner signature — KPI 6 escalation tier 1 because treasury-bound mail flow), APT / DKIM-replay (sophisticated bypass — KPI 6 escalation tier 0 because protocol- layer authentication-bypass requires cryptographic-rotation incident-response). Read the email-security glossary when this monitoring discipline's KPI 6 escalation triage requires distinguishing threat-class severity tiers — the glossary is the authoritative reference for the threat-class taxonomy that determines whether the next step is automated-block signature deployment, treasury-team notification, or full incident-response activation.
• DMARC attacker bypass techniques — the EIGHT-BYPASS-CLASS catalogue for KPI 6 unknown-source escalation triage and KPI 5 forwarder-leakage threat-attribution — the EIGHT-BYPASS-CLASS catalogue companion to this monitoring discipline. Where THIS page documents the EIGHT-KPI steady-state observability framework (KPI 1 authenticated volume, KPI 2 alignment pass rate, KPI 3 SPF pass rate, KPI 4 DKIM pass rate, KPI 5 forwarder leakage, KPI 6 unknown-source volume, KPI 7 disposition distribution, KPI 8 time-to-detection), the attacker-bypass spoke documents the EIGHT BYPASS CLASSES that survive terminal p=reject enforcement and therefore drive the KPI 6 escalation triage AND the KPI 5 forwarder-leakage threat-attribution work: (i) cousin / lookalike domain spoofing — the attack-domain has its OWN aligned DMARC posture so it is INVISIBLE in the operator's own rua= reports (DMARC monitoring cannot see what the receiver evaluated under a different organizational domain); detection requires out-of-band threat-feed monitoring + defensive-registration of typo variants + BIMI-issued Verified Mark Certificates that give recipients a visual cue distinguishing legitimate mail from cousin- domain spoofing, (ii) display-name- only attacks — the From: header address-domain is the attacker's but the display-name imitates a legitimate sender; invisible to DMARC KPIs because the attacker's domain has its own aligned posture, surfaces only as KPI 6 unknown- source spikes from the attacker's domain after a campaign launches, (iii) IDN homograph — Cyrillic / Greek / Cherokee codepoint substitutions rendering visually identical to Latin characters in the From: domain; same KPI 6 invisibility class as (i)/(ii) plus the additional confound that the operator's own brand-monitoring tools may also be blind to the homograph variant, (iv) unauthenticated-subdomain attacks against an organizational domain that publishes p=reject but has NO sp=reject AND NO catch-all wildcard _dmarc.* record — KPI 6 unknown-source rows observing the subdomain spoof reach the rua= mailbox WITH the attacker IP and the unauthorized subdomain, BUT the receiver's policy-evaluation falls back to the org-level p=reject only IF the receiver's recursive-resolver organizational-domain derivation returns the correct ODID — many receivers misderive on weird subdomain patterns, which makes this class show up in KPI 6 AND KPI 7 (disposition distribution) at the same time as elevated forwarder- leakage (KPI 5) when the spoof passes receiver-side checks, (v) ARC- sealed forwarded mail — the ARC trust-list growth pattern in KPI 5 / KPI 8 is the operational signal that an ARC-trust-list bypass is occurring (the receiver is honoring the forwarder's ARC seal rather than the original sender's DMARC alignment); the bypass is operator- configured trust at the receiver, not a protocol weakness in DMARC, (vi) compromised legitimate sender — DMARC passes because the mail IS aligned; the bypass surfaces as unusual sending-volume / unusual recipient- domain / unusual subject-pattern in the legitimate sender's rua= rows, NOT as a DMARC-fail; monitoring needs out-of-band sender-behavior baselines to detect, (vii) third-party-sender abuse — an attacker signs up for an ESP the target domain has authorized via include: in SPF and sends from a shared-tenant pool IP; KPI 3 (SPF pass) PASSES, KPI 6 (unknown-source) is BLIND because the source IP IS in the SPF envelope; detection requires per-ESP sub-tenant attribution in the rua= XML's auth_results blocks, (viii) DKIM replay — a captured DKIM-signed legitimate message replayed through an SMTP relay to a new recipient set; the captured signature is valid, DMARC passes, but the original recipients list was overwritten; monitoring requires per-selector recipient-velocity baselines + signature-expiration (x=) + per-tenant DKIM-replay-mitigation rotation cadence (the dkim-replay-attacks spoke documents the operational countermeasures). Read the attacker-bypass spoke when KPI 6 unknown-source volume spikes WITHOUT a corresponding KPI 1 authenticated-volume increase, or when KPI 5 forwarder-leakage grows beyond the ARC-trust-list baseline — the bypass- catalogue is the operational reference for deciding which of the eight bypass classes is in play and which complementary control to deploy in response.
• DKIM replay attacks — the KPI-5-FORWARDER-LEAKAGE-AND-KPI-8- TIME-TO-DETECTION-DEEP-DIVE companion to this monitoring discipline. Where THIS page documents the EIGHT-KPI steady-state observability framework and the attacker-bypass spoke above catalogues the EIGHT bypass classes (with class (viii) DKIM replay flagged as the "captured-DKIM-signed- message-replayed-to-new-recipient-set" abuse pattern), the dkim-replay-attacks spoke is the OPERATIONAL-COUNTERMEASURES deep-dive reference for bypass-class (viii) — the catalogue documents the four-axis residual-attack-surface engineering model an operator deploys against a successful per-message DKIM verification of a captured-and-replayed signed message: (i) per-selector recipient-velocity baseline thresholds at receivers — Gmail / Yahoo / Microsoft / Apple increasingly publish per-selector-per-time-window recipient-velocity baselines as the deliverability-tier-gate signal for signature reuse; KPI 5 ARC-trust-list growth and KPI 8 time-to-detection drift are the operator-side observability surfaces where a campaign in progress surfaces; (ii) narrow signature- expiration (x=) windows with deliberate t=−x= bounding — the documented signer-side hardening contract whereby x=−t= is narrowed from the de-facto unbounded-emission default to a deliberately-narrow (≤7 days) operational window, strictly bounding the post-capture replay-attempt window and shifting attacker economics toward faster-but-narrower-yield campaigns; (iii) body-length-limit (l=) tag prohibition in production signing — the operational anti-pattern documentation whereby l= use enables attacker-chosen UNSIGNED trailing content (new recipient list, new phishing payload, new attachment) to be appended AFTER the l=-bounded signed prefix while still earning dkim=pass — the operational reason DKIM best practices forbid l= in production signing; and (iv) scheduled per-tenant DKIM selector rotation cadence — the operator-side hardening control whereby periodic selector rotation (overlap-window per dkim_key_rotation contract) limits the per-selector signed-message-capture exposure window and increases the per-campaign attacker capture-and-replay cost. Read the replay-attacks spoke when KPI 5 ARC-trust-list growth, KPI 6 unknown-source-volume spikes, or KPI 8 time-to-detection drift surface in the steady-state monitoring discipline this page documents — the spoke is the operational-countermeasures stack downstream of every bypass-class (viii) attribution this monitoring discipline flags via the eight-bypass-class catalogue referenced from the previous Related-Guides entry.
• Email deliverability fundamentals — the operational-outcome companion to this monitoring page. Where this page defines the eight DMARC KPIs the monitoring discipline tracks (authenticated volume, alignment pass rate, SPF pass rate, DKIM pass rate, distinct sending sources, disposition distribution, reporter coverage, organizational policy ratio), the deliverability page documents the broader operational-outcome surface those KPIs feed into: IP reputation (Sender Score / Talos / Spamhaus ZEN), domain reputation (Google Postmaster Tools / Microsoft SNDS), FCrDNS (forward-confirmed reverse DNS), FBL (Feedback Loop) signals, list hygiene (hard-bounce + complaint thresholds), and the content-filter / throttling / greylisting / tarpitting / IP-warmup operator concerns that surface as deliverability drops in aggregate-report metadata but originate outside the DMARC layer. Read the deliverability page when a Tier-2 monitoring alert (sudden alignment drop, new sending source, reporter dropout) coincides with a delivery-rate drop in Postmaster Tools — the deliverability page catalogues every operator-side control beyond DMARC that the monitoring KPIs cannot directly observe but always interact with.
• SPF explained — Sender Policy Framework (RFC 7208). KPI 3 (SPF pass rate) is grounded in SPF evaluation; the 10-DNS-lookup ceiling is a recurring monitoring concern.
• SPF forwarding issues — the DMARC-MONITORING-STEADY-STATE- DISCIPLINE-CONSUMER-OF-SPF-FORWARDING- BREAK-CATALOGUE companion reference. Where THIS page documents the DMARC monitoring steady-state discipline (KPI 1 DMARC pass rate, KPI 2 DKIM pass rate, KPI 3 SPF pass rate, KPI 4 alignment rate, per-receiver per-day baselines, regression-detection thresholds, per- cohort drift attribution), the spf_forwarding_issues spoke is the SPF- FORWARDING-BREAK CATALOGUE canonical reference documenting the RFC 7208 §10.4 forwarding-failure mechanism + per- forwarder-population per-recipient SPF- fail-rate distribution (vacation auto- forwarders at Gmail/Outlook/Apple; recipient-side mailbox-rule forwarders; mailing-list intermediaries Mailman / Sympa / Discourse; per-customer enterprise forwarding appliances Mimecast/Proofpoint; SRS-vs-non-SRS intermediary class boundary) every DMARC-monitoring KPI baseline + per-day anomaly threshold structurally consumes. FOUR structurally-distinct DMARC- MONITORING-KPI-FORWARDING-BREAK dimensions the forwarding-issues spoke defines that this DMARC-monitoring page structurally consumes: (i) per- forwarder per-recipient SPF-fail-rate AS THE LOAD-BEARING BASELINE for KPI 3 (SPF pass rate) steady-state interpretation — the spf_forwarding_issues spoke documents the per-forwarder SPF-fail-rate baseline an operator's domain experiences across the forwarder-population catalogue; KPI 3 (SPF pass rate) reads at 88-94% steady-state at most organisational domains because the residual 6-12% is per-forwarder per-recipient SPF-fail- rate from the legitimate forwarder population — the operator's KPI 3 baseline interpretation REQUIRES the forwarder-population catalogue knowledge the spf_forwarding_issues spoke documents (a KPI 3 read of 85% is NOT necessarily a regression if the per-forwarder baseline accounts for it; a KPI 3 read of 70% IS a regression because it exceeds the per-forwarder baseline distribution); (ii) per-forwarder per-recipient SPF-fail-rate-with-DKIM-aligned-pass co-occurrence AS THE LOAD-BEARING ATTRIBUTION SIGNAL for KPI 1 (DMARC pass rate) per-cohort divergence — the spf_forwarding_issues spoke documents the per-receiver per- forwarder SPF-fail-with-DKIM-aligned- pass co-occurrence as the canonical forwarder-class signature (forwarders that DON'T body-modify preserve DKIM signature → SPF-fail/DKIM-aligned-pass → DMARC-pass); when KPI 1 (DMARC pass rate) at one receiver diverges from another receiver, the operator consults the per-forwarder SPF-fail- rate at each receiver and the forwarder-population SPF-fail-with- DKIM-aligned-pass co-occurrence signature the spf_forwarding_issues spoke documents to attribute the divergence to forwarder-population differences at the receiver (Gmail vacation-auto-forwarders behave differently from Outlook mailbox-rule forwarders); (iii) per- forwarder per-recipient SPF-fail-rate AS THE PER-DAY ANOMALY DETECTION threshold definition for steady-state regression-monitoring — the spf_forwarding_issues spoke documents the per-forwarder SPF-fail-rate distribution stability (vacation auto-forwarders are seasonally cyclical; mailing-list intermediaries are weekly-cyclical; per-customer enterprise forwarding appliances are stable); the operator's per-day regression-detection thresholds for KPI 3 (SPF pass rate) and KPI 1 (DMARC pass rate) baseline against the per-forwarder distribution stability the spf_forwarding_issues spoke quantifies — a per-day KPI 3 drop during a seasonal vacation- auto-forwarder cyclical peak is explainable; the same drop outside the cyclical window is a regression signal; (iv) per-receiver per-forwarder DKIM-aligned-pass-rate- on-forwarded-path floor AS THE LOAD- BEARING STEADY-STATE OBSERVABILITY BASELINE for ramp-readiness assessment — the spf_forwarding_issues spoke documents the per-forwarder per-recipient DKIM- aligned-pass-on-forwarded-path baseline an operator's domain depends on for DMARC-ramp readiness (the SPF half of DMARC breaks on forwarding by design; the DKIM half MUST carry the per- receiver alignment-pass load); the DMARC-monitoring operator's steady- state observability of this baseline (per-receiver per-forwarder DKIM- aligned-pass-rate-on-forwarded-path floor) is the load-bearing assessment baseline for the DMARC-ramp-readiness decision the deployment-checklist / policy-rollout pages document; the spf_forwarding_issues spoke defines the per-forwarder distribution this baseline-observability assessment consumes. Read the spf_forwarding_issues spoke alongside this DMARC-monitoring page when authoring the per-receiver per-day baseline KPI definitions and regression-detection thresholds — the forwarding-break catalogue is the load-bearing per-forwarder per-receiver SPF-fail-rate baseline reference every DMARC-monitoring KPI interpretation THIS page documents structurally consumes for steady-state distribution framing.
• SPF for Google Workspace — the WORKSPACE-SPF-DAILY-OBSERVABILITY-BASELINE companion to this DMARC monitoring steady-state discipline reference. Where THIS page documents the OPERATIONAL-DISCIPLINE-LAYER monthly / weekly / daily review cadence (KPI 1 aligned-pass rate, KPI 2 dispositional outcomes, KPI 3 SPF pass rate, KPI 4 DKIM pass rate, KPI 5 unauthorised-sender emergence, KPI 6 forwarder churn, KPI 7 ARC-trust-list growth) applicable to any sender on any platform, the SPF-for- Workspace spoke is the Workspace-tenant- SPECIFIC AUTHORING-BASELINE reference for the Workspace operator population that runs THIS monitoring discipline against a Workspace-tenant SPF record. KPI 3 (SPF pass rate, the load-bearing receiver-side authentication-verdict signal that grounds 65%+ of every Workspace operator's daily monitoring attention) MEASURES THE STABILITY of the Workspace-tenant SPF authoring decisions documented in the spoke — the include:_spf.google.com baseline coverage envelope, the secondary-SaaS-sender include population (every newly-onboarded SaaS sender that Workspace operators add to the SPF record contributes to KPI 3 churn), the on-prem-hybrid ip4: explicit-token block (every on-prem outbound IP rotation that the Workspace operator misses ages into a KPI 3 regression), and the ~all-vs--all qualifier-degradation history (a Workspace operator silently downgrading from -all to ~all to chase a temporary KPI 3 floor regression permanently weakens the SPF anti-spoofing guarantee). Read the SPF-for-Workspace spoke alongside this monitoring KPI reference when triaging a KPI 3 SPF-pass- rate regression on a Workspace tenant — the spoke is the authoritative per- platform SPF-authoring reference for the underlying SPF record whose stability KPI 3 measures, and almost every Workspace- tenant KPI 3 regression traces back to one of the authoring-decision categories catalogued in the spoke.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). DKIM key rotation is the most common regression trigger documented in Section 6.
• DKIM best practices — the 15-PER-SELECTOR-DKIM-AUTHORING-RULES- AS-LOAD-BEARING-UPSTREAM-PRODUCER-OF-KPI-3 companion to this DMARC monitoring discipline. Where THIS page documents the eight-KPI dashboard (KPI 3 DKIM pass rate, KPI 7 forwarder population, KPI 8 time-to-detection) and the Section 5 anomaly-detection-patterns Pattern E (per-verdict-shift) signal, the DKIM-best-practices spoke documents the 15 UPSTREAM per-selector DKIM-authoring rules whose per-rule operator-side compliance is the LOAD-BEARING UPSTREAM PRODUCER of every steady-state KPI 3 baseline measurement THIS monitoring dashboard reads. The 15-PER- SELECTOR-DKIM-AUTHORING-RULES-AS-KPI-3- UPSTREAM-PRODUCER cross-reference establishes FOUR structurally-distinct per-best-practice- rule-to-monitoring-KPI-baseline coupling dimensions: (i) 2048-bit RSA minimum + dual k=rsa / k=ed25519 publication per RFC 8301 §3 + RFC 8463 as Pattern E (per-verdict-shift) baseline- regression early-warning input — every Microsoft / Google / Yahoo receiver-side DKIM-cryptographic-key-strength tightening announcement (the recurring industry event where a major receiver bumps the minimum accepted RSA key-length from 1024 to 2048 bits, or adds Ed25519 verification support) triggers a Pattern E (per-verdict-shift) signal in the eight-KPI dashboard the WEEK the receiver-side change takes effect; the best-practices spoke documents Rule 1 (2048-bit RSA minimum) and Rule 2 (dual- publish) as the proactive per-selector authoring discipline whose pre-emptive compliance prevents the per-receiver cryptographic-tightening event from collapsing the operator's KPI 3 (DKIM pass rate) baseline at the receiver in question; (ii) annual rotation cadence with the 7-day-dual-selector-overlap + 30-day-in- flight-drain + 30-day-empty-p=- retention discipline as Section 6 weekly regression-detection cadence dependency — every rotation-window misconfiguration (premature retired-selector deletion, forwarder-population in-flight straddle of the cutover boundary, recursive-resolver TTL straddle of the new-selector TXT publication) produces a per-week DKIM-pass-rate dip the Section 6 weekly regression-detection cadence catches; the best-practices spoke documents Rule 4 (annual cadence) as the steady-state rotation-cadence calibration target — the operational discipline that holds the per- rotation-window DKIM-pass-rate dip below the Section 6 alerting floor when correctly executed; (iii) STRICT prohibition of the l= body-length tag as Section 5 Pattern G (anomalous-replay-burst) prevention discipline — every production selector publishing a non-zero l= body-length tag exposes the operator's signed messages to the replay- attack class where attackers append unsigned body content past the signed-body cutoff (preserving the original dkim=pass verdict while smuggling attacker-controlled payload past the receiver-side cryptographic verification); the best-practices spoke documents Rule 8 (STRICT l= prohibition) as the canonical replay-attack prevention discipline whose violation produces anomalous-replay-burst signals the KPI 5 (forwarder leakage) baseline catches; (iv) emergency revocation via empty- p= within minutes of compromise detection as KPI 8 (time-to-detection) downstream-action validation pattern — the eight-KPI dashboard's KPI 8 measures the operator's time-to-detection of a per- selector compromise (attacker-extracted private key + attacker-emitted dkim=pass spoofing campaign); the operator's downstream action AFTER detection is publishing an empty-p= selector record (RFC 6376 §3.6.1 canonical revocation pattern) rather than deleting the selector TXT record; the best-practices spoke documents Rule 13 (empty-p= revocation) as the load-bearing incident-response operational- discipline anchor whose correct execution distinguishes a controlled emergency- revocation outcome (where in-flight messages signed under the revoked selector cleanly evaluate to dkim=fail (revoked)) from a self-inflicted DKIM-cluster-wide outage (where in-flight messages collapse to dkim=permerror (selector NXDOMAIN) on every receiver). Read THIS monitoring page WITH the DKIM-best-practices spoke when the eight-KPI dashboard surfaces a per-week DKIM-pass-rate regression: the monitoring page documents the per-KPI ANOMALY DETECTION signal, the best-practices spoke documents the 15 PER-SELECTOR PUBLISHING RULES whose violation is the upstream operational cause of every steady-state KPI 3 baseline regression THIS monitoring dashboard detects.
• DKIM key rotation playbook — the DKIM-KEY-ROTATION-AS-PRIMARY-KPI-3- DKIM-PASS-RATE-REGRESSION-TRIGGER companion to this DMARC monitoring discipline. Where THIS page documents the eight-KPI dashboard (KPI 3 DKIM pass rate, KPI 7 forwarder population, KPI 8 time-to-detection) and the Section 6 weekly regression-detection cadence that flags DKIM pass-rate drops, the key-rotation spoke documents the OPERATIONAL CAUSE — the dual-selector 90-day rotation procedure (publish selector2 while selector1 still signs, wait for the TTL-bounded propagation window, switch the signer to selector2, retire selector1 only AFTER the longest receiver-cached TTL elapses) whose seven enumerated failure modes (premature old-key retirement, late new-key publication, stale resolver-cache observation, sub-RFC-8767 serve-stale re-emergence, multi-signer key-overlap drift, third-party-vendor rotation gap, operator-side DNS-TTL misestimate) each surface in the monitoring dashboard as a per-day or per-week dkim=permerror / dkim=fail verdict-rate spike triaged via Section 5 Pattern E per-verdict-shift detection. The monitoring discipline this page documents is the DETECTION layer; the key-rotation spoke is the PREVENTION layer that closes the per-rotation-window regression class upstream.
• DKIM failure verdicts explained — the PER-VERDICT-DKIM-AGGREGATE-RATE- DECODE-REFERENCE-FOR-KPI-3-DKIM-PASS- RATE-AND-KPI-7-FORWARDER-POPULATION-AND- ANOMALY-DETECTION-PATTERNS-SECTION-5 companion to this DMARC monitoring discipline. Where THIS page documents the eight-KPI operational dashboard discipline (KPI 1 authenticated volume, KPI 2 alignment pass rate, KPI 3 SPF pass rate, KPI 3 DKIM pass rate, KPI 4 distinct sending sources, KPI 5 source- IP distribution, KPI 6 DMARC failure rate, KPI 7 forwarder population, KPI 8 time-to-detection) with anomaly-detection patterns in Section 5 (Pattern E per-verdict-shift) and per-week regression detection in Section 6, the dkim-failures-explained spoke documents the per-verdict-decomposition reference operators consume to translate the KPI 3 DKIM-pass-rate headline aggregate into per-verdict drill-down (the dkim=fail rate, the dkim=permerror rate, the dkim=temperror rate, the dkim=none rate) and to map per-verdict per-week-shifts onto Section 5 Pattern E. Four DKIM- VERDICT-VS-KPI-DECOMPOSITION axes the dkim-failures-explained spoke documents that converge on the eight-KPI monitoring dashboard: (i) KPI 3 DKIM-pass-rate decomposition into per-verdict drill- down — the KPI 3 headline aggregate is "(dkim=pass row count) / (total dkim row count)"; the dkim- failures-explained spoke's per-verdict decode reference is the operator-side translation that decomposes the non-pass numerator into the structurally- distinct dkim=fail (body-hash mismatch / signature-mismatch — sender-side fix path), dkim=permerror (selector TXT record gap — sender-side fix path), dkim=temperror (DNS resolution failure — transient, no fix), dkim=none (no DKIM-Signature header — third-party- sender enrolment path) per-week per- verdict-class aggregate-rates, each with a distinct remediation path the operator routes to a different responsible team; (ii) KPI 7 forwarder-population drill-down via dkim=pass-with-misaligned-d= verdict attribution — the KPI 7 aggregate enumerates per-receiver-domain forwarder-fan-out (the legitimate- forwarder population whose second-hop SPF-fail rows the operator MUST NOT treat as attacker traffic); the dkim- failures-explained spoke's dkim=pass-with-misaligned- d= verdict semantics expose the canonical forwarder signature (legitimate-forwarder rebroadcast with the original sender's DKIM signature still passing but the receiver's Header-From not matching the signing domain) that operators consume to enumerate the forwarder population without per-source-IP attacker-traffic- false-positive contamination; (iii) Section 5 anomaly- detection Pattern E (per-verdict-shift) as the dkim-failures-explained-per- verdict-distribution-drift-detection- layer — Pattern E documents the per-week per-verdict-distribution drift signal (a sudden 50-percent jump in dkim=permerror rate / dkim=temperror rate / dkim=none rate); the dkim- failures-explained spoke documents the per-verdict-class root-cause taxonomy operators consume to classify the Pattern E signal (was the dkim=permerror jump caused by a DNS-publisher TXT- record-deletion regression / a selector- rotation gap / a third-party-signer public-key takeover / an attacker- driven anomaly?) and to route each per- verdict-class root-cause to the appropriate per-team incident channel; (iv) Section 6 post-configuration- change regression detection via per- verdict-baseline-shift attribution — Section 6 documents the per-week regression-detection discipline that runs IMMEDIATELY after any DKIM-related configuration change (selector rotation, canonicalisation choice swap, third-party- signer enrolment, key-length upgrade); the dkim-failures-explained spoke's per-verdict decode reference is the operator-side regression-classification ladder that converts each post-change per-verdict aggregate-rate shift into a regression-class diagnosis (was the dkim=fail rate spike caused by the canonicalisation choice swap producing body-hash-mismatch on legitimate-mail, or by an attacker-driven signature- forgery attempt that failed verification producing permerror?). Pair this monitoring page (the eight-KPI dashboard + Section 5 anomaly patterns + Section 6 regression detection) with the dkim- failures-explained spoke (the per- verdict-decode-and-root-cause-class reference) for the complete monitoring- discipline-AND-DKIM-verdict- decomposition posture every operator needs to sustain steady-state observability of the DKIM-signing portion of the DMARC-evaluation surface with per-verdict-class root-cause attribution instead of opaque per- aggregate-headline-number monitoring.
• DKIM canonicalization — the KPI-3-DKIM-PASS-RATE- DECOMPOSITION-BY-CANONICALIZATION- ALGORITHM companion to this DMARC- monitoring KPI-discipline reference. Where THIS page documents the eight- KPI steady-state monitoring discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection), the DKIM- canonicalization spoke documents the RFC 6376 §3.4 four-combination algorithm catalogue whose per-publisher per- selector choice is the LOAD-BEARING UPSTREAM DETERMINANT of the per-message DKIM-pass-rate variance the eight-KPI dashboard surfaces at the per-source-IP + per-receiver-organisation + per- forwarder-class granularity. Three concrete monitoring-vs-canonicalization coupling points: (i) KPI 3 (DKIM pass rate) per-receiver-interval decomposition by canonicalization- algorithm — operators publishing c=simple/simple see DKIM- pass-rate floors lower than operators publishing c=relaxed/relaxed because any whitespace normalisation by an intermediate MTA invalidates the body hash under c=simple; the DKIM- canonicalization spoke documents the per-algorithm whitespace-tolerance rules and the canonical per-publisher per-selector best-practice (c=relaxed/relaxed) the eight-KPI dashboard's DKIM-pass-rate baseline assumes; (ii) KPI 7 (forwarder population) per-forwarder- class DKIM-survival-rate attribution — the per-forwarder DKIM-survival rate the monitoring discipline tracks at the per-receiver- interval scope is structurally bounded by the per-publisher canonicalization choice; the DKIM-canonicalization spoke documents which forwarder mutations survive c=relaxed/relaxed (mid-line whitespace normalisation + SP/CRLF re-folding) vs which break it (body modification beyond whitespace — list-footer injection, banner appending); (iii) KPI 6 (DMARC failure rate) cascade-effect from canonicalization- induced DKIM-fail — a sustained per-message canonicalization-failure rate cascades DIRECTLY into the DMARC failure rate when the same per-message flow lacks an aligned SPF pass; the DKIM-canonicalization spoke documents the per-algorithm canonicalization- failure decomposition that lets the operator attribute the DKIM-fail rows in the aggregate-XML evidence stream to canonicalization-axis root-cause vs key-rotation-axis root-cause vs selector-publication-axis root-cause. Read the DKIM-canonicalization spoke ALONGSIDE this DMARC-monitoring reference whenever the per-domain DKIM-pass-rate KPI surfaces a regression and the canonicalization- algorithm choice is the load-bearing upstream variable to investigate.
• ARC (Authenticated Received Chain) explained — RFC 8617: ARC preserves DMARC verdicts across forwarding hops, an alignment- preserving mechanism that affects KPI 2 for forwarded mail.
• BIMI explained — BIMI deployment readiness checks are part of the Tier 3 monthly review.
• BIMI Verified Mark Certificates (VMC and CMC) — the MONITORING-WORKFLOW-CONTINUOUSLY- OBSERVES-VMC-CONTINUED-VALIDITY- PRECONDITIONS companion reference. Where THIS page documents the six-KPI DMARC monitoring discipline (message- volume, SPF / DKIM / DMARC pass-rate, unknown-source escalation, alert-routing SLO bands) and the Tier 1 daily / Tier 2 weekly / Tier 3 monthly review cadence operators run on top of the aggregate- RUA stream, the BIMI-certificates spoke documents the VMC/CMC X.509 trademark- bound certificate whose CA-MPKI-contract- bound continued validity is STRUCTURALLY DEPENDENT on the per-day pass-rate KPIs this monitoring discipline tracks, across four per-VMC monitoring-KPI dimensions: (i) the Tier 3 monthly review's BIMI deployment-readiness check is the FORMAL DECISION GATE between p=none monitoring posture and p=quarantine pct=100/ p=reject enforced posture the VMC issuance contract requires — the KPI 4 DMARC-aligned-pass rate floor (≥99% across all legitimate sender cohorts) is the empirical evidence input the monthly review consumes to clear the enforcement- ramp graduation milestone, (ii) post- issuance VMC continued validity is contractually conditional on MAINTAINED DMARC enforcement — KPI 4 regression below the pass-rate floor is the LEADING INDICATOR that the operator's MPKI contract obligations are at risk before the trademark-CA renewal cycle ever surfaces an explicit non-compliance signal, (iii) per-receiver-cohort VMC evaluation produces measurable degradation patterns in the KPI 5 unknown-source escalation feed when the receiver's internal DMARC-pass-rate-per-source_ip metric (the same metric KPI 4 exposes for operator-side verification) crosses the receiver's BIMI-evaluator- side display-eligibility threshold, producing observable per-receiver BIMI-display-eligibility transitions the monitoring discipline catches at the Tier 2 weekly review, and (iv) the BIMI-record lifecycle event catalogue (VMC revocation, SVG asset URL rotation, BIMI l= record update) produces verification- result-transition signatures the KPI monitoring dashboards surface as alert-routing-eligible state changes, composing the per-VMC lifecycle event stream with the per-DMARC-record lifecycle event stream this page already monitors. Read the BIMI- certificates spoke alongside this monitoring discipline reference when planning the Tier 3 monthly review's BIMI deployment-readiness checklist — the VMC's MPKI-contract-bound continued-validity preconditions require the KPI 4 DMARC-aligned-pass rate floor to be maintained at the steady-state level that issuance required, and the monitoring discipline THIS page documents is the empirical evidence pipeline that produces the continuous-attestation signal for that contractual commitment.
• BIMI SVG Tiny PS logo requirements — the MONITORING-WORKFLOW-CONTINUOUSLY- OBSERVES-TINY-PS-FILE-FORMAT-COMPLIANCE companion to this DMARC-monitoring KPI- discipline reference. Where THIS page documents the eight-KPI steady-state monitoring discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to- detection) and the Tier 1 daily / Tier 2 weekly / Tier 3 monthly review cadence operators run on top of the aggregate- RUA stream, the BIMI-SVG-requirements spoke documents the byte-level Tiny PS file-format profile whose continuous compliance is STRUCTURALLY UPSTREAM of the BIMI logo-rendering enrichment surface every mailbox provider (Gmail, Yahoo, Apple Mail, Fastmail) gates on the per-publisher per-domain pass-rate floor THIS monitoring discipline tracks. Three concrete monitoring-discipline- vs-Tiny-PS-file-format-compliance coupling points: (i) Tier 3 monthly BIMI-eligibility review — the per-domain monthly cadence verifies BOTH the per-day DMARC-enforcement floor (the monitoring KPI side) AND the live Tiny PS file-format compliance of the l=-URL-resolved SVG (the publication-side precondition); a Tiny PS profile regression at the baseProfile, viewBox, <title>, or forbidden- element axis silently drops BIMI logo rendering even when the KPI-floor remains green; (ii) cross-axis regression triage — when the monitoring discipline surfaces a BIMI-rendering- regression alert (Gmail BIMI logo disappears for a per-domain audience), the Tiny PS file-format axis is one of the four canonical regression-axes the operator must triage (alongside DMARC- enforcement floor regression, VMC chain-of-trust regression, and BIMI DNS-record regression); the BIMI-SVG- requirements spoke documents the per- attribute regression catalogue that bounds the file-format-axis triage step; (iii) brand-onboarding green- path validation — when the monitoring discipline THIS page documents is first stood up for a new domain, the per-domain BIMI-eligibility-establishment green-path requires Tiny PS file-format validation as the pre-publication precondition; the BIMI-SVG-requirements spoke documents the byte-level validation-toolchain (BIMI Group converter + SVGO + validator) the operator runs BEFORE the l=-URL goes live, so the monitoring discipline's BIMI-eligibility KPI does not silently flat-line at the per-day per-receiver granularity. Read the BIMI-SVG-requirements spoke ALONGSIDE this DMARC-monitoring reference whenever the per-publisher per-domain BIMI-eligibility KPI surfaces a logo-rendering regression OR when first standing up the monitoring discipline for a domain whose BIMI deployment-readiness has not yet been validated end-to-end at the file-format- compliance axis.
• MTA-STS explained — SMTP transport security.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460).
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the MONITORING-WORKFLOW-INGESTS-TLS- RPT-JSON-PAYLOAD-BYTE-SCHEMA-ALONGSIDE- DMARC-RUA-XML-PAYLOAD-BYTE-SCHEMA-AS- CROSS-PROTOCOL-UNIFIED-OBSERVABILITY- FEED companion to this DMARC-monitoring KPI-discipline reference. Where THIS page documents the six-KPI monitoring discipline (KPI 1 message-volume per day, KPI 2 SPF pass-rate, KPI 3 DKIM pass-rate, KPI 4 DMARC-aligned-pass rate, KPI 5 forwarder-leakage-rate, KPI 6 unknown-source-IP rate) driven by per- receiver per-day RUA aggregate-report XML-payload ingestion, the TLS-RPT- report-format spoke documents the PARALLEL TRANSPORT-LAYER OBSERVABILITY CHANNEL whose JSON-payload byte-schema feeds an additional FOUR transport- layer KPIs the monitoring discipline absorbs from the same receiver-side feedback infrastructure. FOUR structurally-distinct DMARC-RUA- MONITORING-VS-TLS-RPT-JSON-KPI cross- protocol KPI classes the spoke enumerates that THIS RUA-XML-centric monitoring reference cross-references but does not byte-schema enumerate: (i) per-receiver per-day STARTTLS-success-rate KPI from summary.total-successful-session- count divided by total session- attempt count — the transport- layer parallel to KPI 2 / KPI 3 / KPI 4 application-layer pass-rate KPIs this page documents, surfacing the per- receiver per-day transport-encryption- enforcement-rate as a time-series the monitoring dashboard plots alongside the application-layer pass-rate KPIs; (ii) per-receiver per-day STARTTLS-failure-class breakdown from failure-details[].result-type enumeration — the transport- layer parallel to the RUA aggregate- report per-row auth-results decomposition this page documents, surfacing the per-class transport- failure attribution (starttls-not- supported, certificate-host-mismatch, certificate-not-trusted, certificate- expired, validation-failure, tls- error, dane-invalid) as a per-class- per-receiver per-day time-series the monitoring discipline absorbs as KPI bands; (iii) per-receiver per- day TLS-RPT-receiving-MTA-policy-string attribution from policies[].policy.policy-string decomposition — the per- publisher per-day record of which MTA- STS policy file or DANE TLSA record was evaluated at the receiving MTA, which when joined against the per- publisher per-day DMARC-RUA per-source- IP attribution this page documents produces a unified transport-layer-and- application-layer per-source-IP per- day per-receiver observability matrix; (iv) cross-protocol pipeline- reuse of Stages 1-4 (ingestion, format- detection, decompression, schema- validation) verbatim across RUA XML and TLS-RPT JSON payloads — the operator's seven-stage DMARC-RUA pipeline architecture documented in dmarc_reporting_pipeline reuses Stages 1-4 identically for TLS-RPT JSON payloads, parameterising Stage 5 on application/tlsrpt+gzip vs application/zip Content-Type, so the monitoring discipline this page documents absorbs the TLS-RPT JSON-payload-byte-stream through the same ingestion infrastructure without architectural change. Read the TLS-RPT-report-format spoke alongside this DMARC-monitoring KPI-discipline reference when constructing the organisation's UNIFIED cross-protocol observability dashboard whose top-level KPI cards plot application-layer DMARC- aligned-pass rate (this page) AND transport-layer STARTTLS-success rate (the TLS-RPT-report-format spoke) as complementary per-day per-receiver time-series the security team's defense- in-depth posture is measured-of-record against.
• CAA records explained — Certification Authority Authorization (RFC 8659).
• DMARC for Google Workspace — Workspace-specific monitoring via Postmaster Tools.
• DKIM for Google Workspace (Gmail) — the WORKSPACE-TENANT-SINGLE-SELECTOR- DKIM-PUBLICATION companion to this DMARC- monitoring KPI-discipline reference for operators whose per-domain sender-class inventory includes Google Workspace egress. Where THIS page documents the eight-KPI steady-state monitoring discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) and the Tier 1 daily / Tier 2 weekly / Tier 3 monthly review cadence operators run on top of the aggregate-RUA stream, the Workspace-DKIM spoke documents the per-tenant Admin Console DKIM-publication workflow whose per-tenant byte-level compliance is the LOAD-BEARING UPSTREAM PRODUCER of the Workspace-egress portion of the per-receiver-interval baseline KPI measurements. Three concrete monitoring-vs-Workspace-DKIM coupling points: (i) KPI 3 (DKIM pass rate) Workspace-egress baseline — the Workspace-egress per-receiver- interval DKIM-pass-rate baseline is structurally bounded by the per-tenant single-selector google._domainkey publication discipline; a Workspace tenant that has not completed the Admin Console "Generate new record" workflow (or has stopped at the legacy 1024-bit key default) drops the Workspace-egress DKIM-pass-rate baseline well below the per-domain steady-state floor; (ii) KPI 2 (alignment pass rate) Workspace-egress gappssmtp.com signing- identity gotcha — when a Workspace tenant has not yet activated the operator-controlled google._domainkey publication, Workspace egress signs with the per-tenant <tenant>.gappssmtp.com identity instead of the operator's domain; the per-message DKIM verdict is then dkim=pass but DKIM-alignment fails against the RFC 5322 From: domain, cascading into a sustained DMARC-fail rate the eight- KPI dashboard surfaces as a per- Workspace-tenant alignment-pass-rate regression; the Workspace-DKIM spoke documents the per-tenant activation workflow that closes this gotcha; (iii) KPI 8 (time-to-detection) Workspace-egress regression attribution — when the eight- KPI dashboard surfaces a per-Workspace- tenant DKIM-pass-rate or alignment- pass-rate regression, the operator- side root-cause attribution ladder materially depends on the Workspace- DKIM spoke's per-tenant publication- discipline catalogue to distinguish Admin-Console-rotation-axis root-cause (the per-tenant manual rotation cadence was missed) from publication-axis root-cause (the operator-controlled google._domainkey TXT record was overwritten or expired at the per-domain DNS zone). Read the Workspace-DKIM spoke ALONGSIDE this DMARC-monitoring reference whenever the per-domain mail-flow inventory includes Google Workspace egress and the per-Workspace-tenant DKIM-pass-rate + alignment-pass-rate KPI baseline is the load-bearing measurement the eight- KPI monitoring dashboard tracks.
• DKIM for Microsoft 365 — the M365-TENANT-DUAL-SELECTOR-CNAME- DKIM-PUBLICATION companion to this DMARC- monitoring KPI-discipline reference for operators whose per-domain sender-class inventory includes Microsoft 365 egress. Where THIS page documents the eight-KPI steady-state monitoring discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) and the Tier 1 daily / Tier 2 weekly / Tier 3 monthly review cadence operators run on top of the aggregate-RUA stream, the M365-DKIM spoke documents the per-tenant Defender DKIM- publication workflow whose per-tenant CNAME-publication compliance is the LOAD-BEARING UPSTREAM PRODUCER of the M365-egress portion of the per-receiver- interval baseline KPI measurements. Three concrete monitoring-vs-M365-DKIM coupling points: (i) KPI 3 (DKIM pass rate) M365-egress baseline — the M365-egress per- receiver-interval DKIM-pass-rate baseline is structurally bounded by the per-tenant dual-selector selector1. _domainkey / selector2. _domainkey CNAME-publication discipline; an M365 tenant that has not completed the Defender "Enable DKIM" toggle (or has stopped at the legacy not-yet-activated default where the two CNAMEs are absent from the per-domain DNS zone) drops the M365-egress DKIM- pass-rate baseline well below the per- domain steady-state floor; (ii) KPI 2 (alignment pass rate) M365-egress onmicrosoft.com signing-identity gotcha — when an M365 tenant has not yet activated the operator-controlled selector1 / selector2 CNAMEs, M365 egress signs with the per-tenant <tenant>.onmicrosoft.com identity instead of the operator's domain; the per-message DKIM verdict is then dkim=pass but DKIM- alignment fails against the RFC 5322 From: domain, cascading into a sustained DMARC-fail rate the eight-KPI dashboard surfaces as a per-M365-tenant alignment- pass-rate regression; the M365-DKIM spoke documents the per-tenant activation workflow that closes this gotcha; (iii) KPI 8 (time-to-detection) M365-egress regression attribution — when the eight-KPI dashboard surfaces a per- M365-tenant DKIM-pass-rate or alignment- pass-rate regression, the operator-side root-cause attribution ladder materially depends on the M365-DKIM spoke's per- tenant publication-discipline catalogue to distinguish Defender-activation-axis root-cause (the per-tenant Enable-DKIM toggle was never flipped or was regressed during a tenant migration) from publication-axis root-cause (one or both selector1 / selector2 CNAMEs were overwritten or expired at the per-domain DNS zone, breaking the per-tenant delegation chain even though the Defender toggle is still on). Read the M365-DKIM spoke ALONGSIDE this DMARC- monitoring reference whenever the per- domain mail-flow inventory includes Microsoft 365 egress and the per-M365- tenant DKIM-pass-rate + alignment-pass- rate KPI baseline is the load-bearing measurement the eight-KPI monitoring dashboard tracks.
• MTA-STS for Microsoft 365 — the M365-TENANT-PER-DOMAIN-MTA-STS- TRANSPORT-LAYER-POLICY-PUBLICATION companion to this DMARC-monitoring KPI- discipline reference for operators whose per-domain transport-layer inventory includes Microsoft 365 egress. Where THIS page documents the eight-KPI steady- state monitoring discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) and the Tier 1 daily / Tier 2 weekly / Tier 3 monthly review cadence operators run on top of the aggregate-RUA stream, the M365-MTA-STS spoke documents the per-tenant Exchange Online MTA-STS-publication workflow whose per-tenant TXT-record + HTTPS-policy- host + TLS-RPT-mailbox compliance is the LOAD-BEARING UPSTREAM PRODUCER of the M365-egress transport-layer portion of the per-receiver-interval baseline transport-layer TLS-negotiation KPI measurements. Three concrete monitoring- vs-M365-MTA-STS coupling points: (i) per-receiver-interval transport- layer TLS-handshake-success baseline as load-bearing M365-egress deliverability determinant — the M365-egress per-receiver-interval transport-layer TLS-handshake-success baseline is structurally bounded by the per-tenant mode: enforce MTA-STS policy's correct enumeration of the Exchange Online canonical MX hostnames; an M365 tenant whose mta-sts.txt policy file's mx: hostname-glob list does NOT enumerate *.mail.protection.outlook.com produces a per-receiver transport-layer delivery failure spike the eight-KPI dashboard surfaces as a per-M365-tenant DMARC-source-volume regression; (ii) per-tenant testing → enforce mode-progression as load-bearing rollout- risk-mitigation discipline — the per-tenant Exchange Online MTA-STS mode progression must start at mode: testing with TLS-RPT JSON-aggregate ingestion confirming a per-tenant steady-state zero-failure baseline before advancing to mode: enforce; premature promotion to enforce mode (without testing-mode steady-state baseline confirmation) is the highest-incidence cause of post-rollout M365-egress delivery-failure incidents the monitoring dashboard surfaces; (iii) per-tenant TLS-RPT JSON-aggregate ingestion as load-bearing root-cause attribution axis for transport-layer regression — when the eight-KPI dashboard surfaces a per-M365-tenant transport-layer regression, the operator-side root-cause attribution ladder materially depends on the M365- MTA-STS spoke's per-tenant TLS-RPT JSON-aggregate summary.total- failure-session-count + failure-details[].result-type analysis to distinguish policy-publication- axis root-cause (the per-tenant mta-sts.txt policy file does not enumerate the receiving MX) from certificate-publication-axis root-cause (the per-tenant mta-sts.<domain> HTTPS-policy-host certificate has expired) from DNS-publication-axis root-cause (the per-tenant _mta-sts.<domain> TXT record was overwritten or expired). Read the M365-MTA-STS spoke ALONGSIDE this DMARC-monitoring reference whenever the per-domain transport-layer inventory includes Microsoft 365 egress and the per-M365-tenant transport-layer TLS- negotiation KPI baseline is the load- bearing measurement the eight-KPI monitoring dashboard tracks.
• MTA-STS for Google Workspace (Gmail) — the WORKSPACE-TENANT-PER-DOMAIN-MTA- STS-TRANSPORT-LAYER-POLICY-PUBLICATION companion to this DMARC-monitoring KPI- discipline reference for operators whose per-domain transport-layer inventory includes Google Workspace egress. Where THIS page documents the eight-KPI steady-state monitoring discipline (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) and the Tier 1 daily / Tier 2 weekly / Tier 3 monthly review cadence operators run on top of the aggregate-RUA stream, the Workspace-MTA- STS spoke documents the per-tenant Gmail MTA-STS-publication workflow whose per-tenant TXT-record + HTTPS-policy- host + TLS-RPT-mailbox compliance is the LOAD-BEARING UPSTREAM PRODUCER of the Workspace-egress transport-layer portion of the per-receiver-interval baseline transport-layer TLS-negotiation KPI measurements. Three concrete monitoring- vs-Workspace-MTA-STS coupling points: (i) per-receiver-interval transport-layer TLS-handshake-success baseline as load-bearing Workspace- egress deliverability determinant — the Workspace-egress per-receiver- interval transport-layer TLS-handshake- success baseline is structurally bounded by the per-tenant mode: enforce MTA-STS policy's correct enumeration of the Gmail canonical MX hostnames; a Workspace tenant whose mta-sts.txt policy file's mx: hostname-glob list does NOT enumerate the five *.ASPMX.L.GOOGLE.COM hostnames produces a per-receiver transport-layer delivery failure spike the eight-KPI dashboard surfaces as a per-Workspace-tenant DMARC-source-volume regression; (ii) per-tenant testing → enforce mode-progression as load-bearing rollout-risk-mitigation discipline — the per-tenant Gmail MTA-STS mode progression must start at mode: testing with TLS-RPT JSON-aggregate ingestion confirming a per-tenant steady-state zero-failure baseline before advancing to mode: enforce; premature promotion to enforce mode (without testing-mode steady-state baseline confirmation) is the highest-incidence cause of post-rollout Workspace-egress delivery-failure incidents the monitoring dashboard surfaces; (iii) per-tenant TLS-RPT JSON- aggregate ingestion as load-bearing root-cause attribution axis for transport-layer regression — when the eight-KPI dashboard surfaces a per-Workspace-tenant transport-layer regression, the operator-side root- cause attribution ladder materially depends on the Workspace-MTA-STS spoke's per-tenant TLS-RPT JSON- aggregate summary.total-failure- session-count + failure- details[].result-type analysis to distinguish policy-publication-axis root-cause (the per-tenant mta-sts.txt policy file does not enumerate the five Gmail MX hostnames) from certificate-publication- axis root-cause (the per-tenant mta-sts.<domain> HTTPS-policy-host certificate has expired) from DNS-publication-axis root-cause (the per-tenant _mta-sts.<domain> TXT record was overwritten or expired). Read the Workspace-MTA-STS spoke ALONGSIDE this DMARC-monitoring reference whenever the per-domain transport-layer inventory includes Google Workspace egress and the per- Workspace-tenant transport-layer TLS- negotiation KPI baseline is the load- bearing measurement the eight-KPI monitoring dashboard tracks.
• DMARC for Microsoft 365 — M365-specific monitoring via Defender for Office 365.
• DMARC for Hybrid Exchange (on-prem + Microsoft 365) — the HYBRID-COEXISTENCE-DUAL-OUTBOUND- BOUNDARY companion to this eight-KPI steady-state monitoring discipline. Where THIS page documents the per-receiver- interval KPI 1-8 dashboard reading the aggregate XML feed, the hybrid-coexistence spoke is the HYBRID-TOPOLOGY-SEGMENTATION REFERENCE documenting how hybrid Exchange / Exchange Online coexistence introduces TWO outbound boundaries (on-prem outbound through the HCW-configured send connector + EXO cloud-egress through Exchange Online Protection) whose per-receiver-interval KPI segmentation MUST be split in the rua=-aggregated XML feed: KPI 5 (distinct sending sources) baseline structurally doubles across the on-prem outbound population and the EXO cloud-egress pool; KPI 4 (DKIM pass rate) baseline depends on the operator's resolved dual-signer outcome (cloud-only signing eliminates the on-prem signing boundary; on-prem- only signing eliminates the cloud signing boundary; the dual-signer pattern produces a per-message ambiguous signing- identity verdict the monitoring dashboard cannot disambiguate without the hybrid- topology context this spoke establishes); KPI 1 (DMARC pass rate) baseline requires per-outbound-boundary segmentation to detect on-prem-relay ARC-seal verification regressions independently from EXO-egress DKIM-pass-rate regressions. Read the hybrid-coexistence spoke FIRST when establishing the eight-KPI baseline for any operator domain running hybrid Exchange.
• DMARC for cPanel & Shared Hosting — control-panel-tier monitoring on the Email Deliverability page.
• DMARC for Shared Hosting — Plesk, DirectAdmin, ISPConfig, generic- no-control-panel monitoring patterns.
• DMARC for transactional email — per-ESP KPI-baseline monitoring discipline for SendGrid / Mailgun / SES / Postmark / SparkPost — the PER-ESP-KPI-BASELINE-MONITORING companion to this DMARC monitoring discipline for the operator population running steady-state observability across outbound transactional mail delegated to a third-party ESP. Where this page documents the generic KPI framework (KPI 1 DMARC-pass rate, KPI 2 alignment-pass rate, KPI 3 SPF- pass rate, KPI 4 DKIM-pass rate, KPI 5 forwarder-leakage rate, KPI 6 unknown-source volume), the transactional-email spoke documents the per-ESP onboarding-and- steady-state monitoring patterns that any operator delegating outbound transactional mail must layer onto the generic framework: per-ESP-stream KPI segmentation (SendGrid transactional vs SendGrid marketing tagged separately in the rua=-aggregated XML to prevent broadcast-stream churn from polluting the transactional-stream baseline), per-ESP-IP-pool warmup-phase KPI-floor expectations (SES dedicated-IP warmup produces multi-week KPI 3 SPF-pass churn while new IPs are enumerated; Postmark shared-pool stays stable; Mailgun region- dedicated-pool needs per-region observation), per-ESP DKIM-key-rotation observability (operator can detect the SendGrid CNAME- delegated rotation event by watching the s= selector field in decoded-RUA dkim=pass entries), and the per-ESP Authentication-Results canonicalisation drift the operator must observe (Mailgun and SES diverge in Authentication-Results header formatting which affects which downstream observability tools parse alignment verdicts correctly). Pair this monitoring discipline (the generic KPI dashboard) with the transactional-email spoke (the per-ESP baseline-monitoring overlay) for the complete steady-state observability workflow on any domain whose outbound mail is wholly or partly delegated to a transactional-email ESP.
• DMARC for SaaS senders — the MULTI-TENANT-PLATFORM-CROSS-TENANT- ATTRIBUTION-MONITORING-CHALLENGE companion to this DMARC monitoring discipline. Where THIS page documents the EIGHT-KPI steady- state observability framework and the transactional-email spoke immediately above documents the per-transactional-ESP baseline-monitoring overlay, the saas-senders spoke is the MULTI-TENANT- PLATFORM SIBLING documenting the OPERATIONAL MONITORING CHALLENGES specific to the customer-engagement-platform population (Mailchimp, Marketo, HubSpot, Pardot, Klaviyo, Constant Contact, Salesforce Marketing Cloud, Shopify, BigCommerce) whose outbound mail crosses an authority-boundary gap through a multi-tenant platform's shared-tenant pool IPs. Four operationally-distinct cross-tenant-attribution monitoring challenges the spoke catalogues that the KPI 1-8 framework this page documents individually surfaces but never collectively attributes to multi-tenant-platform authority-boundary configuration: (i) shared-tenant pool-IP source-IP attribution gap in KPI 1 / KPI 6 — the RUA aggregate-report row's source_ip column shows the platform's shared-tenant pool IP with no sub-tenant differentiation, making per-customer authentication-volume (KPI 1) and unknown-source-volume (KPI 6) attribution operationally ambiguous: a spike in pool-IP traffic could mean (a) legitimate platform- wide volume growth from many tenants, (b) a single attacker sub-tenant exploiting bypass class (vii), or (c) platform-side misconfiguration cross-routing one customer's mail through another customer's sender-zone; (ii) per-tenant CNAME- delegated DKIM selector observability in KPI 4 — the operator can detect per-tenant DKIM signing-zone changes by watching the s= selector field in decoded-RUA dkim=pass entries for per-customer CNAME-target rotation (k1._domainkey.customer.com cycles through k1 → k2 → k3 as the platform's master-zone rotation cadence progresses), but the platform-operator's rotation calendar is OPAQUE to the customer-domain operator and unscheduled rotation drift surfaces as transient KPI 4 DKIM-pass-rate troughs the customer cannot debug without platform-side ops support; (iii) platform-side abuse-detection coordination for KPI 6 unknown-source escalation — when KPI 6 surfaces an unknown-source spike attributable to the platform's pool IP, the customer-side DMARC monitoring discipline must coordinate with the platform's abuse-detection / per-tenant rate-limiting / KYC-tier- enforcement teams to isolate whether the spike is a sub-tenant abuse incident (bypass class (vii)), a platform-wide misconfiguration, or a legitimate cross-customer marketing-campaign load — the spoke documents the platform-side cooperation contract every multi-tenant ESP publishes (or refuses to publish); and (iv) BIMI alignment-floor threshold cooperation gap — the steady-state KPI 2 alignment-pass-rate floor THIS page documents as the prerequisite for BIMI certificate publication depends on every contributing SaaS platform's per-customer DKIM- delegation and SPF-include-token coverage being correctly cooperatively-configured; per-tenant cooperation failures (platform published its include token to the customer's apex SPF record but did NOT publish the corresponding per-tenant DKIM CNAME) directly suppress the KPI 2 floor and block BIMI VMC procurement. Read the saas-senders spoke when the KPI 1-8 framework on THIS page surfaces shared- tenant pool-IP attribution gaps or per-tenant cooperation-failure patterns the customer-domain monitoring discipline cannot independently attribute without platform-side coordination — the spoke is the canonical operational-coordination reference downstream of every KPI 1 / KPI 4 / KPI 6 pool-IP-attribution-challenge signal this monitoring discipline raises on multi-tenant-platform-routed mail.
• SPF qualifiers explained — the RUA-AGGREGATE-MONITORING- FEEDBACK-LOOP-FOR-SPF-QUALIFIER- TIGHTENING-FROM-SOFTFAIL-TO-HARDFAIL companion reference. Where THIS page documents the KPI dashboard (alignment-pass rate, source-IP triage, anomaly thresholds, receiver-coverage breadth, ramp-gate criteria) and the Tier 0 / Tier 1 / Tier 2 / Tier 3 monitoring discipline operating on RUA aggregate reports, the SPF-qualifiers spoke documents the FOUR QUALIFIER PREFIXES (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose VALUE-CHOICE on the all mechanism is the OPERATIONAL LEVER the monitoring feedback loop tunes. RUA reports surface per-source-IP result_type rows catalogued under spf=pass / spf=softfail / spf=fail / spf=permerror / spf=temperror / spf=neutral / spf=none dispositions — the monitoring discipline catalogues every non-authorised source-IP per rolling 30-day window. The canonical enforcement-ramp playbook flips the qualifier from ~all (SoftFail, monitoring-mode — receivers SHOULD NOT reject on this result) to -all (Fail — receivers MAY reject per RFC 7208 §4.7) once two consecutive monitoring windows show every non-authorised source-IP attributed to known- attacker-or-bulk-spam-actor patterns (zero legitimate-sender false- positives outside the SPF record). The qualifier-tightening decision is the canonical OUTPUT of the steady-state monitoring loop this page documents. Read the qualifier spoke alongside this page when the monthly KPI review surfaces the qualifier-flip gate as ready — the ~all → -all transition is the monitoring-driven hardening step the observability discipline produces.
• Business Email Compromise (BEC) — the RUA-AGGREGATE-DETECTION-INFRASTRUCTURE-FOR-BEC-PATTERN-SURFACING companion to this monitoring reference — the RUA-AGGREGATE-DETECTION-INFRASTRUCTURE- FOR-BEC-PATTERN-SURFACING companion documenting how the steady-state aggregate-report monitoring loop THIS page documents is the OBSERVATIONAL INFRASTRUCTURE through which operators detect Business Email Compromise attack indicators in production mail streams. Where THIS page documents the monitoring DISCIPLINE in operational terms (Tier 1 weekly per-source_ip alignment-fail-rate review, Tier 2 monthly new-source_ip-row attribution audit, Tier 3 quarterly orgdomain- wide policy_evaluated trend analysis), the BEC spoke documents which RUA-row signatures are diagnostic of the BEC threat class: a sudden non-authorised source-IP row with non-zero envelope-MAIL-FROM count and policy_evaluated.dkim/spf=fail on the From:-aligned domain (direct exact- domain spoofing under p=none), a Punycode-confusable orgdomain in the header_from field of a sibling-tenant's RUA (lookalike-domain spoofing), or a sudden spike in legitimate- source aligned-pass volume that doesn't match the operator's sending calendar (an authentic compromised vendor account whose DKIM-signed mail authenticates successfully but originates from an attacker-controlled operator at the vendor's egress — VEC subtype). Read THIS monitoring-discipline page WITH the BEC reference when the monthly Tier 2 review surfaces a new source-IP row the inventory cannot attribute, OR when the finance team reports a fraudulent wire transfer originating from what appears to be a legitimate-vendor email — the BEC spoke catalogues the four attack sub- techniques (exact-domain spoofing, lookalike- domain registration, display-name spoofing, compromised-account VEC) whose RUA-row signatures map directly to the monitoring observations this page collects.
• DMARC multi-domain strategy — the DMARC-MONITORING-AS-PER- DOMAIN-PORTFOLIO-SCALE-OBSERVABILITY- STREAM companion to this DMARC- monitoring eight-KPI continuous- observability synthesis. Where THIS page documents the eight monitoring KPIs (KPI 1 DMARC pass rate, KPI 2 SPF pass rate, KPI 3 DKIM pass rate, KPI 4 disposition-action distribution, KPI 5 per-source_ip volume baseline, KPI 6 unknown-source-escalation triage cadence, KPI 7 forwarder- population stability, KPI 8 BIMI- display-eligibility steady-state) applied to a SINGLE protected domain's aggregate-report feed, the multi-domain strategy spoke documents how a PORTFOLIO-MANAGEMENT operator running a publisher with MULTIPLE protected domains constructs a UNIFIED CROSS-DOMAIN DASHBOARD where the eight KPIs appear as a PER-DOMAIN matrix whose cross-domain correlations surface portfolio-scale anomalies that single-domain monitoring cannot detect. FOUR structurally- distinct PORTFOLIO-MONITORING- DASHBOARD-COORDINATION dimensions emerge from cross-mapping the eight-KPI catalogue against the portfolio-management workflow: (1) Portfolio-wide KPI 1 DMARC-pass-rate cross-domain joint- baseline-deviation detection at the per-domain-vs-portfolio-aggregate- pass-rate divergence boundary — the multi-domain spoke documents the per-domain baseline-divergence anomaly class where the portfolio's org-domain holds steady-state 98% DMARC-pass-rate WHILE a single acquired-company domain in the portfolio degrades to 85% over a week — a divergence that signals either a per-domain authentication- infrastructure problem (DKIM-record misconfiguration, SPF-include cascade-breakage) OR an attacker- bypass campaign concentrated on the weakest portfolio domain. THIS page's KPI 1 single-domain monitoring is the per-domain observability primitive the multi-domain spoke proves must extend to portfolio-wide joint- baseline-deviation comparison. (2) Portfolio-wide KPI 5 per-source_ip volume-baseline cross-domain shared-egress- infrastructure-correlation at the per-source_ip-cohort-vs-portfolio- domain-set-membership boundary — the multi-domain spoke documents the cross-domain source_ip correlation pattern where a previously-unseen source_ip cohort suddenly appears in MULTIPLE portfolio-domain RUA streams simultaneously — either a legitimate new portfolio-wide ESP relationship the operator must onboard OR an attacker-controlled shared-egress infrastructure targeting the portfolio. Single-domain KPI 5 cannot distinguish these cases; portfolio-wide joint-source_ip- correlation directly surfaces the shared-infrastructure signature. THIS page's KPI 5 single-domain monitoring is the per-domain observability primitive the multi-domain spoke proves must extend to portfolio-wide cross- domain source_ip-cohort join. (3) Portfolio-wide KPI 7 forwarder-population-stability cross-domain joint-population- analysis at the per-forwarder-IP- vs-portfolio-domain-set-membership boundary — the multi-domain spoke documents the cross-domain forwarder-population correlation pattern where the portfolio's joint-forwarder-population (the union of forwarder-IPs across all portfolio domains) is more stable than any single-domain forwarder- population (most forwarders appear across the portfolio). Per-domain forwarder-population churn signals either per-domain audience drift OR per-domain attacker-bypass campaign attempting forwarder- impersonation. Portfolio-wide KPI 7 joint-population analysis surfaces per-domain divergence the single- domain view misses. THIS page's KPI 7 single-domain monitoring is the per-domain observability primitive the multi-domain spoke proves must extend to portfolio- wide joint-population analysis. (4) Portfolio-wide KPI 6 unknown-source-escalation-triage- cadence cross-domain joint- escalation-routing at the per- unknown-source-vs-portfolio-domain- operator-ownership boundary — the multi-domain spoke documents the cross-domain operator-ownership escalation-routing problem: when an unknown-source RUA row appears in an acquired-company-domain stream, the org-domain operator may not know the acquired-company's authorised sender inventory. Portfolio-wide KPI 6 joint- escalation-routing requires per- domain operator-ownership routing (acquired-company-domain escalation goes to the acquired-company operator-of-record, not the org-domain operator) AND per-domain authorised-sender- inventory federation. THIS page's KPI 6 single-domain monitoring is the per-domain observability primitive the multi-domain spoke proves must extend to portfolio- wide operator-ownership routing AND per-domain authorised-sender- inventory federation. Read the multi-domain spoke alongside THIS page when the portfolio-management operator is sizing the cross-domain observability infrastructure: this page tells you WHAT THE KPI MEASURES per-domain, the multi-domain spoke tells you HOW THE KPI COMPOSES across the portfolio AND WHY cross-domain joint-correlations surface portfolio-scale signals invisible to single-domain monitoring.
• Email spoofing explained — the SEVEN-CANONICAL-SPOOFING- TECHNIQUE-CATALOGUE-AS-PER-KPI- MONITORING-INPUT-TAXONOMY companion to this DMARC-monitoring eight-KPI steady-state observability synthesis. Where THIS page documents the OPERATOR-SIDE monitoring DISCIPLINE (eight-KPI per-day dashboard with Tier 1 daily / Tier 2 weekly / Tier 3 monthly cadences), the email-spoofing spoke documents the ADVERSARY-SIDE threat-technique catalogue producing the RUA-row signatures the monitoring dashboard must classify. Concretely, the spoke documents FOUR spoofing-technique-vs-monitoring-KPI- mapping dimensions: (i) exact-domain From-header forgery (spoofing Technique #1) surfaces as KPI 6 (unknown-source-IP) with KPI 1 (DMARC-fail rate) spike — the canonical attack vector the eight-KPI dashboard's Tier 1 daily unknown-source-IP review CATCHES first, because the attacker's source IP appears with non-zero envelope-MAIL-FROM count and policy_evaluated.dkim=fail + policy_evaluated.spf=fail on the protected From: domain; (ii) display-name spoofing (spoofing Technique #4) is STRUCTURALLY INVISIBLE to all eight DMARC KPIs because the From: header domain is the attacker's (gmail.com / outlook.com / attacker-controlled-domain.tld) and DMARC alignment evaluates against the attacker's own domain — the operator monitoring dashboard cannot detect this class, requiring gateway-side content scanners, impersonation-detection rules, and end-user-training as the defense-in-depth layer the spoke catalogues (Section 10 defense-in-depth recommendations); (iii) cousin-domain / lookalike registration (spoofing Technique #5) with Punycode-confusable IDN homograph surfaces as a header_from column value in a SIBLING-DOMAIN's RUA aggregate report (NOT the targeted domain's), requiring the PORTFOLIO-WIDE joint-cross-domain-KPI-correlation discipline the multi-domain-strategy spoke documents to ATTRIBUTE the lookalike-attack-campaign through the sibling-domain monitoring stream — the threat-vector demonstrates why single-domain monitoring is STRUCTURALLY insufficient and the portfolio observability dashboard is the only structural detection primitive for this class; and (iv) compromised-account VEC (spoofing Technique #7 — Vendor Email Compromise) surfaces as legitimate-source aligned-pass VOLUME anomaly (KPI 1 DMARC-pass rate stays at 100% because the attacker is using a genuine DKIM- signed message from the legitimate sender's infrastructure) — the ONLY detection primitive is the per-source-IP per-recipient-pattern baseline drift detection THIS monitoring discipline's Tier 2 weekly review surfaces when a legitimate-source row's recipient- list distribution shifts outside the historical baseline. Read the email-spoofing spoke alongside THIS monitoring discipline when an unknown-source-IP row surfaces in Tier 1 daily review (spoofing Technique #1 candidate), when the SOC reports a suspected lookalike- domain campaign (spoofing Technique #5 candidate requiring portfolio- cross-domain correlation), or when finance reports a fraudulent wire from an apparently-legitimate vendor (spoofing Technique #7 VEC candidate requiring recipient- pattern baseline drift verification) — the spoke's seven-technique catalogue is the AUTHORITATIVE threat-vector taxonomy the eight-KPI monitoring dashboard classifies its surfaced anomalies against.
• Phishing protection — the DMARC-MONITORING-AS-PHISHING- CAMPAIGN-EARLY-WARNING-OBSERVATION- INFRASTRUCTURE companion to this DMARC monitoring reference. Where THIS page documents the 6-KPI steady-state monitoring discipline (DMARC-pass rate, SPF-alignment pass rate, DKIM-alignment pass rate, source-IP stability, RUA-row unknown-source count, abuse-mailbox ingest cadence) the operator must sustain post-deployment, the phishing-protection spoke documents the cross-cluster DEFENSE-IN-DEPTH stack the monitoring discipline FEEDS — an operational dimension structurally DOWNSTREAM of every KPI on this page because (i) KPI 6 (RUA-row unknown- source count) is the SINGLE most operationally-valuable early-warning metric for an in-progress phishing campaign against the protected domain — a sustained spike in unknown-source rows from a previously-unseen ASN / country / IP-range is the canonical phishing-campaign-onset signature the phishing-protection spoke's incident-response runbook is engineered to escalate, (ii) the defense-in-depth stack the phishing-protection spoke synthesises (DMARC + DKIM + SPF + BIMI + MTA-STS + secure-email-gateway anti-impersonation + user-awareness training) is observable via the 6 KPIs this page documents — each KPI is the canonical observability surface for one specific defense layer, and a sustained KPI regression is operationally indistinguishable from a phishing campaign degrading that defense layer, (iii) the post-detection incident- response handoff between this monitoring reference and the phishing-protection spoke is the canonical operator- workflow boundary where the monitoring reference's alert-criteria escalate into the phishing-protection spoke's defense-stack-reinforcement playbook. Read the phishing-protection spoke when a sustained KPI regression on this page triggers the incident-response escalation — the phishing-protection spoke is the canonical cross-cluster navigation reference for which defense layer the operator must reinforce first, which secure-email-gateway anti-impersonation rule must be tightened, and which user-awareness training intervention must be launched to close the phishing-campaign attack window.
• SPF PermError vs TempError diagnostic deep dive — the OPERATIONAL-AGGREGATE- REPORT-AUTH-RESULT-COLUMN- INTERPRETATION companion reference. Where THIS page documents the per-KPI monitoring bands the operator watches in the aggregate-report feed (DMARC pass-rate, SPF-aligned-pass-rate, DKIM-aligned-pass-rate, per- reporter forwarder-cohort drift, per-source-IP volume spikes, Tier 1/2/3 KPI runbook), the SPF-PermError-vs-TempError spoke is the authoritative reference for converting the SPF auth- result-enum column of the dmarc_records table (one of none, neutral, pass, fail, softfail, temperror, permerror per RFC 7208 §2.6) into a SPECIFIC operator-response posture. Monitoring-runbook semantics diverge SHARPLY between the two error modes: spf=temperror BURSTS in the aggregate-report feed are the OPERATIONAL SYMPTOM of an UPSTREAM DNS resolver having a SERVFAIL / timeout / network-unreachable episode — usually a transient condition that resolves on receiver retry per RFC 7208 §5 without operator intervention, and the correct monitoring response is INVESTIGATE-RATE- AGAINST-BASELINE (≤1% temperror rate is normal; ≥10% sustained is a publisher-side authoritative- resolver-tier outage warranting DNS-operations escalation). By contrast spf=permerror ANY occurrence is a RED-FLAG IMMEDIATE-ACTION SIGNAL — the publisher's SPF record has structurally-broken syntax, exceeded the 10-DNS-lookup cap (per RFC 7208 §4.6.4), has multiple SPF records on the same domain (per RFC 7208 §4.5), or contains deprecated mechanisms — and the operator- response is FIX-THE-PUBLISHER- SIDE-RECORD-WITHIN-THE-SAME- BUSINESS-DAY because receivers are PERMANENTLY-FAILING the SPF-alignment side of the DMARC evaluation across the entire sender population until the record is fixed. The SPF PermError-vs-TempError spoke documents the seven canonical PermError causes (record-not- found, syntax-error, multiple- records, too-many-lookups, void- lookup-cap, recursive-include, deprecated-mechanism) and the three canonical TempError causes (DNS resolver timeout, SERVFAIL upstream, transient network unreachable), each with a cause-specific Authentication-Results-header forensic-detection workflow (RFC 8601) and per-symptom resolution playbook. Read the spoke alongside this monitoring page when authoring the per-Tier runbook for SPF-alignment-rate regression alerts — the cause-class determines whether the alert is paged at SEV3 (temperror sustained ≥10% for ≥1 hour — escalate to DNS- operations) vs SEV2 (permerror any sustained rate — escalate to email-deliverability-engineer for immediate publisher-side record fix) vs informational (temperror ≤1% — record as baseline noise).
• Why SPF alone is insufficient — the RUA-MONITORING-OBSERVATION-OF-WHY- SPF-ALONE-IS-INSUFFICIENT companion to this steady-state DMARC monitoring discipline reference. Where THIS page documents the eight-KPI steady-state monitoring posture (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to- detection), the SPF-alone-insufficient thesis page is the STRUCTURAL-PROTOCOL-LEVEL companion articulating the first-principles argument WHY SPF cannot carry the email-authentication posture alone — an argument the steady-state RUA monitoring discipline THIS page documents is the EMPIRICAL OBSERVATIONAL-EVIDENCE- PIPELINE for, at FOUR per-KPI steady-state- observability dimensions: (i) SPF- FAIL-DKIM-PASS-DMARC-PASS RUA rows directly QUANTIFY the SPF-alone insufficiency — every aggregate-report row where SPF would have failed but DKIM rescued is a per-message in-production datapoint proving SPF alone would have lost the authentication evidence for that mail; the daily SPF-pass-rate KPI vs DKIM-pass-rate KPI delta IS the per-domain empirical measurement of the SPF-alone- insufficient thesis at production scale; (ii) FORWARDER-POPULATION KPI directly measures the percentage of legitimate mail that traverses forwarding paths where SPF STRUCTURALLY fails — the steady- state forwarder-population baseline (typically 3-15% of legitimate volume depending on the sender's customer profile) is the empirical per-domain magnitude of the forwarder- independence failure mode the SPF-alone- insufficient thesis catalogues, and the DKIM-pass + DKIM-aligned rescue rate on those forwarded rows is the empirical magnitude of the DKIM-rescue-of-SPF-failure phenomenon the thesis predicts; (iii) SPF-PERMERROR- RATE KPI is a direct in-production measurement of the lookup-budget exhaustion failure mode the SPF-alone-insufficient thesis predicts — a sustained SPF-permerror rate exceeding the Tier 1 SEV2 alert threshold (any sustained permerror rate ≥0.5% over a 24-hour rolling window) is the operational footprint of the publisher's SPF record having breached the RFC 7208 §4.6.4 ten-DNS-lookup budget ceiling, and the parallel observation that DKIM-aligned rows continue to authenticate IS the empirical per-domain validation of the SPF-alone- insufficient thesis at the lookup-budget failure mode; (iv) ALIGNMENT-MIXED- MODE rows where both SPF and DKIM authenticate reveal the per-domain rescue-attribution that determines which protocol actually carries the authentication posture at the per-message level — the steady-state alignment- attribution histogram (SPF-only pass rate vs DKIM-only pass rate vs both-pass rate) is the empirical per-domain decomposition of the authentication-posture-load-bearing-protocol question the SPF-alone-insufficient thesis argues from first principles; in production the both-pass rate is typically 40-70% of authenticated volume, DKIM-only rescue is typically 15-35%, and SPF-only rescue is typically 5-20% — the DKIM-rescue magnitude being structurally larger than the SPF-rescue magnitude is the per-domain empirical confirmation of the SPF-alone-insufficient thesis at the per-message authentication- attribution level. Read the SPF-alone- insufficient thesis page alongside this steady-state monitoring reference when authoring the operator's empirical per-domain evidence portfolio for the recommended SPF + DKIM + DMARC publishing posture — the thesis page is the first-principles argument, THIS page is the steady-state RUA monitoring discipline that empirically OBSERVES the thesis's four predicted failure modes in production.
• Email Header Analyzer — single-message diagnosis tool for post-change observation and user-reported missed mail. Built on includes/EmailHeaderParser.php.
• DMARC myths and misconceptions — the PER-RUA-STREAM-STEADY-STATE- OBSERVABILITY-DISCIPLINE-AS-LOAD-BEARING- EVIDENCE-BASE-FOR-EVERY-DMARC-OBSERVABILITY- MYTH-COUNTERED-BY-THIS-CATALOGUE companion to THIS rua-stream monitoring discipline. Where THIS page documents the steady-state rua-stream KPI tracking (per-source-IP DMARC-pass-rate, per-reporter aggregate-XML ingestion, per- alignment-mode disjunction breakdown), the myths-and-misconceptions spoke is the rebuttal catalogue documenting how every DMARC-observability myth collapses against the per-rua-stream evidence THIS page operationalises at FOUR observability-myth- to-rua-evidence dimensions: (i) "No DMARC reports arriving = it's working" myth — rebutted against THIS page's rua-stream zero-reporter detection KPI; the myths spoke documents how zero-rua-ingestion almost always means the rua= mailbox is bouncing, the published rua= address is unreachable, or no DMARC TXT record is published at all — the "silence-means-success" misconception collapses against the per-reporter ingestion-rate KPI THIS page tracks; (ii) "rua reports are real-time" myth — rebutted against the RFC 7489 §7.2 aggregate-window evidence THIS page documents; the myths spoke documents how aggregate reports are generated on a per-receiver 24-hour aggregation cadence (Google batches at 00:00 UTC, Yahoo on a sliding 24h window, Microsoft on per-tenant 24h) so any "real-time DMARC dashboard" promise collapses against the per-receiver aggregation-window evidence THIS page's rua-cadence KPI surfaces; (iii) "ruf forensic reports are widely available" myth — rebutted against the per-receiver ruf-emission evidence THIS page documents; the myths spoke documents how Google, Yahoo, Outlook, and Apple do NOT emit ruf per-message forensic reports for GDPR / privacy reasons, so the per-message attack- forensics expectation collapses against the per-reporter-emission evidence THIS page's ruf arrival-rate KPI exposes; (iv) "DMARC dashboard alone validates posture" myth — rebutted against THIS page's per-source- IP coverage-gap KPI; the myths spoke documents how dashboard-pass-rate aggregates hide per-source-IP coverage gaps (shadow-IT senders, misconfigured third-party ESPs, mailing-list rewrites, forwarder-induced From-domain failures) that only the per-source-IP rua-stream breakdown THIS page surfaces can detect. Read THIS page when OPERATIONALISING the steady-state rua-stream KPIs; read the myths-and-misconceptions spoke when an operator, executive, or auditor cites a DMARC-observability misconception that contradicts the per-source-IP / per- reporter / per-alignment-mode evidence THIS page surfaces.
• MTA-STS policy file syntax — the PER-PUBLISHER-mta-sts.txt- mode-FIELD-AS-LOAD-BEARING-INPUT-TO- PER-PUBLISHER-PER-RECEIVER-TLS-RPT- POLICY-VIOLATION-RATE-KPI companion to this DMARC monitoring KPI- dashboard reference. Where THIS page documents the per-publisher steady-state KPI dashboard reading the per-publisher per-day per-row aggregate-XML stream the per- publisher message-authentication rollout discipline produces, the mta_sts_policy_syntax spoke documents the per-publisher mta-sts.txt POLICY-FILE BYTE-LEVEL PUBLICATION whose mode:-field per-publisher per-receiver TLS-RPT-policy-violation-rate empirical-evidence stream extends the per-publisher KPI dashboard THIS page documents with the transport-security observability layer. FOUR structurally-distinct PER-MTA-STS-mta-sts.txt-FIELD-VS- PER-PUBLISHER-KPI-DASHBOARD-PATTERN dimensions the per-publisher KPI dashboard THIS page documents structurally extends to when the per-publisher operator adds the transport-security observability layer the policy-syntax spoke catalogues: (i) per- publisher per-receiver TLS-RPT per-day JSON aggregate policy.policy-string=mode: testing|enforce field AS LOAD-BEARING-PER-PUBLISHER-MTA-STS- MODE-STATE-OBSERVABILITY-KPI PARALLEL TO PER-PUBLISHER-DMARC- policy_evaluated.disposition= none|quarantine|reject-FIELD- OBSERVABILITY-KPI — the per-publisher KPI dashboard THIS page documents has a structural per-publisher per-receiver TLS-RPT parallel: the per-publisher operator monitors per-receiver per- day per-mta-sts.txt-mode TLS-handshake-success-rate baseline as a load-bearing per-publisher per-receiver transport-security readiness-signal mirroring the per- receiver per-day per-disposition message-authentication readiness- signal the KPI dashboard documents; (ii) per-publisher per- receiver TLS-RPT per-day per- publisher per-mx-pattern summary.total-failure- session-count AS LOAD- BEARING-PER-PUBLISHER-PER-RECEIVER- PER-DAY-PER-MX-PATTERN-MTA-STS- POLICY-VIOLATION-RATE-KPI — every per-publisher per-receiver per-day TLS-RPT JSON-aggregate report carries per-receiver-side per-mx-pattern policy-violation counts (negotiation-failure, certificate-host-mismatch, expired-certificate, sts-policy- invalid, sts-webpki-invalid, etc.) that surface the per-publisher per-receiver per-mta-sts.txt-mx- pattern transport-security defects the per-publisher KPI dashboard consumer must monitor as a per- publisher steady-state regression- detection KPI parallel to the per-publisher per-source-IP DKIM-pass-rate baseline-shift regression-detection KPI; (iii) per-publisher per-receiver TLS-RPT summary.total-success- session-count / total-session- count RATIO AS LOAD- BEARING-PER-PUBLISHER-PER-RECEIVER- PER-DAY-TLS-HANDSHAKE-COMPLETION- RATE-KPI PARALLEL TO PER-PUBLISHER- PER-SOURCE-IP-PER-DAY-policy_ evaluated.disposition=pass-RATIO- KPI — the per-publisher KPI dashboard THIS page documents consumes per-publisher per-source- IP per-day per-disposition-pass- ratio as a load-bearing per- publisher message-authentication steady-state KPI; the per-publisher per-receiver per-day TLS-handshake- completion-ratio the policy-syntax spoke documents is the structural per-publisher transport-security parallel KPI for the per-receiver- side ability to deliver per- publisher mail under the per- publisher mta-sts.txt-mode terminal- state; (iv) per-publisher per-receiver TLS-RPT per-day per- publisher per-mx-pattern failure-details TLS-handshake-failure-class catalogue AS LOAD-BEARING-PER- PUBLISHER-PER-RECEIVER-PER-DAY- PER-MX-PATTERN-DIAGNOSTIC-KPI PARALLEL TO PER-PUBLISHER-PER- SOURCE-IP-PER-RECEIVER-PER-DAY- auth_results.dkim/spf.result- FIELD-DIAGNOSTIC-KPI — the per-publisher KPI dashboard THIS page documents consumes per- publisher per-source-IP per-row auth_results-field verdict diagnostic-evidence as a load-bearing per-publisher message- authentication defect-class diagnostic-KPI; the per-publisher per-receiver per-day per-mx- pattern TLS-RPT failure- details-field catalogue the policy-syntax spoke documents is the structural per-publisher transport-security parallel per- publisher diagnostic-KPI catalogue (sts-policy-fetch-error, sts- policy-invalid, tlsa-invalid, dnssec-invalid, sts-webpki- invalid, validation-failure) the per-publisher KPI dashboard consumer must add to the per- publisher monitoring discipline THIS page documents. Read the mta_sts_policy_syntax spoke ALONGSIDE this DMARC monitoring KPI-dashboard reference when the per-publisher KPI dashboard discipline THIS page documents is extended to the transport- security observability layer — the spoke is the canonical per-publisher mta-sts.txt- POLICY-FILE-BYTE-LEVEL-PUBLICATION REFERENCE the per-publisher per- receiver TLS-RPT-empirical- evidence stream the KPI dashboard extends to depends on at the per- publisher mta-sts.txt-mode-field publication level.
• TLS-RPT DNS record syntax (RFC 8460 §3 byte-by-byte) — where THIS page documents the 8-KPI per-publisher per-domain DMARC monitoring discipline whose load-bearing input is the per-publisher per-receiver per-day rua aggregate-XML evidence-stream the publisher receives at the _dmarc.<d-domain> -published rua mailbox URI, the TLS-RPT-record-syntax spoke documents the byte-by-byte publication discipline of the per-publisher per-domain _smtp._tls.<d-domain> TXT-record whose rua- mailbox-URI publication discipline is the structural-parallel TRANSPORT-LAYER primitive whose per-publisher per-domain JSON- report aggregate-evidence stream composes the cross-OSI-layer observability framework. FOUR structurally-distinct CROSS-LAYER MONITORING-KPI coupling dimensions the TLS-RPT-record-syntax spoke operationally documents: (i) per-publisher per-domain per-MX-host per-day TLS-handshake- success-rate KPI floor as load- bearing transport-layer structural- parallel to per-publisher per- domain per-receiver per-day DMARC- pass-rate KPI floor at the application layer — the TLS-RPT JSON-report's per-day per- receiver per-MX-host successful- session-count divided by total- session-count is the structurally- analogous transport-layer KPI floor to the rua-aggregate-XML row/policy_evaluated/dmarc= pass-rate the per-publisher per-domain application-layer monitoring discipline THIS page documents the standing observability of; (ii) per-publisher per-MX-host TLS-policy-mismatch alert threshold as load-bearing transport-layer structural-parallel to per-source-IP DMARC-fail alert threshold at the application layer — the TLS-RPT per-MX-host policy-string-failure rate spiking immediately after a per-publisher MTA-STS policy-id bump or TLS-RPT TXT-record publication change is the structurally-analogous transport- layer regression-detection primitive to the per-publisher per- source-IP DMARC-fail rate spike the application-layer monitoring discipline THIS page documents operationally surfaces; (iii) per-publisher per-receiver TLS-RPT reporter coverage KPI as load-bearing transport-layer structural-parallel to per- publisher per-receiver DMARC reporter coverage KPI at the application layer — the per-publisher per-receiver TLS-RPT JSON-report sending-receiver population provides the structurally-analogous transport- layer reporter-coverage primitive to the per-publisher per-receiver DMARC rua-aggregate-XML sending- receiver population the application-layer monitoring discipline THIS page documents the coverage of; (iv) per- publisher per-week / per-month / per-quarter cross-OSI-layer observability review cadence as load-bearing operational discipline consuming BOTH per-publisher per- domain DMARC aggregate-XML evidence-stream AND per-publisher per-domain TLS-RPT JSON-report evidence-stream in a single coherent review session — the standing per-publisher per- domain operational review cadence the monitoring discipline THIS page operationalises materially incorporates the per-receiver per- day per-MX-host TLS-handshake- success-rate JSON-report evidence stream the TLS-RPT-record-syntax spoke documents the publication of, as the structurally-parallel transport-layer evidence-stream the cross-OSI-layer review cadence consumes alongside the application- layer aggregate-XML evidence stream. Read the TLS-RPT-record- syntax spoke ALONGSIDE this DMARC monitoring reference whenever the per-publisher per-domain observability discipline scopes a cross-OSI-layer monitoring framework — the TLS-RPT-record- syntax publication-discipline IS the load-bearing transport-layer primitive whose JSON-report aggregate-evidence stream is the structural-parallel observability primitive to the rua-aggregate-XML application-layer evidence-stream the 8-KPI monitoring discipline THIS page documents materially consumes.
• Reverse DNS / PTR records for mail servers — the PER-AGGREGATE-REPORT-ROW-PER- SOURCE-IP-IDENTITY-ATTRIBUTION- PRIMITIVE companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR-record publication discipline whose per-source-IP rDNS-lookup result is the LOAD-BEARING per-source- IP identity-attribution primitive every per-publisher per-domain steady-state RUA-aggregate-XML monitoring run consumes when triaging the per-publisher per-source-IP-row evidence-stream into AUTHORISED- publisher-managed-sender vs UNAUTHORISED-third-party / forwarder / spoofer per-source-IP-identity categories. Where THIS page documents the 8-KPI per-publisher per-domain steady-state RUA-aggregate-XML monitoring framework (per-publisher DMARC-aligned-pass-rate floor, per-publisher per-source-IP-row volume-distribution, per-publisher per-source-IP-row authentication- result-column breakdown, per-publisher per-day RUA-row-count regression triggers, per-publisher per-source-IP new-emergence anomaly band, etc.), the reverse-DNS-PTR spoke is the PER-SOURCE-IP-IDENTITY-ATTRIBUTION PRIMITIVE companion documenting the per-source-IP rDNS-publication discipline whose Forward-Confirmed reverse DNS (FCrDNS) verification outcome feeds the per-publisher per- source-IP-row triage discipline across four per-monitoring-KPI-to-per-source- IP-PTR-record-publication-discipline- coupling dimensions: (i) per- source-IP-row-rDNS-FQDN-target-byte- grammar-as-load-bearing-per-source-IP- identity-attribution-key — per-source-IP rows in per-publisher per-domain RUA-aggregate-XML evidence- streams (the per-publisher per-day per- source-IP volume-count vs per-source- IP authentication-result-column evidence) are TRIAGED against per- publisher AUTHORISED-sender-identity catalogues by per-source-IP rDNS- lookup; per-source-IP PTR-records with consistent per-CIDR-block FQDN-target byte-grammar (mail-N.publisher- owned-domain.tld / mta-N.publisher-owned-domain.tld) make per-source-IP-identity attribution unambiguous, whereas per-source-IP missing-PTR-record states OR per- source-IP rDNS-FQDN-target-byte- grammar-misalignment force per- publisher per-source-IP-identity attribution down a per-source-IP per- CIDR-block-WHOIS evidence-stream fallback path that LOSES per-source- IP-identity attribution determinism; (ii) per-publisher-new-source- IP-emergence-anomaly-band-KPI-as- load-bearing-unauthorised-sender- detection-primitive — the per-publisher per-day new-source-IP emergence anomaly band (the KPI surfacing previously-unseen per- source-IPs in per-publisher per-domain RUA-aggregate streams) is the LOAD- BEARING per-publisher per-day unauthorised-third-party-sender detection primitive THIS page documents; per-source-IP PTR-record rDNS-lookup result on every new- emerged per-source-IP is the LOAD- BEARING per-source-IP-identity attribution key that converts "new per-source-IP" anomaly into either AUTHORISED-publisher-managed-new- sender-deployment (per-source-IP rDNS matches publisher-owned per-CIDR- block FQDN-target byte-grammar) or UNAUTHORISED-third-party / forwarder / spoofer (per-source-IP rDNS missing / misaligned / publisher-foreign); (iii) per-publisher-per- source-IP-row-vs-per-publisher-RUA- forensic-evidence-bridge — per-publisher per-source-IP-row evidence in RUA streams catalogues per-publisher per-source-IP authentication- result patterns; per-source-IP PTR- record rDNS publication discipline provides the per-source-IP-identity attribution PRIMITIVE that enables per-publisher per-source-IP-row cross-correlation with per-publisher operational sender-catalogue databases; missing per-source-IP PTR- record publication discipline collapses the per-publisher per-source-IP-row cross-correlation capability to per- CIDR-block-WHOIS-based fallback attribution; (iv) per- publisher-per-receiver-mailbox- provider-per-day-IP-reputation- aggregate-floor-as-cross-evidence- layer-monitoring-KPI — the per-publisher per-receiver-mailbox- provider per-day IP-reputation- aggregate floor surfaced via Gmail Postmaster Tools / Microsoft SNDS / Yahoo Sender Hub is a CROSS- EVIDENCE-LAYER monitoring KPI that STRUCTURALLY DEPENDS on per-publisher per-sending-IP PTR-record publication discipline correctness; per-publisher per-sending-IP FCrDNS-misalignment OR per-PTR-record publication- discipline defects degrade per- receiver-mailbox-provider per-day IP- reputation-aggregate floor — surfacing in the per-publisher per-receiver- mailbox-provider per-day inbox- placement-rate KPI band as elevated spam-folder-placement that is NOT SURFACED in the per-publisher per- domain RUA-aggregate-XML per-source- IP-row authentication-result-column evidence-stream THIS page's 8-KPI framework natively consumes. Read THIS page when OPERATING the per-publisher per-domain steady-state RUA-aggregate- XML 8-KPI monitoring framework; read the reverse-DNS-PTR spoke when TRIAGING per-publisher per-source-IP-row identity-attribution OR when investigating per-publisher per- receiver-mailbox-provider per-day inbox-placement-rate degradation that IS NOT surfaced in the per-publisher per-domain RUA-aggregate-XML evidence-stream the 8-KPI framework natively consumes.
• Domain Security Checker — live DNS lookups for DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA. Used in the Tier 3 monthly SPF-lookup-count audit.
• DNS Record Generator — generate syntactically-correct DMARC, SPF, DKIM, BIMI, MTA-STS, TLS-RPT, CAA records when onboarding a new sender.
• DKIM alignment with DMARC — the PER-ROW-DKIM-d-TAG-VS-RFC-5322-FROM- DOMAIN-ALIGNMENT-VERDICT-AS-LOAD-BEARING- INPUT-TO-KPI-3-AND-KPI-4-AND-KPI-6 companion to this monitoring-discipline page. Where THIS page documents the eight core KPIs the operator continuously surveils across the per-publisher per- receiver per-day RUA-aggregate-XML evidence-stream, the DKIM-alignment-with- DMARC spoke is the PER-ROW DKIM-ALIGNMENT- VERDICT-DETERMINATION reference documenting the RFC 7489 §3.1 + §6.6.2 DKIM d=-tag-vs-RFC5322-From-domain alignment check whose verdict the policy_evaluated.dkim field in every aggregate-report row encodes. The MONITORING-KPI-VS-DKIM-ALIGNMENT-VERDICT cross-reference establishes FOUR structurally-distinct per-KPI DKIM- alignment-verdict-coupling dimensions: (i) KPI 3 (DKIM-aligned pass rate) is directly computed from the per-row policy_evaluated.dkim=pass count divided by total per-row evaluated volume — the DKIM-alignment verdict is the load-bearing per-row primitive; the DKIM-alignment-with-DMARC spoke documents the relaxed-vs-strict alignment modes (adkim=r vs adkim=s) whose publisher choice determines which d=- org-domain-vs-From-org-domain edge cases produce the per-row pass-vs-fail verdict the KPI 3 numerator counts; (ii) KPI 4 (DKIM-cryptographic-pass-but-DKIM- alignment-fail divergence) is exclusively a DKIM-alignment-verdict-mediated KPI — the per-row auth_results.dkim=pass AND policy_evaluated.dkim=fail co-occurrence surfaces third-party-sender DKIM-re-signing-without-alignment patterns the operator must triage; the DKIM- alignment-with-DMARC spoke documents the third-party-sender DKIM re-signing pattern (SaaS sender re-signing with a non-publisher d=-tag) the KPI 4 divergence signal flags; (iii) KPI 6 (per-source-IP DKIM-aligned-pass attribution) requires the operator to correlate per-row source-IP with per-row DKIM-alignment verdict — the per-source-IP DKIM-aligned-pass row count is the per- legitimate-sender DKIM-coverage primitive the inventory-drift discipline this page documents at §7 consumes; the DKIM- alignment-with-DMARC spoke documents the per-publisher per-sender DKIM-alignment- coverage baseline the per-source-IP attribution discipline references; (iv) the alert-threshold discipline at §3 (DKIM-aligned pass rate drop >5% week- over-week) is grounded in the per-message DKIM-alignment-verdict-stability assumption the DKIM-alignment-with-DMARC spoke establishes; without a stable per-publisher DKIM-alignment baseline the DKIM-alignment-with-DMARC spoke documents, the per-week DKIM-aligned-pass-rate drift signal this page's alert discipline consumes is not interpretable. Read the DKIM-alignment-with-DMARC spoke before instrumenting any of the eight KPIs that consume the per-row DKIM-alignment verdict so the operator's per-KPI baseline assumptions are grounded in the per- publisher per-domain DKIM-alignment- coverage discipline the receiver-side DMARC engine actually evaluates per RFC 7489 §6.6.2.
• DKIM DNS record syntax (RFC 6376 §3.6.2) — the byte-level encoding-layer reference for the public-key TXT record at <selector>._domainkey.<domain>. When monitoring surfaces a per- source-IP DKIM-pass-rate regression — a published-key revocation by empty p=, a key rotation that swapped the base64 payload, a selector typo at publication time, or a TXT-chunking change that broke the concatenated- string assembly receivers reassemble before parsing — this DNS-syntax reference covers the published-key encoding contract that the per- source-IP per-selector monitoring KPIs this page documents implicitly assume holds. Use this reference to triage every published-key syntactic defect class the monitoring layer surfaces as an unexplained per- selector pass-rate cliff.
• SPF for Microsoft 365 — the PER-PUBLISHER-PER-MICROSOFT- 365-TENANT-SPF-PUBLICATION-DISCIPLINE-AS- LOAD-BEARING-PEER-PROTOCOL-LAYER-PER- OPERATOR-PER-TENANT-AUTHENTICATION- PUBLICATION-DISCIPLINE-AS-UPSTREAM- DETERMINANT-OF-MONITORING-KPI-PASS-RATE companion to this DMARC-monitoring KPI- dashboard reference. Where THIS page documents the per-publisher per-domain DMARC-monitoring KPI dashboard at the per- publisher per-domain operational-trend- analysis layer (the per-source-IP per- receiver per-day pass-rate KPI roll-up, the per-publisher per-domain regression- trigger catalogue, the per-publisher per- domain monitoring-baseline-vs-drift evaluation discipline), the SPF-for- Microsoft-365 spoke is the peer per- publisher per-tenant per-Microsoft-365- operator SPF publication discipline whose per-M365-tenant SPF publication discipline (canonical v=spf1 include:spf.protection.outlook.com -all SPF-record template, per-tenant supplemental third-party-ESP include- statement composition, per-tenant cumulative 10-lookup-limit budget arithmetic, per-tenant M365 admin-portal zone-editor commit cadence) is the LOAD- BEARING upstream determinant of the per- publisher per-domain DMARC-monitoring KPI pass-rate baseline that pairs operationally with the per-publisher per-domain DMARC- monitoring KPI dashboard THIS page documents at FOUR per-monitoring- discipline coupling dimensions: (i) per-publisher per-M365-tenant per- operator SPF-publication-discipline- correctness as upstream determinant of DMARC-monitoring-KPI pass-rate baseline — the per- publisher per-domain DMARC-monitoring KPI pass-rate baseline THIS page documents at the per-publisher per-domain operational- trend-analysis layer operationally depends on the per-publisher per-M365-tenant per- operator SPF-publication-discipline correctness the SPF-for-Microsoft-365 spoke documents the per-tenant per- operator publication-rationale of — a per- publisher per-M365-tenant SPF-record carrying syntactically-correct include:spf.protection.outlook.com composition with per-tenant cumulative budget within the 10-lookup-limit emits per-message spf=pass for messages originating from M365 outbound MTAs that propagates to per-publisher per- domain SPF-leg-aligned-pass populations the per-domain DMARC-monitoring KPI dashboard ingests at Stage 5; (ii) per-publisher per-M365-tenant per- operator SPF-publication-discipline- regression as upstream cause of monitoring- KPI pass-rate-cliff alarm — the per-publisher per-domain DMARC-monitoring KPI regression-trigger catalogue THIS page documents at the per- publisher per-domain regression-detection layer (unexplained per-source-IP per-day pass-rate cliffs, per-publisher per-domain pass-rate-vs-baseline drift) operationally attributes a class of monitoring-KPI pass- rate-cliff alarms to per-publisher per- M365-tenant SPF-publication-discipline regressions (per-tenant cumulative include:spf.protection.outlook.com+supplemental-ESP 10-lookup-limit breach, per-tenant supplemental third-party-ESP include- statement drift after M365 hybrid- connector migration, per-tenant per- domain SPF-record zone-editor commit-step misconfiguration) — the SPF-for-Microsoft- 365 spoke documents the per-tenant per- operator publication-discipline that the per-publisher per-domain DMARC-monitoring KPI dashboard THIS page documents the regression-trigger catalogue for; (iii) per-publisher per-M365-tenant per- operator cross-protocol-pillar monitoring- KPI co-ingestion as complete per-tenant per-operator authentication-monitoring- posture — the per-publisher per-domain DMARC-monitoring KPI dashboard THIS page documents at the per-publisher per-domain operational-trend-analysis layer ingests per-source-IP per-receiver per-day per-publisher per-domain SPF-leg-and-DKIM- leg pass-rate evidence — the per-publisher per-M365-tenant SPF publication discipline the SPF-for-Microsoft-365 spoke documents is the upstream determinant of the SPF- leg pass-rate evidence the per-publisher per-domain DMARC-monitoring KPI dashboard ingests, and the per-publisher per-tenant per-operator cross-protocol-pillar monitoring-KPI co-ingestion (SPF-leg pass- rate KPI + DKIM-leg pass-rate KPI) is the load-bearing per-publisher per-tenant per- operator complete authentication-monitoring posture every per-publisher per-tenant per- operator DMARC-deployment programme requires; (iv) per-publisher per- M365-tenant per-operator monitoring- baseline-vs-publication-discipline-drift evaluation coordination — the per-publisher per-domain DMARC- monitoring KPI baseline-vs-drift evaluation discipline THIS page documents at the per- publisher per-domain monitoring-baseline- evaluation layer pairs operationally with the per-publisher per-M365-tenant per- operator SPF-publication-discipline-drift evaluation the SPF-for-Microsoft-365 spoke documents the per-tenant per-operator publication-rationale of (per-tenant supplemental third-party-ESP include- statement evolution as the operational SPF-publication-discipline-drift trigger, per-tenant M365 hybrid-connector migration as the SPF-publication-discipline-drift catalyst), and the per-publisher per- M365-tenant per-operator monitoring- baseline-vs-publication-discipline-drift evaluation coordination is the load- bearing per-publisher per-tenant per- operator monitoring-discipline rhythm every per-publisher per-tenant per-operator DMARC-deployment programme requires for sustainable cross-protocol-pillar monitoring-discipline coordination. Read THIS page when MONITORING per-publisher per-domain DMARC KPI dashboard regression triggers; read the SPF-for-Microsoft-365 spoke when PUBLISHING per-publisher per- M365-tenant per-domain SPF infrastructure via the Microsoft 365 admin portal whose per-tenant per-operator SPF publication discipline is the LOAD-BEARING upstream determinant of the per-publisher per- domain DMARC-monitoring KPI pass-rate baseline THIS page documents at the per- publisher per-tenant per-operator cross- protocol-pillar monitoring-discipline- composition boundary.
• DKIM selectors explained — the PER-SELECTOR-DKIM-PASS-RATE-AS- LOAD-BEARING-UPSTREAM-INPUT-TO-DMARC- MONITORING-KPI companion to this monitoring-discipline reference. Where THIS page documents the per-publisher per-domain monitoring-KPI dashboard (the per-day per-receiver per-source-IP DMARC- disposition pass-rate aggregate signal), the DKIM-selectors spoke documents the per-publisher per-domain per-selector DKIM-signing-key namespace discipline — the canonical <selector>._domainkey.<domain> TXT-record namespace partition that the receiver-side DKIM verifier consults to retrieve the per-selector signing-key, the per-ESP per-publisher selector allocation policy (M365's selector1/selector2, Workspace's google, SendGrid's s1/s2, Mailgun's k1), the per-selector overlap-window rotation cadence that guarantees pre-rotation in-flight messages remain verifiable after rotation, and the per-selector revocation-via-empty-p= primitive that withdraws a leaked key. Pair THIS monitoring-discipline page WITH the DKIM-selectors spoke whenever the per- publisher per-domain DMARC-aligned-pass- rate KPI dashboard surfaces a per-day per- receiver per-source-IP DKIM-failure spike — the selector spoke's per-publisher per- domain per-selector DKIM-pass-rate KPI decomposition is the canonical OPERATOR- DISCOVERY-PATH that routes the per- publisher operator INTO the per-selector per-rotation-window root-cause analysis ladder, identifying whether the per-day per-receiver DKIM-failure spike traces to a pre-rotation per-selector key-material publication-lag, a per-selector revoked- key replay, or a per-selector compromised- key cohort the per-publisher per-domain per-selector DKIM-publication-and-rotation- discipline must remediate to restore the per-publisher per-domain DMARC-aligned- pass-rate KPI baseline THIS page documents.
• SPF mechanism tokens: include vs ip4 vs a vs mx — the PER-MECHANISM-TOKEN-CLASS-PER- DAY-PER-PUBLISHER-PER-DAY-SPF-PASS- RATE-FLOOR-OBSERVABILITY companion to this DMARC-monitoring KPI dashboard reference. Where THIS page documents the per-publisher per-domain per-day per-publisher per-day DMARC-aligned- pass-rate / SPF-aligned-pass-rate / DKIM-aligned-pass-rate-floor KPI dashboard discipline (per-publisher per-domain per-day per-publisher per- day per-source-IP per-receiver per- day per-publisher per-day per-source- IP DMARC-aligned-pass-rate-floor regression-detection-and-alerting cadence, per-publisher per-domain per-day per-publisher per-day per- selector DKIM-pass-rate floor time- series, per-publisher per-domain per- day per-publisher per-day per-source- IP SPF-pass-rate floor time-series), the SPF-mechanism-token-choice spoke is the PER-MECHANISM-TOKEN-CLASS- OBSERVABILITY-DIMENSION-DOWNSTREAM- CONSUMER documenting how the per- publisher per-domain DMARC-monitoring dashboard SURFACES the per-mechanism- token-class empirical-observability primitive at FOUR per-mechanism-token- class per-day per-publisher per-day monitoring dimensions: (i) per- publisher per-domain per-mechanism- token-class SPF-pass-rate-floor per- day per-publisher per-day time-series segmentation — the per- publisher per-domain DMARC-monitoring dashboard MUST segment per-publisher per-domain per-day per-publisher per- day per-source-IP SPF-pass-rate-floor time-series by per-mechanism-token- class (per-source-IP attributed to per-publisher per-domain ip4:-authorised per-mechanism-token vs per-source-IP attributed to per-publisher per- domain include:<esp-spf- macro>-authorised per-mechanism-token vs per-source-IP attributed to per-publisher per- domain a:<host> / mx:<host>- authorised per-mechanism-token) so the per-publisher per-domain operator can independently track per- mechanism-token-class publication- discipline-correctness; (ii) per-publisher per-domain per- mechanism-token-class SPF-permerror- rate-floor per-day per-publisher per- day time-series regression-detection- and-alerting cadence — the per-publisher per-domain DMARC- monitoring dashboard MUST emit per- publisher per-domain per-day per- publisher per-day per-mechanism- token-class SPF-permerror-rate-floor spike alerting when a per-publisher per-domain per-mechanism-token-class (e.g. a per-publisher per-domain include:-cascade exceeds the per-RFC-7208-§4.6.4 ten-DNS- lookup-budget; a per-publisher per- domain a:<host> mechanism's target host stops resolving; a per-publisher per-domain mx:<host> mechanism's MX target changes without per-publisher per-domain SPF record update) emits per-publisher per-domain SPF-permerror verdicts at the per-receiver-side per-message SPF-evaluation boundary; (iii) per-publisher per-domain per- day per-publisher per-day per-source- IP unauthorised-emitter-cohort identification via per-mechanism- token-class attribution gap — the per-publisher per-domain DMARC- monitoring dashboard MUST surface per- publisher per-domain per-day per- publisher per-day per-source-IP cohorts whose per-publisher per-domain per-message SPF-pass-rate-floor is ZERO across ALL per-mechanism-token- classes (per-source-IP NOT in any per- publisher per-domain SPF-record per- mechanism-token authorisation footprint) as the empirical-detection primitive for per-publisher per-domain attacker-spoofing / forgotten-shadow- IT-egress / orphaned-ESP-cohort unauthorised-emitter populations; and (iv) per-publisher per-domain per-mechanism-token-class per-day per- publisher per-day publication- discipline-correctness empirical-KPI- feedback-loop closure cadence — the per-publisher per-domain DMARC- monitoring dashboard MUST close the empirical-KPI-feedback-loop between per-publisher per-domain per- mechanism-token-class authoring-discipline corrections at the per-publisher per-domain SPF- record publication boundary and per- publisher per-domain per-mechanism- token-class SPF-pass-rate-floor recovery at the per-publisher per- domain DMARC-monitoring dashboard observability boundary, gating per- publisher per-domain DMARC-policy- tier ramp advancement on per- publisher per-domain per-mechanism- token-class SPF-pass-rate-floor sustainability across the per- publisher per-domain per-mechanism- token-class portfolio. Pair this DMARC-monitoring dashboard reference with the SPF-mechanism-token spoke when DIAGNOSING per-publisher per- domain per-day per-publisher per-day per-mechanism-token-class SPF-pass- rate-floor or SPF-permerror-rate- floor regressions surfaced in the DMARC-monitoring dashboard — the SPF-mechanism-token spoke is the PER-MECHANISM-TOKEN-CLASS-AUTHORING- DISCIPLINE-CORRECTNESS REFERENCE whose per-publisher per-domain per- mechanism-token-class decision- matrix the per-publisher per-domain operator structurally consumes as the per-mechanism-token-class authoring-discipline remediation playbook the per-publisher per- domain DMARC-monitoring dashboard regression-detection-and-alerting cadence THIS page documents materially drives.
• DKIM-Signature header explained (RFC 6376 §3.5 byte-by-byte tag anatomy: v= a= c= d= s= h= b= bh= i= q= l= t= x= z=) — the per-message sender-side DKIM-Signature header reference companion to this DMARC monitoring discipline. Where THIS page documents the per-publisher per-domain per-source-IP aggregate-report KPI dashboard + the regression-detection-and-alerting cadence whose source-data is the receiver-side auth_results > dkim element catalogue, the DKIM-Signature spoke documents the SENDER-SIDE per-message header anatomy whose d= + s= tag values become the per- row identifiers in every monitored DKIM Auth-Results record. The DMARC-monitoring- VS-DKIM-Signature cross-reference establishes FOUR coupling dimensions: (i) per-row d= (signing-domain) tag values are the canonical attribution key the monitoring dashboard groups DKIM Auth-Results rows by — a sudden distribution shift toward d=<vendor>.com rows is a per-publisher third-party-sender regression signal; the spoke documents the d= tag semantics this attribution depends on; (ii) per-row s= (selector) tag values partition the monitored DKIM-pass / DKIM-fail cohorts by signing-key generation — operators detect selector-rotation regressions through abrupt s=<old-selector> row disappearance and s=<new- selector> row emergence; the spoke documents the per-selector publication discipline whose rotation cadence this monitoring signal tracks; (iii) per-row DKIM-fail Auth-Results rows trace to specific DKIM- Signature: header tag failure modes — bh= mismatch (body modification), b= mismatch (header modification), missing From: in h= (signed-header list omission); the spoke documents the per-tag failure catalogue every monitoring operator consumes to triage a DKIM-fail regression; (iv) per-publisher DKIM-key- rotation events (visible to the monitoring dashboard as s= tag distribution shifts) coordinate with the per-tag t= (signing-timestamp) / x= (expiration-timestamp) anchor; the spoke documents the timestamp-tag semantics whose per-publisher per-domain key-lifetime coordination THIS page's regression- detection cadence materially relies on. Read the DKIM-Signature-explained spoke when interpreting per-row DKIM Auth- Results values in the monitored aggregate- report stream.
• RFC 7489 — DMARC — the foundational DMARC specification. §7.2 defines the aggregate-report schema that powers every KPI on this page.
• RFC 7208 — SPF — Sender Policy Framework, including the §4.6.4 10-DNS-lookup limit referenced in the regression triggers list.
• RFC 6376 — DKIM — DomainKeys Identified Mail signatures.
• RFC 8617 — ARC — Authenticated Received Chain.
• RFC 8601 — Authentication-Results — the header format every receiver uses to stamp its verdict.
• DANE explained — the per-publisher per-MX DANE TLSA- record transport-layer cryptographic-trust- anchor publication-discipline companion to this DMARC-monitoring KPI dashboard reference. Where THIS page documents the per-publisher per-domain DMARC-monitoring KPI dashboard (the per-day per-receiver per-source-IP DMARC-disposition pass-rate panel, the DKIM-aligned-pass / SPF-aligned- pass coverage-rate baseline KPIs, the alignment-strictness-mode-axis pass-rate- cliff alarm, the p=quarantine-to-p=reject ramp-advancement readiness gate), the DANE- explained spoke is the PER-PUBLISHER-PER-MX- RFC-7672-TLSA-RECORD-AS-DNSSEC-ANCHORED- TRANSPORT-LAYER-CRYPTOGRAPHIC-TRUST-ANCHOR- PUBLICATION reference documenting the per- publisher per-MX-host TLSA-record byte- grammar publication, the per-MX-host _25._tcp.<mx-host> TLSA coordinate, the DNSSEC zone-signing prerequisite, and the per-receiver-MX STARTTLS cryptographic-anchor binding gate. Four CROSS-LAYER-PUBLICATION-DISCIPLINE-VS- MONITORING-KPI-INPUT-COUPLING dimensions the DANE-explained spoke documents: (i) per-publisher per-MX-host DANE TLSA-publication-coverage rate as transport- layer KPI input to operator monitoring dashboard — the per-publisher per- MX-host DANE TLSA-publication-coverage rate (how many of the publisher's MX hosts publish a DNSSEC-signed TLSA record) is the transport-layer cryptographic-publication- discipline-baseline KPI input that pairs with the per-publisher per-domain DKIM- aligned-pass coverage-rate baseline KPI this page documents at the operator monitoring console; (ii) per- receiver-MX TLS-RPT tlsa-invalid / certificate-host-mismatch per- day per-failure-reason-code attribution as DANE-publication-discipline-regression KPI input — the per-receiver-MX TLS- RPT per-day per-failure-reason-code attribution this page documents as part of the cross-protocol-pillar monitoring stream sources its DANE-publication-discipline- regression signal directly from the per-MX TLSA-record verification gate the DANE- explained spoke documents; (iii) per- publisher per-domain DNSSEC zone-signing- coverage-rate as upstream DANE-publication- discipline-baseline KPI — DANE TLSA-record verification requires DNSSEC- signed zones, so the per-publisher per- domain DNSSEC zone-signing-coverage-rate is the load-bearing upstream KPI input the operator monitoring dashboard consumes for per-publisher per-domain transport-layer cryptographic-publication-discipline regression detection; (iv) per- publisher per-MX-host TLSA-rotation-overlap- window discipline as per-day KPI panel input — the per-publisher per-MX- host TLSA-rotation overlap-window discipline (publish new TLSA value with overlap, retire old) the DANE-explained spoke documents produces the per-day per-MX TLSA-record version-change KPI signal the operator monitoring console correlates with per- receiver-MX STARTTLS-failure-rate cliffs. Read the DANE-explained spoke alongside this DMARC-monitoring KPI dashboard reference when DESIGNING the per-publisher per-domain cross-protocol-pillar monitoring console that composes per-publisher per-domain DMARC alignment-pass-rate KPI panels with per-publisher per-MX-host DANE TLSA- publication-coverage / per-day transport- layer failure-reason-code attribution panels.
• DNS propagation — the per-publisher per-domain DNS-PROPAGATION-TIMING companion to this per-publisher per-domain DMARC-monitoring KPI dashboard reference. Where THIS page documents the per-publisher per-domain DMARC monitoring console — per-day per- reporter per-source-IP RUA aggregate-report ingestion, per-day per-publisher per-domain alignment-pass-rate KPI panels, per-day per-receiver-MX TLS-RPT aggregate-report STARTTLS-failure-attribution panels, per- day per-publisher per-domain forensic-report ingestion — the DNS-propagation spoke documents the per-resolver per-TTL operational-timing layer whose propagation-delay determinism gates every upstream DNS-record-publication-change signal the monitoring console observes. The composition operates through three per-publisher per-domain DNS-propagation- timing dependencies the monitoring console materially relies on: (i) per-publisher per-domain rua= / ruf= mailbox-address TTL determines when an operator's per-day per-publisher per-domain DMARC-record edit (rotating the RUA mailbox, adding a secondary RUA address, changing the external-receiver authorisation pattern) becomes visible to per-receiver per-day report-emitter aggregate-report-delivery targets, which determines the per-day per-publisher per-domain RUA-report-volume KPI-panel cliff the monitoring console observes; (ii) per-publisher per-domain SPF / DKIM / DMARC-record TTL determines the per-receiver per-resolver propagation- delay between an operator's per-day per-publisher per-domain authentication-record edit and the per-day per-publisher per-domain alignment-pass-rate KPI-panel inflection the monitoring console observes, which determines whether a per-day per- publisher per-domain alignment-pass-rate regression is an authentication-record edit signal vs a real authentication regression; (iii) per-publisher per-MX- host MTA-STS / TLS-RPT-record TTL determines the per-receiver per-resolver propagation-delay between an operator's per-day per-publisher per-MX-host transport-layer-policy edit and the per-day per-publisher per-MX-host TLS- enforcement-rate KPI-panel inflection the monitoring console observes. Read THIS page when DESIGNING the per-publisher per- domain DMARC-monitoring KPI-dashboard operational discipline; read the DNS- propagation spoke when DIAGNOSING per-day per-publisher per-domain monitoring KPI- panel cliffs whose root-cause is per- resolver per-TTL DNS-propagation delay rather than an authentication-record- publication or transport-layer-policy- publication regression.
• DKIM troubleshooting — the PER-SYMPTOM DKIM-RESULT-CLASS DECISION- TREE operator case-resolution companion to THIS page's steady-state monitoring discipline. Where THIS page documents the eight-KPI operational dashboard (authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, source IP distribution, DMARC failure rate, forwarder population, time-to-detection) plus the Tier 1 / Tier 2 / Tier 3 review cadence, the DKIM-troubleshooting spoke documents the per-symptom decision tree the operator descends when the monitoring console surfaces a KPI 3 (DKIM pass rate) regression event. The MONITORING-VS-DKIM- TROUBLESHOOTING cross-reference establishes the per-KPI-3-regression-symptom per-decision-tree-branch operator path: a KPI 3 cliff dominated by dkim=fail body-hash mismatches points the operator at the troubleshooting spoke's body-hash branch (relaxed vs simple canonicalisation, forwarder body modifications, mailing-list footer injection); a KPI 3 cliff dominated by dkim=temperror points the operator at the troubleshooting spoke's DNS-resolution- timeout branch; a KPI 3 cliff dominated by dkim=permerror points the operator at the troubleshooting spoke's missing-selector or malformed-key branch. The monitoring discipline is the per-receiver-interval SIGNAL; the troubleshooting decision tree is the per-symptom case-resolution PATH the operator follows from signal to root cause. Read THIS page when DESIGNING the steady- state KPI-dashboard discipline; read the DKIM-troubleshooting spoke when DIAGNOSING the per-symptom root cause of a KPI 3 cliff the monitoring console has surfaced.
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-AUTHORING-DISCIPLINE-AS-LOAD- BEARING-AUTHENTICATION-PUBLICATION-INPUT- FEEDING-DMARC-MONITORING-KPI-DASHBOARD companion to THIS DMARC monitoring operational-discipline reference. Where THIS page documents the per-publisher per- domain DMARC monitoring 8-KPI dashboard discipline (per-publisher per-domain aggregate-pass-rate-floor KPI, per- publisher per-domain SPF-aligned-pass-rate- floor KPI, per-publisher per-domain DKIM- aligned-pass-rate-floor KPI, per-publisher per-domain DMARC-composite-verdict-fail- rate-floor KPI, per-publisher per-domain per-source-IP per-receiver-organisation per-disposition distribution-cliff detection, per-publisher per-domain RUA- aggregate-report ingestion-cadence baseline-continuity KPI, per-publisher per- domain forwarder-broken-mailing-list per- source-IP failure-rate KPI, per-publisher per-domain per-third-party-SaaS-sender sender-reputation-score KPI), the SPF- mechanisms-explained spoke is the PER- PUBLISHER-PER-DOMAIN-ENVELOPE-MAIL-FROM- LAYER-AUTHENTICATION-PUBLICATION-INPUT companion at FOUR per-SPF-mechanism- authoring-vs-DMARC-monitoring coupling dimensions: (i) per-publisher per- domain SPF mechanism-choice AS load- bearing per-publisher per-domain envelope- MAIL-FROM-layer SPF-aligned-pass-rate- floor publication-input feeding per- publisher per-domain DMARC monitoring KPI 2 SPF-aligned-pass-rate-floor stream — the per-publisher per-domain SPF mechanism-choice the SPF-mechanisms- explained spoke documents (per-publisher per-domain ip4: / ip6: literal-range publication for per-publisher per-static- outbound-IP-pool senders, per-publisher per-domain include: cascade-delegation for per-publisher per-third-party-SaaS-sender mail-stream coverage, per-publisher per- domain a: / mx: FQDN-resolution for per- publisher per-on-prem MTA-RR-bound mail- stream coverage) IS the load-bearing per- publisher per-domain envelope-MAIL-FROM- layer SPF-aligned-pass-rate-floor publication-input feeding per-publisher per-domain DMARC monitoring KPI 2 SPF- aligned-pass-rate-floor evidence stream the DMARC monitoring discipline THIS page documents the per-day per-publisher per- domain rollout-blocker decision-branch threshold consumption of; (ii) per- publisher per-domain SPF include: cascade- depth audit discipline AS load-bearing per-publisher per-domain SPF-permerror-rate- floor publication-discipline feeding per- publisher per-domain DMARC monitoring KPI 3 SPF-permerror-rate-floor anomaly- detection stream — the per- publisher per-domain SPF include: cascade- depth audit discipline the SPF-mechanisms- explained spoke documents (per-publisher per-domain include: cascade-depth monitoring against the RFC 7208 §4.6.4 10-DNS-lookup cap, per-publisher per-domain include: cascade-membership audit cadence, per-publisher per-domain per-third-party- SaaS-sender ESP-include consolidation discipline) IS the load-bearing per- publisher per-domain SPF-permerror-rate- floor publication-discipline feeding per- publisher per-domain DMARC monitoring KPI 3 SPF-permerror-rate-floor anomaly-detection evidence stream the DMARC monitoring discipline THIS page documents the per-day per-publisher per-domain anomaly-detection per-source-IP per-receiver-organisation distribution-cliff identification of; (iii) per-publisher per-domain per-mail-stream subdomain-delegation SPF- mechanism authoring AS per-publisher per- domain per-mail-stream attribution- improvement publication discipline feeding per-publisher per-domain DMARC monitoring per-source-IP per-mail-stream attribution clarity stream — the per- publisher per-domain per-mail-stream subdomain-delegation SPF-mechanism authoring discipline the SPF-mechanisms- explained spoke documents (per-publisher per-mail-stream news.<d-domain> publication for per-publisher per- marketing-mail mail-stream, per-publisher per-mail-stream mail.<d-domain> publication for per-publisher per- transactional-mail mail-stream, per- publisher per-mail-stream support. <d-domain> publication for per-publisher per-support-mail mail- stream) IS the per-publisher per-domain per-mail-stream attribution-improvement publication-discipline feeding per- publisher per-domain DMARC monitoring RUA per-source-IP per-mail-stream attribution evidence stream the DMARC monitoring discipline THIS page documents the per-day per-publisher per-domain per- mail-stream rollout-blocker decision- branch attribution-clarity consumption of; (iv) per-publisher per- domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination AS load-bearing per- publisher per-domain operator-side unified-trust-signal-publication- discipline-floor feeding per-publisher per-domain DMARC monitoring 8-KPI dashboard composite-rollout-blocker- decision stream — the per- publisher per-domain SPF mechanism- authoring discipline the SPF-mechanisms- explained spoke documents IS the per- publisher per-domain envelope-MAIL-FROM- layer publication-discipline leg of the per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination posture the per-publisher per-domain DMARC monitoring 8-KPI dashboard discipline THIS page documents the composite- rollout-blocker-decision consumption of; per-publisher per-domain operators publish ALL FIVE per-publisher per- domain protocol-layer publications coordinated at the per-publisher per- domain unified-trust-signal-floor publication-readiness boundary against the per-publisher per-domain DMARC monitoring 8-KPI dashboard rollout- blocker-decision threshold floor. Read THIS page when DESIGNING the per- publisher per-domain DMARC monitoring 8-KPI dashboard discipline; read the SPF-mechanisms-explained spoke when AUTHORING the per-publisher per-domain envelope-MAIL-FROM-layer SPF-mechanism- choice publication discipline whose per- publisher per-domain SPF-aligned-pass- rate-floor + SPF-permerror-rate-floor + per-mail-stream attribution evidence streams ARE the load-bearing per- publisher per-domain envelope-MAIL-FROM- layer authentication-publication inputs the per-publisher per-domain DMARC monitoring 8-KPI dashboard discipline THIS page documents consumes.
• DKIM cryptography basics — the PER-PUBLISHER-PER-SELECTOR-DKIM- SIGNING-KEY-CRYPTOGRAPHIC-PRIMITIVE-CHOICE- AS-LOAD-BEARING-DKIM-ALIGNED-PASS-RATE-KPI- FLOOR companion to this DMARC monitoring reference. Where THIS page documents the per-publisher per-domain 8-KPI DMARC monitoring dashboard discipline (aligned- pass-rate floor, per-source-IP failure- rate ceiling, per-receiver coverage, forwarder attribution, per-day cohort comparison, RUA volume, RUF emission, p= progression), the DKIM-cryptography-basics spoke is the UPSTREAM CRYPTOGRAPHIC- PRIMITIVE-CHOICE reference whose per- publisher per-selector key-size-and- algorithm selection drives the DKIM-aligned- pass-rate-floor KPI THIS page documents monitoring of. Four per-publisher per- selector cryptographic-choice-vs-monitoring- KPI coupling dimensions: (i) PER-PUBLISHER- PER-SELECTOR-RSA-2048-VS-RSA-1024-VS-DKIM- ALIGNED-PASS-RATE-FLOOR (per-receiver per- domain cryptographic-strength-gating receivers may degrade DKIM-aligned-pass verdicts for legacy RSA-1024 signatures — a per-publisher per-selector cryptographic- primitive misconfiguration silently erodes the DKIM-aligned-pass-rate KPI floor THIS page documents alerting on); (ii) PER- PUBLISHER-PER-SELECTOR-ED25519-VS-RECEIVER- COMPATIBILITY-WINDOW-VS-DKIM-ALIGNED-PASS- RATE-FLOOR (Ed25519 per RFC 8463 produces smaller TXT-records but is not universally supported — per-publisher per-selector Ed25519 adoption requires per-receiver compatibility-window measurement before rollout to prevent DKIM-aligned-pass-rate- floor regression); (iii) PER-PUBLISHER- PER-SELECTOR-KEY-SIZE-VS-EDNS0-TXT-RR- FETCH-SURVIVAL-WINDOW (RSA-3072 or RSA- 4096 p= public-key payloads risk EDNS0 4096-byte UDP truncation forcing per-recursive-resolver TCP fallback; per-recursive-resolver TCP-fallback failures silently drop per-message DKIM- verification driving DKIM-aligned-pass- rate-floor regression the per-publisher per-domain monitoring KPI dashboard surfaces); (iv) PER-PUBLISHER-PER-SELECTOR-KEY-ROTATION- CADENCE-VS-PER-DAY-COHORT-COMPARISON (per- publisher per-selector annual or semi- annual key-rotation cadence imposes per-rotation-boundary per-day cohort discontinuities the per-day-cohort- comparison KPI must accommodate; uniform per-selector cryptographic-primitive choice across rotation boundaries preserves cohort comparability). Read the DKIM- cryptography-basics spoke alongside this DMARC monitoring reference when AUTHORING the per-publisher per-domain DKIM-aligned- pass-rate-floor KPI alerting threshold, when AUDITING per-publisher per-selector cryptographic-primitive choice against per- receiver per-domain cryptographic-strength compliance floors, or when INVESTIGATING per-publisher per-day DKIM-aligned-pass- rate regressions correlating with per- receiver per-recursive-resolver TXT-RR fetch-survival-window degradation.
• SPF DNS record syntax explained
• MTA-STS vs DANE for SMTP — the transport-security choice whose enforcement failures surface in the TLS-RPT JSON failure-report stream this monitoring discipline ingests alongside DMARC aggregate data. This head-to-head reference compares HTTPS-PKI-anchored MTA-STS against DNSSEC-anchored DANE, so when a TLS-RPT report flags starttls-not-supported or certificate-host-mismatch you can read which transport-enforcement model produced it and where the per-receiver TLS-handshake survival regressed.
• Microsoft SNDS + JMRP monitoring — the third leg of the sender-observability triad alongside DMARC aggregate reports and TLS-RPT: per-IP spam-filter verdicts and Junk-click complaints from Microsoft's consumer network (Outlook.com/Hotmail), fetched via the 30-day Automated Data Access key.

16. Start monitoring your DMARC program now

DMARC Analyzer ingests aggregate (rua) reports via includes/DmarcParser.php and surfaces every KPI documented on this page — authenticated volume, alignment pass rate, SPF / DKIM pass rates, distinct sending sources, disposition distribution, and reporter coverage — in the dashboard (index.php). The per-source-IP drill-down (source_ip_detail.php) powers the weekly sender-inventory diff; the per-reporter drill-down (reporter_detail.php) surfaces reporter-coverage drops; the Email Header Analyzer (header_analyzer.php, built on includes/EmailHeaderParser.php) handles single-message post-change diagnosis; the Domain Security Checker (domain_checker.php, built on includes/DnsChecker.php) runs the Tier 3 monthly DNS audit. Forensic (ruf) samples land via upload.php through includes/ForensicReportParser.php for the Pattern E spoofing-flood detection path.

Check my domain configuration Sign up — Free plan