In short
DMARC reports come in two kinds: aggregate (rua) reports, daily XML summaries of every server sending as your domain, and failure (ruf) reports about individual messages, which many large providers limit or do not send. Since the NCSC retired Mail Check on 31 March 2026, UK organisations that used it need another way to receive and read reports.
Not sure where to start?
Tell us what you need to achieve and we will point you to the right option.
The two types of DMARC report
DMARC defines two kinds of report, each now in its own standard: aggregate reports in RFC 9990 (opens in a new tab) and failure reports in RFC 9991 (opens in a new tab).
| Feature | Aggregate report (rua) | Failure report (ruf) |
|---|---|---|
| Also called | Aggregate or summary report | Forensic or message-level report |
| Format | XML file, usually gzip-compressed, attached to an email | An email per failing message, in the abuse reporting format |
| How often | Daily or more frequent; typically one UTC day per report | Sent almost immediately after a failure |
| What it contains | Counts of messages per sending IP, with SPF, DKIM and DMARC results and what the receiver did | Header fields, and sometimes the whole content, of the failed message |
| Personal data | None about individual users, according to RFC 9990 | May contain personal data, so many providers redact it or do not send it |
| Who sends it | Mailbox providers that support DMARC reporting | Fewer receivers; many limit or redact them |
Aggregate reports are the ones you rely on. RFC 9991 notes that many large-scale providers limit or entirely disable (opens in a new tab) failure reports, preferring aggregate reports, and Microsoft says Outlook.com sends aggregate reports but has no plans to send RUF (opens in a new tab). Some platforms fill the gap: Check Point's DMARC Management, for example, generates virtual RUF reports (opens in a new tab) for failing messages it sees in its own Email Security network.
Not sure which option fits? Ask us
Tell us what you need and we will help you choose the right option.
The rua and ruf tags
You ask for reports by adding addresses to your DMARC record (RFC 9989 section 4.7 (opens in a new tab)). Without a rua tag, receivers must not send aggregate reports at all, so a record with no rua leaves you blind.
| Record | What it asks for |
|---|---|
| v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk | Aggregate reports to a mailbox on your own domain |
| v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk,mailto:reports@platform.example | Aggregate reports to two places: your mailbox and a DMARC platform |
| v=DMARC1; p=none; rua=mailto:reports@platform.example; ruf=mailto:failures@platform.example; fo=1 | Aggregate and failure reports, with failure reports whenever any mechanism fails to give an aligned pass |
Points to know:
- Separate several addresses with commas. RFC 9989 says a report should be sent to each address listed
- The fo tag sets when failure reports are wanted: 0 (the default) when SPF and DKIM (opens in a new tab) both fail to give an aligned pass, 1 when either does, d for DKIM failures and s for SPF failures. It is ignored without a ruf tag
- Addresses at another domain need that domain's permission. Under RFC 9990 section 4 (opens in a new tab), if example.co.uk sends reports to platform.example, receivers look for a TXT record at example.co.uk._report._dmarc.platform.example starting v=DMARC1. DMARC platforms publish these for their customers; Check Point's guide, for example, says it adds the authorisation record (opens in a new tab) automatically
What is inside an aggregate report
An aggregate report is an XML file with a fixed structure (RFC 9990 section 3.1.1 (opens in a new tab)). The attachment name tells you who sent it, for which domain and which period, in the form receiver!policy-domain!begin!end.xml.gz, with the times in seconds since 1970. Inside, the main parts are:
| XML element | Example value | What it tells you |
|---|---|---|
| report_metadata / org_name | The receiver's name, such as a mailbox provider | Who processed the mail and sent the report |
| date_range (begin, end) | Two timestamps a day apart | The reporting period, typically one UTC day |
| policy_published | domain example.co.uk; p quarantine; sp none; np none; testing n | The DMARC record the receiver found and applied |
| record / row / source_ip | 192.0.2.123 | A server that sent mail using your domain |
| row / count | 123 | How many messages came from it with this result |
| policy_evaluated | disposition pass; dkim pass; spf fail | The DMARC verdict: dkim and spf here mean aligned pass or fail |
| policy_evaluated / reason | mailing_list, trusted_forwarder, local_policy, policy_test_mode | Why the receiver did not apply your policy, if it did not |
| identifiers | header_from example.co.uk; envelope_from example.co.uk | The From domain and the envelope (Return-Path) domain |
| auth_results / dkim | domain example.co.uk; selector abc123; result pass | The raw DKIM result, signing domain and selector |
| auth_results / spf | domain example.co.uk; result fail | The raw SPF result and the domain checked |
The example values come from the sample report in RFC 9990 (opens in a new tab). Read that row together: 123 messages from one server passed DMARC because DKIM passed and aligned, even though SPF failed. That pattern is typical of forwarded mail, and of a sender that is missing from your SPF record.
Need help choosing?
We will recommend what fits your organisation and explain why, in plain English.
How to read DMARC reports, step by step
Whether you read the XML yourself or use a platform, the method is the same:
- Gather a few weeks of reports from the main receivers, so occasional senders show up
- Group the rows by sending source: look up who owns each IP address, or let a tool name the service
- Mark each source as yours (Microsoft 365, Google Workspace, your CRM, your website) or not yours
- For your own sources, check the policy_evaluated results: a pass on dkim or spf there means aligned. Fix any that fail on both
- For sources that are not yours, check the disposition: this is spoofing, which your policy will ask receivers to stop once it is enforced
- Look for reason elements: mailing lists and forwarders explain many small failures from servers you do not own
- Repeat as your policy tightens, watching for new sources that appear when teams adopt new tools
When the only sources failing are ones you do not recognise, you are ready to move up a DMARC policy step. For help diagnosing a failing source, see DMARC fail.
Why raw XML gets hard at scale
One report from one receiver is readable. In practice you get a report per receiver, per domain, per day, and a busy domain's reports list hundreds of IP addresses. RFC 9989 section 5.1.5 (opens in a new tab) says that while a person can read aggregate reports, they are formatted to be machine-parsed, and that many third-party services exist to process them.
Volume affects the mailbox too. Check Point's guide explains that large senders receive so many reports that Microsoft and Google often reject some of them (opens in a new tab) when they are sent to an ordinary mailbox, which is why it offers a dedicated hosted rua mailbox. A DMARC report analyser solves both problems: it collects the reports at its own address and turns them into named senders, pass rates and alerts.
Privacy and where report data goes
The two report types carry very different data:
- Aggregate reports contain no identifying details of individual users, no personal email addresses and no message content, according to RFC 9990 section 7.2 (opens in a new tab). They describe domains, servers and results
- Failure reports may include personal data and other non-public information from the failed messages, including header fields and sometimes the content (RFC 9991 section 7.1 (opens in a new tab)). Ask for them only where you have a clear use and somewhere suitable to store them
Where your reports are processed is a fair question for UK organisations, especially public sector bodies and anyone handling failure reports. EasyDMARC, for example, processes reports sent to its .eu reporting addresses in its Ireland (eu-west-1) region, and says reports sent to each set of addresses are processed only within that region (opens in a new tab). EasyDMARC's privacy policy also notes that email subject lines are stored only if you use failure reports. Each platform's data handling is confirmed at quote.
After Mail Check: getting your reports read
Organisations that used the NCSC's Mail Check service to receive and process their DMARC reports need a new home for them. The NCSC retired Mail Check on 31 March 2026 (opens in a new tab), and users no longer receive findings from it. If your DMARC record still lists a reporting address you set up for Mail Check, check whether anyone is reading those reports today.
The fix is a change to the rua tag only: point it at a DMARC platform's reporting address, and your email flow is unaffected. Public sector bodies should also note that gov.uk's Securing government email (opens in a new tab) guidance still requires them to set up DMARC reporting and review the data regularly.
We can help with that move. We can assess your domains, set up reporting on EasyDMARC, Valimail or the Check Point Email Security DMARC Management add-on, and help you use the reports to move to enforcement. Licences can be billed monthly, with terms confirmed at quote. See DMARC management or contact us for free advice.
More on DMARC reports
Frequently asked questions
How often are DMARC reports sent?
Aggregate reports are sent daily or more often. RFC 9989 says receivers should send them at least once every 24 hours, and RFC 9990 says the reporting period is typically a single UTC day. The NCSC (opens in a new tab) says reports from major email providers start arriving within 24 hours of publishing your record. Failure reports, where a receiver sends them, arrive soon after each failing message.
Do I need ruf?
Not to get to enforcement. Aggregate reports give you everything you need to find your senders and fix them, and many large providers limit or do not send failure reports. Failure reports can help diagnose a specific problem, but they may contain personal data, so request them only where you have a clear use and a suitable place to store them.
Why am I getting DMARC reports from Google and Microsoft?
Because your DMARC record has a rua address, and mailbox providers that check DMARC send aggregate reports to it, one per day per domain. Each report covers the mail that provider received claiming to be from your domain. If they arrive in a staff mailbox, a DMARC platform can collect and read them for you instead.
How long are DMARC reports kept?
That depends on where they go. A mailbox keeps them as long as you do. Platforms set their own retention: Check Point's guide says RUF and RUA reports are stored for 60 days (opens in a new tab), and EasyDMARC's pricing page (opens in a new tab) shows data history by plan, from three months upwards. Ask us for the retention on the plan you are considering.
What is the difference between rua and ruf?
rua is where aggregate reports go: daily summaries of every server sending as your domain, with counts and results and no personal data. ruf is where failure reports go: details of individual messages that failed, which may include headers and content. Most organisations rely on rua and use ruf sparingly, if at all.
Still have a question about DMARC reporting?
Ask us and a member of our team will get back to you.