How MSPs can use DMARC audits to win new clients
Updated on 14 Aug 2026: We updated this guide for RFC 9989 and safer, repeatable MSP audit delivery.
DMARC audits help MSPs win new clients by proving a specific email security gap before the sales conversation gets abstract. The audit should show which domains are exposed, which senders are legitimate, which services fail authentication or identifier alignment, and what it will take to move the domain toward an appropriate policy without breaking mail.
The audit works as a service entry point, not a scare tactic. It gives an MSP a reason to talk about identity, mail flow, DNS ownership, and client risk in terms the business owner can understand. The client sees a real finding, then a clear plan.
- Best prospect: A business using Microsoft 365, Google Workspace, a CRM, a billing system, and a marketing sender with no central owner for email authentication.
- Strongest finding: A domain at p=none with unknown senders passing through customer-facing mail streams.
- Saleable outcome: A managed plan that fixes authentication, monitors new sender drift, and stages DMARC enforcement over time.
- Retention angle: The audit becomes a recurring control because new SaaS senders, DNS changes, forwarding paths, and blacklist or blocklist events keep appearing after onboarding.
Why DMARC audits work for MSP prospecting
A good DMARC audit turns a vague security pitch into evidence. Instead of telling a prospect that email authentication matters, show them the exact domain, sender, policy, failure mode, and business impact. That changes the conversation from "do you need another security service" to "who is responsible for fixing this domain".
For MSP teams, the commercial value is simple: DMARC touches DNS, mail routing, sender inventory, user trust, compliance pressure, and executive risk. Those are areas where clients already expect MSP ownership, but many clients have no useful visibility into them.
The audit should lead with evidence
Do not open with DMARC theory. Open with the client domain, its current policy, the authenticated sources you can identify, the sources you cannot verify, and the highest-risk gap. Theory supports the recommendation after the client understands the finding.
- Proof: Show the actual DNS state, message authentication results, and identifier alignment.
- Impact: State the handling requested by the domain policy and note that receivers make the final disposition decision.
- Plan: Give the first DNS change, the first sender cleanup task, and the enforcement path.
- Ownership: Name who needs access to DNS, the mailbox platform, and third-party senders.
Suped's product is relevant at this stage because the MSP workflow is multi-client by default. It brings prospecting reports, client reports, issue detection, SPF and DKIM checks, hosted authentication controls, and blocklist or blacklist monitoring into one operator view across many domains.
What to include in a useful DMARC audit
The audit should be narrow enough for a prospect to read in minutes, but complete enough to justify paid remediation. A concise audit includes the current DMARC record, SPF status, DKIM coverage, identifier alignment, visible sending sources, policy level, reporting setup, subdomain handling, and any blocklist or blacklist signals that affect trust.
Core checks in an MSP DMARC audit report
|
|
|
|---|---|---|
No DMARC | No published policy | Start monitoring |
No rua | No aggregate visibility requested | Add reporting |
SPF or DKIM passes but misaligns | DMARC can still fail | Configure an aligned identifier |
DKIM gap | No aligned signature | Enable and validate DKIM |
At p=none | No enforcement requested by the domain | Review reports and choose policy |
Blacklist or blocklist hit | Reputation signal | Investigate the source |
Compact audit findings and the sales action each one supports.
Keep the report practical. A prospect does not need every XML detail. They need to know whether their main domain lacks a meaningful policy, whether legitimate mail is ready for enforcement, which indirect flows could be affected, and whether the MSP has a controlled way to fix it.
Run the audit in a repeatable workflow
A repeatable workflow matters because DMARC audits become inefficient when every engineer collects evidence differently. Use public DNS for a passive pre-sales check, then obtain written authorization before sending tests, changing DNS, or collecting the prospect's report data. Apply the same technical sequence for authorized audits: identify domains, inspect DNS, validate live authentication, classify senders, and write remediation steps in plain language.
- Scope domains: Start with the root domain, then include customer-facing subdomains, sending subdomains, and parked domains that can be abused.
- Inspect DNS: Check DMARC, SPF, known DKIM selectors, MX, MTA-STS, TLS reporting, and SPF lookup pressure.
- Send authorized tests: Test the main mailbox platform, shared or delegated sending, devices and relays, and key SaaS senders so headers confirm what DNS claims.
- Map senders: Separate verified sources, unknown sources, forwarding noise, and systems that need DKIM enabled.
- Write fixes: Turn each issue into the exact owner, DNS change, sender setting, and validation step.
For a fast first pass, use Suped's domain health checker to collect the obvious public DNS findings before an authorized traffic review. That helps the sales team avoid vague outreach and gives the technical team a clean starting point.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
The first DNS check should never be the final service. It is the door opener. The recurring value comes from tracking actual mail sources over time and catching changes when the client adds a new platform, changes DNS, or lets a sender operate without aligned DKIM.
MSP DMARC audit workflow from domain scoping to client report
Update the audit method for RFC 9989
RFC 9989 replaced RFC 7489 in May 2026, while RFC 9990 and RFC 9991 now define aggregate and failure reporting. An MSP audit should flag records and rollout plans that depend on removed tags or older policy assumptions.
- Remove pct assumptions: RFC 9989 removed the pct tag because receivers applied percentage values inconsistently. Do not promise percentage-based enforcement.
- Review test mode carefully: The new t=y tag asks a receiver to test the stated policy by applying handling one level lower. Older implementations can ignore the unknown tag and apply the stated policy, so t=y is not a universal safety switch.
- Audit policy discovery: Check sp for existing subdomains, np for non-existent domains, psd where relevant, and the DNS Tree Walk that determines the applicable policy.
- Separate report checks: Validate aggregate reporting against RFC 9990 and treat failure reporting under RFC 9991 as optional receiver behavior with privacy implications.
- Choose policy by domain use: Test indirect flows before p=reject on domains used by people. A non-sending domain can use a stricter policy after the MSP verifies that it sends no legitimate mail.
Do not sell p=reject as a universal finish line
RFC 9989 says domains used by people who might post to internet mailing lists should not publish p=reject because indirect flows can fail DMARC after forwarding or message modification. Compare aggregate report results under p=none and p=quarantine, test business-critical indirect paths, and document the client's policy decision.
This standards check is also a useful sales finding. It shows whether the prospect has a current DMARC operating plan, not merely a TXT record that passed a syntax check.
Show the client the gap and the fix
The sales report should connect every finding to an action. If the prospect has no DMARC record, show the starting record. If they use p=none with a rua address, explain that p=none does not ask receivers to alter handling and the rua tag separately requests aggregate reports. If SPF exceeds lookup limits, identify the mechanisms causing pressure and decide which senders need a safer authentication path.
Starter DMARC record for monitoringDNS
Host: _dmarc Type: TXT Value: "v=DMARC1; p=none; rua=mailto:dmarc@yourmsp.com"
That record is not the end state. Replace the example address with a monitored destination. When the rua address uses a different organizational domain, confirm that the report consumer has published the external reporting authorization record required by RFC 9990. The MSP then reviews aggregate reports, confirms legitimate senders, enables aligned DKIM where missing, cleans SPF, tests indirect mail flows, and selects an enforcement policy when the evidence supports it.
Weak audit presentation
- Generic risk: Talks about spoofing without showing the client's domain status.
- No ownership: Lists problems without naming who must change DNS or sender settings.
- No staging: Pushes enforcement before the mail source inventory is trusted.
- No follow-up: Ends with a report instead of a managed service.
Strong audit presentation
- Specific proof: Shows the client domain, policy, source, and authentication result.
- Clear owner: Maps each fix to DNS, mailbox admin, SaaS admin, or MSP action.
- Controlled rollout: Moves through monitoring and enforcement after report review and indirect-flow testing.
- Managed outcome: Turns the audit into monitoring, alerts, reporting, and sender governance.
Create prospecting report dialog with MSP logo, prospect name, domains, prospect logo, and language fields
Turn the audit into managed service delivery
Once the client signs, the MSP needs a delivery model that can be repeated without senior engineers rewriting every plan. The core service is DMARC monitoring, sender cleanup, policy staging, and client reporting. That work becomes stronger when the platform turns raw authentication data into issues and recommended fixes.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product supports this delivery model with multi-tenant client management, automated issue detection, real-time alerts, branded client reports, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist or blacklist monitoring, and plain remediation steps.
At portfolio scale, bulk-import the client-domain register where possible and route authentication regressions into the existing service-desk queue. Each ticket should record severity, affected domain, changed record or sender, owner, and validation step. Keep tenant data separated and grant client users only the access they need.
Policy rollout stages
Use report data and indirect-flow testing to choose a policy without relying on the removed pct tag.
Monitor
p=none
Collect aggregate data and map legitimate senders.
Cautious enforcement
p=quarantine
Request quarantine after aligned senders and indirect flows have been tested.
Domain-specific decision
p=quarantine or p=reject
Choose the final policy according to how the domain is used and the effect on legitimate mail.
Hosted SPF is useful for MSP delivery because it reduces the number of times an engineer needs direct DNS access just to add or remove senders. Suped's Hosted SPF lets the MSP manage sender changes centrally and helps keep SPF under lookup limits.
SPF handoff patternDNS
Host: @ Type: TXT Value: "v=spf1 include:spf.yourmsp.example -all"
Package the audit without making it a one-off project
The easiest mistake is selling the audit as a fixed report and stopping there. DMARC needs ongoing management because clients add senders, vendors change infrastructure, DNS records drift, and inbox providers keep evaluating reputation. The audit should create a managed service path on day one.
- Initial audit: Review DNS, authenticate test mail with authorization, identify source risk, and prepare the client report.
- Remediation project: Fix SPF, enable aligned DKIM, add reporting, remove unused senders, and document DNS ownership.
- Managed monitoring: Review DMARC reports, respond to alerts, approve new senders, and report progress.
- Reputation checks: Monitor blocklist and blacklist events so the team catches domain or IP reputation issues early.
- Governance rhythm: Review sending source changes during quarterly business reviews or security review meetings.
Add blocklist monitoring when the client relies on email for invoices, quotes, alerts, or booked appointments. DMARC will not remove every blacklist risk, but it gives the MSP a better view of who is sending and whether the domain is being abused.
Do not promise instant enforcement
Moving straight to quarantine or reject can disrupt legitimate mail when the client has undocumented senders or indirect flows. Sell enforcement as a controlled rollout with evidence gates, not as a single DNS edit.
- Gate one: All primary mailbox traffic passes SPF or DKIM with domains aligned to the visible From domain.
- Gate two: Major SaaS senders have aligned DKIM enabled and documented ownership.
- Gate three: Unknown sources are explained, retired, or confirmed as unauthorized.
- Gate four: Forwarding, mailing lists, and other indirect flows have been tested and the client understands how new sender approval will work.
Client reports page showing a generated client report, date range, created date, and actions
Make the audit a proof of work
A DMARC audit wins new clients when it proves risk, shows the fix, and gives the buyer a low-friction path into managed work. The audit should not be a long technical dump. It should be a focused report that says what is wrong, why it matters, and what the MSP will do next.
A practical MSP process audits the domain, shows the evidence, remediates authentication, selects policy with report data, and monitors changes. Suped's product supports that process with multi-tenant management, prospecting reports, client reporting, hosted authentication controls, alerting, and blocklist or blacklist visibility.
- Lead with proof: Use the client's own public domain data to make the initial risk concrete.
- Sell the path: Turn authorized findings into onboarding, remediation, monitoring, and reporting.
- Keep ownership clear: Name the DNS, mailbox, SaaS, and MSP actions needed to finish the work.
- Review continuously: Use ongoing reports, regression alerts, and service-desk tickets to catch sender drift after the first project.
