Open-source DMARC report analyzers: how to choose

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, a browser-based or self-hosted Next.js application with automated report support.
• DmarcSrg, 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, 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.

Source: Open the full-size selection matrix. Criteria are derived from the current documentation for Resend DMARC Analyzer and DmarcSrg, 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 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.

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.

Source: Open the full-size architecture. The trust boundaries reflect the aggregate-report delivery and security considerations in RFC 9990.

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 explains the data model; privacy and access decisions still belong to the organization.

Before selecting an analyzer, use Palisade's DMARC checker 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 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 when the written requirements call for ongoing managed operations.

The broader DIY versus managed DMARC guide helps assign that operating decision. The DMARC learning hub remains the protocol reference.

Sources and further reading

• RFC 9990: DMARC aggregate reporting
• Resend DMARC Analyzer documentation
• DmarcSrg documentation
• DMARC.org code and libraries