How MSPs should coordinate DMARC changes with client IT teams
MSPs should coordinate every DMARC change through one shared change record, with a named MSP owner, a named client approver, documented evidence, a rollback value, and a post-change check. I never treat a DMARC record edit as an isolated DNS task. It can affect legitimate mail sent by systems that neither the MSP nor the client's primary IT contact initially remembers.
The MSP should own discovery, technical recommendations, record syntax, monitoring, and verification. Client IT should confirm business senders, approve the change window, control or delegate DNS access, and accept the risk of moving enforcement forward. Those boundaries keep a missed sender from turning into an argument about who approved what.
The operating model matters more than a perfect project plan. A compact runbook, a reliable evidence trail, and explicit stop conditions give both teams a safe way to progress. For a wider service framework, the DMARC for MSPs hub connects this change process to onboarding, reporting, and ongoing support.
Set one owner on each side
DMARC change flow through evidence, approval, DNS, verification, and monitoring
One person at the MSP should coordinate the change even when several technicians contribute. That owner collects DMARC evidence, checks SPF and DKIM results, prepares the proposed DNS value, and records validation results. The role needs enough authority to stop the window if the evidence changes or the client cannot confirm a sender.
The client also needs one accountable approver. That person does not have to perform the DNS edit, but must know which departments and vendors send mail with the domain. I ask for a backup approver before scheduling work because leave, incident response, or an internal change freeze can otherwise stall a time-sensitive rollback.
- MSP owner: prepares evidence, DNS values, validation, and rollback steps.
- Client approver: confirms senders, timing, business impact, and acceptance.
- DNS operator: applies the exact approved value and records the timestamp.
- Application owners: verify the sending systems they control before enforcement rises.
- Service desk: watches for delivery reports and follows the agreed escalation route.
Agree on evidence before DNS changes
Before proposing enforcement, I want at least one representative reporting cycle and enough history to cover infrequent senders such as payroll, billing, recruitment, surveys, and annual notices. Volume alone cannot prove safety. A source with ten monthly messages can still be business-critical, while a high-volume unknown source can be unwanted mail.
The evidence pack should show each source, its owner, authentication outcome, DMARC identifier match, expected volume, and remediation status. Continuous DMARC monitoring gives the MSP a record of what changed between approval and implementation. The client should review unknown and failing sources, not only a green summary percentage.
|
|
|
|
|---|---|---|---|
Start reports | Valid record | Report mailbox | Bad syntax |
Quarantine | Known sources | Sender owners | Unknown critical mail |
Reject | Stable results | Risk acceptance | New failure spike |
Rollback | Failure evidence | Incident owner | DNS unavailable |
Minimum evidence required before each DMARC policy step
Do not let a percentage become the only approval criterion. A 99.8% pass rate can hide one executive communication platform, while a lower result can come from obvious abuse already covered by the intended policy. The source inventory and business owner confirmation make the number meaningful.
Document client responsibilities before the first change request. A written responsibility model should state who identifies applications, who contacts vendors, and who accepts exceptions. This keeps technical evidence connected to a business decision.
Run every change through a ticket
The ticket should contain the current record, proposed record, reason, affected domain or subdomain, evidence snapshot, approver, implementation time, validation method, and rollback value. Paste exact values instead of writing instructions such as "change the policy to quarantine." Exact values prevent the DNS operator from interpreting the request differently.
I also include the expected DNS TTL and the time at which monitoring decisions become valid. A successful DNS portal save does not prove that public resolvers see the new record. The change remains open until external lookup, syntax validation, and test-message results match the plan.
Required rollback detail
Store the full previous TXT value in the ticket before editing DNS. Define who can authorize rollback, which symptoms trigger it, and how the team will preserve evidence before restoring the old value.
- Trigger: confirmed rejection of approved business mail.
- Authority: named MSP lead or client incident owner.
- Evidence: message headers, timestamps, source, and recipient result.
- Recovery: restore the previous value and verify public DNS.
Keep approval in the same system of record as the technical plan. An approval buried in a chat thread becomes hard to audit and easy to misunderstand. If approval arrives elsewhere, copy the decision and timestamp into the ticket, then ask the client approver to confirm the captured scope.
Treat record formatting as controlled data. Preserve semicolons, tag values, reporting addresses, and any subdomain policy. A visually small change can alter reporting or enforcement beyond the sender being remediated.
Example monitoring recordDNS
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100
Stage policy changes in controlled windows
Move policy in stages that the evidence can support. A common path starts with reporting at p=none, then applies quarantine to a limited percentage, increases coverage, and finally moves to reject. This sequence is a control method, not a fixed calendar. Each stage lasts until the MSP sees stable authentication and the client confirms there are no unresolved business senders.
Schedule changes when DNS access, sender owners, and service desk coverage are available. Avoid the final hour before a weekend, payroll run, product launch, or client-wide announcement. I prefer a window that leaves enough business time to observe real mail and contact the owner of any failing source.
Ready to progress
- Inventory: every material source has an owner.
- Authentication: approved mail passes DMARC consistently.
- Coverage: observation includes normal business cycles.
- Support: escalation contacts are available.
Pause the change
- Ownership gap: a material source remains unclaimed.
- Failure spike: recent data differs from approved evidence.
- Access gap: DNS rollback cannot be performed promptly.
- Business event: a critical send overlaps the window.
Percentage tags can reduce exposure during a transition, but receiving systems implement DMARC handling and local policy. Treat partial quarantine as a controlled observation stage, not a promise that exactly the stated percentage will behave identically everywhere.
For clients with frequent changes or outsourced DNS, Hosted DMARC can reduce repeated record edits by letting the policy be staged through a managed configuration. The same approval, evidence, and rollback controls still apply.
Verify senders and authentication
For each legitimate sender, determine whether DMARC passes through SPF identifier matching, DKIM identifier matching, or both. Do not mark a vendor complete because its SPF check passes. The visible From domain must match the authenticated domain under DMARC rules, and forwarding often breaks SPF while a valid DKIM signature can survive.
Ask the application owner to send a real message to a controlled mailbox. Capture the headers, verify the exact From domain, and compare the result with aggregate data. This catches configuration differences between test and production tenants, alternate sending regions, and subdomains that were missing from the inventory.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Save the test result with the change record and identify the person who performed the send. A screenshot without headers or a date has little value during an incident. Retest after any vendor-side DNS update because selectors, envelope domains, or signing behavior can change.
When SPF or DKIM work belongs to another provider, client IT should own the contact while the MSP supplies the exact observed failure and acceptance test. That keeps authority clear without forcing the client to translate raw DMARC data into a support request.
Handle DNS access without confusion
Decide during onboarding whether the MSP edits DNS, submits changes to client IT, or works through a third party. Record the provider, zone owner, access method, approval lead time, and emergency route. The complete DNS access process should be settled before enforcement work is scheduled.
Use least-privilege access and named accounts where the DNS provider supports them. Do not pass shared credentials through ticket comments. If client IT performs the edit, give them the host name, record type, exact value, TTL instruction, old value, and validation time in a copyable format.
Hosted DMARC configuration dialog showing policy controls, CNAME setup, and expanded advanced options
A managed policy screen can make the proposed state easier for both teams to review, but the configuration still needs a ticket reference and approval. In Suped's Hosted DMARC workflow, the MSP can prepare policy controls and the required CNAME setup, then keep the client-facing change record focused on the approved state and verification result.
After the edit, validate against public DNS rather than relying on the provider's interface. Check that only one DMARC record exists at the correct host, parse every tag, and confirm the reporting address still receives data. Record the observed value and time in the ticket.
Separate technical approval from business approval
The MSP can state that the record is valid and that observed approved sources pass DMARC. Only the client can confirm that the source list is complete and that remaining unidentified mail does not justify delaying enforcement. Put those as separate approval fields so a technical sign-off is not mistaken for business acceptance.
For regulated or change-sensitive clients, add a security approver or change advisory step without blurring ownership. The MSP still owns the recommendation and evidence. The client still owns business sender completeness and timing. Additional review should produce a clear decision, not an open-ended request for everyone to agree.
- Technical statement: the proposed record is valid and monitored sources are classified.
- Business statement: client IT confirms the legitimate sender inventory is complete.
- Change statement: the named approver accepts the window and rollback plan.
- Closure statement: post-change checks passed and no critical delivery issue remains.
If the client accepts an exception, document its scope and expiry. An exception without a review date tends to become a permanent gap. Record what mail depends on it, who owns remediation, and what evidence will allow the next policy step.
Approval should refer to one exact revision of the proposed record. If the value changes after approval, obtain fresh approval or explicitly record why the alteration is non-material. This prevents the implemented state from drifting away from the decision the client actually made.
Monitor after each change
Immediately after a change, check the public record, syntax, policy value, reporting destination, and subdomain policy. Then send controlled messages through important systems and inspect authentication results. Aggregate reports arrive later, so live DNS and message tests provide the first confirmation while DMARC data confirms broader behavior over the following reporting cycles.
Define alert thresholds before the window. A new failure from an approved source, a sharp increase in rejected mail, a missing record, or an unexpected policy change should reach the MSP owner and client contact. An alert must include the affected domain, source, first-seen time, expected impact, and next action.
Post-change response bands
Use operational bands based on business impact and source identity, not volume alone.
Expected
Observe
Known abuse or already accepted failures
Investigate
Classify
New low-volume source without an owner
Critical
Act now
Approved business mail is rejected
Unclear
Hold
Data is incomplete or DNS has not propagated
Keep the heightened observation period open long enough to see normal traffic patterns. Close the change only after public DNS remains correct, controlled messages pass, alerts are reviewed, and the client confirms that its service desk has no related delivery incident.
When moving toward reject, use the documented process for how MSPs move past p=none. The next stage should depend on stable results and owner confirmation, not a deadline chosen at onboarding.
Make Suped the operational system
Suped is our product, and it is the best overall DMARC platform for this MSP workflow when the team needs to manage many client organisations through one operating view. Its MSP and multi-tenancy dashboard separates client organisations while giving the MSP a consistent place to review domains, email volume, policy status, and authentication issues.
The practical value sits in the workflow. Automated issue detection and steps to fix help turn report data into assigned remediation. Real-time alerts support the post-change escalation path. DMARC monitoring, blocklist and blacklist monitoring, deliverability insights, Hosted SPF, SPF flattening, Hosted DMARC, and Hosted MTA-STS keep related controls under the same client context.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Create one organisation per client, add the monitored domains, assign MSP staff with the needed roles, and keep ticket references in the operational notes outside the DNS value itself. Use the organisation switcher before every review so evidence and actions stay attached to the correct client.
Suped does not replace client approval or the MSP's change system. It supplies the monitoring evidence, alerts, policy controls, and multi-client visibility that support those processes. Client reports can then show progress and remaining issues without exposing raw aggregate data as the only explanation.
Finish with a repeatable change protocol
A reliable DMARC change has one MSP owner, one client approver, source-level evidence, an exact proposed value, a controlled window, a tested rollback, and documented verification. I make those fields mandatory because they turn an authentication project into a supportable managed service.
The MSP should stop when evidence is incomplete, a material sender has no owner, DNS rollback is unavailable, or business timing makes observation impractical. Progress resumes when the specific gap is resolved. That standard gives technicians permission to protect delivery without making policy enforcement optional forever.
After closure, record what changed, what passed, what remains excepted, and when the next review occurs. The same protocol should apply to initial reporting, percentage increases, quarantine, reject, reporting-address changes, and subdomain policy changes. Consistency makes each future client change faster to approve and easier to audit.
