A responsibility matrix is useful only if it resolves a decision someone will actually face. Saying that IT, security and marketing all own email creates ambiguity when a campaign is blocked or a DNS change is urgent. Build the matrix around discrete controls and their evidence, not around a broad declaration that everyone is responsible for everything.
Separate business and technical decisions
Marketing or another service owner confirms why a sender is needed and who it may contact. IT operates DNS, mail routing and technical tests. Security evaluates abuse exposure and the handling of unresolved risk. These are starting points, not universal department assignments: map them to the people with authority in your organisation and include finance, HR or product teams where they own a sending workflow.
For each control, name one accountable role, the responsible operator, consulted parties, the approval boundary and the evidence retained. A single accountable role is an operating convention used here to reduce ambiguity, not a claim that a particular compliance framework mandates this exact matrix. NIST CM-3 addresses controlled changes and their decisions; CM-5 addresses restrictions on making changes. NIST SP 800-53.
Link responsibilities to real artifacts
Use rows such as approve sender purpose, authorize DNS diff, apply approved configuration, verify receiver authentication, review unknown sources and accept a time-limited exception. Each row should point to a service identifier, a finding or change identifier and an evidence artifact. A meeting invitation is not the same as an approval, and a DNS export is not a delivery test.
Record the handoff conditions. The DNS operator needs the exact approved before and after state. The verifier needs the expected identity, route and recipient scope. The risk owner needs the unresolved defect, business impact and expiry. DMARC provides technical domain-validation semantics, but it does not assign these organisational roles or make a passing result equivalent to risk acceptance. RFC 9989.
Test a handoff when approved scope changes
Consider a hypothetical billing change approved for one DKIM selector. During preparation, the operator discovers that the vendor also requests a broader DNS change. The original approval does not cover that new scope. The operator should retain the proposed difference and obtain the required decision instead of interpreting a general approval label as permission for every vendor request.
The verifier can still prepare the expected message identities and test plan while the changed scope is reviewed. When an actual authorized change occurs, link its exact configuration and final-route evidence to the same service and decision. A correct test from the unrelated campaign service cannot close billing’s verification row. No change, approval or cryptographic test was performed for this example.
Handle absence and urgency explicitly
Name deputies and escalation paths before an incident. Define who can approve an emergency change, what evidence must still be preserved and when review occurs afterward. Avoid a standing exception that lets an operator both reinterpret approval and widen scope without a new decision. In smaller teams, compensating review may be needed when role separation is impractical.
Review the matrix when services, teams, vendors or DNS ownership change. Test it with a realistic scenario: an unknown service passes authentication, or a legitimate billing message fails after a change. Ask who decides, who acts and what proves completion. Close the exercise only when the next person can follow the recorded handoff without guessing. That is more valuable than a large matrix that no one can use during an outage.
Check the handoff with one concrete change
Before applying a proposed change, ask the operator to identify the approved scope and the verifier to identify the expected evidence. If either must guess, return the handoff for clarification. A later test result cannot retroactively authorize an unapproved change.