How to audit client senders before DMARC enforcement
Published 12 Jun 2026
Updated 14 Aug 2026
10 min read
Summarize with
Updated on 14 Aug 2026: We updated this audit workflow for RFC 9989 and stronger domain-scope controls.
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.
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 an MSP DMARC service 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. 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 the technical team and the client contact who knows which apps send email, with the account manager able to follow the decision.
MSP sender audit flowchart: collect reports, identify sources, confirm owners, fix authentication, retest mail, and enforce DMARC.
- 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.
Set domain and subdomain scope
Before inventorying senders, list every registered domain the client controls, each domain or subdomain used in the visible From address, and any default provider domain used for mail. Include parked domains and delegated subdomains even when they do not appear in current aggregate reports.
Document where each DMARC record is published and which parent policy applies. A parent policy covers subdomains unless a subdomain record or the sp and np tags change that result. This prevents an MSP from enforcing the parent domain while overlooking a legitimate subdomain sender or an unused domain that should reject all mail.
|
|
|
|---|---|---|
Organizational domain | User mail and central business systems | Inventory all approved sources |
Sending subdomain | Visible From use, authentication, and inherited policy | Audit and stage separately when needed |
Parked domain | No legitimate mail or active sender | Publish p=reject |
Non-existent subdomains | Whether the parent policy or np tag applies | Use np=reject when no valid use exists |
Domain scope decisions to record before sender remediation.
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.
If the rua address uses a different organizational domain, verify the required external reporting authorization in DNS before assuming collection works. Not every receiver sends aggregate reports, so treat the reported counts as observed coverage rather than a complete measure of all client mail.
|
|
|
|---|---|---|
 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 the visible From domain, the SPF-authenticated MAIL FROM domain, the DKIM signing domain, and the DMARC result. Under the default relaxed mode, an authenticated domain meets alignment when it shares the same organizational domain as the visible From domain. Strict alignment requires an exact domain match. DMARC passes when at least one SPF or DKIM result passes alignment, and it fails when neither does.
The fastest way to find these gaps is to inspect DMARC aggregate reports and then test real mail. In the Authentication-Results header, compare header.from with smtp.mailfrom for SPF and header.d for DKIM, then confirm the recorded dmarc result. 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 SPF allows no more than 10 terms that trigger DNS queries during evaluation.
Monitoring-stage DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
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. Failures can come from retired systems, spoofing attempts, forwarding, mailing list effects, or legacy apps. 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, 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 gates
Use evidence gates instead of a universal pass-rate cutoff, because a small amount of critical business mail can outweigh the aggregate percentage.
Ready
No unexplained failures
Approved mail has consistent DMARC passes across the observation window.
Review
Owned work remains
Known sources still have assigned fixes or owner decisions in progress.
Hold
Delivery risk remains
Business mail is failing or unknown sources remain unresolved.
Fix sources without losing control
A client sender audit becomes messy when every vendor fix turns into a separate mini project. Keep each fix small and reversible, with a clear test. 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 MSP teams, Suped's product keeps sender monitoring, issue detection, hosted DNS workflows, blocklist and blacklist monitoring, alerts, and multi-tenant reporting in one operational view. Use that view to assign failed sources, track fixes, stage enforcement, and prepare client reports.
Move to enforcement in stages
Enforcement should be staged. Move the scoped domains through monitoring, quarantine, then reject, starting with lower-volume domains or subdomains before the most complex parent domain. The right pace depends on report data, business tolerance, and how quickly the client can approve unknown systems.
RFC 9989 makes the pct tag historic, so do not use partial-message percentages as an enforcement control. For a policy test, t=y requests treatment one level below the published policy: quarantine is treated as monitoring, and reject is treated as quarantine. Do not rely on t=y as a universal safety switch because receivers using older DMARC behavior ignore unknown tags. Receiver handling also depends on local policy.
Quarantine-stage DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
Reject-stage DMARC recordDNS
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
Scoped-domain rollout checkpoints
This example shows the share of audited domains or subdomains at each policy, not pct-based sampling of messages.
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 staged policy control 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. 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.
