On Wed, Apr 3, 2024 at 5:21 AM Laura Atkins <la...@wordtothewise.com> wrote:
> > On 1 Apr 2024, at 13:18, Brotman, Alex <Alex_Brotman= > 40comcast....@dmarc.ietf.org> wrote: > > One item left out of Seth’s text is that due to MBPs who act in this > fashion, these SPF evaluation failures will (understandably) not show up in > DMARC reports, and the domain owner may not have visibility for these > failures. However, the text also puts the onus on the domain owner instead > of the MBP. The text could be altered to instead suggest that MBPs who > deploy DMARC should not utilize the outcome of SPF in this fashion. If the > domain owner wants to protect their domain, and has no idea if the MBP > supports DMARC properly (presuming they also have an enforcing policy), is > it more or less advisable to use “-all” with your SPF record? > > > Is that true, though? > > I just saw a report yesterday that someone had temp failures at Gmail (73 > to be exact) and Gmail sent 73 DMARC reports for that sender / IP combo. > > So that’s one bit of evidence that even if the message is not accepted, > DMARC reports are sent. > > laura > > -- > The Delivery Expert > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Delivery hints and commentary: http://wordtothewise.com/blog > This implies that the messages were not rejected at SPF (connection but before "DATA" command) but instead the connection was held open in order to evaluate SPF as part of DMARC. This is a different scenario than a MBP rejecting on the basis of SPF before DMARC evaluation. \Michael Hammer
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
