How MSPs should follow up after a DMARC audit
Updated on 2 Nov 2026: We revised our post-audit workflow for RFC 9989 enforcement guidance, forwarding tests, and clearer remediation evidence.
After a DMARC audit, an MSP should follow up with a written findings summary, a sender inventory, a risk-ranked remediation plan, client approvals for DNS changes, a staged policy timeline, and a reporting cadence that proves authentication health is improving. The follow-up should turn the audit into a managed workflow.
The audit is the point where service delivery begins. The client has already seen that email authentication touches marketing, finance, CRM, helpdesk, payroll, and line-of-business systems. The follow-up has to make that complexity manageable through clear ownership, controlled DNS changes, and simple status reporting.
For MSPs building a repeatable DMARC offer, the audit follow-up should connect the technical work to a monthly service package. A managed DMARC service usually includes recurring monitoring, sender change control, client reporting, and escalation when authentication breaks.
Start with an audit closeout the client can act on
The first follow-up should be a closeout that a business owner and a technical admin can both understand. Avoid sending raw XML, copied DNS output, or a spreadsheet with no decision points. The client needs to know what is working, what is risky, what needs approval, and what happens next.
- Scope: List sending domains, active sending subdomains, parked domains, any exclusions, and the owner for each. Record the effective DMARC policy, including inherited subdomain policy.
- Current state: Document SPF and DKIM results for each mail stream and compare their authenticated domains with the visible From domain. DMARC passes when at least one mechanism passes and meets the configured domain alignment requirement.
- Sender inventory: List the systems observed sending mail, including Microsoft 365, Google Workspace, CRM, invoicing, helpdesk, forms, and marketing platforms.
- Risk ranking: Separate urgent authentication failures from cleanup items that can wait until the next maintenance window.
- Decision points: Ask for approval on sender ownership, DNS changes, policy staging, and who receives progress updates.
The best audit follow-up does not ask the client to interpret DMARC. It asks the client to confirm business facts: which tools are approved to send mail, who owns them, and whether mail from unknown systems should be treated as risk.
Aggregate reports show sources observed by participating receivers during a stated reporting window. They do not provide a complete sender inventory or prove that the client authorized a source. Record coverage gaps, then combine report evidence with client confirmation and production-message checks. Ask about monthly billing runs and seasonal campaigns that were absent during the audit window.
When the closeout is clear, the MSP avoids a common service problem: the technical team waits for business input, the client assumes remediation has started, and neither side has agreed on which sender matters most. Put the decisions in writing before touching enforcement.
Turn findings into a remediation queue
The audit should become a ticket queue with owners, priorities, due dates, and verification steps. This is where DMARC becomes operational work. Each issue needs one clear fix path, not a general note that authentication failed.
|
|
|
|
|---|---|---|---|
No DMARC | MSP | Add monitoring record | Valid DNS record and incoming reports |
SPF fail | MSP | Check source and MAIL FROM | SPF pass with domain alignment |
DKIM missing | App owner | Enable signing | Valid signature with domain alignment |
Unknown mail | Client | Approve or stop | Decision record |
SPF lookup limit | MSP | Reduce terms that query DNS | No permerror on evaluated paths |
Use compact labels so the remediation queue stays scannable.
A useful queue groups work by sender and business impact. Microsoft 365 authentication problems usually need a different timeline than a legacy web form that sends a few messages per month. Do not let low-volume cleanup block urgent fixes for payroll, billing, or customer support mail.
Starting DMARC record for monitoringdns
_dmarc.example.com. 3600 IN TXT ( "v=DMARC1; p=none;" "rua=mailto:dmarc@example.com" )
Replace the example domain and reporting mailbox with the client domain and assigned report destination. Verify that the mailbox receives and processes aggregate reports. When the rua destination is on another domain, check the external reporting authorization described in RFC 9990; a valid policy record alone does not prove reports will arrive.
If the client has no DMARC record, start with a monitoring policy and review enough reporting periods to identify important legitimate senders and coverage gaps. Move to enforcement only after SPF or DKIM alignment is stable for important mail streams. A DNS check confirms publication, but a fresh message from the production path confirms that the intended authentication is in use.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Separate remediation from enforcement
The client can hear the word audit and assume the next step is to switch directly to quarantine or reject. Follow-up should separate remediation work from the enforcement decision. Remediation fixes authentication. Enforcement publishes the domain owner's preferred handling for mail that fails DMARC, while receivers retain discretion over the final disposition.
Remediation
- Goal: Make legitimate mail pass SPF or DKIM with domain alignment.
- Work: Update DNS, enable DKIM, remove stale senders, and correct routing.
- Proof: Show aligned results on the production path and in later aggregate data.
Enforcement
- Goal: Reduce spoofing risk with an approved DMARC handling policy.
- Work: Choose quarantine or reject according to the domain's mail flows, evidence, and client approval.
- Proof: Confirm important mail still passes after the approved policy change.
A follow-up plan should tie the policy choice to a trustworthy source inventory and a known owner for each sender. Quarantine can be the ongoing policy; reject is not a mandatory endpoint. For p=reject, RFC 9989 requires valid DKIM signatures and prohibits relying solely on SPF for a DMARC pass, so verify DKIM domain alignment on legitimate mail.
DMARC policy choices
Choose a policy for the domain's mail flows; these are not mandatory stages.
Monitor
p=none
Use when legitimate senders are still unknown.
Quarantine
p=quarantine
Use after validating legitimate mail flows and obtaining client approval; it can remain the ongoing policy.
Reject
p=reject
Consider only after assessing indirect mail flows, validating DKIM, and documenting the accepted delivery risk.
RFC 9989 defines DMARC, with aggregate reporting in RFC 9990 and failure reporting in RFC 9991. The pct tag is historic; do not use percentage-based rollout. Stage approved changes by domain or subdomain, check the effective inherited policy, and validate the affected production paths. Receivers using older implementations do not necessarily support newer tags or DNS Tree Walk discovery, so confirm actual results.
Suped is our DMARC and email authentication product. Its DMARC monitoring combines source visibility, authentication results, alerts, and client reporting so MSP teams can review findings, verify remediation, and prepare policy decisions using the same evidence.
Test forwarding and mailing lists before enforcement
Forwarding changes the sending IP, so legitimate mail can fail SPF. Mailing lists that change a signed subject or message body can also break DKIM. These indirect mail flows are described in RFC 7960.
- Ask the client which mailing lists, role-based aliases, and external forwarding paths are used for business mail.
- Test those paths and compare the original message with the delivered copy, including DKIM signatures and the receiving system's authentication results.
- Identify a forwarding source before changing SPF. Do not authorize an unrelated forwarder simply to clear a failure.
- Record the business impact and the agreed policy decision in the exception register instead of classifying every failed message as spoofing.
RFC 9989 advises against p=reject for general-purpose email domains. When a domain with mailing-list users still chooses reject, it recommends at least a month at p=none followed by an equally long p=quarantine period to compare outcomes. This assessment can extend beyond the initial 30-day follow-up.
Get client approvals before DNS changes
The follow-up should make approvals explicit. DNS changes are often simple, but the business impact of breaking mail is not. MSPs need a light approval process that covers who requested the change, what record changes, which sender it affects, when it will be deployed, and how it will be verified.
Approval checklist
- Business owner: Confirm the sender is still approved and needed.
- Technical owner: Confirm who can enable DKIM or update the sending platform.
- DNS owner: Confirm who can publish TXT or CNAME records.
- Rollback plan: Save the existing record and TTL, define the failure condition that triggers rollback, and name the technician authorized to restore the record. Cached policy can persist until its TTL expires.
For client domains with many senders, hosted records can reduce operational friction. Suped's Hosted SPF lets MSPs manage approved sender changes after publishing the initial SPF redirect. Its automated flattening refreshes sender IP ranges as they change. When reviewing the original record, count nested includes toward the limit of 10 SPF terms that cause DNS queries in RFC 7208; flattening does not fix domain alignment.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
Do not use hosted SPF as a way to skip change control. Use it to make approved change control faster. The client should still know which senders are authorized and which old systems are being removed.
Validate fixes and manage exceptions
Do not close a remediation ticket when a DNS record appears or a sending platform shows a green status. Retest the same production path that created the finding, then keep the evidence with the ticket. This separates a published configuration from proof that real mail uses it.
- DNS evidence: Query the authoritative DNS service and a public resolver after the expected TTL window.
- Platform evidence: Confirm the active DKIM and return-path configuration in the sending system.
- Message evidence: Inspect a fresh delivered message for the exact mail stream. Use Authentication-Results added by the trusted receiving system and record the SPF MAIL FROM domain, DKIM d= domain, visible From domain, and DMARC result.
- Report evidence: Review later aggregate-report periods and record any receiver-coverage limitations. Check report timestamps; missing reports require investigation and do not prove there were no failures.
Keep an exception register
For a finding that cannot close, record the affected domain or sender, the decision owner, the evidence gap, the accepted risk, the next review date, and the rollback or escalation condition. A deferred ticket without a review date is backlog, not a controlled exception.
An aggregate-report row is an observation, not proof that a sender is approved or unauthorized. Client confirmation establishes the business decision, while production-message evidence and later reports show whether the technical change worked.
Create a client-facing follow-up report
A post-audit report should not read like a vulnerability scan export. It should tell the client what was found, what has been fixed, what needs a decision, and what the MSP will monitor next. The report should also define the service boundary so recurring work does not become invisible labor.
MSP DMARC audit follow-up: confirm senders, fix SPF, enable DKIM, stage policy, and report progress.
Use a simple report structure that keeps the conversation on decisions, not jargon. Include the summary and evidence below, plus domain status, open exceptions, and the next review date. If the client needs audit evidence, include monitoring coverage and the approved change history.
Create client report dialog with organization, date range, logo, and language options
Suped's MSP reporting workflow can produce client-ready reports across managed organizations. The MSP can reuse the same evidence and decision structure for many domains without rebuilding each report by hand.
- Executive summary: Explain the current risk, the recommended next step, and the client decision needed.
- Evidence window: State the domains, reporting dates, receiver coverage, and known evidence gaps.
- Sender table: Show approved, unknown, broken, and retired senders in plain language. For approved sources, give observed message counts and the DMARC pass rate; report suspected spoofing separately so it does not distort legitimate-mail results.
- Remediation plan: List the exact change, owner, status, verification method, and exception state for each issue. Show open and closed ticket counts and flag overdue client decisions.
- Policy path: Record the current policy, proposed change, client decision, test window, and rollback condition.
Build the follow-up into recurring service delivery
After the first remediation cycle, the MSP should define a steady-state service with monitoring, alert triage, sender onboarding, policy review, exception review, service targets, and client reporting.
Recurring DMARC workload
A sample service mix after the audit follow-up moves into managed operations.
Monitoring
Remediation
Reporting
The service should specify what the MSP owns. A clean model is to own DMARC reporting, DNS record management when delegated, SPF lookup control, DKIM verification, alert triage, and monthly client reporting. The client owns business approval for new senders and the decision to retire systems that no longer need to send mail. Define service-level agreement (SLA) response targets for urgent failures, routine sender changes, and overdue client decisions. Route a newly failing approved sender to the service desk under its client and domain; escalate delivery disruption immediately rather than waiting for the monthly report. Limit technician access to the client organizations they support.
For MSP operators, the main risk is inconsistent execution across clients. One technician might move quickly to enforcement while another keeps every domain at monitoring forever. A runbook prevents that drift. If you need a deeper operational model, the related guide on an MSP DMARC runbook covers the ongoing support structure.
Suped's product supports this recurring MSP workflow with multi-tenant client views, issue alerts, managed authentication records, blocklist and blacklist monitoring, and client reports. Use it to triage findings, watch for sender drift, and keep each client's review cycle consistent.
Use a follow-up meeting to make decisions
The follow-up meeting should be short and decision-led. It is not the place to teach every part of DMARC. It is the place to confirm senders, approve fixes, agree on the enforcement path, and define what the client will see in future reports.
- Open with risk: State whether the domain is unprotected, partly protected, or ready for staged enforcement.
- Review senders: Ask the client to confirm approved systems and identify unknown mail sources.
- Approve changes: Confirm which DNS and platform changes the MSP can make.
- Set milestones: Choose dates for remediation review, policy movement, and client reporting.
The meeting should end with a written action list sent the same day, because sender ownership gets unclear quickly. Include the ticket IDs, sender names, expected DNS changes, client-side tasks, evidence required for closure, and the next reporting date.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
The MSP should also record what not to do. If an unknown sender is under review, do not authorize it in SPF just to make failures disappear. If a platform cannot sign DKIM with the client domain, document that limitation and decide whether the platform should continue sending branded mail.
Investigate deliverability and reputation problems
DMARC follow-up also covers domain and IP reputation. When the audit uncovers old infrastructure, shared sending pools, or unrecognized third-party senders, the MSP should check for reputation issues. A blocklist (blacklist) listing requires a separate investigation when authenticated mail is still rejected or sent to junk.
Use blocklist monitoring as supporting evidence alongside DMARC. DMARC shows whether mail using the client domain passed through an aligned SPF or DKIM identity. Blocklist checks show whether sending infrastructure or domains appear on lists that some receivers consult. A DMARC pass does not guarantee inbox placement, and an aggregate report does not reveal every receiver's private reputation decision.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
Suped includes blocklist monitoring alongside DMARC visibility. An MSP can use the separate signals to explain whether a mail problem concerns authentication, reputation, or both.
A practical follow-up sequence for MSPs
Standardize the first 30 days after the audit as an initial remediation cycle, not an enforcement deadline. The exact timing changes by client size, sender complexity, and report coverage, but the sequence should stay consistent.
Authentication improvement target
An illustrative client target for aligned legitimate mail, not a universal enforcement gate.
Aligned legitimate mail
- Day 0: Send the audit closeout, source inventory, top risks, and requested approvals.
- Days 1-5: After approval, fix obvious DNS issues, enable DKIM for major senders, and remove retired SPF entries.
- Days 6-14: Review unknown sources with the client and decide whether to authorize, migrate, or stop them.
- Days 15-30: Retest completed work, record exceptions, report progress, and propose the next DMARC policy decision.
Set the alignment target for each client after reviewing its sender mix and reporting coverage. The chart values are illustrative, not measured results. Neither a 95% DMARC pass rate nor reaching day 30 is an enforcement gate; an important low-volume sender can still be broken.
This sequence also gives the MSP a clean sales and account management handoff. The technical team can show measurable progress, while the account team can position ongoing monitoring as the control that keeps future sender changes from creating the same problem again.
Frequently asked questions
Use the agreed service target. A practical starting target for the written closeout is one business day; urgent delivery failures need immediate escalation. Include findings, risks, requested approvals, and the first remediation steps.
No. Quarantine can remain the ongoing policy. RFC 9989 advises against reject for general-purpose email domains. If reject is chosen, assess forwarding and mailing-list use, verify legitimate mail and DKIM domain alignment, obtain client approval, and document rollback conditions.
The client should approve the sender inventory, DNS changes, sender removals, policy decision, accepted exceptions, and reporting contacts.
Preserve the evidence and check whether the source is an approved sender, a forwarder, or unauthorized use. Ask the client to confirm its purpose. For legitimate senders, document authorization, migration, retirement, or a time-limited exception. Investigate unauthorized use without adding the source to SPF.
Retest the affected DNS record, confirm the active sender configuration, inspect a fresh message from the same production path, and review later aggregate-report data. Keep the evidence with the remediation ticket.
Suped helps MSPs monitor DMARC, detect issues, manage hosted records, triage alerts, and create client reports across managed organizations.
