BuildNot yet confirmed elsewhere1 publisher2 min readPublished
RFC 9989 removes the DMARC ri tag and leaves report timing to receivers
RFC 9990 says DMARC aggregate reports typically cover a single UTC day starting at 0000UTC, and RFC 9989 has no interval tag to change that. A dev.to write-up says a new domain's first report arrives a day or more after publication, so teams should test their pipeline first.
The Engineer · Build desk
What happened
- RFC 9990 took over aggregate reporting from RFC 7489 in May 2026.
- Under RFC 7489, any reporting interval other than daily was "accommodated on a best-effort basis".
- If a rua address sits in another organisational domain, the receiver must find a v=DMARC1 TXT record under _report._dmarc on the destination host, or "the URI MUST be ignored".
- In the author's run on 13 October 2026, mozilla.org's vali.email address was authorised through a wildcard, while its mozilla.com address returned wildcard=False.
Why it matters
- constraint With no interval tag to request an earlier report, parser and mailbox bugs surface a day late at best, so the testing has to finish before the record is published.
- exposure A missing authorisation record for an outside rua address produces silence, not an error, so the gap shows up only as reports that never arrive.
- decision Teams that run their own report mailbox choose between a wildcard, which lets any pointing domain pass, and one record per sending domain, which needs a new entry for each domain added. The author says the per-domain case is the one to test.
The loss of `ri` costs less than the removal suggests. The retired default was 86400 seconds [4], which is 24 hours [24]. A domain that never set the tag was already on a daily schedule. In our view, only teams that had asked for a shorter interval lose anything.
The spec text hedges. It describes reports as "daily (or more frequent)" [7], and the single-UTC-day period is only what a report will "typically" cover [8]. The write-up's author draws a firmer conclusion: the earliest real report covers the UTC day on which the record is published, and it arrives after that day closes, once the receiver gets round to sending [9]. That is a sound planning assumption. It is still a reading, because the spec does not settle which receivers send first or which never send [10].
The DNS half is the part that can be checked today. The author's script uses only Python's standard library. It asks Google's DNS-over-HTTPS JSON API for the authorisation name, then for a name that cannot exist under the destination, to see whether a wildcard answers [15]. Across mozilla.org and wikipedia.org it found three cross-domain destinations, all authorised, one through a wildcard [23]. Stackoverflow.com's address sat in the same organisation, and example.com had no `rua` tag at all [17]. Three destinations from one morning is too few to say how common wildcards are.
The script has a stated limit. Its organisational-domain test compares the last two labels, and the comment above it calls that "good enough for .com/.org/.net" [21]. Anyone testing domains under other suffixes needs a stricter test before trusting its same-organisation branch.
The excerpt ends mid-sentence in the DNS section. The write-up splits the pipeline into the DNS half, the mail half that carries the file, and the parser [22], so the mail and parser tests are not in the text we can read.
What to watch
- Whether any large receiver sends aggregate reports more often than daily under RFC 9990's "or more frequent" wording.
- The mail and parser halves of the author's test, which the excerpt cuts off before reaching.
- Whether hosted report providers keep publishing wildcard authorisation records, since a wildcard lets any domain that points at them pass.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap−5
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The first DMARC aggregate report for a new domain arrives a day or more after the record is published, from a receiver the owner does not control, on a schedule the owner cannot change.
ReportedSupportedSource: dev.to write-up, 'Testing a DMARC aggregate report pipeline before the first real report arrives'View cited source - [2]
If the code that reads aggregate reports has a bug, the owner finds out a day late, and whatever it dropped is gone unless the sender happens to send it again.
- [3]
RFC 9990 took over aggregate reporting from RFC 7489 in May 2026.
- [4]
RFC 7489 had an ri tag that asked receivers for a reporting interval, and it defaulted to 86400 seconds.
- [5]
Under RFC 7489, any reporting interval other than daily was 'accommodated on a best-effort basis'.
- [6]
RFC 9989, the new DMARC core spec, lists ri under 'Tags Removed' and marks it historic in the IANA table.
- [7]
RFC 9990 describes 'daily (or more frequent)' reports.
- [8]
RFC 9990 says a reporting period will typically 'encompass a single UTC day, beginning at 0000UTC'.
- [9]
The author concludes that the earliest a real report can cover a new record is the UTC day it is published, and that it arrives after that day closes and the receiver gets round to sending.
- [10]
Which receivers send first, and which never send at all, is outside the spec.
- [11]
A receiver discovers the rua tag when it looks up a domain's DMARC record for mail it received (section 3.4); with no rua tag there are no reports.
- [12]
If the rua address is in a different organisational domain from the one publishing the policy, RFC 9990 section 4 requires the receiver to find a TXT record at <policy domain>._report._dmarc.<destination host> that starts with v=DMARC1; if it does not, 'the URI MUST be ignored'.
- [13]
When the authorisation record is missing, nothing tells the domain owner it happened; the owner just gets no reports.
- [14]
Section 4 explicitly allows a destination to publish a wildcard authorisation record (*._report._dmarc.example.com).
- [15]
The author's Python script uses only the standard library, reads a domain's DMARC record, and for each rua destination on another domain queries the authorisation name through Google's DNS-over-HTTPS JSON API, plus a name that cannot exist under the destination to detect a wildcard.
- [16]
In the author's run on 13 October 2026 at 07:41 UTC, mozilla.org's rua address at vali.email was authorised with wildcard=True, while its address at mozilla.com was authorised with wildcard=False.
- [17]
In the same run, wikipedia.org's rua address at wikimedia.org was authorised with wildcard=False, stackoverflow.com's rua address was in the same organisation so needed no check, and example.com had no rua tag.
- [18]
Organisations that receive their own reports on a sister domain publish one authorisation record per domain: mozilla.org._report._dmarc.mozilla.com exists, and a made-up name under mozilla.com came back NXDOMAIN.
- [19]
The hosted reporting address answers for a made-up name too, so it publishes a wildcard and any domain pointing at it passes.
- [20]
The per-domain record pattern is the one to test if you run your own report mailbox: add a new sending domain, forget its record on the receiving domain, and reports for that domain are affected.
ReportedSupportedSource: dev.to write-up author (the source text is cut off mid-sentence)View cited source - [21]
The script's organisational-domain test compares the last two labels, and its code comment calls it 'good enough for .com/.org/.net'.
- [22]
The author splits the pipeline into three parts: the DNS half that decides whether anyone sends reports, the mail half that carries the file to the code, and the parser.
- [23]
In the author's run, three cross-domain rua destinations were checked (two for mozilla.org, one for wikipedia.org). All three were authorised, and one used a wildcard.
- [24]
The retired ri default of 86400 seconds is 24 hours.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toTesting a DMARC aggregate report pipeline before the first real report arrives
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.