[dmarc-discuss] Failure reports from Microsoft servers due to SPF and DKIM both failing for forwarded/resent messages
Geir.Waade at confirmit.com
Tue Apr 19 04:10:34 PDT 2016
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 staff at hotmail.com<mailto:staff at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dmarc-discuss