How about this! p=none or quarantine trusts SPF and DKIM, but p=reject trusts DKIM only.
This option addresses Google's desire for a strict rule to protect the most aggressively attacked domains, while leaving flexibility for those who want it. DF On Thu, Jun 22, 2023, 9:55 AM Scott Kitterman <[email protected]> wrote: > My conclusion (it won't surprise you to learn) from this thread is > precisely > the opposite. > > In theory, DKIM is enough for DMARC (this was always true), but in > practice it > is not. > > I don't think there's evidence of a systemic weakness in the protocol. > We've > seen evidence of poor deployment of the protocol for SPF, but I think the > solution is to fix that (see the separate thread on data hygiene). > > Scott K > > On Thursday, June 22, 2023 9:46:07 AM EDT Sebastiaan de Vos wrote: > > It's not easy to set a DKIM key, I can agree with that. I do think, > > Marty should have tested before sending, though. > > > > None of this, however, solves the issue of SPF weakening the DMARC > > standard. The weakness in SPF is not incidental, but systematic. That is > > - independent of the numbers - the reason why I vote to have SPF removed > > from the DMARC standard. > > > > On 22.06.23 15:31, Todd Herr wrote: > > > When we look at the numbers others have posted on the topic, and we > > > see a perhaps higher than expected percentage of DMARC passes that > > > relied on SPF only (or at least a higher than expected rate of DKIM > > > failures) I'd posit that many of those DKIM failures are due to the > > > challenges that Marty and people like them face with getting the key > > > published. > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
