Hi James and welcome to the forums!
There are two important topics to discuss here. First, DKIM survival. The reason the product expresses forwarding in this way is that SPF rarely helps indirect mail flow pass DMARC. This is often due to sender rewriting schemes (SRS), or simply because the forwarding server isn’t listed in the sending domain’s SPF record. DKIM plays a crucial role in ensuring that indirect mail flow, which is beyond your control, can still pass DMARC.
That being said, Avenan is a special case. Along with unique Microsoft reporting behavior regarding DMARC, this can create some confusing data. Avenan is a security product that is set up “in line” with the domain’s email flow. Let’s imagine the domain example.com uses Avenan.
Example.com has MX records pointing to Microsoft 365. Once an email is received, a special connector sends it to an Avenan SMTP server for additional scanning and analysis. After processing, Avenan sends the email back into Microsoft 365 via the domain’s MX record, using an IP whitelist connection filter to bypass spam scanning and email authentication failures.
Sender → MS365 → Avenan → Back to MS365 → Inbox.
The final piece of the puzzle is that Microsoft sends DMARC aggregate reports for all emails checked for DMARC, regardless of whether the sender is whitelisted. In the example above, two counts will be reported by Microsoft in DMARC reports: once when the email is first received from the sender, and again when the email is sent back into MS365 from Avenan. Even though MS365 may report a DMARC failure from Avenan, no enforcement will be applied due to the connection whitelist as part of the product’s setup.
In conclusion, as long as Avenan is set up properly according to the vendor’s directions, the owner of the Avenan service won’t experience any DMARC failures, and this data can safely be ignored.
I hope this helps!
