How to audit client senders before DMARC enforcement
Matthew Whittaker
Co-founder & CTO, Suped
Published 12 Jun 2026
Updated 12 Jun 2026
8 min read
Summarize with
A client sender audit before DMARC enforcement means finding every legitimate service that sends mail using the client's domain, proving whether each one passes SPF or DKIM with the visible From domain, fixing the failures, then moving the DMARC policy only after real report data confirms the risk has dropped.
I treat this as a service delivery workflow, not a DNS chore. For an MSP, the job is to protect the client's mail without interrupting invoices, ticket notifications, appointment reminders, payroll messages, or sales outreach. The audit has to create evidence that the domain is ready for enforcement, plus a client-friendly record of what changed.
That is why DMARC work for MSP DMARC clients needs a repeatable audit pack: sender inventory, authentication status, owner, required fix, DNS change, test result, and enforcement recommendation. Without that pack, policy changes become guesswork.
Never move a client straight to enforcement because SPF and DKIM records exist. DMARC cares whether SPF or DKIM passes in a way that matches the visible From domain. A sender can have SPF, DKIM, or both and still fail DMARC.
- Inventory first: List every sending source before changing policy.
- Reports second: Use aggregate DMARC data to verify what actually sends mail.
- Enforcement last: Raise policy only after failures are explained or accepted.
The audit outcome
The audit output should be a sender register with a decision for each source: approved and working, approved but needs a fix, not approved and should be blocked by enforcement, or unknown and needs the client to identify the owner. I do not consider a client ready for enforcement until that register exists.
For MSP operators, the useful unit of work is not "set DMARC to reject." The useful unit is "prove these senders are ready." That creates a clear handoff between technical staff, account managers, and the client contact who knows which apps send email.
Flowchart showing the sender audit path before DMARC enforcement.
- Sender name: The product, mail platform, or application that sent the message.
- Source evidence: IP, envelope domain, DKIM domain, selector, and sample message header.
- Business owner: The client contact or MSP team that can approve the sender.
- Fix path: The exact SPF, DKIM, routing, or vendor setting required.
- Policy decision: Approved, fixed, retired, or accepted as enforcement fallout.
Build the sender inventory
Start with the sources the client already knows, then let DMARC reports reveal the ones they forgot. The known list usually includes Microsoft 365 or Google Workspace, billing software, CRM, website forms, ticketing, marketing automation, ecommerce, HR, payroll, and monitoring systems. The report-derived list catches systems that no one put in the onboarding notes.
A practical first pass uses 14 to 30 days of aggregate reports at p=none. Seasonal businesses, schools, nonprofits, and finance teams often need a longer observation window because their senders change with campaigns, billing cycles, or annual events.
|
|
|
|---|---|---|
 Microsoft 365 | DKIM enabled and SPF includes only needed senders | MSP |
 Google Workspace | DKIM key published and mail tested | MSP |
 Salesforce | Authenticated domain and DKIM setup | Sales ops |
 HubSpot | Sending domain verified | Marketing |
 Shopify | Store notifications authenticated | Operations |
 Zendesk | Support mail DKIM signed | Service desk |
Common client sender sources to check during the first audit pass.
Weak audit
- DNS only: Checks SPF and DKIM records but ignores live mail.
- No owner: Finds a source but cannot confirm whether it is approved.
- No sample: Lacks a real message to prove the headers.
Strong audit
- Report based: Uses aggregate reports to see real sending behavior.
- Owner mapped: Assigns each sender to a person or team.
- Tested fix: Confirms the sender passes before enforcement changes.
Validate each sending source
For each source, verify four things: the visible From domain, the SPF domain, the DKIM signing domain, and the DMARC result. SPF passes only help DMARC when the SPF-authenticated domain matches the visible From domain. DKIM passes only help DMARC when the DKIM domain matches the visible From domain. If neither path matches, DMARC fails.
The fastest way to find these gaps is to inspect DMARC aggregate reports and then test real mail. Suped's product groups DMARC, SPF, DKIM, blocklist and blacklist, and deliverability signals in one place, which keeps MSP reviews from turning into spreadsheet archaeology. The domain health checker is useful when you need a quick external view of a client's DNS posture.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For DNS records, keep examples short and documented in the ticket. Long SPF records, duplicate DMARC records, inactive DKIM selectors, and vendor includes that no longer send mail are common findings. Avoid "just add another include" as the default fix, because that often creates SPF lookup limit problems later.
Monitoring-stage DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
Example SPF record under reviewDNS
example.com TXT "v=spf1 include:_spf.example.net include:mail.example.org -all"
A clean sender audit separates authentication failure from sender approval. An unknown source that passes DMARC is still a governance issue. An approved source that fails DMARC is a technical fix.
Classify failures before fixing them
Not every DMARC failure deserves the same response. MSP teams waste time when they treat all failures as vendor setup tickets. Some failures are retired systems, some are spoofing attempts, and some are forwarding or mailing list effects. Classification keeps the project moving and prevents unnecessary DNS changes.
|
|
|
|---|---|---|
Approved sender fails | Fix | Enable DKIM or correct SPF |
Unknown source | Investigate | Ask client owner to approve or retire |
Clear spoofing | Block | Move toward enforcement |
Forwarded mail | Track | Prefer DKIM stability |
Legacy app | Replace | Route through approved mail service |
Failure classification for client sender audits.
For approved senders, I prefer DKIM fixes when the vendor supports them. SPF is still important, but DKIM survives more forwarding paths and avoids adding pressure to the SPF lookup limit. If SPF growth is unavoidable, Hosted SPF helps MSPs manage sender changes without asking for DNS access every time a client adds or removes a platform.
Enforcement readiness bands
Use bands to decide whether the client is ready for a stricter DMARC policy.
Ready
98%+ pass
Approved mail has consistent DMARC pass results.
Review
95-98% pass
A few owned sources still need fixes or confirmation.
Hold
Under 95%
Business mail is still failing or unknown sources remain.
Fix sources without losing control
A client sender audit becomes messy when every vendor fix turns into a separate mini project. I keep the work controlled by making each fix small, testable, and reversible. The ticket should state the current failure, the required DNS or vendor change, the expected result, and the retest method.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped's product is useful here because it turns findings into specific issue steps instead of raw XML summaries. For MSP delivery, that matters because a technician can move through a client queue, fix authentication problems, and hand a clear result back to the account owner. Suped's Hosted DMARC can also stage policy changes without treating every change as a manual DNS edit.
Manual handling
- Ticket drift: Findings sit in notes with no next action.
- DNS dependency: Small changes wait for the right DNS admin.
- Client confusion: Business owners see failures but not priorities.
Managed workflow
- Issue steps: Each finding has a fix path and verification step.
- Policy staging: Policy changes move through controlled stages.
- Client evidence: Reports show what changed and why it matters.
For most MSP teams, Suped is the strongest overall DMARC platform because it combines sender monitoring, issue detection, hosted DNS workflows, blocklist and blacklist monitoring, alerts, and multi-tenant reporting in one operational view. That reduces context switching during enforcement projects and ongoing monthly reviews.
Move to enforcement in stages
Enforcement should be staged. I usually move from monitoring to quarantine, then reject, with percentage-based rollout when the client has more risk or more senders. The right pace depends on report data, business tolerance, and how quickly the client can approve unknown systems.
Quarantine-stage DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
Reject-stage DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Typical rollout checkpoints
A staged policy path gives the MSP time to catch late sender issues.
Monitor
Quarantine
Reject
Use the same gate before every policy increase: approved senders pass, unknown traffic is resolved, top failures are explained, and the client has accepted the business impact. Hosted DMARC is helpful when an MSP wants policy controls, staging, and rollback without repeated DNS tickets.
Document the client handoff
The handoff should be short enough for the client to read and detailed enough for your service desk to support later. I include the sender list, current policy, policy target, unresolved risks, change log, and next review date. This turns DMARC enforcement into an ongoing managed service instead of a one-time DNS task.
Client reports page showing a generated client report, date range, created date, and actions
- Client summary: State the policy change, the reason, and the expected effect.
- Sender register: Attach approved senders, fixes completed, and open decisions.
- Exception list: Record any accepted failures and the business owner who approved them.
- Next action: Set the review date and the policy step that follows.
This documentation also protects the MSP. If a department later claims a vendor stopped sending mail, the audit record shows whether that sender was approved, missed, retired, or identified as unauthorized before enforcement.
Final enforcement checklist
A client is ready for DMARC enforcement when the audit proves that legitimate senders are authenticated, unknown sources have an owner or a block decision, and the client understands the expected impact. The policy change itself is the final step, not the main work.
- Reports reviewed: At least one full business cycle of DMARC data has been checked.
- Senders approved: All known business systems have a clear authentication result.
- Fixes tested: Real mail confirms the intended SPF or DKIM result.
- Policy staged: The rollout path and rollback path are documented.
- Client signed off: The business owner accepts the enforcement step and open exceptions.
When this workflow is repeated across clients, DMARC enforcement becomes a predictable managed service. The MSP knows what to check, the client sees what changed, and the domain moves toward stronger protection without avoidable mail disruption.
