DMARC report viewer review 2026

During the 90-day run, DMARC Report Viewer pulled XML aggregate reports from the IMAP mailbox and showed separate traffic for Microsoft 365, Google Workspace, SendGrid, Mailchimp, and the support desk sender. The DMARC-matching SPF pass and DMARC-matching DKIM pass were easy to verify in the report drilldowns, but SPF pass with header From mismatch and DKIM pass on the marketing subdomain needed manual interpretation. The unknown sender appeared as an IP and reporting organization first, so we had to use DNS, location, WHOIS, and export data to classify it.

The hosted comparison puts the same sender evidence into an enforcement workflow: service names, owner notes, policy guidance, and alert rules live with the domain rather than in a separate ticket. In the same sender mix, the unknown sender and the SPF pass with header From mismatch had clearer owner paths, and the unauthorized spoof sample was separated from normal forwarding noise before policy discussion.

Adding the primary domain, marketing subdomain, and parked domain took one container, one Basic Auth setup, and a report mailbox that all three domains sent to. The domain filter made the parked domain easy to check, but the unknown sender took several DNS and WHOIS lookups before we were comfortable classifying it. The forwarded mail SPF failure was visible in the pass and fail data, yet the UI did not explain why DKIM kept the message DMARC-clean.

The hosted workflow reduced that explanation burden by keeping DNS setup, sender status, and fix notes closer together. During the same test setup, the unknown sender was easier to route to an owner, and the forwarded SPF failure had enough context for a non-specialist stakeholder to understand why it was not the same as the spoof sample.

During setup, the docs were enough to run Docker, connect IMAP, enable Basic Auth, and check the health endpoint. DNS handoff stayed entirely on us: we prepared the rua records, explained report mailbox routing, and documented why the parked domain should move faster than the primary domain. For enterprise onboarding, we found no contract path, support SLA, or named escalation process.

The hosted comparison made the support question more about who owns each fix after data arrives. DNS changes still required approval, but setup notes, sender status, and policy movement had a clearer handoff path for security, marketing operations, and IT. That matters when Microsoft 365 and Google Workspace are clean but SendGrid, Mailchimp, and a support desk sender each need a different owner.

For a single enterprise security team, DMARC Report Viewer worked as a low-cost evidence viewer across the primary domain, marketing subdomain, and parked domain. Account separation was the limiting factor: client-style grouping, recurring reports, and handoff notes had to be handled outside the app. SMB teams without a technical owner would also need a plan for upgrades, access control, backups, and mailbox retention.

The hosted comparison fit the operator side better because domain grouping, recurring reporting, and client notes stayed with the DMARC workflow. For MSP use, the difference showed up when the unknown sender needed classification and the support desk sender needed a client-facing explanation. For enterprise use, the same structure helped split marketing, IT, and security ownership without creating separate export files.