Who is accountable when DMARC enforcement behaves differently after an update?

The accountable party is the domain owner, but the operational response usually spans messaging, identity, and DNS teams. If RFC 9989 changes the applied policy or reporting destination, ownership has to be documented at the organizational domain level, not only at the sending application level.

Why This Matters for Security Teams

DMARC is not just a mail-authentication setting, it is an organisational control that can affect who receives reports, how spoofing is blocked, and which teams are expected to respond when enforcement changes. When a policy update shifts alignment, quarantine behaviour, or reporting destinations, accountability follows the domain owner, even if the trigger came from DNS, messaging, or platform automation. That makes change control and ownership mapping as important as the policy itself.

This is a familiar pattern in identity governance: the technical setting may live in one system, but the risk sits with the organisation that owns the identity surface. NHI Mgmt Group’s research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that control drift across systems often becomes a governance failure later. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that responsibility for configuration and monitoring must be assigned, not implied. In practice, many security teams discover ownership gaps only after a policy change has already altered enforcement in production.

How It Works in Practice

Operationally, the accountable party is usually the domain owner or the business unit that controls the organisational domain, while implementation may be delegated to email security, DNS, identity, or platform teams. The key distinction is between operational execution and accountability for outcomes. If a record update changes DMARC enforcement, the owner must be able to explain the intended policy, the approved change, and who receives aggregate and forensic reports.

A practical control model usually includes four steps:

• Document domain ownership at the organisational level, including who approves DMARC policy and who can modify DNS records.
• Track reporting destinations so changes to rua or ruf addresses are reviewed before they go live.
• Bind change approvals to a named control owner, not just a system administrator or vendor queue.
• Monitor for policy drift after updates, especially when registrar workflows, DNS automation, or outsourced email platforms are involved.

That approach aligns with the broader identity lessons in Ultimate Guide to NHIs, where ownership, rotation, and visibility are treated as governance issues, not just technical maintenance. It also fits the current guidance in DMARC operational practice, where change records and reporting paths should be auditable and attributable. When changes are introduced through automation, the organization still owns the result, even if a third party executed the update. These controls tend to break down when domain administration is split across agencies or subsidiaries because no single team has authority over both DNS and mail policy.

Common Variations and Edge Cases

Tighter DMARC governance often increases coordination overhead, so organisations must balance fast platform changes against traceability and approval discipline. That tradeoff becomes visible when policy updates are made for subdomains, third-party senders, or mergers where legacy mail systems still exist.

There is no universal standard for every edge case yet, but current guidance suggests the following distinctions:

• If a vendor manages DNS on behalf of the business, the vendor may execute the change, but the domain owner remains accountable for the policy outcome.
• If reporting destinations change during an update, ownership of the mailbox or SIEM intake path should be documented alongside the DNS record.
• If multiple business units share a parent domain, the parent organization should define who arbitrates conflicting mail policy requirements.
• If enforcement changes after a platform migration, post-change validation should confirm that the applied policy matches the approved intent.

This is similar to the failure mode seen in real-world identity incidents, such as ASP.NET machine keys RCE attack and Gladinet Hard-Coded Keys RCE Exploitation, where a configuration choice becomes a security event because ownership and review were not clearly enforced. In this case, the edge case is not the DNS record itself, but the organizational ambiguity around who owns the domain outcome.

Related resources from NHI Mgmt Group

• Who is accountable when weak authentication remains in place after a regulatory update?
• Who is accountable when a translated authorization query behaves differently from the policy?
• Who is accountable when a review approves excessive authority?
• Who should be accountable for non-expiring credentials?