DMARC Report: How to Read and Act on It

What is a DMARC report?

A DMARC report is feedback that a receiving mail server sends to the domain owner about mail that claimed to come from that domain. The DMARC specification published by the IETF describes two kinds. Aggregate reports go to the address in the rua tag of your DMARC record. They summarise every message the receiver saw, grouped by sending IP and result. Failure reports (often called forensic reports) go to the address in the ruf tag and describe single messages that failed. You only get reports if your record asks for them. A record like v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com publishes the policy and asks for aggregate reports. Without rua, receivers still apply your policy, but they don't tell you anything. The report covers what the receiver saw, not everything you sent. A domain that only mails Gmail and Microsoft users gets reports from those two receivers and nobody else. If you haven't published a record yet, our guide to DMARC setup with record tags and fixes covers the TXT record at _dmarc first.

How often do DMARC reports arrive, and in what format?

The DMARC specification lets the domain owner request a reporting interval with the ri tag, and its default interval is one day. Receivers are free to stick to daily reports no matter what you ask for, and most do. Every report comes as an email with a compressed attachment, usually gzip (.xml.gz) or zip, holding one XML file. The filename typically names the receiver domain, your domain and the start and end timestamps. Timestamps are Unix epoch seconds in UTC, so a report that 'starts at midnight' may not start at your local midnight. One detail trips people up when they send reports to a different domain, such as a monitoring service. The DMARC specification requires the receiving domain to publish a TXT record at yourdomain.com._report._dmarc.theirdomain.com to confirm that it accepts your reports. If that record is missing, compliant receivers drop the external rua address without a word, and your report inbox just stays empty.

How to read a DMARC aggregate report, field by field

An aggregate report has three parts: report_metadata (who sent it and the date range), policy_published (your DMARC record as the receiver saw it) and one or more record elements. The record elements are where the work happens.

XML element	What it holds	What to check
report_metadata / org_name, date_range	The reporting receiver and the begin and end Unix timestamps	Which mailbox provider this covers and which day
policy_published / p, sp, pct, adkim, aspf	Your policy, subdomain policy, percentage and alignment mode (r relaxed, s strict)	That it matches what you think you published. A typo in DNS shows up here
row / source_ip	The IP that delivered the messages	Reverse-look it up to identify the service: your Workspace, Brevo, a CRM, or unknown
row / count	How many messages from that IP shared the same result	Weight rows by volume. A single message from an odd IP is usually forwarding
policy_evaluated / disposition	What the receiver did: none, quarantine or reject	Should match your p= unless the receiver overrode it
policy_evaluated / dkim, spf	The DMARC-aligned result: pass only if the authenticated domain matches your From domain	At least one has to pass for DMARC to pass
identifiers / header_from	The domain in the visible From address	Subdomains appear here separately
auth_results / dkim (domain, selector, result)	The raw DKIM check, including the signing domain d= and the selector	A pass for a vendor's domain doesn't count toward DMARC
auth_results / spf (domain, result)	The raw SPF check on the envelope sender (Return-Path) domain	A pass for a bounce domain you don't own won't align

The most common misreading is treating auth_results as the verdict. It isn't. Look at a row where auth_results shows spf pass but policy_evaluated shows spf fail. SPF passed for some domain, usually a sending service's own bounce domain, but that domain doesn't match your From domain. So SPF counts for nothing under DMARC, and the message passes DMARC only if DKIM is aligned.

What should you do with DMARC reports?

Reports only help if every row ends up in a bucket. Group by source_ip, add up count per group, then work through these cases:

1. 1 Your own service, aligned pass on DKIM or SPF: done. Note the IP range and DKIM selector so you recognise it next time.
2. 2 Your own service, aligned fail: the service is sending as your domain without signing for it. The usual cause is DKIM still signed with the vendor's d= domain because your custom DKIM key was never published or activated. Fix the DNS before you touch p=.
3. 3 Known forwarder or mailing list, SPF fail, DKIM sometimes pass: forwarding changes the delivering IP, so SPF breaks, and list footers or subject tags can break the DKIM signature too. You can't fix this from your side. Small counts like this are normal.
4. 4 Unknown IP, both fail, meaningful count: someone is spoofing your domain, or a team bought a tool nobody told you about. Ask around before calling it abuse.
5. 5 Rows under header_from subdomains you don't use: candidates for an sp=reject policy once your main domain is clean.

Moving from p=none to quarantine is only safe once every legitimate source has sat in the first bucket for a while. If you tighten while a CRM or invoicing tool is still in bucket two, that tool's mail lands in spam or gets rejected. Reports from the last weeks are how you find out. To see where SPF and DKIM fit in, read how DKIM DMARC and SPF depend on each other before changing any record. You can check what's live right now with the SPF, DKIM and DMARC checker.

DMARC with Google Workspace: what the reports show

If your domain runs on Google Workspace, keep two roles apart. As a sender, your DMARC record lives at your DNS host as a TXT record at _dmarc.yourdomain.com. The Workspace Admin console doesn't create it for you. Mail sent from Workspace mailboxes shows up in other receivers' reports with Google IP ranges as source_ip. If you've activated Workspace DKIM, it appears with a DKIM signature using the selector google and d= your domain, the default selector in Google's admin documentation. If DKIM was generated but never switched on with Start authentication, those rows show DKIM signed by a Google domain and an aligned DKIM fail. As a receiver, Gmail sends you aggregate reports with org_name google.com. Google's Workspace help article 'About DMARC reports' describes aggregate reports. Don't count on failure (ruf) reports from Gmail. A common Workspace setup is mail from Workspace plus a separate sending service such as Brevo on the same domain. You'll then see two clusters of rows, each needing its own aligned DKIM. The record itself and the rollout order are covered in our Google Workspace DMARC record and rollout guide.

Which tool should you use to read DMARC reports?

Reading raw XML works for a domain with two senders and low volume. Once several receivers report daily, you'll want something that parses the files and groups the rows. The options below are named in today's search results for this topic. The comparison sticks to how each type of option works, not account-specific limits.

Option	How it works	Suits	Where it stops
Raw XML in a text editor	Unzip the attachment and read the record elements by hand	One domain, one or two sending services, a quick check	No trend over time and no grouping across receivers. Slow above a handful of rows
MxToolbox DMARC Report Analyzer	Paste or upload a single report and get a parsed view (an XML parser, per its page title)	Making sense of one report you've just received	Works report by report and doesn't collect your daily feed on its own
Hosted DMARC monitoring (e.g. Postmark DMARC, EasyDMARC, PowerDMARC, dmarcreport.com)	You point rua at the provider's address, and it collects, parses and summarises reports over time	Ongoing monitoring of several senders and receivers, ahead of moving to quarantine	The provider receives your report data, and an external rua needs the provider's authorisation record. Plans and features vary, so check each vendor's documentation
Your own mailbox plus a script	rua points to a mailbox you control, and you parse the XML with your own code	Teams that want report data to stay in-house	You build and maintain the parsing and storage yourself

Whatever you pick, none of these tools changes what the receiver decides. They show you what happened. Fixes still happen in your DNS and in each sending service's domain settings.

How EmailFlow OS sending shows up in your DMARC reports

EmailFlow OS works on your own infrastructure, so its traffic appears in your reports as your traffic. You record one video and upload it to EmailFlow OS. Then you connect your Brevo account and sending domain and import your prospect list into EmailFlow OS. EmailFlow OS personalises that single recording for each recipient, not each company, and sends each version from your own inbox through your own Brevo account and your own sending domain. There's no shared platform sender. So in aggregate reports, those sends show up under your header_from domain, with Brevo's sending IPs as source_ip. Whether they pass DMARC depends on the DKIM key you've published for Brevo on your domain. If it's set up and aligned, the rows land in bucket one. If not, they land in bucket two like any other misconfigured service. Your reports are how you check that before you send at volume. More on how EmailFlow OS handles personalised AI video email from your own domain is on the home page.

Questions people ask

? Why am I not receiving any DMARC reports?

There are three usual causes. Your DMARC record has no rua tag. The rua address is on another domain that hasn't published the authorisation TXT record the DMARC specification requires for external report addresses. Or the record is broken, for example two v=DMARC1 records at _dmarc, which receivers treat as no record at all. Reports usually arrive daily, so allow at least a day after any fix.

? What is the difference between rua and ruf reports?

rua reports are aggregate. They're daily XML summaries grouped by sending IP and result, with no message content. ruf reports are failure reports about individual messages that failed, and they can include headers or parts of the message. Aggregate reports are widely sent. Many large receivers send few or no failure reports, partly because of the personal data involved.

? Does a DMARC report mean my email was delivered to the inbox?

No. The disposition field only shows whether the receiver applied your DMARC policy: none, quarantine or reject. A message with disposition none and aligned passes can still go to spam because of reputation, content or complaints. DMARC reports cover authentication, not inbox placement. Placement needs separate tools such as Google Postmaster Tools or seed tests.

? Is a DMARC fail in my report always spoofing?

No. Failures also come from forwarding, which breaks SPF and sometimes DKIM. They also come from mailing lists that modify messages, and from your own services sending without a DKIM key aligned to your domain. Check source_ip and the DKIM d= domain first. Treat it as spoofing only when the IP belongs to none of your services or known forwarders.