Introduction
DMARC reports can feel overwhelming at first. You get zipped XML files, unfamiliar IP addresses, and a long list of pass/fail results that do not clearly tell you what to fix. But once you know what to ignore and what to focus on, DMARC reports become one of the most useful tools for finding authentication alignment problems and spotting unauthorized sources sending as your domain.
This guide is written for SaaS and development teams sending transactional email such as OTPs, password resets, receipts, and security alerts. It explains the difference between aggregate (RUA) and forensic/failure (RUF) reports, how alignment works in DMARC, and a practical triage method that turns noisy XML into a short and useful fix list.
DMARC is built to help domain owners publish a policy and receive feedback from receivers, so you can improve your setup over time without guessing. To get started, you can review your setup in the Mailcub documentation and confirm which domains should appear in your DMARC alignment.
The goal is not perfection. The goal is a calm workflow that helps you take the next action quickly.
Quick Answer
- Start with DMARC aggregate reports (RUA) because they are easier to triage and better for daily use.
- Focus on alignment, not only SPF or DKIM pass results.
- Sort by volume first, then check the DMARC disposition (none, quarantine, reject).
- Unknown high-volume sources may be a legitimate sender you forgot or a spoofing source, so verify before blocking.
- Parse XML into a table so you can filter high-count failures quickly.
- RUF reports are optional for many teams. RUA is often enough for most fixes.
Why DMARC Reports Matter
If your authentication is misaligned, inbox placement can become inconsistent across providers. That often leads to “missing email” complaints, which is especially painful for transactional email when users cannot log in or reset a password.
DMARC reports also improve security. They help you detect spoofing attempts and unknown senders early, before they become a larger brand or support issue. When you work from report data instead of assumptions, your fixes are usually smaller, safer, and easier to verify.
DMARC Reports Basics: RUA vs RUF
Most teams will see two types of DMARC reports:
- RUA (aggregate): summarized results over a time window, usually daily
- RUF (forensic/failure): message-level failure samples, often limited or redacted
Start with RUA reports first. They are lower noise and usually enough to solve alignment problems and identify unknown senders.
Step-by-Step Workflow
1) Create a DMARC intake that does not overwhelm you
Set up a dedicated mailbox or pipeline for DMARC reports so they do not clutter your support or main team inboxes.
- RUA mailbox: dmarc@yourdomain.com
- Optional RUF mailbox: forensic@yourdomain.com
Do not route these to your support inbox. DMARC report volume increases as your sending traffic grows.
2) Parse DMARC reports into rows instead of reading raw XML
RUA reports are designed for automated processing, not manual reading. Convert the XML into a table so you can filter and sort quickly.
Your table should include:
- Source IP
- Message count
- SPF result and aligned domain
- DKIM result and aligned domain
- DMARC policy disposition
Once the data is in rows, triage becomes much faster and easier.
3) Understand alignment
This is the most common DMARC confusion. DMARC passes when the visible From domain aligns with the domain validated by SPF or DKIM.
That means you can still see cases like:
- SPF pass but DMARC fail: SPF passed for a different domain, so it is not aligned
- DKIM pass but DMARC fail: DKIM passed, but the DKIM signing domain does not align with the From domain
This is why an SPF pass by itself is not enough.
4) Triage by impact first (volume before everything)
For each source row in your parsed report:
- Sort by message count from highest to lowest
- Check DMARC disposition (none, quarantine, reject)
- Identify whether the failure is SPF alignment or DKIM alignment
- Decide if it is a legitimate sender that needs fixing or an unauthorized sender that should be blocked
This approach prevents you from wasting time on tiny anomalies while high-volume failures continue. You can use the Mailcub docs to run a traceable test send and compare a known-good result in your logs and reports.
5) Map unknown sources to real systems before changing policy
When you find an unfamiliar source IP, do not immediately block it. First, confirm whether it belongs to a system you actually use.
Check if it might be:
- A billing system
- A CRM or marketing tool
- A helpdesk platform
- An authentication provider
- A cloud region your team uses
- A partner sending on your behalf
Only after you identify the source should you update SPF, DKIM, or your DMARC policy.
6) Apply one fix at a time, then re-check reports
Make one change, then watch the next few report cycles before changing anything else. This makes it easier to see what actually improved.
Common fixes include:
- Aligning the envelope-from or return-path domain with your visible From identity
- Correcting the DKIM signing domain (d=) and publishing the right selector
- Moving special senders to a dedicated subdomain (for example, separating marketing and transactional)
After each fix, monitor your reports for a few days to confirm the result. If you are sending product-critical email, you can also review the Transactional Email product and check the pricing page while planning your implementation.
DMARC Reports Cheat Sheet
| DMARC reports pattern | Likely cause | What to check first | Fix |
|---|---|---|---|
| High volume, DMARC fail, SPF pass | SPF not aligned | From domain vs SPF-auth domain | Align envelope-from or use a matching subdomain strategy |
| High volume, SPF fail, DKIM fail | Unauthorized or misconfigured vendor | Identify sender or service | Authorize sender and sign with DKIM, or block |
| DMARC pass via DKIM, SPF fail | DKIM is carrying the pass | DKIM domain and selector stability | Keep DKIM stable and fix SPF later |
| Many small failing sources | Background spoofing noise | Trends and top ASNs | Monitor and tighten policy after legitimate streams are clean |
| Reports stop arriving | Mailbox or DMARC record issue | rua mailbox and DMARC record syntax | Fix mailbox acceptance and record syntax |
Common Mistakes
- Reading raw XML manually instead of parsing it first
- Treating SPF or DKIM pass as success without checking alignment
- Moving to quarantine or reject before all legitimate senders are aligned
- Ignoring high-volume failures while chasing very small anomalies
- Changing multiple settings at once and making troubleshooting harder
Troubleshooting
SPF pass but DMARC fail
This is usually an alignment mismatch. SPF passed, but it passed for a different domain than the visible From domain.
Fix: Align the envelope-from or return-path identity with the From domain, or move the stream to a subdomain that matches the From identity.
We are not receiving DMARC reports
Check these first:
- Your DMARC record includes a valid rua=mailto: destination
- The mailbox accepts large attachments and is not filtering reports
- You have waited long enough for daily report batches (timing varies by receiver)
Too many sources — how do I know what is mine?
Start with the highest-volume sources first. Map each one to a real system such as your transactional provider, CRM, or billing platform. Unknown high-volume sources should be your first priority for investigation.
FAQ
What are DMARC reports and why are they XML?
DMARC reports are feedback messages from receiving servers that summarize authentication and policy results for your domain. Aggregate reports are in XML because they are meant for automated processing at scale.
What is the difference between RUA and RUF DMARC reports?
RUA reports are aggregate summaries over a time period, often daily. RUF reports are message-level failure samples and may be limited or redacted depending on receiver privacy policies.
What does alignment mean in DMARC reports?
Alignment means the domain in the visible From header matches the domain validated by SPF or DKIM under your DMARC settings. DMARC passes when the From domain aligns with SPF or DKIM identity.
Why does SPF pass but DMARC fail?
Usually SPF passed for a different domain than the visible From domain, so it was not aligned for DMARC. You can fix this by aligning the envelope-from domain or using a dedicated subdomain strategy.
How often do DMARC aggregate reports arrive?
Many receivers send aggregate reports in batches, commonly daily, but exact timing can vary by provider.
Do I need RUF (forensic) DMARC reports?
Not always. Many teams start with RUA reports and fix most alignment and sender authorization issues without using RUF. RUF can still help in investigations, but it may add operational complexity.
Conclusion
DMARC reports become much easier once you stop treating them like reading material and start using them as structured data. Parse RUA reports into rows, sort by volume, verify alignment, and fix one sender at a time. Over a few report cycles, you can reduce unknown sources, stabilize authentication, and shorten deliverability troubleshooting time.
To keep this process simple, use the Mailcub documentation as your reference point, test your sending flow with the Transactional Email product, and review the pricing options if needed.