MSP email security stack

Evidence to collect

For every client domain, retain a sender record, public DNS result, one real delivered message from each material path, named client approver, and named change owner. A sender inventory is where that evidence stays connected to a domain and a business purpose.

For a delivered message, record the result seen by the receiving system rather than relying only on a sender-side dashboard. RFC 8601 defines Authentication-Results and cautions that its assertions depend on a trust boundary. Preserve the source of the header with the record. This is evidence for a decision, not evidence that an MSP may make a change without approval.

client: northwind.example
domain: example.com
layer: authentication
evidence: DNS result, delivered message, aggregate report period
client_approver: client-security-owner
change_owner: dns-administrator
exception_state: pending-sender-confirmation
next_review: 2026-10-01

The managed stack should have an evidence object at every layer. For example, a filter alert without an owner cannot become a client decision, and a DNS change request without a delivered-message retest cannot close an authentication issue.

How to run the workflow

1. Set the client boundary and baseline

List domains, sending subdomains, mailboxes in scope, administrative owners, and the client’s approval path. Distinguish services the MSP operates from services the client or a third party controls. A baseline is not an authorization to standardize every tenant at once.

2. Map the managed email-security stack

For each layer, identify one required evidence record and one primary owner. Use the email security protocols guide to keep protocol mechanisms separate from the operational model. Do not collapse authentication into a generic “email security” checkbox: it needs DNS, message, and report evidence that inbound filtering cannot substitute.

3. Validate actual sending paths

Compare public records with a production message from the claimed path. Google’s current email sender guidelines say bulk senders to personal Gmail accounts need SPF, DKIM, and DMARC, and require alignment for direct mail. Record this as a provider requirement only where the client’s traffic is in scope. Do not represent it as a universal approval to change every client’s policy.

4. Create a controlled change queue

Give each change a client, domain, affected identity, evidence, approver, implementation owner, rollback condition, and retest method. Run changes per tenant and preserve the before-and-after evidence. The MSP coordinates the queue; the client approves business risk and the authorized owner applies the change.

5. Review exceptions before expanding coverage

An unknown sender, an unapproved policy change, or a suspected compromise needs a different route. Preserve evidence first, identify the owner, obtain the required approval, then make a narrow client-specific change and retest that path. This avoids turning a portfolio convenience into a cross-tenant DNS change.

Investigate this with your coding agent

Use this handoff when the service record already identifies a configuration repository or runbook that owns a proposed client-specific change. Supply redacted evidence only, and keep client authorization outside the prompt.

Exceptions and escalation

Route an unknown sender to the client service owner and sender owner. Route an unapproved policy change to the DNS change owner and client approver. Route suspected credential compromise or account takeover through the client’s incident process before routine remediation. In each case, record who received the escalation, the evidence retained, the containment decision, and the next review time.

Use an exception register rather than a generic urgent flag. The register should show the client, domain, affected layer, observed evidence, business impact known so far, assigned owner, decision deadline, approval state, and retest result. It lets a QBR distinguish an unresolved decision from a completed control change.

Reporting and success measures

Report by client first, then roll up only measures that retain their meaning: domains with verified authentication paths, open exceptions with owners, overdue reviews, privileged account controls awaiting verification, and changes with a passed same-path retest. Avoid a single portfolio score that lets one unresolved client disappear behind a broad average.

For a domain-level starting posture, use Email Security Score after the evidence checklist. It can help inspect several visible controls on one client domain before the next review. It does not map every sender, configure controls, validate every client tenant, or prove why an individual message was delivered or blocked.

For recurring client conversations, tie the measures to decisions: approve a planned remediation, retain an exception, assign an owner, or close a retested change. The DMARC QBR reporting guide can help structure the authentication evidence portion of that review. Stronger authentication supports safer sender identification and better deliverability conditions, but it does not guarantee inbox placement or receiver behavior.

Palisade's DMARC Agent guidance describes how incoming DMARC reports can become issue tickets with affected sources and recommended next actions for human review. It does not authorize senders, change external DNS, make client risk decisions, or guarantee delivery. Start with Palisade when the recurring bottleneck is reviewing report evidence and assigning client-specific remediation.