# Open-source DMARC report analyzers: how to choose > Compare open-source DMARC analyzers by ingestion, storage, dashboards, security, maintenance, and the operating work each option leaves to you. An open-source DMARC report analyzer can keep aggregate data inside infrastructure you control, but the software is only one part of the system. You still own report ingestion, parser updates, storage, access control, backups, alerting, and incident response. Choose a project by the operating model you can support, not by stars alone. This comparison was checked on July 27, 2026 and should be rechecked before deployment. ## Quick takeaways - Choose between a modern self-hosted web application and a smaller PHP application with relational storage. - Test malformed, duplicate, compressed, and high-volume reports before selecting a project. - Treat repository activity as a maintenance signal, not a security or conformance audit. - Budget for the database, dashboard, authentication, backups, upgrades, and on-call ownership. - Keep raw reports long enough to reproduce parser or aggregation errors. ## Who this comparison is for Self-hosting makes sense when the organization has a strong reason to control the data path and already operates the required infrastructure. Common reasons include data-residency rules, integration with an existing security data platform, an internal engineering requirement, or a need to inspect and transform raw XML before storage. It is a poor fit when nobody owns the mailbox, parser, database, dashboards, and upgrades as one service. DMARC reports arrive continuously, parsers face untrusted compressed XML, and the data becomes less useful when ingestion silently stops. A free license does not remove the operating cost. This article compares two current open-source approaches: - [Resend DMARC Analyzer](https://resend.com/docs/dmarc-analyzer), a browser-based or self-hosted Next.js application with automated report support. - [DmarcSrg](https://dmarc.pl/), a PHP parser, viewer, mailbox collector, and summary generator backed by MariaDB or MySQL. The list is not a certification or an exhaustive directory. DMARC.org maintains a broader [code and libraries resource](https://dmarc.org/resources/code-and-libraries/), but inclusion there also carries no warranty. The durable decision is whether a project's current scope and your operating controls fit. ## How the options were evaluated The evaluation uses ten criteria. Each one maps to a failure an operator may need to detect and repair: - **Input coverage:** IMAP, local files, APIs, object storage, and supported compression types. - **Parser behavior:** current schema support, duplicate handling, malformed input, size limits, and reproducible errors. - **Output model:** raw preservation, normalized JSON or CSV, relational storage, search indexes, and event streaming. - **Analysis surface:** built-in reports, dashboards, filters, alerting, and export. - **Access control:** authentication, authorization, network boundaries, secrets, and auditability. - **Reliability:** retry behavior, failed-message quarantine, health checks, backups, and disaster recovery. - **Scale:** report volume, database growth, retention, indexing, and query cost. - **Maintenance:** supported runtime, dependency updates, release activity, migration work, and rollback. - **Privacy:** report content, source IP data, mailbox credentials, data location, and deletion policy. - **Exit path:** raw export, normalized export, schema documentation, and the effort to change tools later. ![Decision matrix for choosing an open-source DMARC analyzer by operating model.](/images/editorial/dmarc-report-analyzer-open-source/open-source-dmarc-analyzer-selection-matrix.svg "1200x760") *Source: [Open the full-size selection matrix](/images/editorial/dmarc-report-analyzer-open-source/open-source-dmarc-analyzer-selection-matrix.svg). Criteria are derived from the current documentation for [Resend DMARC Analyzer](https://resend.com/docs/dmarc-analyzer) and [DmarcSrg](https://dmarc.pl/), checked July 28, 2026.* ### Resend DMARC Analyzer is the modern application choice Resend DMARC Analyzer is strongest when the organization wants a modern web application that can be used directly in a browser or deployed into an existing Next.js environment. Its documentation describes XML report parsing, readable dashboards, and a self-hosted mode for receiving automated report digests. That convenience still creates service work. You must operate the deployment, report intake, storage, authentication, retention, and monitoring used in your environment. A readable dashboard is not proof that every receiver reported or that every sending source has been assigned to a business owner. ### DmarcSrg is the smaller integrated application choice DmarcSrg combines mailbox or file ingestion, a relational database, a web interface, filtering, DKIM and SPF detail, retention functions, and scheduled summary email. Its smaller stack can be easier to understand than a parser plus a separate search cluster. The tradeoff is a more specific PHP and MariaDB or MySQL operating model. The team owns the web server, database hardening, authentication configuration, mailbox access, backup, and upgrade testing. This can fit a small installation when the built-in views answer the required questions. ## How to choose ### 1. Write the operating requirement before installing anything List the domains, expected daily report count, required retention, data location, analyst roles, alert conditions, and maximum acceptable ingestion gap. Decide whether raw XML must be retained and who may access source IP and authentication data. If the requirement is only to inspect occasional reports, a full search cluster is probably unnecessary. If an MSP must isolate many tenants and prove access boundaries, a single basic dashboard may be insufficient. ### 2. Build an adversarial test corpus Use synthetic or redacted reports that include gzip and zip attachments, duplicate report IDs, overlapping date ranges, unknown extensions, malformed XML, large record counts, IPv6 sources, multiple DKIM results, and policy overrides. [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) defines the current aggregate-report format and explicitly treats report content as a potential attack surface. A parser should reject or quarantine invalid input without losing the evidence required for diagnosis. ```text Expected test result: accepted report -> normalized records + raw source retained duplicate report -> idempotent skip with an observable event malformed report -> quarantined input + actionable error oversized archive -> bounded rejection without resource exhaustion ``` ### 3. Operate a representative pilot Run the candidate on a noncritical reporting address for at least two normal report cycles. Measure ingestion delay, failure rate, database growth, dashboard query time, backup time, and the effort required to identify one legitimate sender and one failing source. Do not expose a default web interface directly to the internet. Put it behind the organization's approved identity, TLS, network, and logging controls. Use a dedicated mailbox credential with the narrowest access the collector supports. ![Reference architecture for a self-hosted DMARC report analyzer from reporting mailbox to analyst workflow.](/images/editorial/dmarc-report-analyzer-open-source/self-hosted-dmarc-analyzer-architecture.svg "1200x680") *Source: [Open the full-size architecture](/images/editorial/dmarc-report-analyzer-open-source/self-hosted-dmarc-analyzer-architecture.svg). The trust boundaries reflect the aggregate-report delivery and security considerations in [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html).* ### 4. Test maintenance and exit before production Perform an upgrade, restore a backup into a clean environment, rotate the mailbox credential, and export both raw and normalized data. Record the exact recovery time and any manual schema work. Review repository activity, supported runtimes, open security issues, dependency alerts, and license obligations on the selection date. A project that is active today can slow later. Your plan needs a replacement trigger, not only an installation guide. ## Operating controls that software does not supply The self-hosted service needs an owner, a runbook, and observable health. At minimum, monitor the last successfully processed report, the number of failed attachments, mailbox backlog, storage growth, database errors, certificate expiry, and backup completion. Separate the ingestion identity from analyst identities. Keep secrets outside the image and repository. Restrict outbound network access where practical. Scan images and dependencies, pin versions, and review changes before upgrades. Define retention for raw email, attachments, normalized records, and backups separately. Aggregate reports contain source IP addresses and authentication identifiers. The [DMARC aggregate report guide](/learning/dmarc-aggregate-report-format) explains the data model; privacy and access decisions still belong to the organization. Before selecting an analyzer, use Palisade's [DMARC checker](/tools/dmarc) to confirm that the domain publishes a current policy and aggregate-report destination. That public check does not prove report coverage, parser safety, source ownership, or the operating quality of any analyzer. If the pilot shows that the team cannot own ingestion, storage, upgrades, access control, and incident response, compare a managed option against the real self-hosting cost rather than a zero-dollar license. Palisade's [DMARC Agent](https://docs.palisade.email/guides/fixing-authentication-issues/) turns DMARC report findings into source-specific authentication tickets and recommended actions, but it cannot guarantee that every receiver reports or classify a sender without business context. [Start with Palisade](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=article_assisted&utm_content=dmarc-report-analyzer-open-source) when the written requirements call for ongoing managed operations. The broader [DIY versus managed DMARC guide](/learning/should-you-diy-dmarc-or-use-an-automated-service) helps assign that operating decision. The [DMARC learning hub](/learning/dmarc) remains the protocol reference. ## Sources and further reading - [RFC 9990: DMARC aggregate reporting](https://www.rfc-editor.org/rfc/rfc9990.html) - [Resend DMARC Analyzer documentation](https://resend.com/docs/dmarc-analyzer) - [DmarcSrg documentation](https://dmarc.pl/) - [DMARC.org code and libraries](https://dmarc.org/resources/code-and-libraries/) ## Frequently asked questions ### Is an open-source DMARC analyzer free to operate? No. The license may have no purchase price, but the organization still pays for infrastructure, engineering time, monitoring, backups, upgrades, incident response, and security review. ### Is Resend DMARC Analyzer a complete managed DMARC service? No. It can render reports in a browser or run as a self-hosted application, but the operator remains responsible for the deployed intake, storage, access, monitoring, and response process. ### Should I choose the repository with the most stars? No. Stars can signal interest, but they do not prove parser correctness, security, maintenance capacity, or fit. Test the current code against your report corpus and operating requirements. ### Can a self-hosted analyzer tell me every service that sends mail? Only partially. It can show sources observed by participating receivers in the reports you receive. It cannot prove that every message or receiver is represented, and business ownership still requires investigation. ### When should I use a managed DMARC platform instead? Use a managed platform when the organization needs ongoing monitoring, guided sender identification, support, or multi-domain operations but cannot reliably own the ingestion, storage, security, upgrade, and response work of a self-hosted service.