On 5/25/25 2:20 AM, Tom Ivar Helbekkmo via NANOG wrote:
SPF was the first. It lets you publish, through DNS, a list of the addresses of the mail servers that you have authorized to send email from your domain. When some mail server tries to deliver email purporting to be from your domain, you're asking the recipient mail server to check that list, and accept the email if the delivering mail server is on it, but refuse if it is not.
SPF wasn't really the first. Both DKIM and SPF arose pretty much at the same time.
DKIM was next. It lets you publish, again through DNS, the public key of a public/private pair. You then use the private key to create a cryptographic fingerprint of the message, using the body and a few selected headers (To:, Cc:, From:, and Subject: normally included). When a mail server out there receives the email, it can use your public key to verify the fingerprint. A match implies that the email has not been modified since it left the signing server. If the domain in the "From:" header matches the domain where the public key is stored, the recipient knows that the email was DKIM signed by a mail server trusted by the sending domain (since it must have the private key). It can, therefore, assume that the email really is from the "From:" address, and has not been modified along the way.
DMARC, finally, ties these things together. It lets you publish, once again using DNS, a few policy options for the handling of SPF and DKIM, for what you want done with the email, and for reporting back to you what was done, and why. DMARC requires either SPF or DKIM to pass, and you can choose whether you want the recipient system to quarantine or simply refuse email that fails to pass at least one of them.
It's never been especially clear to me why these two piece of policy needed to be unified -- it's certainly caused a huge amount of grief and a near-infinite amount of standards churn trying to do so as evidenced by it taking 10+ years to get to a still non-PS rfc, afaik. SPF had its own policy mechanism, DKIM its own too (ADSP nee SSP). Why DMARC is "better" is still pretty much a mystery, and my suspicion is it's mainly politics.
A modern mailing list is not a simple forwarder. It sends out copies of the received email item (which, then, will have passed the DMARC requirements of the sending domain, if specified, or it wouldn't reach the mailing list software in the first place),
So mailing list software today typically checks the originating domain's DMARC configuration. If that has a policy other than "none" (which says to deliver email even if it fails both SPF and DKIM), it will send the email "From:" the list, and not the originator. The email then nicely passes the mailing list's own SPF, of course. Additionally, the mail server sending it out from the list software will normally DKIM sign the outgoing email, so it ends up properly authenticating as coming from the mailing list software. It would be nice if this were more uniformly true, but alas I don't
There is no requirement that a mailing list honor or even care about DMARC. That's true of all of this: it's purely informational to the receiver to use as they will (or not). Expecting mailing lists to do anything in particular is a mistake. think you can really count on it. Even IETF mailing lists don't resign (somebody has claimed this is a bug, but it's been a bug for a very long time, from what I can tell).
This means that members of the list can choose to trust the mailing list owner to have configured everything so that they've properly verified the originating sender, and are not passing on something that is a forgery. If their own mail server is properly configured to check SPF/DKIM/DMARC, they can trust that the email is really arriving from the (trusted) mailing list.
More likely is that the receiving domain (ie, the mailbox provider) is the ones doing that. Obviously individual mailboxes don't scale very well.
This stuff isn't perfect, of course. As is obvious from what I wrote toward the end of the last paragraph, transitive trust is a problem that it would be nice to have a good solution for. ARC is an attempt at this, but has failed to gain traction. Let's hope that DKIM2 (which John Levine mentioned in another post in this thread), by attacking the problem from another angle, does better!
I don't expect that the soi-dissant DKIM2 will do much to help, and it seems to be a lot of wheel reinvention for its own sake. The closest thing for mailing list traversal is the so-called "modification algebra" but it's not really much different than what is already available with DKIM (ie, z= and l=), and it unfortunately requires active participation of the mailing list software which is going to be dodgy for probably a long, long time (this is unlike z= and l= which are under the control of the originating domain). Nobody but me, it seemed, cared about using that capability with DKIM so anything new imo is too little too late. If people started using the current DKIM capabilities as standardized in STD 76 I might have a different opinion, but to my knowledge either nobody or very few are. There isn't a silver bullet here and anything that claims so is peddling snake oil, IMO. Mike