I manage the Dmarc implementation across several domains and I feel it’s not unusual to see some reports from Enterprise Outlook/Outlook.com where DKIM fails (I’d say it seems to happen both with forwards and non-forwards). The emails were sent from it’s original source with valid DKIM which means that O365/Outlook are modifying the content/header, making DKIM fail.
Does anyone experience the same thing and know in what cases/why O365/Outlook would modify the content/header making DKIM fail? For some of my sources it’s not possible to align SPF with the sending domain either, which makes these emails fail Dmarc as we’re depending on the DKIM signature to be preserved.
There are 2 main scenario, in my experience, where DKIM fails in relations to MS365 or outlook handling of emails.
The DKIM check results in a DMARC Fail due to a temperror verdict. There could be several causes for this kind of verdict, but more often than not it will be due to DNS timeouts where Microsoft were unable to retrieve the DKIM public key record due to DNS timeouts.
Automatic forwarding. A mailbox rule with a routing rule of “redirect to” will always break DKIM. this is a known issue with the way Outlook handles emails and it’s been that way for years. When automatically forwarding from a Outlook mail client, the “Forward” action is recommended if a complete mailbox forward is not possible or desirable. Alternatively, the “redirect to” action within the scope of a server mail flow rule (transport rule) will also work, but this needs to be done at the server level by an email administrator.
I stumbled upon the below in another older thread here on the forums, which could also at least partly explain the cases I’m seeing:
“That being said, Microsoft does not currently report if an override took place for any reasons (arc, whitelist). This means Enterprise Outlook and Outlook reporters will only ever show you results of either “none” for when DMARC passes, or whatever your policy is at in DNS for a failure verdict.”
Coming along here while having issues with emails forwarding from a customer with pretty tough dkim/dmarc rules, that got eaten up somewhere after forwarding from o365 to gitlab.com support desk feature.
We use a shared mailbox with full mail forwarding, and only had issues with this particular customer.
Simiar to @Asher I removed the forward action and added some mail flow:
