Q: How can I deal with the fraud warnings that are inserted into email messages by Office 365?
Office 365 customers who use LISTSERV have indicated that they have been receiving fraud warnings on certain email messages. The extra flagged text is added to the message by Office 365 on the receiving end when the "From" domain is the same as the receiving domain after passing through LISTSERV. However, other domains, including other Office 365 domains, will not see this warning. It is added to the text and HTML versions of the message so that a reply or forward will also display the warning for any recipient. Contrary to what Microsoft says in a blog post, this happens even with messages passing SPF and DMARC. A couple of workarounds are to use Exchange Transport Rules (ETR) or DEBUG_DMARC_REWRITE; but these workarounds are not pretty, require constant updating and only work for known, specific domains.
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 I said above, this is not reasonable because this list will keep growing and shrinking, requiring continual investments of time.
Another step that Microsoft suggests is to use DomainKeys Identified Mail (DKIM) to help prevent the fraud warning. We have now implemented DKIM message signing (formerly, only DomainKeys was supported). This is a deployment upon request, so if you are seeing this issue and would like to take part in the ongoing analysis and remediation, let a support representative know. To use DKIM, the process is almost the same as that followed for DomainKeys – create a public/private key pair, add/test the public key in the DNS record, and supply the private key to LISTSERV. The DKIM Signatures specification RFC6376 says that you will want to use a key of 1024 bits or larger. With this setup, you will be off and running signing list postings. You can set DKIM_SIGN_ALL=1 to also sign administrative messages and help steer those away from spam folders.
L-Soft also recommends that you use an SPF record to increase deliverability.
This type of move by Microsoft may establish a new trend causing other email providers to create comparable warnings for their users. If that happens, then you will want to have all the tools at your disposal to ensure that your messages get delivered to your subscribers' mailboxes unhindered. You can read about Microsoft's other suggestions in their blog post.
More information on DKIM can be found at:
Subscribe to LISTSERV at Work.