Based on the data we receive at DMARCanalyzer.com we see that the source for these 'multiple SPF record' reports is mostly Microsoft.
About 98.5% of these records are from Microsoft. The other 1.5% is from 126.com/163.com/yeah.net. Regards, Michiel DMARCanalyzer.com 2016-04-04 19:03 GMT+02:00 Lugo, Dave via dmarc-discuss < dmarc-discuss@dmarc.org>: > Thanks, I see a need to familiarize myself with 7208… > > -- > Dave Lugo > Engineer, Comcast Anti-Abuse Technologies > Desk: 215-286-5451 > > > From: Franck Martin <fmar...@linkedin.com> > Date: Monday, April 4, 2016 at 1:00 PM > To: Dave Lugo <dave_l...@cable.comcast.com> > Cc: DMARC Discussion List <dmarc-discuss@dmarc.org> > > Subject: Re: [dmarc-discuss] Multiple SPF results in report > > The question, is what is the RFC5321.mailfrom is empty? The > RFC7208.MAILFROM is never empty. > > https://tools.ietf.org/html/rfc7208#section-2.4 > > SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check > either has not been performed or has not reached a definitive policy > result by applying the check_host() function to the "MAIL FROM" > identity as the <sender>. > > [RFC5321] allows the reverse-path to be null (see Section 4.5.5 in > [RFC5321] <https://tools.ietf.org/html/rfc5321#section-4.5.5>). In this > case, there is no explicit sender mailbox, and > such a message can be assumed to be a notification message from the > mail system itself. When the reverse-path is null, this document > defines the "MAIL FROM" identity to be the mailbox composed of the > local-part "postmaster" and the "HELO" identity (which might or might > not have been checked separately before). > > > > On Mon, Apr 4, 2016 at 8:59 AM, Lugo, Dave via dmarc-discuss < > dmarc-discuss@dmarc.org> wrote: > >> Franck, >> >> What if the RFC7208.MAILFROM is empty? I recall some questions from >> colleagues re dmarc reporting and the spf scope (help or mailfrom). >> >> Thanks, >> >> Dave >> >> -- >> Dave Lugo >> Engineer, Comcast Anti-Abuse Technologies >> Desk: 215-286-5451 >> >> >> From: dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of >> Franck Martin via dmarc-discuss <dmarc-discuss@dmarc.org> >> Reply-To: Franck Martin <fmar...@linkedin.com> >> Date: Monday, April 4, 2016 at 11:51 AM >> To: Maarten Oelering <maar...@postmastery.net> >> Cc: "n...@graafhenk.nl" <n...@graafhenk.nl>, DMARC Discussion List < >> dmarc-discuss@dmarc.org> >> Subject: Re: [dmarc-discuss] Multiple SPF results in report >> >> It is a bug. >> >> There can only be one SPF per record. Theoretically SPF returns 2 >> results, one for the RFC7208.HELO and another one for RFC7208.MAILFROM, but >> DMARC takes as input only RFC7208.MAILFROM, therefore only this results is >> needed in DMARC reports. >> >> RFC7208.MAILFROM is not RFC5321.MailFrom, there is a subtle but important >> difference here. >> >> On Mon, Apr 4, 2016 at 12:23 AM, Maarten Oelering via dmarc-discuss < >> dmarc-discuss@dmarc.org> wrote: >> >>> Do you mean that in the XML you see 6 <spf> elements in one >>> <auth_results> element? Or do you mean you see 6 different <spf> domains in >>> the your reports? >>> >>> Maarten Oelering >>> Postmastery >>> >>> On 4 apr. 2016, at 09:05, Nick via dmarc-discuss < >>> dmarc-discuss@dmarc.org> wrote: >>> >>> I received a DMARC report with multiple SPF results. I wonder how this >>> is possible as I only have one SPF record for my domain defined. In one >>> report I got 6 SPF results. >>> >>> The only thing I could think of is some automatic forwarding service >>> changing the return path header. Are there more usecases possible how this >>> can happen? >>> >>> Thanks >>> Nick >>> _______________________________________________ >>> dmarc-discuss mailing list >>> dmarc-discuss@dmarc.org >>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >>> >>> NOTE: Participating in this list means you agree to the DMARC Note Well >>> terms (http://www.dmarc.org/note_well.html) >>> >>> >>> >>> _______________________________________________ >>> dmarc-discuss mailing list >>> dmarc-discuss@dmarc.org >>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >>> >>> NOTE: Participating in this list means you agree to the DMARC Note Well >>> terms (http://www.dmarc.org/note_well.html) >>> >> >> >> _______________________________________________ >> dmarc-discuss mailing list >> dmarc-discuss@dmarc.org >> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >> >> NOTE: Participating in this list means you agree to the DMARC Note Well >> terms (http://www.dmarc.org/note_well.html) >> > > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well > terms (http://www.dmarc.org/note_well.html) >
_______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
