> > Presumably, a sender who uses DMARC might publish SPF to cover > > recipients who don't use DMARC, but would prefer that recipients use > > DMARC (authenticated by DKIM only). > > I get that, but that's still simultaneously saying "use SPF to > authenticate me" and "don't use SPF to authenticate me." If SPF is so > unreliable that you don't want people to use it for your DMARC alignment, > why would you want them to use it otherwise?
Because it's not better than DKIM and adds no value over DKIM... but it's better than *nothing*, so if you don't check DKIM, I'm providing SPF for you. > I worry this is encouraging security theater, look I have super secure > DMARC p=reject and, we won't get our deliverability numbers without a big > fuzzy SPF record. If the alternative to DMARC p=reject, for recipients who don't handle that, is nothing at all, I don't see that providing SPF is bad. And if you don't want that, don't publish an SPF record. But for now, DMARC isn't deployed widely enough that we can fully deprecate SPF, and SPF does still provide value when a receiver isn't implementing DMARC. If the DMARC spec makes that clear, I think we win. And recipients can still do what they want: if DMARCbis goes out with "use DKIM only" and a recipient wants to use SPF anyway, they can do that... just as a recipient that decides to use best-guess-SPF in the absence of actual SPF records is free to make that choice. Barry _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
