How to document approved senders for MSP clients
An approved sender register should give an MSP one reliable record of every service allowed to send mail using a client's domain. Each entry needs the service owner, business purpose, sending domain, visible From domain, envelope sender, DKIM selector, authentication status, approval evidence, change history, and review date. A spreadsheet can work for one small client, but the process matters more than the storage format.
I treat the register as the control point for DMARC service delivery. It tells the service desk which sources are expected, gives engineers a basis for SPF and DKIM changes, and gives the client an approval trail before enforcement. For a multi-client practice, I connect that record to a consistent DMARC for MSPs workflow so the same evidence, ownership rules, and review cadence apply across every tenant.
Start with an approved sender register
I treat one row as one sending path, not one vendor. A client can use the same provider for staff mail, transactional notices, marketing campaigns, or automated alerts, with different return paths or DKIM selectors for each stream. Separate entries make changes easier to assess and prevent a broad vendor approval from hiding an unknown configuration.
|
|
|
|---|---|---|
Client | Tenant and domain | Prevents cross-client changes |
Source | Service and stream | Defines the approved use |
Identity | From and return path | Supports DMARC matching |
Authentication | SPF and DKIM state | Shows the passing path |
Owner | Client contact | Provides change authority |
Lifecycle | Status and review | Finds stale approvals |
Core fields for an MSP-approved sender register
Keep the register inside the client's existing documentation system when practical, but give it a defined owner and access controls. Client business owners should be able to confirm the purpose and continued need for a sender. MSP engineers should maintain the technical evidence. Restrict DNS credentials, secret keys, vendor passwords, and API tokens to the credential system rather than copying them into the register.
Five parts of an approved sender record: client, purpose, identity, authentication, and approval
Build one complete record per sending path
Start with the source inventory, then turn each discovered source into a controlled record. The inventory can include vendor invoices, identity platform applications, website forms, CRM workflows, help desk notifications, scanners, line-of-business software, and DMARC aggregate data. A documented sender is not approved until the named client owner confirms its business use.
- Business identity. Record the client, domain, service name, use case, department, business owner, and technical contact.
- Mail identities. Capture the visible From domain, envelope-from domain, HELO domain when known, DKIM signing domain, and selector.
- Traffic evidence. Record observed source IPs, provider identifiers, approximate volume, first-seen date, last-seen date, and sample message results.
- Control state. Track approval status, SPF scope, DKIM status, DMARC result, remediation ticket, approver, approval date, and next review.
I use controlled status values so technicians do not invent labels. A practical set is Discovered, Pending client confirmation, Approved and passing, Approved with remediation, Rejected, and Retired. Add a reason whenever a status changes. This turns the register into an audit trail instead of a snapshot.
Approved sender record templateYAML
client: Northwind domain: example.com service: Billing notifications business_owner: Finance operations visible_from: example.com return_path: bounce.example.com dkim_domain: example.com dkim_selector: billing1 spf_status: scoped dkim_status: passing dmarc_status: passing approval_status: approved approved_by: Client finance director approved_on: 2026-07-24 next_review: 2026-10-24 change_ticket: CHG-1042
Do not approve a vendor name alone
A vendor can send through several accounts, domains, or delegated services. Approval should identify the exact client account and sending path. IP addresses alone are weak identifiers because shared pools and infrastructure change.
Verify each sender with DMARC evidence
Compare the proposed sender with DMARC aggregate reports before granting technical approval. Confirm that the source appears under the expected client domain, then inspect SPF and DKIM results and the domain used for each check. A sender needs at least one passing, DMARC-aligned authentication path. A raw SPF pass for a provider-owned return path does not satisfy DMARC for the client's visible From domain.
Issues page showing verified and unverified source sections for reviewing sending sources
Suped's verified and unverified source view supports this review across client organizations. An MSP can compare observed sources, separate expected traffic from unknown traffic, and open an issue when a legitimate source fails authentication. The platform's DMARC monitoring keeps the evidence tied to real mail rather than a vendor questionnaire alone.
Send a controlled message through each application when possible. Preserve the header result or ticket reference, but avoid storing message content that contains personal or confidential data. Compare the test with aggregate traffic because a single successful test does not prove that every stream or region uses the same configuration.
- Confirm purpose. Get written confirmation from the client's accountable business owner.
- Match traffic. Link the request to observed DMARC sources, domains, selectors, and volume.
- Test authentication. Verify one aligned SPF or DKIM path and record the result.
- Approve narrowly. Approve only the documented account, domain, stream, and use case.
- Schedule review. Set an owner, next review date, and retirement trigger.
Separate business approval from technical approval
Two approvals reduce ambiguity. The client owns the decision that a service is legitimate and required. The MSP owns the technical decision that its sending path is understood, limited, and ready for the client's DMARC policy. One person can perform both roles for a small client, but the record should still show both decisions.
Client approval
The business owner confirms why the service sends mail and who can authorize future changes.
- Purpose. The use case is current and necessary.
- Owner. A named contact accepts accountability.
- Scope. The approved domain and stream are explicit.
- Data. Any privacy constraints are recorded.
MSP technical approval
The engineer confirms the source identity and records a safe authentication path.
- Evidence. Observed traffic matches the request.
- SPF. Authorization stays within lookup limits.
- DKIM. Signing and selector ownership are verified.
- DMARC. At least one aligned path passes.
Put the approval into the service ticket or change record, then link that ticket ID in the register. Avoid approvals buried in chat because they are hard to retrieve during an incident or staff handover. Define this split during onboarding and include it in the client's responsibility matrix. A clear responsibility model prevents technical staff from approving business use by assumption.
Control DNS changes and enforcement readiness
I do not translate every approval into an SPF include. I prefer DKIM for third-party services when the provider supports customer-domain signing. SPF still needs a narrow record of authorized infrastructure, but adding broad provider ranges increases exposure and can push the domain over the ten-lookup evaluation limit. Record why each mechanism exists and which sender depends on it.
Example DMARC monitoring recordDNS
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none;" "rua=mailto:reports@example.com; fo=1"
Keep the DMARC policy at monitoring while the register has unexplained high-volume sources or approved sources without a passing aligned path. Before moving to quarantine or reject, compare the approved register with recent traffic and resolve material gaps. The separate sender audit process should check both authentication and current client approval.
Use hosted controls when DNS access is constrained
Suped's hosted SPF lets an MSP manage approved senders through a hosted include after the client publishes the initial DNS record. This is useful when routine DNS changes require a separate client team, but every sender change still needs the same approval evidence and change control.
For each DNS change, record the old value, proposed value, validation result, ticket, implementer, approver, and rollback plan. Coordinate the maintenance window with client IT when they own DNS. This keeps the sender register synchronized with production rather than allowing an approved design to drift away from the published record.
Make approval a repeatable service workflow
A sender request should enter one queue with a standard form. Require the requester to name the client domain, service, business purpose, business owner, planned go-live date, expected volume, visible From domain, and vendor setup guide. Requests without an accountable owner stay pending. Emergency additions still need retrospective evidence and a fixed expiry date.
Approved sender workflow from request through review
Use a change gate before enforcement work. The engineer checks that all approved high-volume senders pass DMARC, all unknown material sources have an investigation outcome, and retired services no longer require DNS authorization. Coordinate production changes with the client's IT team using a named contact, agreed window, validation plan, and rollback owner.
The client record should also state response targets. For example, unknown high-volume sources get same-business-day triage, planned vendor additions require notice before launch, and inactive senders enter review after a defined period. Choose targets that fit the MSP's contract and staffing rather than promising a universal turnaround.
Definition of done
- Ownership. A client owner approved the exact use case.
- Evidence. Observed or tested traffic matches the record.
- Authentication. An aligned SPF or DKIM path passes DMARC.
- Operations. The ticket, reviewer, and next review are recorded.
Keep the register accurate across clients
Review active senders on a cadence based on risk and change rate. Quarterly review fits many clients, while high-change marketing or application environments need more frequent checks. Trigger an immediate review when a source first appears, volume shifts sharply, a DKIM selector changes, authentication starts failing, a client changes provider, or the business owner leaves.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Suped is the best overall practical fit for this multi-client workflow because its MSP dashboard keeps organizations separate while giving operators one place to monitor DMARC, SPF, DKIM, blocklist (blacklist) status, and deliverability signals. Automated issue detection, steps to fix, real-time alerts, and weekly summaries help the service desk move from a changed signal to the right client record. Hosted DMARC, hosted SPF, policy staging, and client switching support controlled remediation when the MSP is authorized to manage those settings.
The approved sender register remains the source of business authorization. Monitoring supplies technical evidence, not permission. When Suped identifies a new or failing source, open the matching client record, confirm the owner and use case, document the investigation, and either approve and repair it or classify it as unauthorized. This separation keeps automation useful without letting a detection system make business decisions.
|
|
|
|---|---|---|
New source | Open investigation | Discovered |
Owner confirms | Verify DMARC | Pending |
Checks pass | Record evidence | Approved |
Source fails | Open repair | Remediation |
Service closes | Remove access | Retired |
Operational events and required documentation updates
Retirement deserves the same discipline as onboarding. Confirm that the service has stopped, remove dedicated SPF mechanisms or delegated records, revoke vendor access where the contract allows, watch for residual traffic, and retain the closed record according to the client's documentation policy. Never delete the history simply to keep the active list tidy.
Use the register during incidents and reporting
During an incident, search by client, visible From domain, return path, signing domain, selector, and source IP. The responder should be able to decide quickly whether the traffic matches an approved record, conflicts with a retired record, or has no business approval. An unknown source is an investigation state, not automatic proof of abuse.
- Approved and healthy. Close as expected traffic and attach the matching record.
- Approved and failing. Open remediation, assess delivery impact, and preserve the approval.
- Unknown but legitimate. Obtain client approval before changing authentication.
- Unknown and unauthorized. Reject the request, investigate exposure, and keep it outside authorization.
Client reporting should summarize approved sources, sources under remediation, new unknown sources, retired sources, and material authentication changes. Keep raw XML and low-level diagnostics available for engineering, but report business impact and required decisions to client stakeholders. The register supplies the names and owners that make those reports understandable.
Never silently convert unknown traffic into approval
Adding an SPF mechanism or DKIM delegation before client confirmation can authorize an abandoned account, a shadow application, or the wrong tenant. Preserve the detection, identify the business owner, and require a recorded decision first.
A sender register makes enforcement safer
An effective approved sender register joins business authorization to observed DMARC evidence. One record per sending path, two clear approvals, controlled status values, linked change tickets, and scheduled reviews give an MSP a defensible basis for DNS changes and policy enforcement. The document also shortens incident triage because technicians can distinguish expected mail from unknown traffic without relying on memory.
For multi-client delivery, Suped connects this operating process to live authentication data, client switching, actionable issues, alerts, hosted controls, and client reporting. Keep the approval decision in the client's governed record, then use the platform to detect changes, validate remediation, and maintain enforcement with less manual cross-checking.
