Reading DMARC Reports Without Going Broke: A Practical Guide for Small Teams

In a LinkedIn thread about DMARC enforcement, an IT leader at a small volunteer organization raised a question we hear often: "These reports are gobbledygook. We can't send the reports to an external paid tool for analysis due to budget restrictions. How do I handle the flow of these reports as we send out our mass emails to hundreds of members, several times per month?"

The honest answer is that DMARC aggregate reports are not designed to be read by humans. They're machine-readable XML, sent at receiver-defined intervals (usually daily), with one report per receiver per day. A domain in active production receives dozens of reports per week. Each report is a few kilobytes of structured data that, in raw form, takes meaningful effort to interpret.

The good news: there's a middle ground between "raw XML in your inbox" and "$50,000/year enterprise DMARC platform." This post is the practical guide for small and mid-sized organizations that need DMARC visibility without an enterprise budget.

What's Actually in a DMARC Aggregate Report

Every aggregate report is an XML document with a few sections worth understanding:

Report metadata. The receiver that generated the report (usually Google, Microsoft, Yahoo, or a smaller provider), the time window covered, and a unique report ID.

Policy published. What your DMARC record said at the time of report generation — the policy (p=), the alignment modes (adkim=, aspf=), the percentage (pct=), and the subdomain policy (sp=).

Records. One block per unique source IP that sent mail under your domain during the window. Each block contains: - The source IP and the count of messages from it - The disposition the receiver applied (none, quarantine, reject) - Authentication results (SPF result, SPF-authenticated domain, DKIM result, DKIM-signing domain) - Alignment results - The header-from domain on the messages

A typical day's worth of reports for an active domain might cover 20 to 50 distinct source IPs, ranging from your legitimate sending infrastructure to forwarders, third-party services, and (often) actual spoofing attempts.

The raw XML for a single report looks something like this excerpt:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>342</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

Useful. Not exactly human-friendly when you have a hundred of these per day.

The Tooling Landscape

DMARC report analysis breaks into three tiers, roughly defined by cost and capability.

Free / open-source. A handful of community projects exist for parsing aggregate reports. parsedmarc is the most established — a Python utility that ingests XML reports and outputs structured data, with optional integrations into Elasticsearch and Splunk for visualization. dmarc-srg is a lightweight PHP-based viewer that runs on a small VPS. The DMARC Insight tool that Ayokunmi Ogundapo mentioned in our LinkedIn thread is available on Docker Hub.

The strength of self-hosted tools is cost (effectively zero for hosting) and data sovereignty (your reports stay on your infrastructure). The weakness is operational overhead — you have to run the tool, keep it updated, configure receivers, and interpret the output yourself. For an organization with technical capacity and time, this is the right answer. For an organization that can't dedicate someone to the work, it isn't.

Low-cost SaaS. This is the tier we recommend to most small-to-mid clients. The two we consistently use are:

• URIports at approximately $1 per domain per month. URIports ingests aggregate reports, parses them, breaks them down by source IP, and presents the data in a web UI that makes it possible to identify legitimate sources, flag failures, and act on findings. Beyond DMARC, URIports also processes browser security reports, MTA-STS TLS-RPT reports, and other modern security telemetry. For a small organization with a handful of domains, the cost is in the noise and the value is substantial.

• dmarcian has a free tier that covers up to 5,000 daily mail volume on a single domain. Beyond that, their paid tiers start at around $25/month. The free tier is genuinely useful — full report ingestion, source identification, and a usable web UI. The dmarcian team has been in DMARC analysis since the protocol was introduced and their tooling reflects that depth.

Other entries in this tier include EasyDMARC, PowerDMARC, and ValiMail. Each has its own strengths and pricing structures. For most small organizations, the choice between them is more about UI preference than capability — they all do the basic job of "ingest reports, give me a readable view."

Enterprise platforms. Red Sift OnDMARC, Cisco Email Threat Defense, ProofPoint Email Fraud Defense, and Valimail Enforce sit at the top of the market. These platforms add features like automated SPF flattening, BIMI deployment, threat intelligence overlays, integration with security information and event management (SIEM) systems, and managed services. The pricing typically starts at $1,000+ per month and scales with domain volume and feature set.

For organizations with hundreds of domains, complex sending environments, regulatory requirements, or dedicated security teams, the enterprise tier earns its cost. For the IT leader at a volunteer organization sending newsletters, it's massive overkill.

What to Actually Look For

Once you have a tool that gives you a readable view of your aggregate reports, the analysis work breaks into a few categories:

Identifying your legitimate sending sources. The first pass is to identify every source IP or sender block that should be sending under your domain. Your corporate mail platform (Google or Microsoft IPs). Your ESPs (SendGrid, Mailgun, Amazon SES). Your CRM. Any SaaS tools that send transactional or marketing mail under your domain. For each, you should be able to see authentication passing — DKIM signed by the expected domain, SPF authorized via your published includes.

If you see sources you don't recognize, that's the first investigation. Sometimes they're legitimate but forgotten (an old CRM that someone in marketing still uses). Sometimes they're forwarders (your mail being forwarded by recipients to other accounts). Sometimes they're spoofing attempts. The distinction comes from the volume pattern, the IP geography, and whether authentication is passing or failing.

Failures from legitimate sources. A legitimate source that's failing authentication is the immediate priority. SPF failures usually mean the source's IPs aren't in your SPF record (or the record has expired, or there's a typo). DKIM failures usually mean the source isn't signing under your domain, or its DKIM record is misconfigured. In either case, the fix is on your side — update DNS, work with the vendor to enable signing, or both.

Failures from unknown sources. Mail that's failing authentication and isn't from a source you recognize is the spoofing signal. At p=none, you can see this happening but the mail still delivers. At p=quarantine or p=reject, the policy is doing what it should — blocking or marking the spoofed mail. Either way, the volume and pattern of spoofing attempts is intelligence about who is targeting your domain.

Sources that disappear. If a source you previously saw stops appearing, that's worth checking. Sometimes it means a vendor changed infrastructure (their old IPs aren't being used anymore). Sometimes it means a campaign ended. Sometimes it means a service got decommissioned and nobody told IT.

The cadence of this analysis depends on the size of your environment. For a small domain with a few sending sources and minimal change, a weekly review of the reports is sufficient. For a domain in active DMARC rollout (moving from p=none to enforcement), daily review during the transition is appropriate. For a steady-state enforced environment, monthly is fine for most organizations.

The Common Pitfalls

A few patterns we encounter in audits of organizations that have been "reading their DMARC reports" for a while:

Treating "all passing" as success. If 100% of mail in your reports is passing authentication, the temptation is to declare victory and stop looking. But "all passing" can also mean "everything that's reaching the reporting receivers is passing, and we're not seeing the failures because they're being silently dropped somewhere upstream." The check is to verify your volume against expectations. If you expect to send 50,000 messages a week and your reports show 47,000, that's reasonable. If they show 5,000, something is missing.

Ignoring small-volume failures. A source that's failing authentication on five messages a week is easy to dismiss as noise. It might be — a single misconfigured user agent, a one-off forwarder, a stray test. It might also be a spoofing attempt that's testing whether you're paying attention. In our audit work, low-volume persistent failures from sources you can't identify warrant investigation more often than not.

Reading the apex only. If your domain has subdomains in active use (mail.example.com, marketing.example.com), each subdomain has its own DMARC reporting flow if you've configured it that way. Reading only the apex reports gives you an incomplete picture. The same source IPs may appear differently across the apex and subdomains depending on alignment and signing configuration.

Misreading forwarded mail as spoofing. A common pattern: mail you sent to a recipient who has set up forwarding to another account. The forwarding server appears in your reports as a source IP, with failing SPF (because the forwarder isn't authorized in your SPF) and possibly failing DKIM (if the forwarder modified the message). At low volumes, this is normal and you can ignore it. At high volumes, it might be worth investigating ARC and considering changes to your sending configuration to reduce forwarding-induced authentication failures. It's almost never spoofing.

What URIports Specifically Looks Like

For the volunteer org case that prompted this post, our specific recommendation was URIports because it solves the immediate problem (readable DMARC reports) at a price that doesn't require approval from a finance committee. The setup takes about ten minutes:

1. Sign up at uriports.com
2. Add your domain to the account, which generates a custom RUA address (something like c8f4e2.dmarc@uriports.com)
3. Update your domain's DMARC record to include that address in the rua= field
4. Wait 24-48 hours for reports to start arriving
5. Log into the UI and start reviewing

Beyond aggregate report parsing, URIports also handles:

• TLS-RPT reports for MTA-STS monitoring
• Browser security reports (CSP, NEL, etc.) for organizations that want a unified reporting endpoint
• Source IP geographic and reputation overlays
• Alerting on changes to your DMARC, SPF, or DKIM records

For organizations with more than a handful of domains, the per-domain pricing model means costs scale linearly — at 20 domains, you're at $20/month, which is still trivial compared to enterprise tooling. At 200 domains, the math starts to favor the next tier up, but most organizations don't get there.

We've deployed URIports across hundreds of client domains over the past several years. The product is unflashy, the pricing is honest, and the data is reliable. It's not the right tool for every environment — high-volume enterprise senders with complex multi-team workflows will eventually outgrow it — but for the band of organizations between "small business" and "Fortune 1000," it's the best price-to-capability ratio in the market.

The Important Part

The tooling matters less than the discipline of looking at the reports. We've seen organizations with $50,000/year DMARC platforms whose reports were not being reviewed by anyone — because the alerting wasn't configured, or the dashboard owner left the company, or the data was being routed to a queue nobody monitored. We've seen organizations with dig and a spreadsheet maintaining better security posture, because someone was paying attention.

For most small and mid-sized teams, the right configuration is: a low-cost SaaS tool, a weekly or bi-weekly review cadence, and a clear escalation path when an unfamiliar source appears. The cost is in the tens of dollars per month. The value is the difference between "we have DMARC configured" and "we know what our DMARC reports are telling us."

If your reports are still gobbledygook, that's solvable today, not over a budget cycle.

---

Written by the team at SH Consulting. If you want help interpreting your DMARC reports, setting up monitoring, or moving from p=none to enforcement with confidence, book a call.