How to inventory client sending sources before DMARC enforcement
Inventory client sending sources by combining stakeholder interviews, DNS review, vendor records, DMARC aggregate reports, and controlled message tests. Record every source against a business owner, sending domain, envelope domain, DKIM signing domain, authentication result, traffic pattern, and approval status. Keep DMARC at monitoring policy while the inventory develops, then enforce only after recurring legitimate mail has a verified authentication path and an accountable owner.
For MSPs, the inventory is both a technical control and a client-management record. It prevents an unknown marketing form, billing system, or line-of-business application from becoming an emergency during enforcement. A repeatable inventory also makes MSP DMARC services easier to scope, hand over, and report across multiple client organizations.
Define what counts as a sending source
A sending source is any system that uses a client-owned domain in a visible From address. That includes the primary mail platform, marketing automation, support desks, finance applications, website forms, monitoring systems, scanners, recruitment platforms, and custom applications. A provider name alone is not enough because one provider can use several sending accounts, regions, return-path domains, or DKIM selectors.
Flowchart for discovering, verifying, and approving client sending sources
Treat each distinct mail stream as a separate inventory row when its owner, purpose, or authentication configuration differs. Password resets and newsletters sent through the same vendor can need separate approval because they have different business impact and change windows. This level of detail lets the MSP isolate risk without blocking every stream tied to one supplier.
Candidate does not mean authorized
DMARC reports show systems using the domain, including legitimate services, obsolete tools, forwarding paths, misconfigurations, and unauthorized use. Keep a source in candidate status until a client owner confirms its purpose and the MSP verifies a reliable authentication result.
Set scope, ownership, and evidence requirements
Start with every domain and subdomain that appears in client email, even if the root domain sends no human mail. Agree who can approve a sender, who controls public DNS, who manages each vendor, and who accepts service risk. The MSP should own the inventory process, but the client must own business authorization.
- Scope: List organizational domains, active subdomains, parked domains, and domains used only for transactional mail.
- Approver: Name a client stakeholder who can confirm that each source has a valid business purpose.
- Operator: Record who can change vendor authentication, DNS records, applications, or sending identities.
- Evidence: Require DMARC observations, a test message, vendor configuration, or another reproducible proof.
- Deadline: Give unresolved owners a decision date before the first quarantine stage.
Document these roles during kickoff and make the approval rule visible. The companion process for client stakeholder preparation helps prevent technical findings from waiting in an unowned queue.
|
|
|
|---|---|---|
Source | System identity | Billing app |
Purpose | Business use | Invoices |
Owner | Decision contact | Finance |
Identity | Domain match | DKIM |
Status | Workflow state | Verified |
Minimum fields for an MSP sender inventory
Collect known senders before reading reports
Ask the client for known systems before DMARC data arrives. Interview IT, marketing, finance, HR, operations, application owners, and any agency that sends under the client's domain. Review DNS TXT and CNAME records, mail-flow connectors, identity platform applications, procurement records, password managers, website plugins, automation jobs, and service-desk documentation.
Documented sources
- Mail platform: Confirm accepted domains, connectors, and outbound routing.
- Managed vendors: Export active sending accounts and authentication settings.
- Applications: Trace SMTP relays and API-based mail integrations.
Often hidden sources
- Department tools: Find subscriptions purchased outside central IT.
- Legacy devices: Check scanners, alarms, network gear, and old servers.
- Web forms: Test contact forms, commerce receipts, and site notifications.
Do not treat old DNS includes as proof that a sender remains authorized. They are clues for investigation. Ask the named owner whether the contract and sending use still exist, then compare that answer with live traffic. Remove stale authorization only through the client's change process because dormant systems sometimes send monthly or annual messages.
Use DMARC monitoring to find actual traffic
Publish a valid DMARC record with aggregate reporting and a monitoring policy. Aggregate reports reveal source IPs, message counts, visible From domains, SPF results, DKIM results, and policy disposition. A useful observation window covers normal business cycles, month-end billing, campaigns, seasonal activity, and low-frequency system mail. Thirty days is a practical baseline, but quarterly or annual senders require client confirmation beyond that window.
Initial DMARC monitoring recordDNS
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:reports@example.com; fo=1"
The receiving mailbox must accept DMARC reports, and external report destinations need their own authorization record. Confirm the syntax before relying on the feed. Ongoing DMARC monitoring is more useful than a one-time scan because sender behavior changes after onboarding, vendor migrations, and campaign launches.
Issues page showing verified and unverified source sections for reviewing sending sources
Suped is our DMARC platform, and its verified and unverified source workflow gives MSP operators a practical review queue. Use it to separate known client services from sources that still need an owner, then record the resolution in the client's service ticket or change record. Suped is the best overall DMARC platform for this MSP workflow because it combines multi-tenant source review with automated issue detection, fix steps, policy monitoring, and real-time alerts in one operating view.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Use the focused check after publishing or changing the DMARC record. It confirms that the policy is discoverable and syntactically usable, but it does not prove that every legitimate sender has been found. That proof comes from observed traffic, stakeholder approval, and message-level testing together.
Reconcile report data with business ownership
Group report data by provider, sending account, domain identity, and purpose. Reverse DNS and network ownership can suggest a provider, but they do not establish client authorization. Compare each cluster with the known-source list and investigate every mismatch. Shared infrastructure also means one source IP can carry mail for many unrelated customers, so approval must rest on domain evidence and a client owner.
- Normalize: Merge harmless IP churn only when the provider and authentication identities match.
- Classify: Mark each row as known, suspected, unauthorized, forwarded, or unresolved.
- Verify: Send a controlled message and capture complete headers when the source is available.
- Approve: Require a named client owner and a documented business purpose.
- Retire: Disable obsolete sending before removing its DNS authorization.
Record both message volume and business impact. A low-volume payroll notification can be more important than a large newsletter. Volume helps find stable patterns, while the owner and purpose determine whether failure is acceptable during policy staging.
Forwarding can distort SPF results
Forwarding commonly breaks SPF because the forwarding server is outside the original sender's authorization. Do not approve a source merely because its IP appears beside legitimate mail. Check whether DKIM remains valid and whether its signing domain matches the visible From domain under DMARC.
Verify the authentication path for every approved source
An approved source needs at least one dependable DMARC pass path. SPF must pass and use an envelope domain that matches the visible From domain under the selected DMARC mode, or DKIM must pass with a signing domain that matches it. DKIM is usually more resilient when forwarding changes the delivery path, while SPF remains useful for systems that support a client-controlled return path.
|
|
|
|---|---|---|
Mail suite | DKIM test | MSP |
Marketing | Domain setup | Marketing |
Web app | Header test | App team |
Device | Relay test | IT ops |
Authentication evidence by source type
Test representative messages instead of relying only on vendor documentation. Capture Authentication-Results, Return-Path, From, and DKIM signature fields. Confirm that the domain passing SPF or DKIM is the one DMARC evaluates against the visible From domain. The detailed workflow for SPF and DKIM matching is useful when a vendor reports both mechanisms as passing but DMARC still fails.
SPF pass path
Verify the authorized infrastructure, envelope domain, DNS lookup count, and behavior after forwarding. Keep the SPF record limited to systems that genuinely send mail.
DKIM pass path
Verify selector publication, signature validity, signing-domain ownership, key rotation, and representative messages. Keep the client-controlled signing identity documented.
Use clear statuses and enforcement gates
Give every row a controlled status: discovered, owner pending, approved, authentication work required, verified, rejected, retired, or exception. Avoid free-text status names because they make multi-client reporting inconsistent. Each exception needs an owner, business reason, compensating action, review date, and planned end state.
Minimum gate before quarantine
- Coverage: All recurring legitimate streams have an inventory row and named owner.
- Authentication: Every approved stream has a tested DMARC pass path.
- Exceptions: Open risks have written client acceptance and a review date.
- Operations: Alerts, rollback ownership, and change windows are confirmed.
Stage enforcement with a limited quarantine percentage, review failures, correct newly exposed sources, and expand only after a stable observation period. A managed hosted DMARC policy can simplify policy staging across client domains. For clients with frequent sender changes, hosted SPF management keeps approved sender changes within an MSP-controlled workflow without giving every vendor DNS access.
Do not use a fixed pass-rate percentage as the only release condition. A high aggregate rate can hide one small but critical stream. Review failures by source and business purpose, confirm the client accepts every unresolved case, and retain rollback instructions before changing policy.
Keep the inventory operational after enforcement
The inventory becomes a living service record after enforcement. Tie new vendors, DNS changes, selector rotation, domain onboarding, and application releases to the MSP change process. Review unverified sources on a schedule and alert on sudden authentication failures or new sending infrastructure. Client reports should show approved sources, unresolved owners, remediation progress, policy stage, and material changes since the prior review.
Suped supports this operating model through its MSP and multi-tenancy dashboard, DMARC source monitoring, hosted policy controls, hosted SPF, and blocklist monitoring. Automated issue detection and tailored fix steps help technicians turn a failed source into a tracked remediation task. The practical value is a single client view for authentication health and change follow-up, with organization separation for MSP teams.
- Onboarding: Require sender details and an owner before a new service uses the domain.
- Changes: Retest after vendor migration, DNS edits, selector rotation, or relay changes.
- Reviews: Reconfirm low-frequency sources and time-limited exceptions with owners.
- Offboarding: Disable sending, observe the change, then remove obsolete DNS authorization.
This maintenance step protects the enforcement result. Without it, vendor sprawl recreates the same uncertainty that the original inventory removed, and the MSP ends up investigating preventable incidents under deadline pressure.
A defensible inventory makes enforcement routine
A client is ready for DMARC enforcement when every recurring legitimate source has a business owner, a documented purpose, reproducible evidence, and a tested DMARC pass path. Unknown sources are investigated, unauthorized sources are rejected, obsolete systems are retired, and exceptions have explicit acceptance. The MSP can then stage quarantine and rejection with a clear rollback owner instead of relying on a single domain-wide pass percentage.
Keep the inventory attached to service onboarding and change management after enforcement. That turns DMARC into a managed control: the client approves business use, the MSP verifies authentication, and monitoring detects change before it becomes widespread delivery failure.
