DMARC Monitoring in 2026: What RFC 9989 Changes for Multi-Domain Operators
Published August 2026 by Solarc Labs
RFC 9989 is now the current DMARC standard
RFC 9989 was published in May 2026 as a Standards Track specification and obsoletes RFC 7489 and RFC 9091. It keeps the core DMARC model: domain owners publish policy in DNS, receivers evaluate SPF or DKIM authentication with identifier alignment, and domain owners can request reports about use of their domain. For operators, the important consequence is that DMARC should be implemented against the current protocol rather than treated as a frozen checklist copied from an older guide.
A DNS check is a snapshot, not a monitoring system
A domain can be correctly configured during an onboarding audit and drift later because someone changes DNS, adds a sender, removes a record, migrates a provider or changes a policy. The operational job is therefore transition detection: what materially changed, when did it change, and does the new state need attention? That is a different product from a one-time score. A useful monitor preserves the last known state, compares new observations with it and only interrupts an operator when the verifiable state changes meaningfully.
Alignment is the boundary that matters
DMARC passes when a message has a passing SPF or DKIM result whose authenticated domain aligns with the visible Author Domain under the applicable alignment mode. Monitoring should therefore report the facts it can verify instead of reducing the protocol to whether three DNS records exist. DKIM also needs a concrete selector to query. A monitoring service should not guess selectors and then present the result as complete coverage. If a selector is not supplied or discovered through an explicitly supported evidence path, the honest state is that the DKIM check is not established for that selector.
Aggregate reports are evidence, not a license to auto-mutate DNS
DMARC reporting helps domain owners understand observed authentication and alignment behavior. Report ingestion can support triage by normalizing records, highlighting changes and showing which sources are associated with failures. It does not mean the monitor should automatically edit DNS or jump a domain to a stricter policy without an operator decision. For MSPs and email-operations teams, the safer workflow is inspect, compare, alert, review and then make the DNS change through the system that actually owns that authority.
Multi-domain operations need bounded change detection
Managing one domain manually is possible. Managing many customer or business domains makes repeated point-in-time checking expensive and inconsistent. A bounded monitor can register the exact domains and selectors an operator owns, retain prior observations, parse supported aggregate reports and produce transition-only alerts. The product boundary remains important: DMARC monitoring can surface authentication-control state, but it cannot guarantee inbox placement, sender reputation or protection from every form of impersonation.
Primary sources
Sources used for this article
Continue the job