Self-hosted DMARC monitoring, on your infrastructure.

What it is, concretely

One image. The web console and the mailbox polling run in a single container, next to PostgreSQL — two containers, and nothing else to install. No search cluster to keep alive, no separate dashboard service to import and maintain. Around 1 GB of RAM.

mkdir dmarc-analyzer && cd dmarc-analyzer
curl -fsSL -o compose.yml https://raw.githubusercontent.com/dmarc-analyzer-net/DmarcAnalyzerApp/main/deploy/compose.yml
# generates the key that encrypts stored mailbox passwords — back this up
echo "DMARC_ENCRYPTION_KEY=$(openssl rand -base64 32)" > .env
docker compose up -d

Then open http://localhost:8080, create the first administrator, and point it at the mailbox your aggregate reports already arrive in. The image is on ghcr.io/dmarc-analyzer-net/dmarc-analyzer for amd64 and arm64, so a Raspberry Pi or an Apple Silicon machine works too. The full walkthrough is install with Docker.

You can run it alongside whatever you already have. Ingestion is read-only — it never deletes, moves or flags anything in the mailbox, and re-reading a report it has already seen changes nothing. So you can point this at the mailbox another tool is reading today, without touching that tool, and compare the two on the same data for as long as you like before committing.

It is a finished application rather than parts to assemble: the console, ingestion, alerting and multi-tenancy in one image, with unlimited domains and no paid tier — free and open source under Apache-2.0. Nothing here can be capped, shortened or moved behind an upgrade later, because it is your install and your database.

The rest of this page is the honest case for and against running it yourself.

What you are actually handing over

"DMARC reports don't contain message content" is true, and it is the reason the question gets waved away. But an aggregate report is a census of your sending infrastructure, and a year of them is a very good one:

• Every IP that sends as you — your mail servers, and the ones you forgot about.
• Every SaaS vendor in your stack that sends mail — payroll, CRM, ticketing, invoicing, the marketing tool one team signed up for. Sending sources are a reasonable proxy for what a company buys.
• Volumes over time, per source — which reveals seasonality, growth, and when something changed.
• Your subdomain structure, including internal names that never appear in public DNS.

None of that is catastrophic to share, and plenty of organisations reasonably decide a hosted service is fine. But it is worth knowing what the decision is, rather than assuming there is no data in play. Self-hosting means the answer to "who else has this?" is nobody.

Where regulated environments land

Aggregate reports are mostly infrastructure metadata, not personal data — but "mostly" is doing work in that sentence, and a self-hosted install is a much shorter conversation with a DPO than a new sub-processor is. There is no vendor to add to the register, no transfer to assess, and retention is a setting rather than a support ticket. The specifics — what is stored, what counts as personal data, how erasure works — are in data protection and GDPR.

What self-hosting costs you

It is not free in effort, and a page that pretended otherwise would be setting you up badly. Running this yourself means:

• You own uptime. Nobody is paged when ingestion stops. The app has health endpoints and mailbox-health alerts for exactly this, but you have to wire them into something that wakes you up.
• You own backups. A database you never restored is not a backup — see upgrading and backup.
• You own patching. New image, new database migrations, occasional breaking changes at a major version.
• You own the perimeter. Putting it behind TLS and not exposing PostgreSQL is on you — reverse proxy and security cover both.

That is genuinely a real cost. It is also the same cost you are already paying for everything else you run, which is why it lands very differently depending on whether you already operate infrastructure.

Who should self-host, and who should not

• Self-host if you already run containers, you handle client data under contract, you have more domains than a per-domain price makes comfortable, or your data-residency answer needs to be "our own servers."
• Do not self-host if one person handles email part-time, there is nowhere to run a container, and nobody wants to own a database. A hosted tool's free tier is the better call — the buyer's guide covers those honestly.

What running it looks like

Day to day it connects to a mailbox over IMAP, reads the reports providers send there, and builds the dashboards from them. The first sync reads the whole mailbox, not just new mail, so however far back your reports go, that becomes your history on day one.

The default two-container shape is not the only one. There is a maintained Helm chart if you would rather run it on Kubernetes, and choosing a deployment walks through bundled versus external PostgreSQL, and one container versus two.

Where it sits among the self-hostable options

The usual objection to self-hosting DMARC is the stack, and the options really do sit at two extremes. The lightest hold no state at all — history is only ever what is still in the mailbox. The most capable are parsers you wire to a search cluster and a dashboard yourself, then keep alive. DMARC Analyzer is deliberately in between: a finished multi-tenant application with its own database, which is why the install above is two containers and no assembly. The open-source roundup puts them side by side.