DMARC ri is historic in RFC 9989: stop promising a custom aggregate-report interval

The protocol fact to establish first

RFC 9989 marks the ri tag historic and identifies it as the former aggregate reporting interval request. RFC 9990 says aggregate visibility typically comes in daily or more frequent reports but does not make the old ri tag active again.

Older DMARC records sometimes include `ri=` to request an aggregate reporting interval. Under RFC 9989, `ri` is historic rather than an active policy control, and aggregate reporting is specified separately by RFC 9990. That means a sender should not build monitoring logic around the belief that `ri=3600` forces every receiver to send a report hourly. Reporting organizations control their own report generation and operational cadence. The practical consequence is simple: treat report arrival time as telemetry with receiver-specific behavior, not as a service-level guarantee encoded in your DNS record. Removing obsolete assumptions is more important than adding increasingly aggressive `ri` values.

Why the obvious reading is misleading

A DNS checker can display ri=3600 without proving receivers honor it. Historical acceptance of a tag and current standards status are different questions.

A common dashboard bug is to mark a receiver “missing” when no report arrives within the requested `ri` interval. That can create false incident alerts, especially for low-volume domains that may not generate meaningful report data in every period. Another mistake is interpreting late aggregate data as evidence that the DMARC policy itself was not enforced. Reporting and message disposition are separate functions. A message can be evaluated under policy even when an aggregate report arrives later, is batched differently, or is not produced by a particular receiver. Keep enforcement diagnosis anchored to message/authentication evidence rather than report-clock expectations.

A reproducible test from raw evidence

Inspect the live DMARC TXT record for ri, then review actual report date ranges and generator organizations over several days. Compare behavior by receiver instead of measuring against one requested interval.

Audit current records for `ri` and then audit the software consuming aggregate reports. Search alert rules, scheduled jobs, and dashboards for assumptions such as “a report must arrive every N seconds.” Compare actual reporting cadence across several major receivers and several days. If you use RFC 9990 XML reports, deduplicate by report identity and reporting organization instead of treating each file arrival as a unique time slot. The test is successful when the monitoring pipeline remains accurate even if one receiver reports daily, another batches differently, and a low-volume receiver produces no file in a short interval.

Repair only the failing layer

Remove ri from new templates and make ingestion tolerant of different arrival times, overlapping delivery delays, and multiple reports for a period. Alert on missing coverage using a wider window than one hour.

The repair is usually to remove `ri` from newly maintained record templates and document that cadence belongs to the reporting side, not to sender enforcement. Existing records with the historic tag should be cleaned deliberately rather than during an unrelated enforcement change, so a policy rollout does not mix semantic and cosmetic edits. Design alerts around authentication failure rates, source changes, unexpected sending IPs, and missing data over a meaningful window. This yields a monitoring system that survives provider cadence changes without creating incidents from an obsolete tag.

Small-sender example

A domain may receive one Google report covering a UTC day and several files from another receiver. That variation is not evidence that the policy record failed simply because the old ri request was shorter.

Reporting pipelines should be resilient to irregular arrival. Store the report’s own metadata—reporting organization, report ID, begin/end interval—and use that interval for aggregation instead of the filesystem arrival time. That prevents a delayed file from being graphed as if its authentication events happened when the attachment arrived. It also helps deduplication when a provider retries delivery or a mailbox rule creates duplicate copies. For a small sender, daily trend review is usually more actionable than trying to force hourly reports through DNS. Use faster signals such as current SMTP errors and message-level Authentication-Results for live incidents; use aggregate DMARC data to see source distribution and alignment patterns over a broader period. This division of labor remains valid even as individual reporting organizations choose different schedules.

What to retain in the incident log

Track report generator, policy domain, begin/end timestamps, arrival time, report ID, and duplicate status. Those fields tell you what period the data covers without relying on a DNS cadence hint.

The boundary that prevents over-correction

Do not fabricate gaps by assuming every mailbox provider participates in DMARC aggregate reporting. Absence of a report from one receiver is not the same as absence of mail.

Field checklist

• Capture the raw evidence for DMARC ri tag removed RFC 9989 reporting interval before editing DNS, queue state, or mailbox metadata.
• Confirm the cited mechanism using dmarc-rfc, dmarc-aggregate rather than a generic deliverability score.
• Keep a known-good control case so the failing layer can be compared without changing several variables at once.
• Apply the narrow repair described for DMARC ri is historic in RFC 9989: stop promising a custom aggregate-report interval and preserve a rollback or retry path.
• Repeat the original failing test after the change; do not substitute a different checker as proof of recovery.
• Store timestamp, affected identity, raw result, action taken, and the post-change result in the operator log.