TL;DR: DMARCbis moves DMARC, aggregate reporting and failure reporting onto the IETF Standards Track, formalising full-message policy enforcement, DNS-based public suffix handling and clearer reporting rules, according to Red Sift. The update makes indefinite monitoring mode and partial enforcement increasingly out of step with how email authentication should now be governed.
At a glance
What this is: This is an analysis of RFC 9989 and the related reporting RFCs, showing how DMARC is being tightened into a clearer standard with stronger enforcement and reporting semantics.
Why it matters: It matters because email authentication policy is moving from flexible guidance toward more explicit governance, which affects domain owners, mailbox providers and anyone responsible for impersonation resistance and message trust.
By the numbers:
- In May 2026, the IETF published RFC 9989, the updated DMARC specification.
- RFC 9990 defines aggregate reporting as a standard, including XML schema and delivery requirements.
- RFC 9991 covers failure reporting as near-real-time, per-message reports for DMARC failures.
Context
DMARC has long been a practical control for stopping spoofed mail, but its original Informational RFC left room for inconsistent interpretation across receivers and vendors. That ambiguity matters in email security because enforcement is only as reliable as the policy semantics that receivers actually implement.
The new RFC set tightens that model: DMARCbis formalises policy evaluation, splits reporting into separate standards, and replaces older transition mechanics with clearer testing and alignment rules. For identity and access teams, the governance lesson is that authentication policy only works when its receiver behaviour is predictable and standardised.
Key questions
A: Start by inventorying every authorised sender, including marketing, support, and transactional platforms, then validate SPF and DKIM for each one. Move policy gradually from none to quarantine and finally reject, while reviewing DMARC reports for failures. The goal is not faster enforcement, but accurate enforcement that blocks spoofing without disrupting real business mail.
Q: Why does removing partial DMARC enforcement matter for email security teams?
A: Partial enforcement creates uneven protection because some failing mail is still allowed through, which leaves room for inconsistent receiver behaviour and long-lived exceptions. Full enforcement reduces ambiguity, strengthens sender trust and makes policy outcomes more predictable. For governance teams, it also makes accountability clearer because the control is no longer selectively applied.
Q: How can security teams use DMARC reporting to diagnose authentication failures?
A: Use aggregate reports to spot trends in sending sources, alignment failures and policy changes over time, then use failure reports for message-level troubleshooting when a specific failure needs diagnosis. Treat the two report types as complementary rather than interchangeable, because one supports governance and the other supports rapid investigation.
Q: What changes when public suffix domains are handled through DNS rather than a maintained list?
A: DNS-based handling reduces dependence on a manually updated list and makes public suffix identification part of the live domain structure. That improves consistency across receivers, but it also means teams must recheck how organisational domains and subdomain inheritance are interpreted. The practical issue is scope accuracy, not just parsing logic.
Technical breakdown
How DMARCbis changes policy enforcement
DMARCbis turns a formerly informational specification into a Proposed Standard, which matters because the protocol semantics are now more explicit for implementers. The core idea remains the same: domain owners publish a policy, receivers evaluate alignment against SPF and DKIM, and the receiver decides whether to accept, quarantine, or reject based on that policy. The key shift is that partial enforcement through pct is removed, so policy is no longer meant to be sampled indefinitely. That reduces ambiguity between sender intent and receiver behaviour and pushes organisations toward complete policy treatment rather than gradual opt-in enforcement. See the DMARC, SPF and DKIM Guide.
Practical implication: Treat pct as a temporary migration aid, not a steady-state control.
Why reporting is now split into two standards
The update separates aggregate reporting and failure reporting into distinct RFCs because they serve different governance needs. Aggregate reports are daily summaries that show sending sources and authentication outcomes at scale, while failure reports are near-real-time and per-message, designed to help diagnose specific authentication failures. That separation makes implementation and conformance clearer for receivers and gives domain owners more precise feedback loops. It also formalises the reporting contract itself, which is useful when teams rely on RUA and RUF data to understand spoofing, forwarding issues, and alignment drift.
Practical implication: Use aggregate and failure reports for different operational questions, not as interchangeable telemetry.
How DNS-based public suffix handling affects organisational domain scope
DMARCbis formalises public suffix domain support and moves identification away from a manually maintained public suffix list toward DNS Tree Walk. In practical terms, that means public suffix boundaries are determined from DNS itself rather than from an external list that can lag or differ across receivers. The spec also introduces psd=n to designate subdomains as organisational domains, which affects alignment and policy inheritance. This matters because domain scoping determines which identities are considered within the same administrative trust boundary, and mis-scoping can create false confidence in policy coverage.
Practical implication: Review organisational domain assumptions wherever alignment or policy inheritance depends on subdomain boundaries.
Threat narrative
Attacker objective: The attacker’s objective is to impersonate trusted domains well enough to deliver fraudulent or malicious email at scale.
- Entry occurs when spoofed or unauthorised mail reaches receivers under ambiguous DMARC interpretation or incomplete enforcement.
- Credential_harvested is not the main issue here; the relevant abuse path is authentication failure and sender impersonation rather than stolen credentials.
- Impact is delivered through weakened sender trust, inconsistent policy handling and reduced confidence in domain-based email authentication.
Breaches seen in the wild
- Firebase misconfiguration exposure 2024: Missing Firebase security rules on 916 websites exposed 125 million user records and 19.87 million plaintext passwords; a quarter were fixed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
DMARCbis closes an authentication governance gap, not just a technical one. The article shows that the original DMARC model left enough room for different receiver interpretations that policy enforcement could vary in practice. That is a governance problem as much as a protocol problem because identity assurance depends on consistent receiver behaviour across the ecosystem. Practitioners should treat the update as a signal to standardise policy meaning, not merely to reformat records.
The removal of pct exposes how often transition settings become permanent controls. pct was intended to phase policy in gradually, but the article makes clear that it also enabled long-lived partial enforcement. That pattern matters beyond email because many identity programmes keep temporary monitoring modes in place long after they have served their purpose. The practical conclusion is that a transition mechanism should have a retirement date, or it becomes a permanent exception.
Standards clarity changes the evidentiary bar for email trust. By splitting aggregate and failure reporting into separate standards, the IETF has made authentication telemetry more explicit and more usable. That creates better governance for domain owners, but it also raises expectations: if a team still cannot explain who sends on its behalf or why failures occur, the issue is no longer tooling ambiguity alone. The control gap is now organisational ownership of sender identity and enforcement.
Email authentication now sits closer to identity lifecycle governance than many teams admit. DMARC, SPF and DKIM are not just mail settings, they are controls that define who may speak for a domain and under what conditions. The article’s move toward standardised reporting and stricter enforcement aligns email governance more closely with IAM and identity assurance disciplines. Teams should manage domain identity with the same lifecycle discipline they apply to privileged accounts and service identities.
What this signals
DMARCbis turns email authentication into a more governable identity control. The shift from an Informational RFC to a Proposed Standard matters because it reduces the room for interpretation across receivers. For practitioners, the signal is that email trust is becoming more deterministic, which makes lingering exceptions and soft rollout states harder to justify.
Testing modes should become transient, not habitual. The removal of pct and the introduction of t=y or t=n make the transition story clearer, but they also expose a familiar governance failure: temporary settings that quietly become permanent policy. Teams should expect audit questions about why any domain is still treated as non-enforcing when standards now make the target state clearer.
For practitioners
- Audit long-lived pct usage Identify any DMARC records still relying on pct as more than a short transition mechanism, then plan a move to full policy enforcement.
- Revisit indefinite p=none monitoring Confirm whether monitoring mode is still justified, and if not, establish a path to rejection or quarantine with clear ownership.
- Validate reporting pipelines against the new RFC split Check that your tooling and processes can consume aggregate and failure reporting as separate operational inputs, not one blended feed.
- Review domain scoping and subdomain inheritance Reassess which subdomains should inherit organisational-domain treatment under the updated public suffix handling model.
Key takeaways
- DMARCbis tightens email authentication governance by making policy semantics and reporting more explicit across the ecosystem.
- The article’s key evidence is the move to Proposed Standard status, the formal split of reporting into separate RFCs and the removal of pct as a long-term enforcement model.
- Teams should now treat monitoring mode and partial enforcement as transition states that need expiry, ownership and a plan to reach consistent policy enforcement.
Related NHI Mgmt Group resources: DMARC, SPF and DKIM Guide · Email Security Buyer's Guide · Email Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | DMARC policy and alignment govern which senders are authorised to speak for a domain. |
| Recommendation — Apply PR.AA-05 to enforce explicit sender authorisation and remove ambiguous domain-level exceptions. | ||
| CIS Controls v8 | CIS-5 — Account Management | Email domain trust depends on managing legitimate senders and removing stale identities. |
| Recommendation — Use CIS-5 to inventory and retire unauthorised or stale mail-sending identities. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | DMARC relies on the lifecycle of SPF, DKIM and related authenticators. |
| Recommendation — Apply IA-5 to govern email authenticators with clear rotation, validation and retirement rules. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Spoofed mail and authentication failure are part of the credential abuse path that DMARC helps disrupt. |
| Recommendation — Map email impersonation activity to TA0006 and prioritise domains with weak authentication controls. | ||
Key terms
- DMARC: DMARC is an email authentication policy mechanism that uses DNS-published records to tell receiving mail systems how to handle messages that fail alignment checks. It helps reduce impersonation risk, but it only works when the published policy is accurate, current, and governed as part of the domain's security state.
- Aggregate Report: A DMARC aggregate report is a summary of email authentication results sent by mailbox providers. It shows which sources attempted to send mail, whether authentication passed, and where alignment problems exist. Teams use it to discover legitimate senders, spot unknown infrastructure, and decide when stronger policy is safe.
- Failure Reporting: Failure reporting is near-real-time, per-message feedback for individual DMARC authentication failures. It gives domain owners more immediate evidence about specific problem messages, but it can also expose sensitive content and therefore needs careful handling.
- Public Suffix Domain: A Public Suffix Domain is a DNS boundary that marks where one party's namespace ends and another party's begins. RFC 9989 uses this idea to make delegated boundaries explicit, so receivers can apply policy based on declared ownership rather than inferred structure.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org