DMARC report monitoring

We send email from our own domain, which means we publish a DMARC policy and receive aggregate reports from every major mailbox provider — Google, Microsoft, Yahoo, Fastmail, you name it. Every day, they send compressed XML files to our reporting address telling us whether our emails passed SPF and DKIM checks.

The problem? Those reports arrive as .xml.gz or .zip attachments in a mailbox. To actually read them, someone has to open the email, download the file, decompress it, and make sense of the XML inside. Most days everything is fine. But you won't know about the day it isn't fine unless you check.

We weren't going to do that manually every morning. So we built a flow that does it for us — using EmailConnect, obviously.

What we built

The idea is simple: DMARC reports arrive by email, and we want two things out of them:

  1. A database row for each record, so we have a queryable audit trail
  2. A notification summary, so we know at a glance if anything needs attention

Here's what the flow looks like:

DMARC report lands in our inbox (.xml.gz or .zip)
  → EmailConnect delivers it as a webhook
    → Our automation downloads the attachment
      → Decompresses and parses the XML
        → Each record gets stored in a database
        → We receive a summary notification

That's it. Five steps, no manual work, reports are processed the moment they arrive.

How it actually works

Receiving the reports

We have dmarc@emailconnect.eu set up in EmailConnect with a webhook. When a DMARC report arrives, we get a structured payload with the email metadata and the attachment as a downloadable file. Nothing special here — this is what EmailConnect does.

Decompressing the attachment

This is where it gets slightly annoying. DMARC reporters can't seem to agree on a compression format. Google sends .zip files, Fastmail sends .xml.gz, others do whatever they feel like. So instead of trusting the file extension, we check the first two bytes:

  • 0x1F 0x8B → it's gzip, decompress directly
  • 0x50 0x4B → it's a zip archive, find the .xml entry inside and extract it

Works every time, regardless of what the sender decided to use.

Parsing the XML

DMARC reports follow a standard schema. The interesting bits are:

  • Report metadata — who sent the report, what period it covers
  • Policy published — your domain's DMARC configuration
  • Records — one per source IP, with message count and authentication results (SPF pass/fail, DKIM pass/fail, what action the receiver took)

We pull out the fields that matter and structure them into rows.

Storing everything

Each record becomes a database row:

Field Example
reportId 2026.02.14.1881047327
source google.com
sourceIp 209.85.220.41
messageCount 12
dkimResult pass
spfResult pass
dkimDomain emailconnect.eu
spfDomain emailconnect.eu
dateBegin / dateEnd 2026-02-14

This means we can query across all providers, look up specific IPs, spot trends over time, or just prove to ourselves (or anyone who asks) that our email authentication is solid.

The notification

Once the report is processed, we get a summary like this:

📊 DMARC Report: emailconnect.eu
📤 From: google.com
📅 2026-02-14 → 2026-02-14

✅ 12× from 209.85.220.41
    DKIM: pass | SPF: pass
✅ 3× from 209.85.220.69
    DKIM: pass | SPF: pass

📬 Total: 15 messages, no failures

Green checkmarks, quick scan, move on with your day. If something fails, it shows up with a red cross and we know to investigate.

What we flagged as a failure

A record gets flagged when any of these are true:

  • DKIM result is not pass
  • SPF result is not pass
  • Disposition is not none (meaning the receiving server quarantined or rejected the mail)

That's the signal. Everything else is just confirmation that things are working as expected.

Before and after

Before: Someone on the team was supposed to check 3–10 DMARC emails daily. In reality, it got skipped more often than not. When it did get done, it meant downloading zip files, extracting XML, and squinting at angle brackets. If there was a deliverability issue, we'd find out late — or not at all.

After: Reports process themselves. We get a notification per report, glance at it, and move on. Failures are impossible to miss. The database gives us a full audit trail without any extra effort. Took under an hour to set up.

Try it yourself

If you're monitoring DMARC (and you should be), the setup is straightforward:

  1. Make sure your DNS is configured — your _dmarc TXT record needs a rua tag pointing to an address you control: v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
  2. Set up that address in EmailConnect with a webhook pointing to your automation platform
  3. Build a flow that downloads the attachment, decompresses it, parses the XML, stores the records, and sends you a summary
  4. Wait a day or two — reports start flowing in as mailbox providers generate their daily aggregates

From there, it just runs. One less thing to worry about.

This is a real flow we use every day at EmailConnect. Dogfooding at its finest — and a good example of how a webhook-based approach can replace the kind of mailbox-checking chore that nobody enjoys but everybody needs.