# MSP email security stack

> Build an MSP email security stack with accountable layers, evidence records, exception routing, and client review measures.

An MSP email security stack is an operating model for protecting each client’s sending identity, inbound mail, accounts, and recovery path with named owners and evidence. It is not a list of products. Start with a per-client baseline, connect every layer to a decision record, and route exceptions to the person who can authorize or change that tenant. This makes a shared service repeatable without treating client domains as interchangeable.

## Quick takeaways

- Define the stack by security outcome, evidence record, owner, and exception path before selecting or standardizing tools.
- Keep authentication, inbound defense, account protection, resilience, and service operations as separate layers.
- Use a client-specific sender inventory and a delivered-message check before altering DNS or DMARC policy.
- Keep authorization with the client and configuration control with the DNS or sender owner.
- Treat review cadence and service thresholds as MSP operating recommendations, not mailbox-provider requirements.

## Operating context and ownership

The multi-client difference is accountability. A single business can decide informally which platform sends mail. An MSP needs a record that survives technician changes, new senders, and a client acquisition. Begin with a [client email security assessment](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client), then turn its findings into the recurring service model described here.

Use five layers. Authentication covers SPF, DKIM, DMARC, domain alignment, and the identities used by outbound services. Inbound defense covers the client’s chosen mail filtering and user-reporting process. Account protection covers privileged access, MFA, recovery contacts, and change approval. Resilience covers backup, continuity, and an incident contact path. Service operations connects all of these to inventory, evidence, exceptions, and client reporting.

The protocol layers have real boundaries. [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489.html) defines DMARC’s policy and reporting framework, while [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html) defines MTA-STS policy discovery for SMTP transport. Neither standard assigns the client business owner, approves a DNS change, or supplies an MSP service cadence. The layer-to-owner model below is a Palisade operating recommendation.

## 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](/learning/msp-email-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](https://www.rfc-editor.org/rfc/rfc8601.html) 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.

```yaml
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.

![Matrix showing five MSP email-security layers with their evidence records, MSP responsibilities, and client or provider responsibilities.](/images/editorial/msp-email-security-stack/msp-email-security-stack-matrix.svg "1200x820")

*Source: Original Palisade operating framework informed by [RFC 7489](https://www.rfc-editor.org/rfc/rfc7489.html), [RFC 8461](https://www.rfc-editor.org/rfc/rfc8461.html), and [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html). It maps accountability and does not prove a control is effective for a particular tenant. [Open the full-size stack matrix](/images/editorial/msp-email-security-stack/msp-email-security-stack-matrix.svg).*

## 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](/learning/email-security-protocols) 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](https://support.google.com/mail/answer/81126) 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.

```agent
Problem: A client-specific email-security exception has evidence but no verified configuration change proposal.
Evidence: Redacted domain, sending identity, DNS result, Authentication-Results outcome, approved change ticket, and expected owner.
Repository scope: The client-scoped infrastructure-as-code directory or email-security runbook only.
Constraints: Inspect before editing. Do not apply changes until I approve the proposed diff. Do not access credentials, production systems, other client directories, or make DNS, sender, policy, or tenant changes.
Requested output: Identify the relevant files, explain the smallest proposed change, list rollback steps and unknowns, and provide a minimal diff for review.
Verification: Run the repository's existing validation, then require public DNS and a same-path delivered-message retest after human approval.
Stop if: Credentials, unredacted customer data, production mutation, missing client approval, or ambiguous ownership is required.
```

## 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.

![Exception-routing flow from evidence collection through approval, one-tenant change, retest, and outcome record.](/images/editorial/msp-email-security-stack/msp-email-security-stack-exception-flow.svg "1200x620")

*Source: Original Palisade operating framework informed by [CISA phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf). It is an approval-gated routing model and never authorizes a production DNS or tenant change. [Open the full-size exception-routing flow](/images/editorial/msp-email-security-stack/msp-email-security-stack-exception-flow.svg).*

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](/tools/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](/learning/dmarc-qbr-reporting) 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](https://docs.palisade.email/guides/fixing-authentication-issues/) 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](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=msp_operations&utm_content=msp-email-security-stack) when the recurring bottleneck is reviewing report evidence and assigning client-specific remediation.

## Sources and further reading

- [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc7489.html)
- [RFC 8461: SMTP MTA Strict Transport Security](https://www.rfc-editor.org/rfc/rfc8461.html)
- [RFC 8601: Authentication-Results header field](https://www.rfc-editor.org/rfc/rfc8601.html)
- [Google email sender guidelines](https://support.google.com/mail/answer/81126)
- [CISA phishing guidance](https://www.cisa.gov/sites/default/files/2025-03/Phishing%20Guidance%20-%20Stopping%20the%20Attack%20Cycle%20at%20Phase%20One%20508.pdf)

## Frequently asked questions

### Is an MSP email security stack a product list?

No. A usable stack names the security layers, evidence records, owners, approval path, and exception handling for each client. Products may support those layers, but a product list alone does not tell a technician who may approve a change or how to verify its result.

### Should every client use the same email-security settings?

Not necessarily. Standardize the operating record and review process first. Client domains, senders, mailboxes, risk tolerance, contracts, and administrative ownership can differ, so a configuration change must remain scoped to the approved tenant and supported by its evidence.

### Can a published DMARC record prove that all senders are secure?

No. A published record shows a policy and reporting destination, not every active sender, its business authorization, or its delivered-message outcome. Pair DNS with sender inventory, client confirmation, and production-message evidence before changing policy.

### Who should approve a DNS or policy change?

Only the client’s authorized approver and the designated change owner should approve and apply it under the client’s process. The MSP can prepare evidence, propose a scoped change, and coordinate retesting, but should not treat portfolio management as delegated authority.

### What should an MSP show in a QBR?

Show client-specific decisions: verified sending paths, open exceptions, overdue ownership confirmations, planned changes, and retest outcomes. Explain what evidence supports each item and what decision the client needs to make. Avoid presenting a portfolio-wide score as proof that every client is protected.