How to read your first DMARC report, line by line

A DMARC aggregate report is a summary that large email providers send to the address in your DMARC record, usually once a day. It lists each server, by IP address, that sent mail using your domain to that provider, how many messages it sent, and whether they passed SPF and DKIM. To read it, open the attached file in a report reader and sort each row into one of four kinds: your own mail, services you haven't authorized yet, forwarders, and strangers.

Where the reports come from

When your DMARC record includes a tag such as rua=mailto:dmarc@example.com, receivers that support reporting send aggregate reports to that address. Each large receiver sends its own, usually one a day. They arrive as an email with a compressed attachment, normally .zip or .gz, holding one XML file: a text format made for machines, with tags in angle brackets. Not every receiver sends reports, and one that saw none of your mail usually sends nothing.

A report holds counts, IP addresses, domains and results. It has no message text, subjects or recipient addresses. If you haven't published DMARC yet, start with DMARC in one day.

Open the report

1. Save the attachment. You don't need to unzip it.
2. Drop the .xml, .xml.gz or .zip file into the DMARC report reader. It unpacks and reads the file in your browser, one report at a time, and uploads nothing.
3. Read the overview: which organization sent the report, the date range, and your published policy as the receiver saw it.
4. Read the totals: messages that passed, were quarantined, were rejected, and failed both SPF and DKIM.
5. Look at the list of IPs that failed both. Investigate these first.
6. Go through the full table: for each record, the IP, count, SPF, DKIM, disposition and header From.

The parts of the report, in plain words

The format is defined in RFC 9990, section 3.1.1 (2026; older guides cite RFC 7489, which it replaced). A check is aligned when the domain it verified matches the domain in the visible From line; in the usual relaxed mode, a subdomain matches too.

Part	What it means
report_metadata	Who sent the report (org_name, a contact email), a report_id, and the date_range, with begin and end in seconds since 1 January 1970, UTC.
policy_published	Your DMARC record as the receiver found it: domain, p (the policy), sp (the policy for subdomains) and adkim/aspf (alignment mode: r relaxed or s strict). Newer reports add testing (y while your record says t=y); older ones show pct (the share of failing mail the policy applied to).
record	One group of messages with the same source and the same results. An IP can appear in several records.
row: source_ip, count	The IP of the server that handed the mail to the receiver, and how many messages are in the group.
policy_evaluated: disposition	What the receiver did: none (no DMARC action; normal spam filtering still applies), quarantine (usually the spam folder) or reject (refused).
policy_evaluated: dkim, spf	DMARC's verdict: pass only if the check passed and was aligned. An optional reason, such as forwarded or local_policy, explains when the receiver didn't apply your policy.
identifiers: header_from	The domain in the visible From line.
auth_results	The raw results before alignment: for DKIM, the signing domain, selector and result; for SPF, the domain checked and the result.

The last two parts answer different questions. auth_results says whether a check passed and for which domain; policy_evaluated says whether it counted for yours. The reader's SPF and DKIM columns come from policy_evaluated, and a record counts as passed when either one is pass. To see auth_results for a row, open the XML in a text editor and search for its IP.

Why your own services show up failing

An invoicing tool, a newsletter service or an online store often sends mail with your address in From, but from its own servers. Until you authorize it, SPF fails, or passes only for the service's own bounce domain, and it signs DKIM with its own domain instead of yours. In auth_results both may say pass, but for invoice-app.example, not your domain. Nothing aligns, so policy_evaluated shows fail twice, and at p=reject that mail would be refused.

The fix is in the service's settings, usually called domain authentication or sender domain. It gives you DKIM records for your domain, and sometimes an SPF include. After that, its rows show DKIM pass.

Forwarder or spoofer?

When someone forwards mail from one address to another, or a mailing list resends it, the final receiver gets it from the forwarder's server, which isn't in your SPF. So SPF fails. The clues:

• SPF fail, DKIM pass. DMARC passed. It's usually forwarding, which keeps the DKIM signature intact when the message isn't changed, or a service that signs with your domain but uses its own bounce address. Nothing to do.
• Both fail, but auth_results shows a DKIM result for your own domain. You signed the message and something changed it on the way, often a mailing list that adds a footer or edits the subject. Counts are usually small.
• Both fail, no DKIM for your domain, an IP you don't recognize. Someone is sending as you. There is nothing to fix on your side: p=reject is what stops it.

To see who runs an IP, type it into DNS lookup for a reverse lookup, which returns the name the network gave that address, if any. The query goes from your browser to Cloudflare's public DNS resolver. A name at a mail provider or a service you use points to a forwarder or a forgotten tool; a generic hosting name, or none, is more suspicious. It's a clue, not proof.

A worked example

A day's report for tienda-ejemplo.co, published with p=none. The reader shows 477 messages: 418 passed (88%), none quarantined or rejected, and 59 (12%) failed both, from two IPs.

IP, count	SPF / DKIM	What it is	What to do
198.51.100.20, 412	pass / pass	Your mailbox provider	Nothing.
198.51.100.77, 38	fail / fail	Your invoicing tool; auth_results shows a pass for invoice-app.example	Turn on its domain authentication.
192.0.2.140, 6	fail / pass	A client forwarding your mail to another mailbox	Nothing.
203.0.113.9, 21	fail / fail	A hosting server you don't use, no DKIM for your domain	Nothing to fix; move toward reject.

One more common row: SPF pass but DKIM fail from your own mailbox provider usually means DKIM isn't turned on for your domain there.

From p=none to reject

At p=none, the disposition is none on every row: receivers only watch and report. The full plan is in DMARC in one day. In short:

1. Read reports for at least two weeks, from several receivers.
2. Fix every legitimate source until only forwarders and strangers fail. The Email security checker confirms your SPF, DKIM and DMARC records after each change.
3. Change to p=quarantine. Failing rows now show quarantine; check that none of them are yours.
4. After a few quiet weeks, change to p=reject. Failing rows now show reject.
5. Keep reading reports, at least monthly, and set up DKIM for each new service before it sends.

Receivers still make their own call: a failing row can show a milder disposition than your policy, with a reason such as forwarded.

Checklist

• A mailbox for rua reports that someone checks every week.
• Each report opened in the reader: overview, totals and failing IPs.
• Every IP that fails both identified.
• Each legitimate service signing DKIM with your domain.
• Forwarders recognized and left alone.
• Quarantine, then reject, once only strangers fail.

Frequently asked questions

Why do I get several reports a day?

Each receiver that saw mail from your domain sends its own report, covering only what it saw.

The counts don't match what I sent. Why?

A report counts only the mail one receiver saw, including forwards and fakes. Receivers that don't send reports aren't counted at all.

Should I also ask for failure reports (ruf)?

Failure reports describe single failing messages and can include parts of them. Many large providers don't send them, so most domains rely on aggregate reports.

Is it safe to open a report in the reader?

Yes. The file is unpacked and read in your browser, and nothing is uploaded. A report holds IPs, counts and domains, not message content.

Try it

• 2.7DMARC report readerOpen a DMARC aggregate report (.xml, .xml.gz or .zip) and see, for each sending IP, how many messages passed or failed SPF and DKIM.
• 2.2Email securityCheck a domain's SPF, DKIM, DMARC, MTA-STS, BIMI and DNSSEC, and get copy-ready DNS records for what's missing or wrong.
• 2.4DNS lookupLook up any domain's DNS records (A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV) or the reverse DNS of an IP, with TTLs and DNSSEC validation.