How MSPs should monitor new client senders after onboarding
MSPs should monitor every new client sender daily for the first 14 days, at least twice a week through day 30, weekly through day 90, and monthly once its identity, ownership, volume, SPF, DKIM, and DMARC alignment remain stable. I would keep any sender unapproved until the client owner confirms its business purpose and a real message passes the expected authentication path.
The job does not end when aggregate reports start arriving. A newly onboarded domain usually exposes old services, forgotten campaigns, forwarding paths, and shared vendors over several sending cycles. The MSP needs a repeatable process that turns each observed source into an approved sender, a repaired sender, an investigated unknown, or a source that should remain blocked.
Use a 90-day monitoring cadence
I use a staged cadence because new sources rarely appear on a convenient schedule. Payroll can send monthly, a board portal can send quarterly, and a marketing platform can remain quiet until the next campaign. Frequent early reviews catch common systems quickly, while a 90-day observation window gives low-frequency business mail a chance to appear.
Post-onboarding review cadence
Minimum review frequency for each client domain after DMARC reporting begins.
Days 1-14
Daily
Review sources every business day.
Days 15-30
2x weekly
Review at least twice each week.
Days 31-90
Weekly
Review once each week.
Steady state
Monthly
Review monthly and on every alert.
Cadence alone is not a control. Each review needs an owner, a ticket, a decision deadline, and recorded evidence. High-risk clients, active migrations, or domains already at enforcement need tighter review intervals. A sender that suddenly appears at high volume should be triaged immediately rather than waiting for the next scheduled review.
Do not approve by IP address alone
Cloud services reuse and rotate infrastructure. Treat the visible IP, reverse DNS, envelope domain, header From domain, DKIM signing domain, provider identity, and client confirmation as one evidence set.
Build the baseline before approving sources
Start with the client's pre-onboarding inventory, then reconcile it against observed DMARC data. A good sender inventory process records the business owner, service name, purpose, sending domains, expected volume, authentication method, and change contact. I treat the inventory as a hypothesis until DMARC data and a controlled test confirm it.
- Identity: Map the source IP and reverse DNS to a named service and client owner.
- Purpose: Record whether it sends transactional, staff, support, billing, or campaign mail.
- Authentication: Capture SPF result and alignment, DKIM result and alignment, and the resulting DMARC disposition.
- Expected pattern: Define normal volume, active days, recipient regions, and known campaign dates.
- Decision: Set the source to approved, repair, investigate, retired, or unauthorized.
Keep client confirmation attached to the sender record. A verbal approval that cannot be traced later creates trouble when staff change or the service is replaced. The practical standard is documented ownership plus technical evidence, followed by a review date.
Issues page showing verified and unverified source sections for reviewing sending sources
Suped's verified and unverified source views support this queue-based workflow. The MSP can separate known client services from sources that still need ownership confirmation, then keep the decision visible to operators working across shifts or clients.
Classify every sender with evidence
Every new source should enter the same triage path. First identify the provider or system. Next compare it with the approved inventory. Then verify a message sample and ask the client owner to confirm the business use. Finally, assign a status and remediation owner. This prevents an operator from treating a familiar provider name as proof that the client authorized the mail.
Six-step flow for identifying and approving a new client sender
The identity check should use more than a public ownership lookup. Compare the source with actual message headers and the provider configuration supplied by the client. Shared infrastructure can be legitimate, but it does not establish which customer account created the traffic.
If the client recognizes the service but authentication fails, classify it as repair rather than approved. Keep it separate from an unauthorized source so the engineer can fix the known service while the analyst continues investigating activity with no owner.
Evidence supports approval
- Owner: A named client contact confirms the service.
- Message: A test matches the expected headers and content.
- Alignment: SPF or DKIM passes and aligns for DMARC.
Evidence requires containment
- Unknown owner: No client team accepts responsibility.
- Mismatch: Headers do not match the claimed service.
- Failure: Authentication fails without an explained path.
Do not authorize an unknown source by adding it to SPF just to improve a pass rate. That change grants sending authority before identity has been established. Investigate the source, preserve samples, and follow the client incident path if the mail looks deceptive or no owner can explain it.
Verify the real authentication path
A DMARC pass does not prove that both SPF and DKIM work. DMARC needs one aligned mechanism to pass. I still inspect both paths because forwarding can break SPF, vendor changes can break DKIM, and a sender that relies on only one path has less tolerance for operational changes.
|
|
|
|---|---|---|
SPF | Result, domain | Pass plus alignment |
DKIM | Result, signer | Pass plus alignment |
DMARC | Result, policy | Aligned path passes |
Headers | From, return path | Expected identity |
Compact evidence to capture for each sending source.
Send a controlled message through every available route, including normal user mail, automated notices, ticket replies, invoices, and campaigns. Inspect the received headers rather than accepting a vendor setup screen as proof. Then compare the sample with aggregate DMARC results after enough reporting time has passed.
Test both routine and exceptional routes when possible. A help desk platform can sign direct replies correctly while a forwarding or escalation route uses another identity. Store the test date, recipient, visible From domain, and result so another operator can reproduce the check.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
The email tester gives the operator a concrete message-level result to attach to the ticket. It complements aggregate reporting, which shows patterns across receivers but does not preserve every message header. A clean test should not close the review if production data still shows failures or unexpected signing domains.
Record the evidence in a structured format instead of free-form notes. Consistent fields make it easier to compare later changes, audit approvals, and hand work to another technician. The status should describe the current decision, while the review date forces a future check.
Sender evidence recordYAML
service: client-approved-name owner: client-contact purpose: transactional-mail header-from: example.com spf: aligned-pass dkim: aligned-pass dmarc: pass volume-band: expected status: approved review-date: YYYY-MM-DD
Alert on change, not only failure
A useful monitoring service detects change in an approved sender's behavior. Authentication failures matter, but so do a new source IP range, a new DKIM signing domain, a volume jump, mail appearing after a retirement date, or a shift in policy disposition. These changes often indicate a vendor migration, configuration drift, or an account that needs investigation.
- Critical: A high-volume unknown source, suspected impersonation, or failure after enforcement.
- High: An approved sender begins failing alignment or changes signing identity.
- Normal: A low-volume new source needs ownership confirmation within the service target.
- Review: A stable approved source remains in the scheduled health review.
Thresholds should fit the client. Ten failed messages can matter for an executive-only domain while being routine noise during a large migration. Record the baseline first, then alert on meaningful deviation and severity. The wider DMARC monitoring workflow should send each event to the correct operator with client context, not to a shared inbox without ownership.
Notification settings page with DMARC alerts, weekly summary, toggles, and preview buttons
Suped's notification settings let an MSP configure DMARC alerts and summaries for the operational contacts who need them. Pair each alert with a ticket rule that records the client, domain, source, severity, assignee, due time, and resolution. For cross-client operations, use a common triage standard so the same condition receives the same initial response.
Control sender changes through tickets
Client teams often add a cloud service before telling the MSP. I make sender changes a small change-control process: request, owner approval, DNS plan, test, observation, and closure. The client does not need to understand every DMARC field, but the business owner must confirm that the service is legitimate and accept responsibility for notifying the MSP when it changes.
Before a sender change
Capture the business owner, provider instructions, sending domain, expected launch date, authentication design, rollback path, and sample recipients.
After a sender change
Run a real message test, watch aggregate data, confirm normal volume, document the observed identities, and schedule a removal date if the service is temporary.
Keep one approved-sender register per client and update it through tickets. A consistent method for documenting approved senders prevents the inventory, DNS configuration, and monitoring labels from drifting apart. Include a last-seen date so dormant systems can be reviewed and removed instead of remaining authorized forever.
SPF changes need their own review
Adding every discovered vendor to SPF creates unnecessary authorization and can exceed the ten-lookup limit. Use DKIM alignment where the service supports it, remove retired includes, and consider hosted SPF when an MSP needs controlled sender management without repeated client DNS access.
Run the workflow across every client
The workflow has to work at multi-tenant scale. I keep one operating queue across clients, but preserve client-specific owners, thresholds, maintenance windows, and escalation contacts. Operators should be able to switch context quickly without merging evidence or applying one client's approval to another client's sender.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Suped is the best overall practical fit for this DMARC service workflow because its MSP and multi-tenancy dashboard keeps client organizations separate while giving the operator one place to review domain status, authentication data, issues, and alerts. Suped's product also brings DMARC, SPF, DKIM, blocklist (blacklist) monitoring, and deliverability insights into the same operating view, with automated issue detection and steps to fix. The DMARC for MSPs workflow is built around managing multiple organizations without losing client context.
Use role-based access, a shared status taxonomy, and a documented handoff rule. The service manager should sample closed sender reviews each month to confirm that approvals contain both client confirmation and technical evidence. Report repeated late approvals, recurring authentication failures, and unauthorized sources as service risks, not merely as dashboard counts.
|
|
|
|---|---|---|
Client owner | Business approval | Ticket confirmation |
MSP analyst | Source triage | Headers, DMARC data |
MSP engineer | DNS remediation | Change record |
Service manager | Quality review | Monthly sample |
Minimum ownership model for the sender-monitoring service.
Close onboarding with a stable sender register
Onboarding is operationally complete when the MSP has observed the agreed period, classified every material source, verified approved senders with message evidence, assigned unresolved items, and documented how future senders enter the process. The 90-day point is a review gate, not an automatic declaration that every sender is safe.
I would hand the client a concise sender register and service report showing approved sources, repairs completed, open risks, policy state, and owner actions. After that, move the domain into steady-state monthly review while keeping real-time or near-real-time alerts for meaningful changes. That gives the MSP a defensible record and gives the client a clear route for adding the next service without weakening authentication.
