Hello, > Maybe the ability to outsource report analysis played a role. But the 51.42% > of ruas and 57.12% of rufs that only direct reports to their own domain (data > posted on June 16th[*]) suggest that is not the only reason.
I will complete Alessandro's analysis, from the measurement I did for my [ https://hureau.com/paper/pam2024Dmarc.pdf | research paper ] in 2024 (subsections 4.2 and 4.3). In October 2023, I scanned 286M active domain names (registered domain names) for their DMARC record: 15.9M had a valid one (5.4%). Out of those domain names subscribing to DMARC, ~42.8% of them have either a RUA or RUF tag in their published policies. 42% and 21% of domain names have at least one URI in the RUA and RUF tags, respectively. (Only 0.9% have solely RUF) About the email addresses and outsourcing to their parties : a total of 11.7M email addresses are present in the tag (it represents a set of 4M, some email addresses are used in multiple DMARC records). I extracted the registered domain name parts of the email addresses, and ~30% of them belong to proofpoint, reportdmarc.nl, mailinblue, agari, and dmarcanalyzer. I did not go further in the analysis, but Figure 5 also shows other DMARC actors (dmarcian, valimail, cisco, dmarcadvisor, etc..) > But the 51.42% of ruas and 57.12% of rufs that only direct reports to their > own domain I did not produce the analysis, but from my souvenirs, the DMARC policies that had ONLY email addresses of their own domain were not that high (they usually had multiple email addresses, and their own domain was present in the tuple) Best regards, Olivier Hureau De: "Alessandro Vesely" <ves...@tana.it> À: "dmarc" <dmarc@ietf.org> Envoyé: Mercredi 2 Juillet 2025 11:47:38 Objet: [dmarc-ietf] Re: Security Considerations On Tue 01/Jul/2025 13:18:09 +0200 Alessandro Vesely wrote: >> On Mon, Jun 30, 2025 at 2:45 PM Murray S. Kucherawy <superu...@gmail.com> >> wrote: >>> [...] >>> Wouldn't DKIM error detection satisfy the need in this situation? Why do we >>> need failure reporting at both levels? >> >> [...] > Albeit less honored than rua= requests, failure reports are still the most > successful of all the RFC 5965 derived instances, IME. I thought I would corroborate this statement by querying dnswl.org subscribers again. This time I also queried for DKIM, SPF and their respective error reporting requests, as specified by RFCs 6651/2. The script is not perfectly accurate, as it relies on an optional tag for RFC 6651, for example (body of the loop below.) However, I think the averages are mostly correct. Here are the results: domain.list: 23488 records 16972 DMARC records (72.26%) 13178 rua reporting (56.11%) 8631 ruf reporting (36.75%) 17999 dkim (76.63%) 14 dkim reporting ( 0.06%) 21900 spf (93.24%) 10 spf reporting ( 0.04%) Maybe the ability to outsource report analysis played a role. But the 51.42% of ruas and 57.12% of rufs that only direct reports to their own domain (data posted on June 16th[*]) suggest that is not the only reason. Best Ale -- [*] https://mailarchive.ietf.org/arch/msg/dmarc/oFNGmCVp5jtNjDSubkUW6twg7bE ----- begin body of the query script loop ----- ((++total)) record=$(dig +short "_dmarc.$domain" txt | grep -E 'v *= *DMARC1') if [ -n "$record" ]; then ((++dmarc)) case "$record" in *+( |;)rua*( )=*) ((++rua));; esac case "$record" in *+( |;)ruf*( )=*) ((++ruf));; esac fi record=$(dig _domainkey.$domain | sed -rn 's/^;; ->>HEADER<<- opcode: QUERY, status: ([A-Z]*), id: [0-9]*/\1/p') if [ "$record" = "NOERROR" ]; then ((++dkim)) fi record=$(dig +short "_report._domainkey.$domain" txt | grep -E 'ra *=') if [ -n "$record" ]; then ((++dkim_r)) fi record=$(dig +short "$domain" txt | grep -E 'v *= *spf1') if [ -n "$record" ]; then ((++spf)) case "$record" in *+( |;)ra*( )=*) ((++spf_r));; esac fi ----- end body of the loop ----- _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
_______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
