Who is accountable when spoofed email gets through DMARC controls?

Why This Matters for Security Teams

When spoofed email gets past DMARC, the issue is rarely just a technical failure. It usually points to a governance gap across domain ownership, mail flow, and third-party sender approval. DMARC can reduce impersonation risk, but it does not replace sender lifecycle controls, vendor oversight, or incident response. NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control ownership problem, especially where authentication, configuration, and accountability overlap. Security teams often assume a passing DMARC policy means the environment is safe, when the real question is whether every legitimate sender is still governed.

That matters because attackers do not need to break DMARC universally. They only need one weakly managed domain, one overlooked subdomain, or one approved vendor with loose mail practices to create trust abuse at scale. The business impact lands on fraud, phishing, executive impersonation, and customer trust, not just email hygiene. In practice, many security teams encounter spoofed email only after a recipient reports a convincing message that should never have been deliverable, rather than through intentional monitoring of sender governance.

How It Works in Practice

Accountability should follow the control points that make DMARC effective, not a single team label. Domain owners are responsible for policy decisions, messaging or email operations manage authentication and alignment, and procurement or vendor management should ensure third-party senders are approved before they are allowed to send on behalf of the organization. Security should define oversight, exception handling, and escalation paths, especially where external marketing, payroll, ticketing, or SaaS platforms send mail under corporate domains.

The practical workflow usually includes:

• Maintaining an authoritative inventory of all sending systems, subdomains, and approved vendors.
• Requiring SPF, DKIM, and DMARC alignment checks before a sender is onboarded.
• Reviewing DMARC reports to find unauthorized or misconfigured sources.
• Documenting who can approve sender changes and who can retire them.
• Escalating spoofing incidents into phishing response, fraud review, and domain policy review.

Where teams mature this control, they treat DMARC as part of a broader governance chain rather than a standalone filter. That chain includes DNS administration, mail gateway policy, certificate and key management, and periodic sender review. A useful reference point is the NIST SP 800-53 Rev 5 Security and Privacy Controls, which maps well to ownership, configuration management, and system integrity expectations. These controls tend to break down when multiple business units can onboard senders without a single approval process because policy drift makes DMARC outcomes inconsistent.

Common Variations and Edge Cases

Tighter sender governance often increases operational overhead, requiring organisations to balance fraud reduction against marketing speed, procurement flexibility, and help desk load. That tradeoff becomes most visible when subsidiaries, mergers, or outsourced service desks use separate mail systems. In those cases, DMARC may be technically correct while accountability remains fragmented across legal entities or regional IT teams.

There is also no universal standard for how much responsibility belongs to a vendor versus the customer when a third-party platform sends authenticated mail. Current guidance suggests the customer still owns the domain trust decision, but the vendor may own the implementation details that determine whether authentication actually works. Best practice is evolving for large ecosystem environments, especially where shared branding, delegated sending, and subdomain use are common.

For regulated sectors, a spoofed message can trigger broader governance questions than email security alone. If a fraudulent message affects payments, user identity, or customer onboarding, the accountable party may also need to demonstrate control evidence for audit, incident response, and supplier oversight. The core rule is simple: if an organisation allows a sender to use its domain, it also inherits the obligation to govern that sender tightly.

Related resources from NHI Mgmt Group

• Who is accountable when fraud gets through digital tax controls?
• Who is accountable when a small business breach spreads through weak access controls?
• Who is accountable when P2P fraud slips through fragmented APAC controls?
• Who is accountable when ransomware spreads through weak IAM controls?