Who is accountable for email authentication controls when an organisation uses its own provider for transactional messages?

Why This Matters for Security Teams

transactional email often looks like a vendor problem, but the security obligation stays with the organisation that chooses the provider and authorises the use case. That matters because email authentication controls such as SPF, DKIM, and DMARC are only effective when the domain owner, platform owner, and application owner coordinate on configuration, key handling, and monitoring. NIST’s Security and Privacy Controls treat this as an accountability issue, not a procurement issue.

When teams hand off transactional messaging to a third-party service, they often assume the provider “covers” authentication. In practice, the provider can send the mail, but the organisation still owns domain reputation, approved sender identity, and the security of any secrets used to access the service. That is why the Ultimate Guide to NHIs — Standards is relevant: the service account or API credential used for mail delivery is a non-human identity that must be governed like any other privileged workload identity.

In practice, many security teams only discover the gap after a spoofing attempt, a leaked mail API key, or a domain alignment failure has already affected delivery and trust.

How It Works in Practice

The cleanest way to assign accountability is to separate ownership into three layers: domain control, provider configuration, and operational monitoring. The organisation owns the sending domain and decides which subdomains are authorised for transactional mail. The provider owns the service infrastructure, but not the organisation’s policy decisions or message reputation. The application team owns the integration path, including credentials, templates, bounce handling, and sender alignment.

Start with authentication controls. SPF should reflect the actual sending service. DKIM should be configured with keys that the organisation can rotate and revoke. DMARC should define the enforcement posture, alignment expectations, and reporting destinations. If the provider offers managed key rotation or hosted signing, that can reduce overhead, but it does not remove accountability for verifying that the resulting messages authenticate correctly. This is where a control like The State of Secrets in AppSec becomes operationally relevant: leaked or overexposed secrets remain a common failure mode, and the average time to remediate a leaked secret is 27 days.

For implementation, the organisation should treat mail-sending credentials as secrets with narrow scope and short lifetime, not as durable platform settings. Store them in a central secrets manager, restrict who can read them, and alert on unusual send volume or domain mismatch. Review provider logs for authentication failures, suppression events, and unexpected sender changes. If a provider supports webhooks or event streams, route those into security monitoring so delivery problems can be distinguished from abuse.

• Define who owns SPF, DKIM, DMARC, and DNS changes.
• Use per-service credentials with least privilege and rotation.
• Monitor delivery, alignment, bounce rates, and abuse signals.
• Require change approval for sender identity, keys, and routing.

These controls tend to break down when multiple product teams send from the same domain without a shared policy, because sender drift and inconsistent DNS management quickly undermine authentication.

Common Variations and Edge Cases

Tighter sender control often increases operational overhead, requiring organisations to balance stronger authentication against release speed and marketing or product autonomy. That tradeoff becomes sharper when the same provider handles both transactional and promotional mail, because reputation problems in one stream can spill into the other.

One common edge case is a provider that supplies a default shared domain or managed sending subdomain. That can simplify setup, but it may limit visibility into authentication posture and make incident response slower. Another is delegated administration, where a marketing team manages templates while security owns domain policy. Current guidance suggests this can work only if DNS control, secret custody, and monitoring thresholds are clearly assigned in writing.

Another frequent misunderstanding is assuming that a compliant provider makes the organisation compliant. It does not. If the organisation selects the provider, approves the use case, and controls the domain, it remains responsible for secure configuration and for reviewing delivery outcomes. This is especially important after incidents like the DeepSeek breach and JetBrains GitHub plugin token exposure, which show how quickly exposed credentials can expand into wider trust failures. Organisations that split accountability too loosely usually find the gap only after authentication failures surface in production mail flows.

Related resources from NHI Mgmt Group

• Who should own secure email trust controls in an organisation?
• Who should be accountable when BEC-driven exfiltration uses identity and email controls together?
• Who is accountable when an organisation modernises authentication but leaves transaction risk controls incomplete?
• Why do misdirected email controls need better contextual understanding of sender and recipient relationships?