ri= in DMARC: reporting frequency and what it changes

ri=86400   → daily reports (default, recommended)
ri=3600    → hourly reports (if the ISP supports it)
ri=604800  → weekly reports

_dmarc.example.com.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ri=86400"

Why 86400 (24h) is the value to use

For the vast majority of contexts, ri=86400 is the value to use — or simply omitting ri=, which amounts to the same thing (the default is 86400). Here's why:

• It's the cadence ISPs actually apply.
• A daily report gives a manageable volume of information: trends over the day show up, and a new source or an unusual spike surfaces within 24 hours at most.
• A more frequent report doesn't bring more useful information — just more noise if some actors actually respected it.
• A weekly report (ri=604800) delays problem detection too long.

On a critical domain where a security incident in the first 24 hours could have major impact, real-time monitoring via a DMARC tool beats any attempt to modify ri= — it's more effective.

The delay between sending and receiving reports

A commonly misunderstood point: a report arriving at 8am covers the previous day's period, not the current day. There's always a lag between when messages were evaluated and when the report lands. In practice:

• The reporting period generally covers 00:00→23:59 UTC.
• The report is generated and sent in the early hours following (often between 3am and 9am UTC).
• It arrives minutes to hours later depending on email routing.

Concretely: what happened yesterday shows up in tomorrow morning's report. Same-day incidents wait for the next day's report. That's why a DMARC platform with a continuous view is more useful than manually monitoring reports.

A dedicated mailbox for the reports

A practical point that's often overlooked: the mailbox receiving all of this. With a daily cadence and several ISPs each sending their own file, the rua= address quickly accumulates several compressed attachments per day — XML in .zip or .gz, unreadable to the naked eye. A personal inbox is the wrong target for rua=: the reports would drown the real messages, and an overzealous filter could end up junking or deleting them. A dedicated address, with a comfortable quota, is the right home. A DMARC platform exposes its own collection address and the question disappears. Where reports are processed by hand, an automatic sorting rule and a regular purge are needed: a full mailbox bounces incoming reports, and visibility vanishes unnoticed.

What actually deserves watching (and how often)

The real question isn't "how often do reports arrive?" but "how often are they read?" And there, the right answer depends on the DMARC deployment phase.

In the observation phase (p=none): a weekly read. There's no disruption risk, changes are slow (identifying and fixing sources takes time), and a weekly review is enough to track progress. In the transition phase (p=quarantine): daily reads for the first few weeks, or configured alerts. That's where a legitimate flow gets blocked inadvertently — and where fast detection matters. Once stabilized in quarantine for a few weeks, weekly is enough again. In the stable phase (p=reject): a monthly review is often sufficient, complemented by automatic alerts for anomalies (new unknown IP, sudden failure spike). Monitoring becomes maintenance, not investigation.

ri= changes nothing about this logic — reports arrive daily in all cases. It's the reading and analysis cadence that matters, not the reception cadence.

Reports and security audits

For organizations subject to audits (ISO 27001, NIS2, banking sector…), DMARC reports constitute monitoring proof. Keeping a report history — even partial — demonstrates during an audit that the DMARC policy is watched and that anomalies are detected and handled. It's the same reasoning as for firewall logs: their value isn't in daily reading, but in the ability to prove that monitoring and reaction happen. A DMARC platform that keeps report history and logs alerts fills this role without anyone archiving hundreds of XML files. Where this audit dimension is a requirement, the chosen tool needs a long history (at least 90 days) and exports for compliance needs.

The reporting interval that actually matters: the reading cadence

There's a concept worth distinguishing: the reception interval (when reports arrive, controlled by ri= and ignored by ISPs) vs. the reading interval (when someone actually looks at them, entirely under the organization's control). The second is what actually affects the security posture.

While sources are actively being fixed on the way to p=reject, reading reports daily — or using a tool that flags changes automatically — keeps the pace up. A misconfiguration caught within 24 hours takes an hour to fix; one missed for two weeks may block legitimate mail once the policy tightens. On the other hand, once p=reject is reached and all sources are correctly configured, monthly reviews are typically sufficient, supplemented by automated alerts.

The lesson: tuning ri= is wasted effort. It won't change what the ISPs send. The reading process and the tooling are the real levers — that's where the gains are.

What to do with the lag: using reports for trend analysis

Because DMARC reports always cover a past period — yesterday, not today — they're best used as trend data rather than real-time visibility. A single report is a snapshot. Ten reports over ten days are a trajectory. Is the failure count on a known source declining (the fix worked) or rising (something changed upstream)? Is a new IP appearing that wasn't there two weeks ago (new sending service, or an impersonator at work)?

Trend analysis is what transforms a DMARC setup from a one-time configuration project into active email security monitoring. The daily cadence of reports, uncontrollable as it is, creates a reliable data stream for this purpose.

ri= in DMARCbis (RFC 9989)

In the new version of DMARC (DMARCbis), the ri= parameter stays and keeps the same meaning. The major DMARCbis changes concern other tags (pct removed, np and t added) — not ri=. On migration to DMARCbis (see migrating to the new standard), an existing ri= value remains valid without modification.

Frequently asked questions

Do I need to include ri= in my record? No, it's optional. The default value is 86400, which is the right value for most cases. Explicitness argues for adding ri=86400; otherwise it can be left out.

Can hourly reports be requested? Technically yes (ri=3600), but almost all ISPs ignore it and still send daily. A frequency below 24 hours isn't something to count on.

Does ri= apply to RUF as well? No. ri= concerns aggregate reports (RUA). Forensic reports (RUF) are triggered by event (a message that fails), not by interval.

What happens when reports from several ISPs arrive at different times? That's normal — each ISP generates and sends its report on its own schedule. The Gmail report may land at 6am and the Microsoft report at 2pm, both for the same period. DMARC tools aggregate them automatically.

Can a report cover a period other than 24 hours? Yes, especially at startup: a DMARC record published at 3pm may yield a first report covering only the remaining 9 hours of the day. Subsequent reports revert to 24 hours.

How does the reporting interval interact with my DMARC policy? It doesn't — they're completely independent. ri= affects only when reports are generated and sent. The policy (p=none, quarantine, reject) and how messages are handled in real-time are entirely separate from reporting.

Do DMARC reports cover different time zones? Reports use Unix timestamps (UTC) for date_range. The ISP decides the period covered, generally 00:00→23:59 UTC. Where activity sits mainly in a different time zone (UTC+2, UTC-8…), reports may split a working day across two reporting periods. That's a detail that matters when analyzing an incident on a specific day.

Thomas monitors the cadence

The real value isn't in report frequency, it's in what gets done with them. Thomas, the virtual CISO, monitors the reports instead, raises a flag when something unusual appears — a new IP, a failure spike, a source that stops passing — and says what to do, not just what to look at.

Analyze a domain for free or create an account for continuous DMARC monitoring.