Reading DMARC Aggregate Reports Like a Pro

DMARC aggregate reports are how you find out who is actually sending mail on behalf of your domain. They arrive as daily XML files from every major mailbox provider, listing each sending IP that claimed your From domain, what authentication results it produced, and what action the receiver took. Read correctly, they let you move from p=none to p=reject without breaking legitimate mail.

This guide covers the XML format, what each DMARC tag controls, how to interpret common patterns, and the workflow I use to take clients from monitoring to enforcement.

What's in a DMARC aggregate report

A DMARC aggregate report XML has three main sections:

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <date_range>...</date_range>
  </report_metadata>
  <policy_published>
    <domain>yourdomain.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>192.0.2.1</source_ip>
      <count>1247</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>yourdomain.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>mailer.example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>yourdomain.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The key fields per record:

• source_ip — IP that sent the mail
• count — number of messages from that IP in the period
• header_from — From: header domain
• dkim/spf auth_results — did each check pass on its own
• policy_evaluated.dkim/spf — did each check produce DMARC alignment
• disposition — what the receiver did (none / quarantine / reject)

DMARC tags reference

Tag	Purpose	Common value
v	Version (required)	DMARC1
p	Policy for primary domain	none / quarantine / reject
sp	Subdomain policy	inherits from p if absent
rua	Aggregate report destination	mailto:dmarc@...
ruf	Forensic report destination (rarely supported)	mailto:dmarc-forensic@...
adkim	DKIM alignment	r (relaxed) / s (strict)
aspf	SPF alignment	r (relaxed) / s (strict)
pct	Percent of mail to apply policy	0-100
fo	Forensic options	0 / 1 / d / s
ri	Reporting interval (seconds)	86400 (24hr)
rf	Report format	afrf (default)

For setup basics, see the DMARC setup guide.

What aggregate reports tell you

Once you start receiving reports, three things matter most:

1. Which sources are sending as you? Group by source IP and authentication domain. You should recognize every high-volume source.
2. Are legitimate sources aligning? A source can SPF-pass but DKIM-fail (or vice versa) and still produce DMARC alignment on one of the two. Look at policy_evaluated.
3. Where is shadow IT happening? Surprise sources — a marketing team using a tool you didn't authorize, an old vendor still sending — show up clearly.

Practitioner note: I always find at least two unauthorized senders in the first month of DMARC reporting for any company over 50 employees. Marketing tools, recruiting platforms, HR systems, third-party survey vendors — they all send "from" your domain without anyone in IT knowing. Aggregate reports are the only way to see them.

Reading reports without parsing XML

The raw XML is unreadable at scale. Use a parser. The major options:

Tool	Free tier	Notes
dmarcian	14-day trial	Most mature, strong UI
Postmark DMARC	Free, basic	Excellent free option
EasyDMARC	Limited free	Solid, agency-friendly
Valimail Monitor	Free for small senders	Acquired by Proofpoint
MXToolbox DMARC	Paid	Combines with their other tools

For most senders, Postmark's free DMARC monitoring is the right starting point. Upgrade to dmarcian or Valimail if you need agency features.

Common patterns and what to do

Pattern 1: Single source, 100% pass, recognized sender → Healthy. Nothing to do.

Pattern 2: New source, 100% fail, unknown IP → Investigate. Could be shadow IT, could be a spoof attempt.

Pattern 3: Recognized sender, 60% pass / 40% fail → Misconfigured. Usually a sub-account or new domain not properly added to SPF/DKIM.

Pattern 4: Forwarded mail (university, association mailing lists) → SPF will fail because the forwarder rewrites the path. DKIM should still align if the original sender signed. This is normal and unavoidable.

Pattern 5: Sudden spike from unknown IP, very high volume, all DMARC-fail → Active spoofing campaign. Your DMARC policy is protecting you; verify recipients aren't being hit.

Practitioner note: The biggest mistake at the start of a DMARC rollout is reacting to forwarder fails as if they were spoofs. Mailing list forwarders break SPF by design. DKIM should still align because the body signature survives forwarding. Don't tighten policy until you've separated forwarders from real spoofs.

Moving from p=none to enforcement

The standard staged rollout:

1. p=none for 4-8 weeks. Collect reports. Identify and authorize all legitimate senders.
2. p=quarantine; pct=10 for 2 weeks. Sample-test.
3. p=quarantine; pct=100 for 2-4 weeks. Monitor for issues.
4. p=reject; pct=10 for 2 weeks.
5. p=reject; pct=100. Done.

For the full path, see DMARC at 100% reject and DMARC none to reject.

When DMARC reports tell you nothing

If you're not receiving aggregate reports after 7+ days at p=none, check:

1. The rua= mailbox actually exists and accepts external mail
2. DNS for the rua mailbox's domain resolves
3. If the rua mailbox is on a different domain than your DMARC record, you need an authorization record (_report._dmarc.yourdomain.com TXT "v=DMARC1" on the destination domain)
4. The DMARC record itself is syntactically valid (validate with dmarcian or MXToolbox)

If you need help interpreting reports or planning a DMARC rollout, book a consultation. I do DMARC deployments from initial monitoring through enforcement for companies that need to clean up shadow senders and lock down their domain.

Sources

• RFC 7489 — DMARC — IETF
• DMARC.org overview — DMARC.org
• MXToolbox DMARC tag reference — MXToolbox
• Google DMARC documentation — Google
• dmarcian DMARC primer — dmarcian
• Postmark DMARC guide — Postmark

---

v1.0 · May 2026