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:dmarc-reports@yourdomain.com; 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
-
Weeks 1 to 2. Publish
p=nonewithrua=. Change nothing else. Collect reports and build a list of every IP and service sending as you. - 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.
-
Weeks 7 to 8. Move to
p=quarantine, optionally starting on a subdomain viasp=. Watch the reports for a full week for any legitimate sender you missed. -
Week 9 onward. Move to
p=reject, and keeprua=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.
