Why MSPs should offer email security services

Service decision record

Before offering the service to a client, create a service decision record. This Palisade-authored framework separates commercial choices, operating responsibilities, and protocol evidence. It prevents a broad request for "email security" from becoming an unbounded promise to administer every client system.

The decision record should include:

• Client segments in scope, such as managed domains, selected business units, or defined sender categories.
• Baseline evidence needed before recommendations, including public DNS answers, sender inventory inputs, and message evidence where available.
• Included work, excluded tasks, and any separate incident-response or mailbox-filtering services.
• MSP, client, DNS-host, and sender-owner responsibilities.
• Escalation contacts for business-critical sending paths and specialist issues.
• Reporting cadence, review audience, and the operational artifact delivered.
• Change approval requirements, rollback conditions, and change-window limits.
• Risks requiring specialist escalation, such as an active compromise, unavailable sender access, or business-critical mail failures.
• The next review date for unresolved evidence or accepted risk.

client: example-client
segments_in_scope:
  - primary corporate domain
  - marketing sending domain
baseline_evidence:
  - public DMARC record
  - client sender inventory
  - redacted production message sample
included_work:
  - evidence review
  - sender ownership coordination
  - approved remediation recommendations
excluded_tasks:
  - unapproved DNS changes
  - mailbox incident response
  - third-party licensing administration
ownership:
  msp: maintain evidence register and coordinate retests
  client: confirm senders and approve changes
  dns_host: publish authorized DNS records
  sender_owner: configure sender authentication settings
escalation_path: client technical approver, then sender specialist
reporting_cadence: monthly operational review
change_approval: client approval required before production changes
specialist_risks:
  - suspected account compromise
  - failed business-critical mail flow
next_review_date: 2026-09-15

The record is not proof that mail is configured correctly. It is the operating artifact that shows what evidence is missing, who controls the next action, and when the client will revisit it.

Evidence to collect

Create one working record per client domain. Keep onboarding statements separate from observed evidence. A sender named by the client is not yet a confirmed production path, and a published DNS record is not proof that a particular application signs or sends with the intended domain.

Collect:

• Client name, domain, business owner, technical contact, and escalation contact.
• MSP service owner and the scope the client has authorized.
• DNS host, change authority, approval path, and change-freeze periods.
• Known employee-mail, marketing, CRM, billing, support, and application senders.
• Dated DNS answers, sender-platform status, redacted message headers, support tickets, and client confirmations.
• A next action, responsible party, review date, and rollback condition for proposed changes.
• An exception state for blocked, unknown, retired, or accepted-risk items.

For a domain-level question, the DMARC checker can inspect the public DMARC record. A public record check does not show whether every production sender authenticates, identify every low-volume source, monitor future DNS changes, or determine how a receiving provider will handle a later message.

How to run the workflow

1. Define the service boundary

Owner: MSP service owner. Input: client agreement, contacts, and domain list. Output: an approved scope record.

Document whether the service assesses, recommends, implements approved changes, or reports findings only. State where it stops, such as endpoint protection, incident response, mailbox-filter administration, or third-party licensing. A DNS assessment is not a commitment to configure every sender the client has ever used.

2. Build a sender inventory

Owner: MSP analyst, with client business and technical contacts. Input: onboarding responses, existing tickets, DNS evidence, and available message evidence. Output: a sender inventory with confidence labels.

Include routine and infrequent paths. Invoice systems, password-reset mail, support platforms, campaign tools, and application alerts may use the same visible domain. Assign an owner to every uncertain sender and retain it until the client confirms, remediates, or retires it.

The email threats MSPs should know provides useful context for the client conversation. The service record still needs the client's actual domains, systems, and evidence.

3. Validate at four separate layers

Owner: MSP analyst. Input: DNS results, sender-platform status, redacted delivered-message headers, and later DMARC evidence. Output: a dated evidence package.

Use separate checks for a material authentication decision:

• DNS: Query the authoritative DNS service and at least one public resolver for the published record.
• Vendor: Confirm the sending platform's current authentication or verification status.
• Message: Review a real delivered message from the exact production path. RFC 8601 defines the Authentication-Results header field, which records authentication assessment results.
• DMARC: Review aggregate-report data after reports have had time to accumulate.

4. Turn evidence gaps into assigned work

Owner: MSP service owner. Input: sender inventory and evidence package. Output: a remediation or decision ticket with a named control owner.

Write observable, owner-specific work. For example: "Client marketing owner must confirm whether the observed campaign sender remains active and provide a redacted delivered-message sample." The ticket identifies the party that controls the next action and the same-path retest required to close it.

The client may confirm whether a sender is allowed. A DNS administrator may publish an approved record. A sender provider may expose the authentication settings. The MSP coordinates the evidence and records the result.

5. Review and authorize changes

Owner: client approver, with MSP support. Input: proposed change, evidence, rollback condition, and maintenance timing. Output: an approved, declined, or deferred change record.

Do not apply a production change because it improves a portfolio metric. The client should review the affected business path, expected impact, and rollback trigger. The MSP should retain the before-and-after record values, approval, publication time, and post-change evidence.

A DMARC policy change can affect legitimate mail. Do not move a client toward enforcement until legitimate sending paths have evidence, owners, and a documented response if a business-critical path fails.

6. Report the decision and review the queue

Owner: MSP service owner. Input: current evidence register, tickets, exceptions, and client decisions. Output: a client operational review.

Use a monthly operating review and a periodic client service review. Include domains in scope, sender states, open remediation work by owner, approved changes, exceptions, accepted risks, and the next review date. Keep detailed DNS, header, and report evidence in an appendix or ticket record.

The related guide on running an email security assessment for a new client can help establish the initial baseline. Ongoing service work should show what changed after the assessment and which decisions remain open.

Exceptions and escalation

Escalate when the MSP cannot establish ownership, safe validation, or authority for a material mail path. Common examples include an unknown high-volume source, a business-critical sender with no test window, unclear DNS ownership, sender-platform limits that block the requested configuration, and conflicting evidence between reports and the client inventory.

Use the service decision record to route each exception:

• If the business purpose is unknown, send it to the client business owner.
• If DNS publication is required, send the proposed record and approval requirement to the DNS change owner.
• If sender configuration is required, send the observed authentication gap to the sender-platform owner.
• If a message is failing now, follow the client's incident process. Do not treat the normal service queue as an incident-response channel.
• If the issue needs security, legal, contractual, or provider-specific expertise beyond the agreed service, record the handoff and keep the item blocked until the client decides.

Reporting and success measures

Measure the health of the operating process, not a claim that every message is secure. Useful service measures include:

• In-scope domains with a current client approver and technical contact.
• Senders with dated evidence and an assigned state.
• Unknown sources without an owner or review date.
• Open remediation work past its agreed review date.
• Proposed changes with complete approval, rollback, and post-change evidence.
• Exceptions that remain accepted after their next review date.

Build a recurring evidence queue for each client

Once a client has more than a one-time public DNS question, the recurring gap is usually sender inventory, evidence review, remediation ownership, and policy-readiness decisions across domains. Palisade is AI-first, agent-first DMARC software that analyzes DMARC aggregate-report data, identifies sending sources and authentication or alignment issues, creates prioritized remediation tickets, and proposes the next policy step when the evidence indicates readiness.

Start with Palisade

Palisade does not authorize client senders, make external DNS changes without the required access and approval, repair every sender automatically, or guarantee how receiving mailbox providers will handle mail.