Q: How can I deal with the fraud warnings inserted by Office 365?

By Joshua DesPortes
Sales Engineer, L-Soft

In a previous tech tip, we wrote about the fraud warnings that Office 365 has started to insert when receiving an email containing its own "From" domain in the headers after passing through LISTSERV.

Contrary to what Microsoft says in its documentation (please see link below), this happens even with messages passing SPF and DMARC validation. No other domains, including other Office 365 domains, will see this warning. The extra flagged text is added to the plain text and HTML bodies of the message so that a reply or forward will also display the warning to any subsequent recipient.

Our extensive testing with Microsoft support concludes that the only current solutions are Exchange Transport Rules (ETRs) or rewriting the "From" address using DEBUG_DMARC_REWRITE. Unfortunately, these workarounds are not pretty, require constant updating and only work for known specific domains. While we would like for things like passing SPF, DMARC and DKIM to prevent this notification, it appears that the spam heuristics used in these systems have some hard coding that prevents that.

The Problem

Consider companies A and B who both use Office 365 for their email. They have domains o365.A.com and o365.B.com respectively and are both using a LISTSERV server at LSV.A.com. Emails from o365.A.com through LSV.A.com will go to o365.A.com with a fraud warning and to o365.B.com without a warning.

Emails from o365.B.com through LSV.A.com will go to o365.A.com without a warning, but it is added to o365.B.com emails on the receiving end.

Now if company A uses an ETR to have messages from LISTSERV skip filtering, these scenarios are slightly different.

So this works on a case-by-case basis and company B could also use an ETR, but now let's add some more companies (C, D and E) who each have their own Office 365 domain and LISTSERV server. Every single company can add an ETR for their and every other LISTSERV service as they find them, but as described above, this is not desirable because this list will keep growing and shrinking requiring continual investments of time.

We have spent time with Microsoft support trying to resolve this issue and found that they have no interest in creating a scalable resolution. You can read more about Microsoft's suggestions in their blog post, but remember that only the two solutions mentioned above actually work.

Subscribe to LISTSERV at Work.