DMARC Monitoring: How to Read Your Reports | FortifyNet

DMARC monitoring means collecting and reading the aggregate reports that mail receivers send back to your domain every day, so you can see exactly who is sending email as you before you switch your policy to quarantine or reject. You turn it on by adding a rua=mailto: tag to your DMARC record. Within 24 to 48 hours, providers such as Google, Microsoft 365 and Yahoo start mailing you compressed XML files summarising every message that claimed your domain. Those files are the only evidence you get, and without them, moving to enforcement is guesswork.

What DMARC monitoring actually is

DMARC (Domain-based Message Authentication, Reporting and Conformance) does two jobs. The policy half tells receivers what to do with mail that fails authentication. The reporting half tells you what receivers are seeing. Monitoring is that second half, and it is the part most domain owners skip.

The mechanism is straightforward. When a receiving provider evaluates mail claiming your From domain, it counts the results. At the end of each UTC day it packages those counts into an XML file and emails it to the address in your rua= tag. RFC 9990 section 3.1.1.4 specifies that the reporting period covers a single UTC day beginning at 0000 UTC, which is why your first report arrives 24 to 48 hours after you publish the tag rather than immediately.

Reports are gzip compressed and small. Measured per-provider file sizes ran between 3.6 KB and 4.8 KB (Google 3,962 bytes, Yahoo 4,626, Fastmail 4,839) in the dataset published by Ashiq et al. at USENIX Security 2023. Storage is never the constraint. Volume is: a busy domain can receive hundreds of files a day, which is why almost nobody reads them by hand.

More than half of DMARC domains fly blind

DMARC policy distribution across the 1,670,975 domains that publish a record. Source: DMARCguard, State of Email Authentication 2026, scan of 5,499,028 Tranco domains, 27 February 2026.

That same scan found only 894,057 of those 1,670,975 domains (53.5%) publish a rua= tag. The other 776,918 have a policy and no telemetry at all.

The consequence shows up in the policy split above. 57.9% of DMARC domains, 967,474 of them, sit at p=none. Monitoring-only mode is meant to be a staging area, not a destination, and the reason so many domains never leave it is simple: without reports there is nothing to base the decision on.

The stakes are not theoretical. The FBI's Internet Crime Complaint Center recorded $2.77 billion in Business Email Compromise losses across 21,442 complaints in its 2024 annual report. On the other side of the ledger, after Google and Yahoo enforced bulk-sender authentication requirements in February 2024, Gmail reported 265 billion fewer unauthenticated messages that year (Neil Kumaran, Group Product Manager, Gmail Security and Trust, October 2024).

Turning reporting on

Add a rua= tag to the TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[e-mail]; fo=1

Check what is currently published with a DNS lookup:

dig +short TXT _dmarc.yourdomain.com

Three rules worth knowing before you edit DNS:

• One record only. RFC 9989 requires exactly one DMARC TXT record per domain. Publish two and receivers apply no policy at all, silently disabling DMARC.
• No rua= means no reports. Receivers must not generate aggregate feedback without the tag. There is no opt-in anywhere else.
• Coverage is partial by design. Microsoft's own documentation, updated 14 May 2026, states that not all receivers send reports and that coverage is typically 70 to 90 percent of total mail volume. Apple iCloud and Proton are not documented as report senders at all.

Sending reports to a different domain

If your rua= address sits on a different organisational domain than the policy, that receiving domain has to authorise it. RFC 9990 section 4 requires a TXT record at <your-domain>._report._dmarc.<reporting-domain> containing v=DMARC1;. Without it, receivers silently stop sending. This is the single most common reason a correctly written rua= tag produces no reports at all.

Aggregate reports versus failure reports

	Aggregate reports (RUA)	Failure reports (RUF)
Specification	RFC 9990	RFC 9991
Cadence	Once per UTC day, per provider	Near real time, per message
Content	Counts per source IP with SPF and DKIM alignment plus the applied disposition	Details of one failing message, potentially including headers and body
Privacy	Aggregated counts, no message content	RFC 9991 states reports may contain personally identifiable information
Provider support	Broad: Google, Microsoft 365, Yahoo, Mail.ru, Fastmail, Zoho	Rare. Microsoft 365 does not send them even with a valid ruf=
Best used for	Building the sender inventory and deciding when to enforce	Diagnosing one specific failure you can reproduce

Start with RUA. Almost everything you need to reach p=reject safely is in the aggregate data, and it carries none of the privacy baggage of failure reports.

Reading a report: the four outcomes that matter

Each <record> block in the XML pairs a source IP with a message count, the raw SPF and DKIM results, and a policy_evaluated verdict. What matters is alignment, not raw authentication. SPF or DKIM has to pass and match your From domain for DMARC to pass.

SPF aligned	DKIM aligned	What it means	What to do
Pass	Pass	Healthy. Your own infrastructure, correctly configured	Nothing. This is the target state for every legitimate sender
Pass	Fail	The sender is authorised but is not signing, or is signing with its own domain	Enable DKIM at that service and align the d= domain to yours
Fail	Pass	Almost always forwarding or a mailing list. DMARC still passes	Safe. Do not add the forwarder to your SPF record
Fail	Fail	Either a legitimate sender you forgot about, or spoofing	Identify the IP. Authorise it, or leave it to be blocked at enforcement

The third row is the one people get wrong most often. Forwarding breaks SPF by design, because the envelope sender changes at the forwarding hop. That is precisely why DKIM matters as a fallback, and why the 43.0% of DMARC domains that rely on SPF alignment alone (DMARCguard, February 2026) are more fragile than they look.

What changed in 2026: RFC 9989, 9990 and 9991

In May 2026 the IETF published RFC 9989, RFC 9990 and RFC 9991. Together they obsolete RFC 7489 and move DMARC onto the Standards Track as a Proposed Standard for the first time since 2015, with reporting split into its own documents.

Item	RFC 7489 (2015)	RFC 9989 / 9990 (2026)	What you should do
pct tag	Supported, for partial rollout	Removed	Stop relying on it. Use the new t=y testing mode
rf and ri tags	Defined	Removed	Delete them at your next DNS edit
Organisational domain discovery	Public Suffix List	DNS tree walk	Nothing. This is a receiver-side change
Report XML namespace	http://dmarc.org/dmarc-xml/0.1	urn:ietf:params:xml:ns:dmarc-2.0	Any parser you run must accept both
DKIM selector in reports	Optional	Required	Fix generators or parsers that drop the field
disposition values	none, quarantine, reject	Adds pass	Handle the new value instead of rejecting the file
Unknown elements	Undefined	Ignore and continue (RFC 9990 section 5)	Never reject a report you do not fully understand

Your existing record keeps working. The v=, p=, sp=, rua=, ruf=, adkim=, aspf= and fo= tags all retain their meaning. In practice every major provider still emits legacy-shaped XML today, so expect a mixed window lasting years and parse tolerantly rather than strictly.

A safe four-stage rollout to p=reject

1. Weeks 1 to 2. Publish p=none with rua=. Change nothing else. Collect reports and build a list of every IP and service sending as you.
2. Weeks 3 to 6. Fix alignment. Add missing senders to SPF, enable DKIM everywhere, and confirm each third-party service signs with your domain rather than its own.
3. Weeks 7 to 8. Move to p=quarantine, optionally starting on a subdomain via sp=. Watch the reports for a full week for any legitimate sender you missed.
4. Week 9 onward. Move to p=reject, and keep rua= in place permanently. Monitoring is not scaffolding you take down after the build.

Rushing stage one is the classic failure. A quarterly invoice run or an annual campaign will not appear in two weeks of data, and it will bounce on the day you enforce.

FAQ

How often are DMARC reports sent?
Once per UTC day per reporting provider, covering a window that begins at 0000 UTC (RFC 9990 section 3.1.1.4). Your first report typically arrives 24 to 48 hours after you publish rua=.

Why am I not receiving any reports?
Most often the rua= address is on a different domain and the required authorisation record at <your-domain>._report._dmarc.<reporting-domain> is missing. Other causes: a syntax error in the DMARC record, two DMARC records published at once, or simply no mail claiming your domain during the window.

Is the DMARC report in my inbox legitimate?
Almost certainly. Genuine reports use the subject pattern Report Domain: <domain> Submitter: <reporter> Report-ID: <id> and attach compressed XML with a bang-separated filename. Real reports contain no links to click, no payment demands and no credential requests.

Do I still need monitoring after reaching p=reject?
Yes. New services get added, DNS gets edited, DKIM keys get rotated. Reports are how you find out something broke before your customers do.

Can I just delete the reports?
You can remove rua= to stop them, but that trades a cluttered inbox for zero visibility into who is spoofing you. Pointing rua= at an analyser is the better answer.

Check your setup in 60 seconds

Before you touch DNS, it helps to know exactly where you stand. FortifyNet's free scan reads your DMARC, SPF and DKIM records and tells you whether reporting is actually configured, whether your policy is at enforcement, and what is missing. It takes about a minute and needs no signup. Run a free scan at FortifyNet.

Related guides: How to Set Up DMARC, Step by Step · What Is DKIM? · SPF Record Checker · DNS Security Configuration

Originally published at fortifynet.com/blog/dmarc-monitoring. I'm the founder of FortifyNet, a website security scanner; this article comes from our blog, so factor in that founder bias when you read any tool recommendations here.