DMARC Reporting: Turn Aggregate Reports Into Fixes

DMARC reporting turns email authentication results into operational data. If you read it well, you can find unauthorized senders, broken third-party tools, and alignment failures before they turn into blocked mail.

What DMARC reporting is

DMARC reporting is the feedback loop that tells you how mailbox providers evaluate mail claiming to be from your domain.

DMARC sits on top of SPF and DKIM. It checks whether the visible Header From domain aligns with the domain authenticated by SPF or DKIM. Then it applies your policy:

• p=none — monitor only.
• p=quarantine — ask receivers to treat failing mail as suspicious.
• p=reject — ask receivers to reject failing mail.

Reporting gives you the evidence behind those decisions.

A basic DMARC record with reporting looks like this:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-forensic@example.com"

Aggregate reports versus forensic reports

DMARC has two report types.

Report type	DMARC tag	What it contains	Best use
Aggregate reports	rua	Daily summary data grouped by source, authentication result, alignment, and disposition	Finding patterns and fixing sending infrastructure
Forensic reports	ruf	Samples or event-level failure reports, when supported	Investigating specific failures or abuse cases

Most teams rely on dmarc aggregate reports. They are more widely supported, less sensitive, and easier to use for operational troubleshooting.

Forensic reports are less common. Many mailbox providers do not send them, or they redact details heavily. Treat them as optional evidence, not your main workflow.

What rua and ruf mean

The rua tag tells receivers where to send aggregate reports.

rua=mailto:dmarc-aggregate@example.com

The ruf tag tells receivers where to send forensic failure reports.

ruf=mailto:dmarc-forensic@example.com

You can send reports to a mailbox you control, a vendor mailbox, or both. If reports go to a domain different from the one being monitored, that external destination usually needs authorization through DNS.

What reports include and do not include

DMARC aggregate reports usually include:

• Reporting organization.
• Report date range.
• Source IP.
• Message count.
• Header From domain.
• SPF result.
• DKIM result.
• SPF alignment result.
• DKIM alignment result.
• Final DMARC disposition: none, quarantine, or reject.

They usually do not include:

• Full message content.
• Recipient addresses.
• Subject lines.
• Click or open data.
• Bounce reason text.
• Complaint details.
• Proof that a sender is legitimate.

That last point matters. A report can show that an IP sent 20,000 aligned messages for your domain. It cannot tell you whether those messages were wanted, whether the list was clean, or whether the campaign harmed engagement.

Why DMARC reports are hard to read

DMARC reports are hard to read because they arrive as XML summaries from many providers, each with slightly different reporting behavior.

A raw report often arrives as a compressed attachment. Inside, you see dmarc xml reports like this:

<record>
  <row>
    <source_ip>203.0.113.42</source_ip>
    <count>18420</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>mail.example.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

That is readable for one record. It becomes painful when you receive thousands of records across Google, Yahoo, Microsoft, and regional mailbox providers.

XML is not the real problem

XML is annoying, but volume is the real problem.

A single day of reporting may include:

• Your primary marketing platform.
• Your transactional email provider.
• CRM sequences.
• Billing software.
• Help desk notifications.
• Old systems nobody remembers.
• Forwarded messages.
• Mailing lists.
• Spoofing attempts.
• Cloud apps sending as your domain.

If you inspect each row manually, you will waste time. You need grouping.

Patterns matter more than one-off failures

One-off failures happen. They come from forwarding, mailing lists, temporary DNS lookups, or receiver-side quirks. Do not overreact to a single row with a low count.

Look for patterns like:

• One source IP sending thousands of messages with SPF alignment failing.
• A known platform passing DKIM for its own domain but not yours.
• A legacy tool sending unauthenticated mail every weekday.
• A sudden burst from IPs you do not recognize.
• Quarantine or reject dispositions on legitimate mail.

A practical rule: fix high-volume, repeatable failures before low-volume noise.

Privacy limits and provider differences

DMARC reports are intentionally limited. Receivers avoid exposing personal data. That is good for privacy, but it means you lose context.

You may also see differences between mailbox providers:

• Some send reports daily. Others send irregularly.
• Some include detailed DKIM selector data. Others do not.
• Some report forwarded mail differently.
• Some aggregate source IPs in ways that reduce precision.
• Some send fewer reports at low volume.

So do not treat one provider’s report as the full truth. Use multiple days and multiple receivers before making a hard call.

The fields that matter in aggregate reports

The most important fields in aggregate reports are source, volume, authentication results, Header From domain, disposition, and alignment.

You do not need to memorize every XML element. You need to answer six operational questions.

Source IP and sending volume

Source IP tells you where the receiving provider saw the message come from. Volume tells you how much mail came from that source.

Use these together.

Source pattern	What it may mean	What to do
High volume from known platform	Legitimate sender, possibly misconfigured	Check SPF, DKIM, and alignment
High volume from unknown IPs	Possible spoofing or forgotten system	Investigate ownership and logs
Low volume from random IPs	Background spoofing or forwarding noise	Monitor unless it grows
Sudden new source	New vendor, compromised tool, or abuse	Validate with internal owners

Source IP alone does not always identify a vendor. Many platforms use large shared IP ranges. Combine IP data with DKIM domains, SPF domains, reverse DNS, and your own vendor inventory.

SPF and DKIM pass/fail results

SPF and DKIM results show whether the message authenticated at all.

SPF passes when the sending IP is authorized by the envelope sender domain. DKIM passes when a valid cryptographic signature verifies for a signing domain.

But DMARC does not only care about pass or fail. It cares about alignment with the visible From domain.

Example:

Header From: example.com
SPF authenticated domain: vendor-mail.com
DKIM signing domain: vendor-mail.com

SPF and DKIM may pass for vendor-mail.com. DMARC can still fail if neither domain aligns with example.com.

Header From domain

The Header From domain is the domain users see in their email client.

For DMARC, this is the anchor. SPF or DKIM must align with it.

If you use subdomains, watch them closely:

• example.com
• news.example.com
• mail.example.com
• billing.example.com

Your DMARC policy and alignment mode determine how strict matching needs to be. Relaxed alignment allows organizational-domain matches. Strict alignment requires an exact match.

Disposition: none, quarantine, or reject

Disposition shows what the receiver did after evaluating your DMARC policy.

• none means the receiver monitored the mail and did not apply a DMARC enforcement action.
• quarantine means the receiver treated failing mail as suspicious. It may go to spam.
• reject means the receiver rejected failing mail during SMTP or blocked it from delivery.

During rollout, you usually start with p=none. You use reports to fix legitimate senders. Then you move toward quarantine and reject when failures are understood.

Alignment outcomes

Alignment is where many teams misread DMARC.

A message can have:

• SPF pass, SPF alignment fail.
• DKIM pass, DKIM alignment fail.
• SPF fail, DKIM pass and aligned.
• SPF pass and aligned, DKIM fail.
• Both fail.
• Both pass.

DMARC passes if either SPF or DKIM passes and aligns.

That means you do not always need both SPF and DKIM aligned for every stream, but you should prefer DKIM alignment where possible. DKIM survives forwarding better than SPF.

How to analyze DMARC reports step by step

A good DMARC report analysis workflow groups mail by source, classifies each sender, separates authentication failures from alignment failures, and prioritizes by volume.

1. Group by sending source

Start with a pivot table or parser. Group records by:

• Source IP.
• DKIM signing domain.
• SPF authenticated domain.
• Header From domain.
• Provider that sent the report.
• Message count.
• Disposition.

Your goal is to turn raw rows into sender clusters.

For example:

Cluster	Evidence	Likely owner
Marketing platform	DKIM domain contains known vendor; steady weekday volume	Lifecycle team
Transactional provider	High volume; app subdomain; DKIM aligned	Engineering
CRM	Sales cadence timing; vendor return-path	RevOps
Unknown IP range	No known DKIM domain; random volume	Investigate

Keep a simple inventory. Include platform name, owner, domain used, DKIM status, SPF alignment status, and notes.

2. Separate authorized platforms from unknown senders

For each source, ask: did we authorize this system to send as our domain?

Use your internal records:

• DNS records.
• Email service provider settings.
• Marketing automation tools.
• Product notification systems.
• CRM and sales engagement platforms.
• Help desk and support tools.
• Billing, invoicing, and payroll systems.
• Legacy servers and cron jobs.

Then classify each source:

• Authorized and healthy — aligned DMARC pass.
• Authorized but broken — legitimate platform failing authentication or alignment.
• Unknown but probably benign — forwarding, mailing list, or low-volume noise.
• Unknown and suspicious — high-volume or repeated unauthenticated mail.
• Obsolete — old sender still active or still authorized in DNS.

This classification prevents two common mistakes: blocking a legitimate tool too early, or ignoring a real spoofing pattern because it looks like report noise.

3. Identify alignment failures versus authentication failures

Next, decide what actually failed.

Authentication failure means SPF or DKIM did not pass. Alignment failure means SPF or DKIM passed, but for the wrong domain.

Here is the difference:

Finding	Likely issue	Fix direction
DKIM fails for your domain	Bad selector, missing DNS key, signing disabled	Correct DKIM setup
SPF fails for return-path domain	Sending IP not included, DNS lookup issue	Fix SPF record or sender config
SPF passes but alignment fails	Envelope sender uses vendor domain	Configure custom return-path
DKIM passes but alignment fails	Vendor signs with its domain, not yours	Enable branded DKIM
Both pass but DMARC fails	Check Header From domain and alignment mode	Review domain configuration
Failures only after forwarding	SPF breaks in transit	Rely on aligned DKIM where possible

This is where most dmarc failure reasons become clear. Do not just ask “did SPF pass?” Ask “did SPF pass for a domain aligned with the Header From domain?”

4. Prioritize high-volume failures first

Fix the biggest repeatable issues first.

A useful priority order:

1. Legitimate high-volume mail failing DMARC.
2. Legitimate mail receiving quarantine or reject.
3. Unknown high-volume sources.
4. Critical business systems, even at lower volume.
5. Medium-volume misalignments.
6. Low-volume failures and forwarding noise.

Tie priority to risk. A billing system sending 500 failed messages can matter more than a newsletter test sending 2,000 failed messages. But in general, volume gives you the fastest reputation and delivery gain.

Common fixes based on report findings

The right fix depends on whether the report shows an authentication failure, an alignment failure, an obsolete sender, or abuse.

Add or correct DKIM for third-party platforms

If a legitimate platform sends mail as your domain, configure branded DKIM.

Most platforms ask you to publish one or more CNAME or TXT records. After that, they sign mail with a domain aligned to yours.

Check for these mistakes:

• DKIM records published under the wrong selector.
• DNS value copied with missing characters.
• DKIM enabled in DNS but not activated in the platform.
• The platform signs with its default domain instead of your domain.
• You changed the sending subdomain but did not update DKIM.

DKIM is often the cleanest DMARC fix because it does not depend on the sending IP at final delivery. It also holds up better when messages are forwarded.

Configure a custom return-path for SPF alignment

If SPF passes but SPF alignment fails, look at the envelope sender or return-path domain.

Many vendors default to a return-path like:

bounce.vendor-mail.com

That may pass SPF for the vendor. But it does not align with:

Header From: example.com

A custom return-path fixes this by using a domain you control, such as:

bounce.example.com

or:

mail.example.com

The vendor usually gives you a CNAME record. After setup, SPF can authenticate an aligned domain.

SPF alignment is useful, but do not rely on SPF alone. Forwarding can break SPF. Use DKIM alignment as your stable baseline.

Remove obsolete senders

DMARC reports often expose old systems.

You may find:

• A retired ESP still sending.
• A staging app using production From addresses.
• A legacy server with direct SMTP access.
• An old CRM integration.
• SPF includes for vendors you no longer use.

Fix the sending system first. Then clean DNS.

SPF records collect stale includes over time. That creates risk. It also makes SPF harder to maintain and can push you toward DNS lookup limits.

Remove obsolete authorization only after you confirm the sender is no longer needed. Coordinate with the system owner. Then monitor reports for a few days to confirm the source disappeared.

Escalate suspected spoofing sources

Spoofing usually shows up as unknown sources failing both SPF and DKIM.

Common signs:

• Random IP ranges.
• No aligned DKIM.
• No authorized return-path.
• Short bursts across multiple receivers.
• Header From uses your root domain or executive-style addresses.
• Volume grows suddenly.

For low-volume background spoofing, monitoring may be enough while you move toward enforcement.

For high-volume or targeted abuse:

1. Preserve report evidence.
2. Check whether any internal system owns the traffic.
3. Search logs for matching campaigns.
4. Escalate to security or incident response.
5. Report abuse to the hosting or network provider when appropriate.
6. Tighten DMARC policy when legitimate senders are ready.

DMARC does not stop every phishing technique. It does make direct domain spoofing harder once you enforce quarantine or reject.

DMARC reporting and broader deliverability health

DMARC reports show authentication health, not full deliverability health.

They tell you whether mail claiming to be from your domain passed DMARC at participating receivers. They do not tell you whether your recipients are valid, engaged, or complaining.

Authentication is only one layer

Strong authentication helps mailbox providers trust that your mail is really yours. It also protects your brand from direct spoofing.

But inbox placement also depends on:

• Bounce rate.
• Spam complaint rate.
• Recipient engagement.
• Sending consistency.
• Content and link reputation.
• List acquisition practices.
• Complaint handling.
• Unsubscribe behavior.
• Sending domain and IP history.

You can have perfect DMARC alignment and still deliver poorly if you send to bad addresses or unengaged recipients.

Connect authentication fixes with bounce reduction

DMARC can show that your marketing platform authenticates correctly. It cannot show whether the addresses in that campaign are deliverable.

That is where list hygiene matters.

Before you send, verify addresses at capture and before large campaigns. A real-time verification API can catch:

• Invalid mailboxes.
• Disposable domains.
• High-risk catch-all domains.
• Role accounts.
• Common typos like gmial.com.
• Risky or unknown addresses that need different handling.

Bounceable fits here when you need to validate addresses before they enter your CRM, product, or campaign workflow. DMARC reduces authentication failures. Verification reduces avoidable bounces. You need both if you care about sender reputation.

Review reports on a recurring cadence

DMARC reporting works best as a routine, not a one-time project.

Use this cadence:

Cadence	What to review
Daily during setup	New sources, high-volume failures, policy impact
Weekly after stabilization	Trends, broken vendors, unknown senders
Monthly	Sender inventory, stale SPF includes, subdomain usage
Before policy changes	All legitimate sources passing aligned DMARC
After adding a vendor	DKIM, return-path, volume, disposition

A practical rollout looks like this:

1. Publish DMARC with p=none and rua.
2. Collect at least a few weeks of aggregate reports.
3. Build a sender inventory.
4. Fix legitimate high-volume failures.
5. Remove or disable obsolete senders.
6. Investigate suspicious sources.
7. Move selected subdomains or the root domain toward quarantine.
8. Monitor impact.
9. Move toward reject when failures are understood.
10. Keep reviewing reports as new tools get added.

Do not assume the system stays clean. Marketing adds platforms. Sales tests tools. Engineering ships notifications. Finance changes billing vendors. Every new sender can break alignment if nobody checks it.

DMARC reporting gives you the map. Your job is to turn that map into ownership, fixes, and a repeatable review process.