Migrating from parsedmarc.

Not a pitch — the mechanics. What comes across, what doesn't, and how to run both at once until you're sure.

First: you may not want to

People leave parsedmarc for one reason, and it is rarely the parser — it is the stack around it. Dashboards mean standing up and maintaining Elasticsearch or OpenSearch plus Kibana or Grafana, and that is a lot of infrastructure to keep alive for a few XML files a day.

Three cases where you should stay exactly where you are:

  • You need forensic (RUF) reports. parsedmarc parses them. We do not.
  • You need SMTP TLS (TLS-RPT) reports. Same — parsedmarc reads them, we are DMARC-only for now.
  • You already run a search stack, or you want a parser to feed your own pipeline. parsedmarc writes to OpenSearch, Splunk, PostgreSQL, Kafka, S3, Microsoft Sentinel, Graylog, syslog or a webhook. That flexibility is the whole point of it, and we deliberately do not compete there — you get one application with one database.

The full feature-by-feature table is on the parsedmarc comparison. This page assumes you have read it and want to know what moving costs.

The mailbox is the migration path

There is no export from parsedmarc to import here. The report data you need is already somewhere better: the mailbox the providers delivered it to. DMARC Analyzer connects to that mailbox over IMAP and parses the reports itself.

Three properties of that ingestion make the move much easier than it sounds:

  • The first sync reads the entire mailbox, not just new mail. However far back your reports go, that becomes your history on day one.
  • It never modifies the mailbox. Nothing is deleted, moved, flagged or marked read. It only reads.
  • Re-reading a report is a no-op. Reports are stored with a uniqueness constraint on the report's own identity, so ingesting the same one twice changes nothing.

Taken together: you can point this at the mailbox parsedmarc is already reading, today, without touching your parsedmarc install. Both run. Neither interferes. You compare them on the same data for a week and then decide.

What does not come across

Whatever is only in parsedmarc's data store. If you have three years in Elasticsearch but your mailbox only keeps ninety days, you get ninety days — there is no import endpoint, and inventing one that reconciled another tool's schema would be a worse idea than saying this plainly.

Two practical consequences:

  • Check your mailbox retention before you decommission anything. If a rule deletes reports after parsedmarc processes them, turn it off and let the mailbox refill first.
  • If the old history genuinely matters, keep the parsedmarc install read-only alongside for as long as you need it. Nothing forces a cutover date.

What you decommission

This is the part that motivated the move. After the cutover, the search cluster, its dashboards, its heap tuning and its disk go away. What replaces them is one container and a PostgreSQL database — see choosing a deployment, and the Helm chart if you would rather run it on Kubernetes.

The actual steps

  1. Start it with Docker — prebuilt image, no build step.
  2. Create a client and add the mailbox source, pointing at the same mailbox parsedmarc reads.
  3. Let the first sync run. It reads everything in the mailbox, so this takes longer than later syncs will.
  4. Compare against your existing dashboards on the same period. This is the step worth not rushing.
  5. When you are satisfied, stop parsedmarc and retire the search stack.

What you gain, specifically

  • Per-client multi-tenancy. parsedmarc is not built to keep many clients' data separate; this is built around that, with read-only client access. It is the substantive difference for agencies and MSPs.
  • Dashboards you do not maintain. The console ships with the app rather than being imported into a stack you operate.
  • Alerting and digests without a separate rules engine — see alerts and notifications.
  • The same licence and the same principle — Apache-2.0, self-hosted, no per-domain pricing. You are not trading open source for convenience.

Named products are trademarks of their respective owners. Comparisons reflect our understanding at the time of writing and may change; corrections welcome.