# MSP email sender inventory

> Build an MSP email sender inventory with evidence, owners, authorization decisions, exceptions, and review records for every client domain.

An MSP email sender inventory is a per-client record of every observed service that sends as a domain, the evidence behind it, the responsible owner, and the decision to authorize, investigate, retire, or escalate it. Build it before changing SPF, DKIM, or DMARC policy. DMARC reports and DNS reveal useful evidence, but neither proves that a client intended to authorize a sender. A named client approver and a sender owner close that gap.

## Quick takeaways

- Keep one sender record for each client domain and sending identity, rather than one undifferentiated list of vendors.
- Treat aggregate reports, SPF records, DNS, and message headers as evidence inputs, not authorization decisions.
- Give the client, sender owner, DNS owner, and MSP distinct responsibilities before changing mail flow.
- Record unknown, seasonal, and retiring sources as exceptions with a next review date.
- Do not move a domain toward enforcement until the sender records support the decision and the change path is approved.

## Operating context and ownership

The inventory is the operating record produced during a broader [client email security assessment](/learning/how-do-msps-run-an-email-security-assessment-for-a-new-client). Unlike the assessment, it remains active after onboarding: a new marketing platform, an acquired domain, or a changed return path can reopen a sender decision for one client without changing the rules for every other client.

Use four named roles. The MSP maintains the record and gathers evidence. The client service owner confirms business purpose and authorization. The sender owner confirms the sending configuration and supplies test mail when needed. The DNS or change owner approves and applies record or policy changes. One person may hold more than one role, but the record should still name each responsibility.

This is a Palisade operating recommendation, not a mailbox-provider requirement. DMARC policy applies to mail using the domain in the visible From field, and the current protocol distinguishes message authentication from policy disposition in [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html). A service observed in a report is therefore a candidate for review, not automatically an approved sender.

## Evidence to collect

Start every record with the client domain, the observed source, the claimed sending purpose, and the dates covered by the evidence. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines DMARC aggregate reports as feedback records that can identify source IP information and authentication or policy results. Use them to find candidates, then compare the result with DNS, client context, and a delivered message.

```yaml
client: northwind.example
domain: example.com
sending_identity: billing.example.com
observed_source: billing-platform
evidence: aggregate report, SPF record, delivered message
client_service_owner: finance-operations
sender_owner: billing-platform-admin
dns_change_owner: client-it
authorization_state: pending-confirmation
exception: seasonal invoicing stream, review after next billing cycle
next_review: 2026-10-01
```

The record is deliberately more than a provider name. One provider can use multiple domains, selectors, envelope identities, or mail streams. Conversely, several source IPs can belong to one approved service. Record the identity that matters to the client decision, then attach the source evidence that supports it.

![Sender inventory lifecycle from observed source through evidence collection, owner confirmation, authorization or exception, and scheduled review.](/images/editorial/msp-email-sender-inventory/msp-email-sender-inventory-lifecycle.svg "1200x680")

*Source: Original Palisade operating framework based on [RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) and [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). It models a review process, not a mailbox-provider or vendor interface. [Open the full-size sender inventory lifecycle](/images/editorial/msp-email-sender-inventory/msp-email-sender-inventory-lifecycle.svg).*

For public configuration, use the [DMARC checker](/tools/dmarc) to record the visible policy and reporting destination. A public check cannot show the full sender population, confirm a vendor account, or authorize a source. Ask the client owner for that context.

## How to run the workflow

### 1. Create the client and domain scope

List the client domains, subdomains that send mail, and domains that must be protected even if they do not send. Assign the client approver and the DNS change owner before collecting sender candidates. This prevents an MSP from treating a discovered record as permission to alter a client domain.

### 2. Add observed sending candidates

Import sources from available aggregate reports, SPF includes, DNS records, sender-platform documentation, and client interviews. Google advises senders to use DMARC reporting to monitor mail sent from, or appearing to be sent from, their domain in its [email sender guidelines](https://support.google.com/mail/answer/81126). Mark every new entry as observed until a responsible owner confirms it.

### 3. Attach evidence and test the claimed path

For a candidate that matters to mail flow, retain the report period, relevant DNS result, and a delivered message from the actual path. Confirm SPF, DKIM, and DMARC results in an `Authentication-Results` field added by a receiver you trust. [RFC 8601](https://www.rfc-editor.org/rfc/rfc8601.html) says the field's assertions are only reliable within the relevant trust boundary. Then note any mismatch between the claimed and observed identity. This gives the sender owner a concrete question to resolve instead of an unsupported request to "fix DMARC."

### 4. Obtain owner confirmation and record the decision

Ask the client service owner whether the source is authorized and whether it should continue sending as the domain. Ask the sender owner what they can change. Set the state to authorized, pending, unauthorized, retired, or exception. Do not use an SPF include alone as authorization: [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html) defines SPF evaluation, but it does not identify the business owner of a service.

### 5. Hand approved changes to the change owner

When evidence and authorization support a change, prepare the smallest scoped task for the DNS or sender owner. State the affected identity, proposed configuration change, test evidence, approval, rollback condition, and review date. A verified inventory can feed a staged [MSP sender-requirements rollout](/learning/how-will-2024-dmarc-rules-change-msps-email-protection-for-smbs), but it does not justify an enforcement change by itself.

### 6. Recheck after the change and schedule review

Verify public DNS, a production message, and later report data. Keep a record open when evidence is missing or traffic is too rare to judge. Review records after a material sender change and on the portfolio cadence your service agreement defines; the cadence is an MSP policy choice, not a DMARC rule.

## Exceptions and escalation

An exception is not a blank field. Record why the source cannot yet be confirmed, who owns the next action, what evidence is missing, and when the record will be revisited. Seasonal billing, low-volume alerts, acquired brands, forwarding paths, and a vendor migration can all require a temporary state.

Escalate when the client cannot identify a business owner, the sender owner cannot explain the observed identity, the proposed configuration change broadens authorization beyond the approved source, or a policy increase would affect an unresolved record. The MSP can coordinate evidence and remediation, but the client retains authorization decisions and the DNS change owner retains control of external changes.

## Reporting and success measures

Report inventory status by client and domain: records awaiting owner confirmation, authorized sources that need an authentication repair, open exceptions, overdue reviews, and completed changes. Avoid a portfolio-wide percentage that hides a high-risk unresolved client domain. A useful QBR discussion is whether each open record has a named owner, evidence, decision, and next date, not merely whether the domain has a published DMARC record.

For recurring portfolio work, Palisade's [DMARC Agent guidance](https://docs.palisade.email/guides/fixing-authentication-issues/) describes report-based authentication issues and recommended next actions. It can help organize recurring evidence into prioritized remediation work. It does not authorize a sender, change external DNS, 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-sender-inventory) when the recurring bottleneck is reviewing sender evidence and assigning remediation across client domains.

## Sources and further reading

- [RFC 9989: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc9989.html)
- [RFC 9990: DMARC Aggregate Reporting](https://www.rfc-editor.org/rfc/rfc9990.html)
- [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.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)
- [Palisade DMARC Agent guidance](https://docs.palisade.email/guides/fixing-authentication-issues/)

## Frequently asked questions

### Is an SPF record a complete sender inventory?

No. SPF can identify authorized mechanisms for an envelope identity, but it does not identify the client service owner, prove that a platform is still in use, or show every mail path that should be evaluated for DMARC.

### Can DMARC aggregate reports authorize a sender?

No. Aggregate reports show receiver-observed traffic and authentication evidence. The client must still confirm business purpose and authorization, and the sender owner must confirm what can be changed.

### Should each client have a separate inventory?

Yes. Each client needs its own domains, owners, approval path, exceptions, and evidence history. A shared platform name does not make an authorization decision portable between clients.

### What should happen when a sender has no owner?

Treat it as an exception or escalation. Preserve the evidence, ask the client to assign a business owner, and avoid expanding SPF, DKIM, or DMARC policy around the source until that decision is documented.

### Does an authorized sender mean the domain is ready for DMARC enforcement?

Not necessarily. Authorization is one decision. Before changing policy, verify the intended authentication and alignment with public DNS, production messages, and later aggregate-report evidence.