MSP email sender inventory

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.

Operating context and ownership

The inventory is the operating record produced during a broader client email security assessment. 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. 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 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.

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.

For public configuration, use the DMARC checker 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. 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 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 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, 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 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 when the recurring bottleneck is reviewing sender evidence and assigning remediation across client domains.