Accountability should sit with both security and the teams that own the domains or applications sending mail. A shared service can send messages, but it still needs an owner who maintains records, reviews failures, and removes old trust paths. Without clear ownership, email authentication degrades into a technical orphan.
Why This Matters for Security Teams
Email authentication is not just a mail gateway setting. It is a domain trust control that determines whether receivers can verify SPF, DKIM, and DMARC alignment across human users, SaaS platforms, and automated senders. When accountability is unclear, teams leave old senders authorized, fail to remove stale DNS records, and miss spoofing paths that attackers can exploit after a vendor or app change. Guidance from the NIST Cybersecurity Framework 2.0 treats this as an ownership and governance issue, not only a technical one. NHIMG research on the Salesloft OAuth token breach shows how trust in an integrated sender can become a path to downstream exposure when identities and permissions are not actively managed.
In practice, many security teams discover email authentication drift only after a delivery failure, phishing event, or vendor offboarding has already exposed the gap.
How It Works in Practice
Accountability usually needs two layers. Security owns the control framework, policy, and monitoring, while the domain or application owner owns the sender configuration, DNS records, and vendor lifecycle. That split matters because email authentication depends on accurate records and timely changes in systems that security rarely operates day to day. For SaaS senders, the application owner should know which service generates mail, which return-path and DKIM selectors are in use, and when a vendor or platform migration changes the trust boundary. For domain-level governance, security should require registration of all authorized senders and periodic review of SPF, DKIM, and DMARC reports.
Practical ownership often includes:
- A single accountable owner for each sending domain and each SaaS application that transmits mail
- Change control for adding or removing authorized senders, including third-party marketing and transactional platforms
- Regular review of DMARC aggregate reports to detect unauthorized or forgotten senders
- Revocation of old DNS entries and keys when systems are decommissioned or moved
- Escalation paths for failed alignment, especially when business-critical mail is affected
Current best practice is to treat this as a shared control with explicit operational ownership, not a shared assumption. The DeepSeek breach illustrates the broader pattern: once trust material and operational ownership spread across teams, stale credentials and forgotten dependencies become durable attack paths. These controls tend to break down when multiple business units send mail through the same domain but no one owns the full sender inventory because configuration changes outpace review.
Common Variations and Edge Cases
Tighter control over email authentication often increases operational overhead, requiring organisations to balance delivery reliability against governance discipline. That tradeoff is clearest in distributed SaaS environments where marketing, support, product, and finance all send from related domains. In those cases, best practice is evolving toward domain-level ownership with per-application delegate owners, because a single central team cannot safely approve every sender change without business context.
There are a few common edge cases:
- Shared service providers that send on behalf of many brands, where contract ownership and technical ownership may differ
- Third-party platforms that only support partial DMARC alignment, which may require compensating controls or sender redesign
- Merged companies or acquired domains, where old records linger long after the original owner has left
- Shadow IT senders using help desks, CRM tools, or notification services without security registration
When that happens, accountability should be documented in the application inventory, DNS change process, and incident response playbook. NHIMG research on the BeyondTrust API key breach and the Snowflake breach reinforces the same operational lesson: trust paths that are not continuously owned and reviewed tend to persist longer than the teams that created them.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OV-01 | Ownership and oversight are central to domain email authentication governance. |
| NIST CSF 2.0 | PR.DS-01 | Email authentication depends on protecting and maintaining DNS and signing data. |
| OWASP Non-Human Identity Top 10 | NHI-03 | SaaS senders rely on secrets and tokens that need lifecycle ownership. |
Assign explicit control ownership for each sending domain and review sender trust paths regularly.
Related resources from NHI Mgmt Group
- Why do TXT records matter to email authentication programs?
- How should security teams make NHI best practices usable across the business?
- Who is accountable when a compromised SaaS integration is used to move across multiple clouds?
- How do security teams prioritise phishing controls across email, identity, and SaaS?
