DMARC monitoring tools: what to look for and which exist

A DMARC record with rua=mailto:dmarc@yourdomain.com causes receivers to send you a daily aggregate report: a gzipped XML file listing every IP that sent mail claiming to be your domain, how many messages each sent, and whether SPF and DKIM passed and aligned. One domain generates reports from dozens of receivers. That is why monitoring is a tooling problem rather than a mailbox problem.

What a report actually contains

<record>
  <row>
    <source_ip>203.0.113.9</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>yourdomain.com</header_from>
  </identifiers>
</record>

Note what is there and what is not. You get IPs, volumes and per-mechanism results. You do not get subject lines, recipients or message content — aggregate reports are deliberately privacy-preserving. Failure reports (ruf) can contain more, which is why most large receivers never send them.

What to judge a tool on

Report parsing and grouping. The baseline. A useful view groups by sending source rather than by IP, so "Google Workspace", "your CRM" and "an unknown host in another country" are three rows instead of four hundred.

Sender identification. The genuinely hard part. Mapping an IP range to a named service is what turns a report into an action. A tool that only shows IPs leaves you doing reverse lookups by hand.

Policy progression guidance. Something that answers "is it safe to move to quarantine yet" with evidence: what percentage of your volume is aligned, and which unaligned sources are still unidentified.

Record generation and validation. Convenient, but low value — the record is one line and the syntax is in the specification. Treat a generator as a typo-checker, not a reason to choose a product.

Multi-domain support. Essential if you own parked domains, which you should also be protecting with p=reject and an empty SPF record.

Report-authorisation handling. If rua points at a tool's domain rather than yours, your domain must be authorised by a record at yourdomain.com._report._dmarc.<their-domain> containing v=DMARC1. A good tool tells you this up front; a bad one leaves you wondering why no reports arrive.

Retention. Reports are a time series. Twelve months of history makes a policy change reviewable; thirty days does not.

Options that exist

These are established, independently verifiable products and projects. Capabilities and packaging change, so check the current state before committing.

For a single domain with a handful of senders, an email digest or parsedmarc on a small server is genuinely sufficient. For a portfolio of domains across business units, sender identification and delegated record management are what you are paying for.

Hosted DMARC and hosted SPF

Several platforms offer to host your records: you publish a CNAME at _dmarc.yourdomain.com pointing at them, and they serve the policy. This is convenient — policy changes need no DNS ticket — and it is a real dependency. Their outage is your authentication outage, and leaving the vendor means reclaiming DNS control. Worth it for an organisation with slow DNS change processes; unnecessary for a domain where you control the zone.

A monitoring routine that does not need a dashboard every day

1. Publish v=DMARC1; p=none; rua=mailto:...; fo=1 and leave it a full week.
2. List every sending source and classify each as known-good, known-bad or unidentified.
3. Fix the known-good ones so they produce an aligned DKIM signature.
4. When aligned volume stops improving and nothing is unidentified, move to p=quarantine.
5. Watch one week, then p=reject.
6. After that, you only need to look when volume from a new source appears — set an alert for that and ignore the dashboard otherwise.

What not to do

• Do not send rua to a mailbox a person reads. The volume is constant and the payload is gzipped XML.
• Do not pick a tool on the strength of its record generator. The record is trivial; the reporting is not.
• Do not interpret a high "DMARC compliance" percentage as deliverability. It measures alignment, not inbox placement — a fully aligned domain can still be filtered on reputation.
• Do not enable ruf without deciding where failure copies will be stored. They can contain recipient information.
• Do not treat an unknown source as an attacker by default. Most turn out to be a forgotten internal tool.

MailPilot is not a DMARC report aggregator — pair it with one of the above. What it does do is check SPF, DKIM and DMARC for every connected mailbox's domain and measure real per-provider inbox placement with a seed-inbox network, which is the question a compliance percentage cannot answer.