How to Read a DMARC Report (and What to Do With It)

A DMARC aggregate report is a daily XML summary from a receiving server listing every IP address that sent mail using your domain, how many messages each sent, and whether they passed SPF, DKIM and DMARC alignment. Reading one means checking the published policy, then working through each record row to sort sources into legitimate senders, forwarders and impostors.

What actually arrives in the mailbox

Once your DMARC record includes a rua tag, receiving organisations that support reporting start sending aggregate reports to that address. Each report covers a time window, usually 24 hours, and summarises all the mail that receiver saw claiming to be from your domain during that window.

The reports arrive as email attachments, compressed as .gz or .zip. The file name follows a convention that already tells you a great deal: the reporting organisation, your domain, and the start and end of the reporting period as Unix timestamps, separated by exclamation marks. For example, a report from a large mailbox provider about yourcompany.co.za covering one day carries both of those details in its name before you open it.

Expect volume. A domain that sends to many different organisations will receive reports from many of them, every day. A small business might get a handful; a busy domain can get dozens. Three practical rules follow:

• Send rua to a dedicated address or reporting service, never a person’s inbox.
• Do not judge your domain on one report. One receiver sees only its own slice of your traffic.
• Remember that reports describe what happened, not what will happen. They are evidence, not configuration.

Anatomy of an aggregate report

Unzip a report and you get a single XML document with a root element called feedback. Inside are three parts that matter.

1. Report metadata

The report_metadata block identifies who sent the report (org_name and a contact email), a unique report_id, and a date_range with begin and end timestamps. This is housekeeping, but it is how you avoid double-counting and how you know which receiver’s view you are looking at.

2. Policy published

The policy_published block records the DMARC policy the receiver found when it looked up your record: domain, adkim and aspf (alignment modes, r for relaxed or s for strict), p, sp and pct. Always check this first. If you changed your record yesterday and the report shows the old policy, you are looking at data gathered before the change, or the receiver cached the old value.

3. Record rows

The bulk of the report is a series of record elements. Each one represents a group of messages that shared the same characteristics:

Evaluated vs raw results: the most misread part

Every record contains two sets of authentication results, and confusing them is the most common reading error.

auth_results shows the raw outcome of each check. DKIM may say pass for d=mailer-platform.example, and SPF may say pass for bounces.mailer-platform.example. Those are genuine passes, but for domains that are not yours.

policy_evaluated shows whether those results count for DMARC, which requires the authenticated domain to align with header_from. In the example above, both raw results pass but both evaluated results are fail, because neither domain aligns with yourcompany.co.za. DMARC fails.

This is exactly the pattern you see when a newsletter or invoicing platform sends as you without custom domain authentication. The detail of why this happens is in DMARC alignment explained, and the SPF side of it in why SPF pass does not always mean safe.

Sorting sources into three buckets

Aggregated over a few weeks, every source IP in your reports falls into one of three buckets. Sorting them is the core skill.

Identifying an IP usually starts with a reverse DNS lookup and the owning network. A source whose reverse DNS points at a well-known email platform is likely a service someone in the business signed up for. Ask around before assuming it is malicious: finance, marketing and HR adopt tools without telling IT, and our guide to the services that send as you lists the usual culprits.

A note on shared infrastructure

Be careful with conclusions drawn from IP ownership alone. Large email platforms send for thousands of customers from shared pools of addresses, so an IP belonging to a well-known newsletter service tells you which platform sent the mail, not which account. If that platform appears failing alignment and nobody in the business admits to using it, it may be a forgotten account, a supplier sending on your behalf, or someone abusing the platform to impersonate you. The DKIM domain and selector in auth_results are often the best clue, because they show which account signed the message.

A triage framework: what to fix first

Do not try to fix everything at once. Work in this order, weighted by volume and business impact:

1. Confirm the policy published is what you intended, and that all reporting receivers see the same record.
2. Check your primary mailbox platform. Microsoft 365 or Google Workspace traffic should be the largest aligned block. If it is failing DKIM alignment, nothing else matters until that is fixed.
3. Fix high-volume legitimate senders that fail: newsletters, invoicing, CRM. These carry the most business risk once you enforce.
4. Fix low-volume but critical senders: payroll notifications, statements, the website contact form. Small counts, high consequences.
5. Note forwarders and move on, unless a significant partner relies on forwarding that strips your DKIM.
6. Record unknown sources over time. Consistent failure from unrelated networks is the case for enforcement, not a reason to delay it.

Repeat this across at least one full business cycle. The goal is a report where everything you recognise passes, and everything that fails is something you would want blocked. At that point, staying on p=none is a choice to leave the door open, as we explain in why monitoring-only DMARC is a false sense of security.

Signs a report needs urgent attention

• A sudden new source sending large volumes as your domain.
• Your own mailbox platform appearing with dkim=fail after a configuration change.
• A disposition of quarantine or reject on messages you know are legitimate.
• Reports showing an SPF permerror, which usually means too many lookups or duplicate records.

Why forensic (ruf) reports are rarely used

DMARC also defines failure reports, requested with the ruf tag. These are per-message reports about individual failures and can include headers or portions of the message itself.

In practice they are of limited use. Many large mailbox providers do not send them at all, largely because of privacy concerns about passing message content to a third party. Those that do send them may redact the content. For a South African business, collecting copies of other people’s messages also raises questions under POPIA that most do not want to answer for marginal benefit.

Aggregate reports give you everything needed to reach and maintain enforcement. Our recommendation is to omit ruf unless you have a specific investigative need and a process for handling what arrives.

How MailMarq helps

Reading XML every morning is not a good use of a finance manager’s or IT generalist’s time. MailMarq collects and interprets your aggregate reports, identifies every source, chases the senders that need fixing and gives you plain-language summaries, as described on how it works. Talk to us about a free assessment.

Frequently asked questions

MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.