Read DMARC aggregate reports by checking the reporting period, identifying sending sources, and separating raw SPF or DKIM authentication from alignment with the visible From domain. Before changing enforcement, confirm who owns legitimate senders that fail DMARC, document reporting gaps, and agree on a validation and rollback plan. An aggregate failure is evidence of an authentication outcome, not proof of compromise or a reason to block an unidentified sender.
- DMARC aggregate reports support enforcement decisions only when sending sources, alignment, reporting dates, and coverage limits stay attached.
- DMARC passes when at least one authentication mechanism both passes and aligns with the visible From domain.
- A published p=none policy requests monitoring; it does not establish compromise or explain the domain owner's intent.
- Resolve ownership of legitimate failing senders before requesting quarantine or rejection.
How to read DMARC aggregate reports before changing enforcement
Use this sequence for your 2026 review. Keep the original report alongside your interpretation so another practitioner can reproduce the conclusion.
A DNS check establishes what a domain publishes at the time of observation. Aggregate reports add receiver-reported authentication outcomes for specific reporting windows. The distinction is covered in whether an SPF, DKIM, and DMARC checker is enough.
1. Establish the report's scope
Record the reporting organization, report identifier, covered domain, and beginning and ending timestamps. Preserve the original timestamps and show a consistent timezone in your working summary. A report's arrival date is different from its observation window.
Check for duplicate reports before combining totals. Retain the published-policy information inside each report because it describes the policy the receiver reported evaluating, rather than necessarily matching today's DNS record.
Do not describe aggregate-report counts as unique people, unique campaigns, or confirmed inbox deliveries. They are receiver-reported message counts grouped by shared characteristics.
2. Read the fields in context
Use the report's fields together. A source address alone does not identify the business owner, and an authentication result alone does not establish DMARC alignment.
| Report field | What it contributes | Interpretation limit |
|---|---|---|
| Reporting organization and date range | Source and observation window | Does not establish coverage across all receivers |
| Published policy | Policy and alignment settings reported by the receiver | Can differ from the domain's current record |
| Source IP and message count | Reported sending source and grouped volume | Does not prove who authorized the mail |
| Header From domain | Domain used for the DMARC alignment comparison | Is not necessarily the envelope sender |
| Policy-evaluated SPF and DKIM | Receiver's DMARC alignment outcomes | Must be distinguished from raw authentication results |
| Authentication results | SPF domains, DKIM signing domains, and available results | A pass can belong to an unaligned domain |
| Disposition and override reasons | Receiver-reported handling and exceptions | Does not prove inbox placement or business legitimacy |
The XML structure and DMARC alignment model are documented in IETF RFC 7489. Treat that specification as the technical reference for these fields, not as evidence about a particular customer's mail.
3. Map sources to accountable owners
Group sending sources by the business service they appear to represent. Then ask the customer to confirm the service, its purpose, and its owner. Infrastructure attribution is a research lead; shared hosting or a recognizable provider name does not establish authorization.
Keep separate entries for confirmed legitimate mail, confirmed unauthorized use, and unresolved sources. An unresolved source stays unknown until supporting evidence changes its status.
Record the basis for each classification. A service owner's confirmation and a configuration review carry different information from a reverse-DNS name.
4. Separate authentication from alignment
SPF checks an envelope identity, commonly the MAIL FROM domain. DKIM validates a signature associated with its signing domain. DMARC asks whether a passing identity aligns with the visible From domain.
DMARC requires 1 aligned authentication pass, not successful alignment through both mechanisms. A message can pass raw SPF for a service provider's domain and still fail DMARC if neither SPF nor DKIM aligns with the visible From domain.
Read the published alignment settings too. Relaxed alignment permits an organizational-domain match under DMARC's rules; strict alignment requires an exact domain match. Do not apply strict-alignment assumptions to a report evaluated under relaxed settings.
5. Compare evidence before changing policy
Build a dated baseline showing legitimate sources, their owners, alignment outcomes, and unresolved questions. Include business sending patterns such as scheduled campaigns or infrequent operational mail where the customer confirms they exist.
After an approved change, compare subsequent reports with that baseline. Preserve report windows and receiver coverage so a change in the report population is not mistaken for an improvement.
Why this matters
Enforcement changes affect messages that receivers evaluate as failing DMARC. If a legitimate sender is misconfigured, stronger enforcement can affect that sender's mail. If a sender remains unidentified, the report alone cannot tell you whether blocking it would help or interrupt a business process.
Your 2026 recommendation should therefore explain the decision boundary: which sources are understood, which legitimate failures need work, and which evidence remains unavailable. A large pass total does not answer those questions by itself.
The useful outcome is an owned decision supported by dated evidence. A report full of failures can support investigation without supporting an immediate policy change.
Compare the 3 DMARC policy choices
These policies express the domain owner's requested treatment of mail that fails DMARC. Receivers retain discretion over handling.
| Policy | Best for | Benefit | Limitation |
|---|---|---|---|
p=none | Observation while sender ownership and alignment are assessed | Requests no DMARC-specific enforcement action | Does not request quarantine or rejection for failures |
p=quarantine | An approved enforcement stage after legitimate senders are reviewed | Requests suspicious treatment of failing mail | Misconfigured legitimate mail can be affected; handling varies |
p=reject | An approved rejection policy supported by sender validation | Requests rejection of failing mail | Legitimate failures can be rejected; receiver exceptions still exist |
No policy value substitutes for an inventory of legitimate senders. Read subdomain-policy settings separately when subdomains are in scope, and document which domain each recommendation covers.
Do not describe p=none as evidence of negligence. Monitoring can be intentional. Establish the owner's intended outcome before proposing a different policy.
Why DMARC aggregate reports vary
Several factors change what a report contains and what you can infer from it:
- Receiver participation determines which receiving organizations contribute evidence. Missing reports do not establish that no mail was sent.
- Reporting windows affect comparisons. Different periods can contain different sending activity even when configuration stays unchanged.
- Business sending patterns affect source coverage. Customer-confirmed periodic mail needs representation in the review.
- Forwarding can break SPF because the forwarding server becomes the connecting sender. DKIM can survive forwarding if signed content remains intact.
- Message modification can invalidate DKIM signatures. Mailing-list processing is one context that requires closer investigation.
- Receiver handling can include local-policy decisions or exceptions. Disposition alone does not establish the reason a message was accepted or rejected.
Keep these explanations tied to the actual evidence. A forwarding explanation is a hypothesis until the available report details or authorized investigation support it.
Turn a finding into evidence, insight, and proof
For a 2026 client review, use the same structure for every material observation. This keeps the technical condition separate from its possible consequence and the customer's next choice.
- Evidence: Record the condition, affected domain, check or report source, reporting window, and relevant alignment result.
- Insight: Explain the possible consequence for the identified sender. State unknowns and identify the person responsible for confirming business use.
- Proof: Compare later evidence against the pinned baseline after an authorized change. Preserve remaining gaps rather than calling them resolved.
Consider a report showing DMARC failure for a source the customer recognizes as a business sender. Record the failure and the customer's attribution separately. Confirm the service's sending configuration before selecting a correction.
The possible consequence is that legitimate mail from that sender could face the requested enforcement treatment. The next choice belongs to the responsible owner: investigate configuration, correct an authorized sender, retire an unused service, or defer the policy change while evidence is gathered.
Proof requires a comparable follow-up observation. A configuration change alone establishes that something changed, not that the intended mail now passes DMARC.
Keep public observations separate from authorized evidence
A public DNS observation can show the DMARC record retrieved at a stated time, including its policy and reporting destinations. It cannot reveal the contents of reports sent to those destinations. A reporting address in DNS does not prove anyone reviews the reports.
Aggregate reports supplied by an authorized customer add a separate evidence source. Label who supplied them, their reporting windows, and any missing periods. Do not present customer-supplied reports as findings from a public-domain scan.
Microsoft 365 tenant evidence is another separate scope. A public-domain review cannot establish Conditional Access coverage, application permissions, license assignments, or tenant sharing configuration. An email-authentication report cannot fill those gaps either.
For your 2026 evidence packet, keep observation state and coverage separate. A source can be observed while its business ownership remains unknown. Missing or unreadable reports belong in the coverage limitations, not in the passing column.
Use a decision gate before enforcement
Change policy only after the authorized owner accepts the evidence and the remaining uncertainty. Keep the approval attached to the exact domain and proposed configuration.
- Confirm legitimate sending services and their accountable owners.
- Investigate legitimate DMARC failures and document the chosen outcome.
- Record unresolved sources without assigning unsupported intent.
- Confirm access to DNS changes and the previous configuration.
- Define follow-up reporting, service-owner checks, and rollback responsibility.
- Record approval, implementation time, and the baseline used for comparison.
Do not invent a universal pass-rate threshold or observation duration. The decision needs evidence covering the customer's actual sending activity. Calendar time without representative mail does not establish readiness.
Can SPF pass while DMARC fails?
SPF can pass while DMARC fails when the passing SPF identity does not align with the visible From domain and no aligned DKIM signature passes. Check the authenticated domain, not just the pass label.
A provider sending on a customer's behalf needs an appropriate aligned authentication path. The correct configuration depends on the service and the customer's approved design.
Does a rejected disposition prove malicious mail?
A rejected disposition reports receiver handling; it does not prove malicious intent. A misconfigured legitimate service can also fail DMARC.
Confirm authorization separately. Preserve the source, reporting window, alignment outcome, and any receiver-supplied override explanation.
Where prospect intelligence fits
SCOUTz is best for MSPs preparing prospect conversations with dated cybersecurity evidence and account context. The platform's role is preparation. The MSP retains responsibility for interpreting the evidence and choosing the next action.
SCOUTz cybersecurity prospect intelligence can give that conversation a starting point, but a public-domain observation does not replace access to aggregate reports or sender-owner confirmation. That boundary matters when a prospect asks whether an enforcement change is safe.
SCOUTz's October 15, 2026 product reference distinguishes public-domain reviews from customer-authorized, read-only Microsoft 365 evidence. Microsoft 365 evidence covers configuration and metadata, never mail, files, chats, documents, or prompts. Keep any supplied DMARC reports separately sourced.
For MSPs considering the platform, the primary next step is Join Open Beta through the site. Bring a specific preparation task and retain responsibility for the recommendation. A scan does not close a deal.
FAQ
What should I look at first in DMARC aggregate reports?
Start with the reporting organization, reporting window, covered domain, and published-policy information. Then inspect sending sources and aligned authentication outcomes before interpreting failures.
Does DMARC require both SPF and DKIM to pass?
DMARC requires at least one authentication mechanism to pass and align with the visible From domain. A raw SPF or DKIM pass for an unrelated domain does not satisfy alignment.
How long should I review reports before changing enforcement?
Review enough representative sending activity to identify legitimate services and investigate their failures. A fixed duration cannot establish readiness when relevant business mail is absent from the reporting window.
Does p=none mean an email domain has been compromised?
A published p=none policy does not establish compromise. It requests no DMARC-specific enforcement action, and the domain owner must confirm whether that policy remains intentional.
Can a public domain scan read my DMARC aggregate reports?
A public domain scan cannot read reports merely because it can retrieve a reporting destination from DNS. Report access requires a separate authorized evidence source.
Do missing DMARC reports mean no spoofing happened?
Missing DMARC reports do not establish that no spoofing or other mail activity occurred. Record the missing receiver or reporting period as a coverage limitation.
Can SCOUTz prove a prospect is ready for DMARC rejection?
SCOUTz public-domain evidence alone cannot establish readiness for DMARC rejection. The decision also requires authorized report review, legitimate-sender confirmation, and approval from the responsible owner.
One last thing
A better-looking report can reflect a different reporting population rather than a better configuration. Before presenting a reduced failure count as proof, compare the reporting organizations, covered periods, and represented senders.
For your final 2026 handoff, preserve the baseline, approved change, follow-up evidence, unresolved questions, and owner's decision together. That packet supports an evidence-led proposal or QBR without turning an unknown into a resolved finding.
