Technical guide
How to Identify Unknown Senders in DMARC Reports
Identify unknown senders in DMARC reports using source, authentication and ownership evidence without mistaking an unfamiliar IP for proof.
Technical guidance only. Confirm changes against the current standards and your providers’ documentation before editing production DNS.
An unfamiliar source IP in a DMARC aggregate report creates a question, not an answer. It may belong to an approved SaaS platform, a legacy application, a forwarding path, a misconfigured legitimate sender or unauthorised use of the domain.
The safe response is to classify the source from several pieces of evidence. This guide provides a repeatable investigation workflow for one domain or an MSP customer portfolio.
If the XML fields are unfamiliar, start with Understanding DMARC Aggregate and Failure Reports. That article explains the report structure; this one focuses on source attribution and the decision that follows.
Evidence available in an aggregate report
Aggregate reports describe what a participating receiver observed during a reporting period. The current aggregate format is defined in RFC 9990, while RFC 9989 defines the DMARC protocol.
No single field identifies the business application that sent a message. Treat the fields as related evidence.
| Signal | What it can tell you | What it does not prove |
|---|---|---|
| Source IP | The address that connected to the reporting receiver | The customer, user or application responsible for the message |
| Message count | The receiver’s aggregate count for that row and period | Total messages sent across all receivers |
| Header From domain | The domain presented in the visible From address | That the sender was authorised to use it |
| SPF authentication domain and result | Which domain was checked for SPF and whether it authenticated | DMARC alignment with the visible From domain |
| DKIM signing domain, selector and result | Which signature the receiver evaluated | Business approval or message safety |
| Policy-evaluated result | Whether aligned SPF or aligned DKIM satisfied DMARC | The receiver’s final delivery action in every case |
| Reporter and date range | Who observed the traffic and when | Current behaviour after a recent configuration change |
The distinction between authentication and alignment matters. A provider can pass SPF using its own return-path domain or pass DKIM using its own signing domain while still failing DMARC for the customer’s visible From domain.
A safe classification model
Avoid labelling every unfamiliar source as shadow IT. Use an investigation status until the source is supported by business and technical evidence.
| Classification | Minimum evidence | Normal next action |
|---|---|---|
| Authorised and aligned | Confirmed service owner plus aligned SPF or DKIM evidence | Document and monitor |
| Authorised but misaligned | Confirmed service owner, but neither SPF nor DKIM aligns | Use the provider’s supported authentication design |
| Intermediary path | Forwarding, mailing-list or gateway evidence | Review ARC, header changes and receiver handling |
| Unknown, under investigation | Report evidence without confirmed ownership | Gather provider, header and business evidence |
| Unauthorised or obsolete | Confirmed lack of approval or confirmed decommissioning | Remove access or authorisation through change control |
This model separates observation from judgement. It also gives an MSP a consistent status vocabulary across customer domains.
The investigation workflow
1. Confirm the report context
Record the policy domain, reporting organisation, report ID and date range. Check whether the report reflects a period before a recent DNS or provider change.
Start with the exact row that raised the question. Preserve its source IP, count, disposition, SPF result, DKIM result and authentication domains.
2. Group related observations
Do not investigate each IP address in isolation. Group rows that share a network owner, reverse-DNS pattern, DKIM signing domain, SPF domain and authentication result.
A provider can send through several addresses. The same address can also support shared infrastructure, so the grouping creates a hypothesis rather than a final attribution.
3. Identify the network operator
Check reverse DNS, IP registration and network ownership. These can narrow the likely provider or hosting network.
Network ownership is not application ownership. An address belonging to a cloud or hosting provider could represent many customers and services.
4. Compare the evidence with the sender inventory
Review the customer’s known mailbox, marketing, CRM, helpdesk, billing, website, monitoring and application services. Include low-frequency and seasonal senders.
A typical South African customer may use Microsoft 365 for staff mail, a marketing platform for campaigns, an accounting service for invoices and a locally hosted website for form notifications. The low-volume website or billing source may appear later than daily staff mail.
Across a managed portfolio, this is where incomplete onboarding records become visible. Compare report evidence with DNS changes, service tickets, customer contacts and offboarding records instead of relying on memory.
5. Inspect authentication and alignment
Use the report’s SPF and DKIM evidence to understand the sending path:
- An aligned DKIM pass shows that the message carried a valid, aligning signature, but the source still needs a confirmed owner.
- An SPF pass for a provider-owned return-path domain does not satisfy DMARC alignment with the customer’s visible From domain.
- A DKIM pass for a provider-owned signing domain can also remain unaligned.
- Repeated failures from a known service usually indicate a configuration or domain-selection problem, not automatic proof of abuse.
For legitimate services, follow the provider’s documented authentication design. The SPF record guide explains SPF authorisation, while the DKIM setup guide for MSPs explains selectors, signing domains and alignment.
6. Confirm the business owner and sending path
Ask a named customer or internal service owner to confirm the application, purpose, visible From domain and expected sending pattern. Where possible, obtain a controlled message sample and inspect its headers.
Match the sample’s return path, DKIM d= domain, selector, sending IP and timestamps to the aggregate evidence. Provider documentation and tenant settings can then confirm whether the observed path is supported.
7. Record the decision
Store the classification, evidence, service owner, reviewer, decision date and next action. Keep uncertainty explicit.
An entry such as unknown, likely hosting provider is safer than a confident application name based only on reverse DNS. Update the label when stronger evidence arrives.
8. Verify the result after a change
Check the public DNS record after an approved change, then review controlled message headers and later aggregate reports. The free DMARC checker can verify point-in-time public DMARC and SPF information, but it does not identify aggregate-report sources.
Allow for the reporting period. A later report can still include traffic observed before the change took effect.
Common investigation patterns
Microsoft 365 or Google Workspace
Recognising a large mailbox provider’s network is only the first step. Confirm that the traffic belongs to the customer’s tenant and that the return-path or DKIM signing domain aligns with the visible From domain.
Unexpected traffic from a familiar provider can represent an approved tenant, a separate service using that provider or unauthorised use. The provider name alone does not decide the case.
Marketing and transactional platforms
These services often use shared infrastructure and provider-controlled authentication domains until a customer domain is configured. Look for a consistent signing domain, selector, return path and campaign or application owner.
Do not add a platform to the root-domain SPF record merely because its name appears likely. Confirm whether it supports aligned DKIM, a custom return path or a dedicated sending subdomain.
Website, billing and legacy application mail
Low-volume mail from a website, printer, monitoring system or accounting application can be easy to miss during onboarding. Check hosting records, relay configuration, application owners and change history.
A source in a South African hosting network may be a legitimate website process, a shared relay or an unrelated tenant. Hosting ownership provides a lead, not proof.
Forwarding and gateway paths
Forwarding changes the connecting IP and commonly breaks SPF. Message modification can also break DKIM.
ARC information may help a receiver make a local decision, but it does not change a DMARC failure into a pass. The ARC override guide explains why a failed message can still be delivered.
Remediation by classification
Authorised and aligned
Document the provider, owner, approved domains and expected traffic pattern. Continue monitoring for new authentication failures or unexpected changes.
Authorised but misaligned
Use the provider’s supported configuration for aligned DKIM or an aligned custom return path. A dedicated sending subdomain can also separate ownership where the provider supports it.
Adding another include to SPF is not a universal fix. It can leave DMARC alignment unresolved and increase recursive SPF lookup pressure. Review SPF flattening and the 10-lookup limit before expanding an already complex record.
Intermediary path
Confirm the forwarder, mailing list or gateway through headers and service ownership. Record the exception and assess it separately from a direct sending service.
Unauthorised or obsolete
Remove provider access, application credentials or DNS authorisation through the customer’s approved change process. Verify that no business owner or periodic process still relies on the source.
DMARC is not a sender-specific IP blocklist. Policy applies to messages that fail DMARC for the domain, and receivers retain local discretion. Progress policy only after legitimate sources and exceptions are understood.
Still unresolved
Keep the source under investigation and collect more evidence. A low count may need more reporting periods, while a material unexplained source may need faster customer escalation.
Volume informs priority, but it does not determine legitimacy.
Source identification across a customer portfolio
A free-text note does not scale across many domains. Use a sender register with consistent fields:
- customer and policy domain;
- source group and observed IPs;
- likely provider and confidence level;
- SPF and DKIM authentication domains;
- DMARC alignment result;
- business owner and purpose;
- classification and evidence links;
- remediation owner and due date; and
- last verified date.
Review new sources, changed authentication patterns and overdue investigations as portfolio exceptions. Do not convert a dashboard label into automatic approval or blocking.
The DMARC service delivery guide for MSPs places this investigation inside a controlled onboarding and policy-progression process.
What aggregate reports do not prove
Aggregate reports do not provide complete visibility. They contain observations from receivers that choose to report, not a record of every message sent or received.
An IP address does not identify a person or application. Network ownership, reverse DNS and volume require supporting evidence.
Authentication does not establish authorisation. A technically valid SPF or DKIM result does not prove that the customer approved the sending service.
DMARC does not classify message content. A DMARC pass does not establish that a message is wanted, safe or free from fraud.
One reporting period may be misleading. Seasonal mail, delayed reports and recent changes can alter the picture.
A source label is not a policy decision. Customer approval, delivery risk and change control still govern remediation and enforcement.
Frequently Asked Questions
Is an unknown IP address proof of shadow IT?
No. It is an unknown sending source until business and technical evidence establish what produced the mail and whether it was authorised.
Can reverse DNS identify the exact sending service?
Not reliably. Reverse DNS can suggest a provider or network, but shared infrastructure can support many tenants and applications.
Should an unfamiliar provider be added to SPF?
No. Confirm the service owner and use the provider’s supported authentication design before changing DNS. Aligned DKIM or a custom return path may be more appropriate.
Why can SPF pass while DMARC fails?
SPF can authenticate a provider-owned return-path domain that does not align with the visible From domain. DMARC needs aligned SPF or aligned DKIM.
Can a DMARC report identify the employee who sent a message?
Aggregate reports normally group technical observations and do not establish an individual sender. Use authorised internal records and controlled message evidence where that investigation is necessary.
How many reporting periods are needed before classifying a source?
There is no universal number. Use enough evidence to cover normal, low-frequency and seasonal sending patterns for that specific domain.
Does p=reject block one selected source IP?
No. DMARC policy applies to messages that fail DMARC for the domain, while receivers retain local policy discretion. It is not an IP blocklist.
Should the highest-volume unknown source be investigated first?
Often, but not automatically. Consider business impact, authentication results, customer knowledge and the risk of an unauthorised source alongside volume.
Do all receiving systems send aggregate reports?
No. Reporting participation and coverage vary, so aggregate data cannot provide a complete view of all mail associated with the domain.
Next step
If you manage authentication across customer domains, see how Vigil supports service-provider workflows on the managed DMARC for MSPs and WISPs page. For a domain-specific review of unresolved sending sources, contact Vigil.