How to Resolve Plain Text Conversion for Non-Custom Domains When Sending HTML Newsletters via Microsoft 365 with Graph API?

Question

We are managing a Microsoft 365 email account under an organization, used primarily for sending newsletters. The emails are sent by a web application that integrates the Microsoft Graph API with application-level permissions. The Content-Type is explicitly set to HTML when sending these newsletters.

To ensure proper delivery, we have configured custom remote domains like Gmail and Yahoo to disable RTF. However, subscribers using other, non-custom domains are receiving the emails in plain text format, resulting in loss of formatting and a suboptimal experience.

Since our subscriber base includes emails from diverse domains, it is not feasible to configure all potential domains as custom remote domains. We also considered disabling RTF globally for the default domain (wildcard *), but this action raises a security vulnerability warning in the Microsoft 365 Exchange Admin Center.

Key Requirements:

1. The email account is used for sending HTML newsletters via a web application with Microsoft Graph API integration.
2. Manually configuring all possible subscriber domains as custom remote domains is impractical.
3. The solution must ensure that emails are delivered in HTML content type for all domains, while maintaining security best practices.

What is the recommended approach to handle this issue permanently for newsletters sent via a Microsoft 365 account, ensuring HTML formatting is preserved across all recipient domains?

Answer 1

You should not be using M365 for such scenarios to begin with. The service is not designed for bulk mailing external recipients. In fact, Microsoft is planning to further limits external sending rates, as detailed in this blog post: https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-introduce-external-recipient-rate-limit/4114733

Their suggested solution is to leverage the Azure Communication Services instead: https://learn.microsoft.com/en-us/azure/communication-services/concepts/email/prepare-email-communication-resource

Anyway, to answer your question, you have already examined the available options. You can control this behavior either on a per-domain or per-recipient basis. If toggling this on the default domain is not an option, your best bet is to provision additional remote domains where it makes sense. Or create mail contact objects for each recipient and toggle the setting therein.