“DMARC monitoring” can mean anything from receiving reports to investigating sender failures and implementing approved changes. A service catalogue should let a customer predict what will happen when a new application starts sending, a report reveals an unknown source or a critical notification fails.
Organize around customer jobs
Define onboarding, sender investigation, change planning, approved implementation, ongoing review and offboarding as separate deliverables. For each, state its inputs, owner, output, acceptance evidence and exclusions. Explain what the customer must provide, such as application ownership, DNS access or approval of business impact.
Use protocol evidence to constrain the promise. RFC 9990 aggregate reports provide reported authentication activity, but they do not enumerate every application or guarantee complete recipient coverage. RFC 9989 describes DMARC authentication and alignment; it does not make an authentication pass a guarantee of inbox placement. Avoid service wording that implies either outcome.
Specify the unit of work
A sender-onboarding unit might include one application, agreed domains, supported sending paths and a defined test window. A change unit might cover a reviewed record diff and an authorized rollback. Define how additional applications, complex forwarding, urgent work and unsupported providers enter a separate assessment rather than silently expanding the original scope.
Distinguish continuous collection from staffed analysis. If reports are collected all day but analysts review them only during specified hours, say so. Define incident intake and escalation separately. Describe where the service depends on customer staff, DNS hosts and recipient systems, with evidence of each dependency.
Follow one customer journey
Suppose a customer reports that its invoice application uses an unaligned provider signing identity. A bounded investigation unit can identify the account, confirm the owner and supply evidence-backed diagnosis. If the MSP’s agreed scope excludes application signing changes, its deliverable should name the application owner, the required provider-side check and the acceptance evidence needed after repair. It must not mark implementation complete merely because the diagnosis is correct.
A separately authorized change unit may follow if the provider has demonstrated capability and the customer approves the exact scope. Keep message-path verification distinct from configuration readback. This hypothetical customer journey is not a supplied catalogue, completed investigation, price, contract or verified product capability. It shows how an exclusion should produce an accountable handoff rather than an unexplained stop.
Make exclusions operationally useful
An exclusion should say where the customer goes next. If the service cannot modify application signing settings, identify the application owner and supply a diagnostic handoff. If legal review or privacy approval is required for report processing, record that dependency before collection. Do not treat an exclusion as permission to abandon an active incident without an accountable handover.
Close each unit with an evidence packet and unresolved exceptions. A customer should be able to see what was delivered, what remains and who owns the next action. Review the catalogue after repeated out-of-scope requests or capability changes. Update promises only after confirming staffing, tools and verification capacity can support them.