Re: [dmarc-ietf] DMARC2 & SPF Dependency Removal

["Brotman, Alex" <[e-mail]>]

A bit of additional data.  A single day of data for “many millions of messages”.   I did not (yet) look at alignment relating to DMARC, only the DMARC policies, and values of SPF/DKIM pass/fail.

For messages that were accepted:

37% reject
11% quarantine
24% none
28% absent

Of the ones that did have a policy of any sort (there is overlap for the domain count, as some messages from the same domain may have different states), and again, no DMARC alignment evaluated as part of these data queries:

DKIM Pass
SPF Pass
Message Count
Distinct Domain Count
N
N
0.16%
16.22%
N
Y
2.39%
13.70%
Y
N
1.02%
10.27%
Y
Y
96.43%
59.81%


However, while looking the SPF-only pass, roughly 32% of those had attempted DKIM, but were failing.  Some of these are failing all of the time, some a fair bit less.  I did not try to analyze why they might be failing.  To give a sample, here are the most popular failing domains.

twitter.com
tommybahama.com
news.saks.com
e.redrobin.com
redfin.com
emails.beallsoutlet.com
fedex.com
gmail.com
bestfriends.org

I took a closer look at “twitter.com”, and their messages are failing about 50% of the time.  The Gmail ones are largely coming from Google systems (the majority of related subjects seem suspect, so perhaps they do not sign messages they believe to be spam).  I also looked at those that were not attempting any sort of DKIM (that we appeared to log), and these had the highest incidence rate:

e.officedepot.com
snapsteps.com
remedina.com
catchmycity.com
emailinfo.bestbuy.com
quirky.retroidols.com
little-open.com
engage.minecraft.net
BroadwayInChicago.com
leblanc.crystalpurtechnology.org

If folks are curious about other data points, I’ll do my best to provide them.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: dmarc <[e-mail]> On Behalf Of Tobias Herkula
Sent: Thursday, June 8, 2023 1:59 PM
To: [e-mail]
Subject: [dmarc-ietf] DMARC2 & SPF Dependency Removal

Hi All,

This message comes out of some discussions I had at the current MAAWG meeting in Dublin.

I hope this message finds you well. The intent of this is to propose and discuss an evolutionary step in the DMARC protocol, which I believe will result in increased efficiency, reduced DNS load, and a more accurate reflection of the current email landscape.

My team recently concluded an extensive study on the current use and performance of DMARC. We analyzed a staggering 3.2 billion emails, and the insights drawn are quite enlightening. Of these, 2.2 billion emails (approximately 69%) passed the DMARC check successfully. It's quite an achievement, reflective of our collective hard work in fostering a safer, more secure email environment.

However, upon further analysis, it's evident that a mere 1.6% (or thirty-six million) of these DMARC-passed emails relied exclusively on the Sender Policy Framework (SPF) for validation. This is a remarkably low volume compared to the overall DMARC-passed traffic, raising questions about SPF's relevancy and the load it imposes on the DNS systems.

Given the current use case scenarios and the desire to optimize our resources, I propose that we explore the possibility of removing the SPF dependency from DMARC. This step could result in a significant reduction in DNS load, increased efficiency, and an accurate alignment with our predominant use cases.

However, such a fundamental shift in the protocol's architecture warrants a clear signifier. I suggest we upgrade our DMARC version string from the current state to 'DMARC2.' This upgrade would not only denote the change of SPF removal, but also the switch from the Public Suffix List (PSL) to the Tree-Walk algorithm.

By moving towards DMARC2, we not only update our standard to better reflect our present requirements, but we also make a clear commitment to the ongoing evolution and improvement of the protocol.

Best regards,

Tobias Herkula
Mail Security & Transfer
1&1 (GMX, Web.de, Mail.com, IONOS)