How MSPs should follow up after a DMARC audit
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, not a one-time technical note.
I like to treat the audit as the point where the service delivery motion 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 feel manageable. That means 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. That package usually includes DMARC for MSPs delivery, 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.
- Current state: Document whether SPF, DKIM, and DMARC exist, pass, and align for the client domain.
- Sender inventory: List the systems 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.
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 record | DNS check |
SPF fail | MSP | Update include | Pass result |
DKIM missing | App owner | Enable signing | Aligned pass |
Unknown mail | Client | Approve or stop | Volume trend |
SPF limit | MSP | Flatten | Lookup count |
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; fo=1" )
If the client has no DMARC record, start with a monitoring policy, collect enough data to identify legitimate senders, then move to enforcement only after SPF or DKIM alignment is stable for important mail streams.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Separate remediation from enforcement
The client may hear the word audit and assume the next step is to switch directly to quarantine or reject. That is not the right default. Follow-up should separate remediation work from the enforcement decision. Remediation fixes authentication. Enforcement tells receiving mail servers what to do with unauthenticated mail.
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 pass rates, aligned sources, and lower unauthenticated volume.
Enforcement
- Goal: Reduce spoofing risk by moving the DMARC policy beyond monitoring.
- Work: Stage policy changes through none, quarantine, and reject.
- Proof: Show that important mail still authenticates after policy changes.
A clean follow-up plan shows that enforcement happens in stages. For many clients, the first milestone is not reject. It is a trustworthy source inventory and a known owner for each sender. After that, the MSP can set a controlled policy timeline.
Policy readiness bands
A practical way to explain staged DMARC movement after the audit.
Monitor
p=none
Use when legitimate senders are still unknown.
Contain
p=quarantine
Use when most key mail is aligned and failures need closer review.
Enforce
p=reject
Use when important mail streams are aligned and exceptions are documented.
This is also where Suped can make the MSP workflow cleaner. Suped's DMARC monitoring brings DMARC, SPF, DKIM, source visibility, alerts, and client reporting into one place, which helps MSP teams avoid switching between raw reports, DNS panels, and spreadsheets.
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, CNAME, or MX-related records.
- Rollback plan: Define the exact record to restore if the change causes delivery problems.
For client domains with many senders, hosted records can reduce operational friction. Suped's Hosted SPF lets MSPs manage sender changes without asking for DNS access every time, while SPF flattening helps keep records below lookup limits.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS 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.
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.
Flowchart showing an MSP DMARC audit follow-up process.
I use a simple report structure because it keeps the conversation on decisions, not jargon. The report should have an executive summary, domain status, sender inventory, remediation plan, enforcement path, and next review date. If the client has compliance pressure, include evidence of monitoring and change history.
Create client report dialog with organization, date range, logo, and language options
Suped's MSP reporting workflow helps here because it can produce client-ready reports across managed organizations. That matters when the MSP has to repeat the same follow-up process for dozens or hundreds of domains without rebuilding reports by hand.
- Executive summary: Explain the current risk, the recommended next step, and the client decision needed.
- Sender table: Show approved, unknown, broken, and retired senders in plain language.
- Remediation plan: List the exact changes, owner, status, and verification method for each issue.
- Policy path: Define the planned movement through monitoring, quarantine, and reject.
Build the follow-up into recurring service delivery
A DMARC audit creates value once. Managed follow-up creates recurring value. After the first remediation cycle, the MSP should define a steady-state service with monitoring, alert triage, sender onboarding, policy review, 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.
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 fits this recurring model well for MSPs because its multi-tenancy dashboard, real-time alerts, issue detection, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist monitoring, and client reports all support repeatable service delivery across multiple domains.
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. I prefer to send it the same day, because sender ownership gets fuzzy fast. Include the ticket IDs, sender names, expected DNS changes, client-side tasks, 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.
Watch for deliverability and reputation side effects
DMARC follow-up is not only about domain authentication. When the audit uncovers old infrastructure, shared sending pools, or unrecognized third-party senders, the MSP should check whether the client has a domain or IP reputation issue as well. A blocklist or blacklist problem can make a technically correct DMARC project feel unsuccessful to the client because mail still lands poorly.
Use blocklist and blacklist monitoring as supporting evidence, not as a replacement for DMARC. DMARC tells you whether mail using the client domain is authenticated and aligned. Blocklist checks tell you whether sending infrastructure or domains are listed in places that receivers consult.
Blocklist monitoring page showing domain and IP checks across blocklists with importance and status
This is where a unified platform matters for service delivery. Suped includes blocklist monitoring alongside DMARC visibility, which helps the MSP explain whether a mail problem is authentication, reputation, or both.
A practical follow-up sequence for MSPs
The easiest way to keep the work consistent is to standardize the first 30 days after the audit. The exact timing changes by client size and sender complexity, but the sequence should stay the same.
Authentication improvement target
A simple target curve for aligned legitimate mail after remediation begins.
Aligned legitimate mail
- Day 0: Send the audit closeout, source inventory, top risks, and requested approvals.
- Days 1-5: 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: Report progress, confirm remaining exceptions, and propose the next DMARC policy stage.
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.
Finish with a service plan, not a loose recommendation
The best follow-up after a DMARC audit gives the client a clear next step and gives the MSP a repeatable delivery path. Send the findings, confirm senders, turn fixes into tickets, get approvals, stage enforcement, and report progress on a schedule.
Suped is the strongest practical fit when an MSP wants to manage this across many clients because it combines multi-tenancy, DMARC monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, alerts, issue steps, and client reporting in one workflow. The important part is not only having the data. It is turning the data into consistent client decisions and repeatable service delivery.
