Let’s Be Honest: DMARC Reports Look Like a Punishment
But not to worry, Morse will save you.
If you’ve ever opened a DMARC report and thought:
“Is this encrypted?”
“Is this a threat?”
“Did I accidentally download the Matrix?”
You’re not alone.
DMARC reports:
- Arrive daily
- Come as XML
- Contain zero vibes
- Are aggressively unfriendly to humans
Which is why most businesses do this:
- Publish DMARC
- Set p=none
- Ignore reports
- Never enforce policy
And that’s a shame – because DMARC reports are where the real value lives.
If you haven’t read the foundations yet, start here: DMARC: The Email Security Standard You Can’t Afford to Ignore.
This post is about turning reports into insight.
What DMARC Reports Actually Are (In Plain English)
DMARC reports are feedback loops from receiving mail servers.
They answer four critical questions:
- Who sent email claiming to be you?
- Where did it come from?
- Did SPF pass?
- Did DKIM pass?
- Did DMARC align?
- What action was taken?
That’s it.
They are not:
- Alerts
- Incidents
- Breach notifications
They are evidence.
The Two Types of DMARC Reports (One Matters More)
1. Aggregate Reports (RUA) – The Important Ones
Aggregate reports:
- Arrive daily
- Summarise all mail activity
- Show pass/fail counts
- Reveal spoofing and misconfigurations
These are your primary diagnostic tool.
If you only look at one type of DMARC report, look at these.
2. Forensic Reports (RUF) – The Optional Ones
Forensic reports:
- Are triggered per-failure
- May include message samples
- Are often blocked for privacy reasons
Useful in theory.
In practice? Rare, noisy, and often unavailable.
Most organisations don’t need RUF to enforce DMARC successfully.
Why DMARC Reports Matter So Much
DMARC reports show you things you cannot see anywhere else, including:
- Who is spoofing your domain
- Which third-party tools are misconfigured
- Which platforms forgot DKIM
- Which senders rely on SPF only
- Where alignment is broken
In other words:
Your entire email attack surface – daily.
Don’t ignore that, attackers won’t.
What’s Actually Inside a DMARC Aggregate Report
Let’s demystify the contents.
A DMARC aggregate report typically includes:
Source IP
Where the email came from.
Used to identify:
- Legitimate platforms
- Unknown senders
- Infrastructure you didn’t know existed
Header From Domain
The visible domain users see.
This is the brand identity DMARC protects.
SPF Result
- Pass / Fail / Softfail
Tells you whether the sending IP was authorised.
DKIM Result
- Pass / Fail
Shows whether the email was cryptographically signed correctly.
DMARC Result
- Pass / Fail
This is the final verdict after alignment is checked.
Policy Disposition
What action was taken:
- none
- quarantine
- reject
This is how you validate enforcement impact.
How to Read DMARC Reports Without Hating Your Life
Step 1: Ignore the XML
Seriously.
Unless you enjoy pain, don’t read raw XML.
Use:
- Morse
- A DMARC reporting tool
- A security dashboard
- A parser that turns data into charts
This is not cheating.
This is sanity.
Step 2: Identify Known Legitimate Senders
Your first job is classification.
Look for:
- Microsoft / Google IP ranges
- Marketing platforms
- CRMs
- Ticketing systems
If they fail:
- SPF
- DKIM
- Alignment
You’ve found a configuration issue – not an attack.
Step 3: Spot the Unknown Senders
This is where things get spicy.
Unknown IPs sending as your domain usually mean:
- Active spoofing
- Phishing campaigns
- Brand impersonation
If DMARC policy is enforced, these fail harmlessly.
If it’s not – they land.
Step 4: Look at Failure Volume
One failure might be:
- A misfire
- A test
- Noise
Thousands? That’s abuse.
Volume tells you intent.
Step 5: Validate Policy Behaviour
Check:
- Are failing emails being quarantined or rejected?
- Is enforcement behaving as expected?
- Are legitimate senders passing cleanly?
This step tells you whether you’re ready to move policies.
Policy progression is covered here: DMARC policy types explained: none vs quarantine vs reject.
The Big Mistake: Treating DMARC Reports as “Set-Up Only”
DMARC reports aren’t just for initial deployment.
They should be used:
- Continuously
- After system changes
- When adding new tools
- During incident investigations
Email ecosystems change.
DMARC reports show you when they do.
How DMARC Reports Support Business Decisions
This isn’t just technical data.
DMARC reports help you:
- Prove spoofing attempts were blocked
- Demonstrate “reasonable security controls”
- Support cyber insurance discussions
- Evidence governance maturity
Which is why insurers increasingly expect DMARC enforcement—covered here: Email authentication and cyber insurance requirements.
When DMARC Reports Reveal Something Uncomfortable
This happens more than people admit.
DMARC reports often expose:
- Shadow IT
- Legacy platforms
- Undocumented integrations
- “Temporary” solutions from years ago
This is not a failure.
It’s visibility.
And visibility is what allows enforcement.
DMARC Reports and Deliverability (Yes, They’re Related)
As you clean up:
- SPF failures
- DKIM misalignment
- Spoofing noise
Your domain reputation improves.
Which means:
- Better inbox placement
- Less spam filtering
- Higher trust with providers
This improves your email reputation and deliverability—for more on policy decisions: DMARC policy types explained.
The Morse Take
DMARC reports aren’t scary.
They’re honest.
They tell you:
- Who’s behaving
- Who’s broken
- Who’s attacking
Ignoring them doesn’t make email safer.
It just makes surprises bigger.
If DMARC is the lock,
reports are the CCTV.
And you don’t install CCTV just to never look at it.
Part of the DMARC Cluster
This article is part of our DMARC & Email Authentication series:
DMARC: The Email Security Standard You Can’t Afford to Ignore
Related reads:
- DMARC vs SPF vs DKIM
- DMARC policy types explained
- Common DMARC mistakes
- DMARC for Microsoft 365 and Google Workspace
- Email authentication and cyber insurance
Dot. Dash. Observed.