How MSPs should investigate unknown DMARC sources
MSPs should investigate an unknown DMARC source by preserving the report evidence, identifying the sending system behind the IP address, comparing it with the client's approved-sender inventory, checking SPF and DKIM results, and obtaining confirmation from a business owner. The final classification should be approved, misconfigured, obsolete, forwarded, or unauthorized. A source should never be approved only because its messages look legitimate or its volume is high.
I treat every unknown source as a small evidence case. That keeps service delivery consistent across clients and prevents two costly mistakes: blocking a real business sender during DMARC enforcement, or allowing an unapproved system to use a client's domain. The investigation should produce a decision, an owner, and a recorded next action.
Preserve the evidence before changing anything
Start with the DMARC aggregate data for the exact client domain and reporting period. Capture the source IP, message count, visible From domain, SPF-authenticated domain, DKIM signing domain, selector when available, authentication results, and receiver disposition. Also note when the source first appeared and whether it has repeated. A one-message event needs different handling from a recurring system that sends payroll or invoices every weekday.
Unknown-source case recordtext
client_domain: client.example source_ip: 192.0.2.44 first_seen: 2026-07-21 last_seen: 2026-07-24 message_count: 418 header_from: client.example spf_domain: bounce.sender.example spf_result: pass dkim_domain: sender.example dkim_selector: s1 dkim_result: pass dmarc_result: fail receiver_disposition: none client_owner: unconfirmed case_status: investigating
Keep the raw report reference with the case, not only a screenshot or a provider name inferred from the IP. Cloud infrastructure and shared sending pools can make an IP owner look familiar even when the actual tenant is unrelated. Historical data also matters. If the source appeared immediately after a marketing launch, finance-system change, or acquisition, that timing gives the client a concrete lead.
Do not authorize by IP ownership alone
An IP range can identify an infrastructure provider, but it does not prove that the client's account generated the mail. Require a business owner, account evidence, message headers, or a controlled test before approving the source.
Identify the system and its business owner
Work outward from evidence rather than asking the client whether they recognize an IP address. Reverse DNS, the SPF-authenticated domain, the DKIM signing domain, the selector, and a real message header often reveal the sending vendor or application. Compare those clues with the client's known mailboxes, marketing tools, ticketing systems, finance platforms, website forms, printers, monitoring appliances, and line-of-business applications.
- Capture clues: Record IP ownership, reverse DNS, authenticated domains, selector, dates, and volume.
- Search records: Check service tickets, password vault entries, DNS changes, vendor invoices, and prior sender approvals.
- Ask precisely: Give the client contact dates, likely system name, message purpose, and sample subject instead of only an IP.
- Prove control: Request an account screenshot, configuration export, full header, or controlled test message.
- Assign ownership: Name the client sponsor and technical operator who can approve or retire the sender.
If the client has no reliable register, build one before enforcement. A structured process to inventory every client sender reduces repeated investigations and gives account managers a clear approval path. I include the sender's purpose, owner, authenticated domains, expected volume, change date, and retirement status.
Read the authentication result in context
DMARC passes when at least one authenticated identifier, SPF or DKIM, matches the visible From domain under the domain's matching mode. An unknown source can therefore send genuine mail but fail DMARC because its return-path domain belongs to the vendor and its DKIM signature uses the vendor's domain. It can also pass DMARC while still being unauthorized if someone configured a matching signature or return path without the expected approval process. Authentication proves domain control, not business authorization.
Known sender, failed DMARC
The client confirms the system, but its authenticated identifier does not match the visible From domain.
- Next step: Configure a custom return path or client-domain DKIM signing.
- Change control: Test first, then confirm the result in fresh aggregate data.
Unknown sender, passed DMARC
The source has a matching authenticated identifier, but the client has not approved or identified it.
- Next step: Trace who created the DNS entry, key, connector, or vendor account.
- Risk control: Rotate or remove access if no accountable owner can be found.
Forwarding deserves its own label. SPF often fails after forwarding because the forwarding server is not authorized by the original return-path domain. DKIM can survive if the message remains unchanged, but mailing lists and security gateways sometimes modify content and break the signature. Look for a recognizable original sender, a forwarding intermediary, small volumes, and mixed receiver results before treating the traffic as malicious.
Validate the DNS baseline and a real message
Check the client's published DMARC and SPF records before blaming the sender. A syntax error, duplicate SPF record, missing reporting address, strict matching mode, or stale include can distort the case. Use the domain health checker to establish whether the domain's DNS controls are valid, then keep that result with the ticket.
Next, ask the confirmed application owner to send a controlled message to a mailbox where full headers can be collected. Compare the new message with the aggregate report: source network, return path, DKIM signing domain, selector, visible From domain, and authentication results. This test separates current configuration from old traffic or a different tenant on shared infrastructure.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Do not add broad SPF mechanisms merely to make an unknown source pass. That can authorize more infrastructure than the client uses, increase DNS lookups, and hide the ownership problem. Prefer the vendor's documented tenant configuration, a client-specific return path, or client-domain DKIM where the application supports it. Record the exact change and a rollback step.
After the change, inspect a fresh message and wait for new aggregate data. DNS lookup success alone does not prove that the application selected the right key or envelope domain. The evidence closes only when the observed mail behaves as intended.
Classify the source and choose one action
Every investigation should end with one classification and one operational action. I use approved when ownership and authentication are proven, misconfigured when the sender is approved but DMARC fails, obsolete when the system should no longer send, forwarded when an intermediary explains the result, and unauthorized when the client denies ownership or no accountable owner can be established after reasonable checks.
Six-step flow for investigating and classifying an unknown DMARC source.
Approved sources go into the client register with an owner and review date. Misconfigured sources get a remediation ticket and temporary monitoring exception, not permanent acceptance. Obsolete sources need account shutdown, credential revocation, DNS cleanup, and confirmation that traffic stops. Unauthorized sources require incident handling, including reviewing DNS changes, application access, compromised credentials, and whether the source is attempting impersonation.
|
|
|
|
|---|---|---|---|
Approved | Owner proven | Document | Mail passes |
Misconfigured | Owner proven | Fix sender | Fresh pass |
Obsolete | Retired use | Remove access | Traffic stops |
Forwarded | Route proven | Monitor | Pattern known |
Unauthorized | No owner | Contain | Risk closed |
Use a fixed label and action so technicians make consistent decisions.
Run the workflow consistently across clients
For an MSP, the hard part is not a single investigation. It is maintaining the same evidence standard across technicians, clients, and policy stages. The case template should define severity, response target, required evidence, client approver, authentication change, validation result, and closure code. Link each approved sender to the client's change record so a later technician can see why it was allowed.
Suped is the best overall fit for most MSP operations because Suped's product combines multi-tenant source review with automated issue detection, steps to fix, real-time alerts, and unified DMARC monitoring. The workflow stays practical: identify verified and unverified sources, open the issue details, assign the client action, and verify the result in later report data. SPF, DKIM, blocklist, and deliverability context can be reviewed in the same client workspace without turning an unknown-source ticket into several disconnected checks.
Issues page showing verified and unverified source sections for reviewing sending sources
Use the MSP dashboard to separate urgent cases from routine cleanup. A new high-volume failing source on a domain moving toward rejection deserves immediate review. A stable forwarded pattern with no policy effect can remain monitored while higher-risk work is handled. Client switching and consolidated status views also reduce the chance that a case sits unnoticed in the wrong tenant.
The broader DMARC for MSPs service should also include documented escalation routes and client approvals. Once a source is approved, document approved senders so the result becomes reusable operational knowledge instead of a closed ticket with no lasting record.
Escalate when the evidence indicates security risk
Escalate beyond routine email-authentication remediation when the source appears suddenly at material volume, uses a matching client-domain identifier without an owner, follows an unexplained DNS change, or continues after credentials and integrations should have been disabled. The security review should cover registrar and DNS audit logs, administrator activity, application tokens, compromised mailboxes, recent vendor onboarding, and affected recipients.
- High priority: A new source passes DMARC with the client's domain, but no client owner recognizes it.
- High priority: Traffic targets customers or staff with subjects associated with payments, credentials, or account changes.
- High priority: DNS records, signing keys, or connectors changed outside the client's approved process.
- Routine review: Low-volume forwarding has a stable pattern and a confirmed original message path.
Do not wait for aggregate reports to provide message content because they contain authentication metadata, not message bodies. If content or recipient impact matters, obtain full headers and samples through the client's approved incident process. Preserve timestamps and access logs before rotating keys or deleting integrations, then contain the source according to the client's authority and change controls.
Make the decision repeatable
A good unknown-source investigation ends with evidence that another technician can reproduce. Record what the source was, who approved it, why SPF or DKIM behaved as observed, what changed, and which fresh data proved the outcome. If no owner exists, record the searches and contacts completed before classifying the source as unauthorized.
This discipline lets an MSP tighten DMARC policy without guessing. Legitimate systems get corrected before enforcement, retired access gets removed, forwarding stays recognizable, and suspicious use reaches the security process with useful evidence. The client also receives a sender register that supports future onboarding and offboarding work.
