MS-Exchange tends to normalize the email (like fix html) before storing it (in TNEF format) or forwarding it. It is known, and is being addresses. Several fixes have been in place in office365 (less so for on-premises systems), but your mileage may vary...
A search through the list archives may help you. On Tue, Apr 19, 2016 at 4:10 AM, Geir Waade via dmarc-discuss < dmarc-discuss@dmarc.org> wrote: > Hello, > > > > We have been ramping up DMARC usage over the last year or so, and recently > enabled the failure reporting option to allow recipient servers to notify > us when a message is quarantined or rejected due to a failing policy. We > have SPF and DKIM in place for our domains and have set the failure policy > to fo=0, which requires both SPF and DKIM to fail for the DMARC check to > fail. > > > > What we've noticed is a potential problem with certain conditions of > message forwarding, resulting in a bit of failure report flooding. Whenever > we send a message to someone with a Hotmail/MSN/Outlook.com address, who > has configured their account to forward email to another address on > Microsoft's services (Office365 / Exchange hybrid?), we get DMARC failure > reports from st...@hotmail.com. The headers in the report's attached > emails show that delivery from our servers to the hotmail server for the > original address succeeds, with both SPF and DKIM checks passing. However, > there's an internal delivery exchange of the message between outlook.com > / hotmail.com / onmicrosoft servers for the new recipient's address, and > the recipient's server performs a new authentication check on the forwarded > message. This fails the SPF check, which is to be expected, but should not > be enough to fail the message per our DMARC policy of 'fo=0'. However, for > some reason it also fails the DKIM check at this point – possibly due to a > modified subject or an added anti-spam scan disclaimer? The final > recipient's server politely adheres to our DMARC policy and > rejects/quarantines the message, and we get a failure report as a result. > > > > Is there anything we can do as a sender to prevent this from happening, > beyond relaxing the policy to maybe quarantine less than 100% of failed > messages? It seems odd that we are getting an abundance of these from > Microsoft, but almost nothing from other services. Has Microsoft > implemented some superfluous auth checks in their internal delivery line > that fails due to them breaking the DKIM signature on a previous step, or > is possibly this due to Office365 customer setup? > > > > I have several examples of emails with headers showing the odd forwarding > path these messages take, if you'd be interested in taking a look. Any > suggestions you can give us would be most welcome. > > > > Best regards, > > Geir W > > _______________________________________________ > 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)
