SPF, DKIM, DMARC, and Apple mail

Recently our company migrated from an on-premises email solution to hosted Exchange. The change was surprisingly easy and everything worked as expected.

A couple of months later we moved our on-premises Barracuda to the cloud (ESS). Everything appeared to be working properly for the first few months, then some people started having issues. Mail forwarded to Apple owned domains (iCloud, mac.com) was being rejected as failing DMARC.

After some investigation, correcting of SPF records, and enabling of Sender Rewrite Scheme (SRS) in Barracuda, mail was still failing the DKIM check and thus DMARC. For that reason, Apple domains kept sending NDA notices for any forwarded email.

Contacting support, Barracuda blamed O365 and O365 blamed Barracuda. We were almost to the point of hiring a contractor when I found a little blurb in the Barracuda knowledgebase about how ‘link protection’ was turned on by default and would result in DKIM failure because, of course, the body had been changed. This means a different hash and DKIM failing as it should in this case. None of this showed in the headers because the links looked normal when viewing them.

So, we turned off link protection and TA-DA email passed DKIM and DMARC without issue. That was a lot of time and research I’ll never get back, but it did feel good to fist-pump the air in joy at finding the solution.

So, if you forward mail to Apple domains, be sure that link protection is turned off or it will bounce back forever.