Email Infrastructure Ownership Matrix for Agencies

An agency RACI for email infrastructure should make responsibility visible before a migration or incident. RACI means Responsible for doing the work, Accountable for the outcome, Consulted for input, and Informed for notification. Adapt the matrix to each client; never assume the agency controls DNS, provider accounts, or recipient data.

Assign the control plane

Start with the email infrastructure model. Identify who owns domain registration, DNS, mailbox administration, provider accounts, sending applications, credentials, event destinations, templates, audience approval, suppression, and monitoring. For each row, require one accountable role even if several parties are responsible for execution.

A client commonly remains accountable for domains, brand identity, audience authorization, and business approvals. The agency may be responsible for campaign configuration, QA, and first-line monitoring. The provider is consulted for platform behavior and incidents, but a provider’s existence does not transfer the client’s accountability.

Add evidence and escalation

Every row should name the artifact that proves completion: a DNS change ticket, provider account owner, access review, rendered-template approval, suppression event, or incident timeline. Define who is paged for authentication failure, bounce spikes, complaint signals, provider blocks, and compromised credentials. Link the recovery owner to the sender reputation recovery plan.

Review the matrix at onboarding, provider change, team change, and offboarding. During offboarding, transfer domain access, API credentials, suppression data, templates, event subscriptions, and historical evidence. Keep a client-specific exception log where a row differs from the default model.

Avoid ambiguous ownership

Do not write “shared” without naming who approves, who executes, and who is notified. Do not let an agency promise receiver outcomes it cannot control. If the provider’s platform selection limits audit, export, or isolation, record that constraint as a decision rather than hiding it in operations.

Related resources

The Email Infrastructure academy is the natural hub for this matrix.

This workflow should be checked against the cited standards and current provider documentation 1.

Operate the RACI at four gates

Use the matrix at intake, preflight, incident, and exit. At intake record the client domain owner, provider owner, data steward, and escalation contact. At preflight require approval for the exact value, evidence, and rollback. During an incident the accountable owner decides whether to pause; the operator preserves provider responses and timestamps. At exit the client accepts the inventory before access is removed. This assigns control; it does not promise receiver acceptance or placement.

Control	Evidence fields	Stop rule
DNS/domain	owner, ticket, before/after value	Stop without owner/delegate approval
Credentials	scope, custodian, rotation, revoke path	Stop when a secret is shared and ownerless
Suppression	source, reason, timestamp, systems	Stop if an opt-out misses any send path
Monitoring	alert owner, threshold, evidence URL	Pause ramp when telemetry is missing
Incident	severity, decision maker, timeline	Pause when receiver evidence is ambiguous

Reject “shared,” “platform,” or “agency” without a named team, scope, and escalation clock. Cross-check the Google sender guidelines and Microsoft authentication overview. Reopen after a registrar transfer, provider migration, credential incident, contact change, or complaint spike.

References

[object Object]