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.your-domain.com.  IN TXT
  "v=DMARC1; p=quarantine; rua=mailto:dmarc@your-domain.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 omit 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: you see trends over the day, you detect a new source or an unusual spike 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.

If you manage a critical domain where a security incident in the first 24 hours could have major impact, monitor activity in real time via your DMARC tool rather than trying to modify ri= — it's more effective.

The delay between sending and receiving reports

A commonly misunderstood point: the report you receive 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 reaches you. 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).
• You receive it minutes to hours later depending on email routing.

Concretely: if you want to know what happened yesterday, tomorrow morning's report will tell you. For same-day incidents, you have to 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 to receive your 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. Don't point rua= at your personal inbox: the reports would drown your real messages, and an overzealous filter could end up junking or deleting them. Create a dedicated address for this purpose instead, with a comfortable quota. If you go through a DMARC platform, it exposes its own collection address and the question disappears. If you process reports by hand, set up an automatic sorting rule and a regular purge: a full mailbox bounces incoming reports, and you lose visibility without noticing.

What you should actually watch (and how often)

The real question isn't "how often do I receive reports?" but "how often do I read them?" And there, the right answer depends on your DMARC deployment phase.

In the observation phase (p=none): read your reports weekly. You're taking no disruption risk, changes are slow (identifying and fixing your sources takes time), and a weekly review is enough to track progress. In the transition phase (p=quarantine): read reports daily for the first few weeks, or configure alerts. That's where you can inadvertently block a legitimate flow — you want to detect it fast. Once stabilized in quarantine for a few weeks, return to weekly. 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 — lets you show 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 you monitor and react. A DMARC platform that keeps report history and logs alerts fills this role without you having to archive hundreds of XML files. If this audit dimension is required of you, check that the tool you choose offers a long history (at least 90 days) and exports for compliance needs.

What reporting interval actually matters: your 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 you actually look at them, entirely under your control). The second is what actually affects your security posture.

If you're actively fixing sources and moving toward p=reject, reading reports daily — or using a tool that flags changes automatically — keeps you moving fast. A misconfiguration caught within 24 hours takes an hour to fix; one missed for two weeks may block legitimate mail once you tighten policy. On the other hand, once you've reached p=reject and all sources are correctly configured, monthly reviews are typically sufficient, supplemented by automated alerts.

The lesson: don't try to tune ri=. It won't change what the ISPs send. Tune your own reading process and tooling instead — 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 tells you a snapshot. Ten reports over ten days tell you a trajectory. Is the failure count on a known source declining (your fix worked) or rising (something changed upstream)? Is a new IP appearing that wasn't there two weeks ago (new sending service, or someone spoofing you)?

Trend analysis is what transforms a DMARC setup from a one-time configuration project into active email security monitoring. The daily cadence of reports, even if you can't control it, 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=. If you migrate to DMARCbis (see migrating to the new standard), your 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. If you want to be explicit, add ri=86400; otherwise omit it.

Can I request hourly reports? Technically yes (ri=3600), but almost all ISPs ignore it and still send daily. Don't count on a frequency below 24 hours.

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 if I receive reports from several ISPs at different times? That's normal — each ISP generates and sends its report on its own schedule. You might receive the Gmail report 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: if you publish your DMARC record at 3pm, the first report may only cover 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. Your 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. If your activity is 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.

Let Thomas monitor the cadence for you

The real value isn't in report frequency, it's in what you do with them. Thomas, your virtual CISO, monitors reports in your place, alerts you when something unusual appears — a new IP, a failure spike, a source that stops passing — and tells you what to do, not just what to look at.

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