Bring Your Own Domain for Microsoft 365 Service Messages

Use a Verified Domain to Send Microsoft 365 Service Messages

Announced as Microsoft 365 message center notification MC531211 (21 March 2023, Microsoft 365 roadmap item 103628) and now rolling out to tenants, organizations can choose one of the verified domains available for their tenant as the domain used for product advisory emails (Microsoft 365 service messages).

Microsoft 365 apps that support the feature include:

  • SharePoint Online
  • OneDrive for Business
  • Office
  • Stream
  • Planner
  • Project
  • Viva Connections
  • Viva Topics
  • Viva Amplify

Microsoft 365 apps use email addresses like and when they generate informational messages to communicate alerts, events, or digest information to users. For instance, when someone stores a document with a higher-level sensitivity label in a SharePoint Online site, SharePoint generates an email to tell them about the potential problem caused by the label mismatch. Figure 1 shows an example of such a message after selecting the domain to send service messages.

Using a verified tenant domain to send Microsoft 365 service messages
Figure 1: Using a verified tenant domain to send Microsoft 365 service messages

The messages don’t cover service alerts (when a service has an outage), nor do they cover One Time Passcodes (OTP) generated by sharing actions from OneDrive and SharePoint Online. Sharing notifications continue to use to ensure delivery of these emails.

Using a Verified Domain

The steps to select a verified domain for service messages are laid out in the Microsoft documentation. In essence, tenant administrators use the Send email notifications from your domain option in the Organization profile section of Org Settings in the Microsoft 365 admin center to select a username and domain (Figure 2).

Selecting a username and verified domain to use for Microsoft 365 service messages
Figure 2: Selecting a username and verified domain to use for Microsoft 365 service messages

The domain must be one of the verified domains for the tenant. After saving the new configuration, the Microsoft 365 apps switch to use the selected username and domain instead of their default domains when they send email. Messages are now routed by Exchange Online on behalf of the organization. Just like any of the verified domains used for mail routing, the DNS records for the chosen domain should be configured for SPF, DKIM, and DMARC. This is especially important if email is relayed to Exchange on-premises or an external email service.

The Username for Service Messages

By default, the username is set to no-reply. The intention of a no-reply address is that users know that replying to the address will result in an undeliverable message. However, it’s possible to change the username to one for a routable address such as a shared mailbox so that users can get a response to questions about why they received a service message. Be careful if you do this because service emails then appear to be like any other email sent by the chosen address. Figure 3 shows an example of a message sent by SharePoint Online to report updates to documents in a site. The message appears to come from a shared mailbox because that’s what matches the configured address for service messages.

A service message from a shared mailbox
Figure 3: A service message from a shared mailbox

Not External Messages

Because the tenant’s instance of Exchange Online routes the service messages, they are now internal rather than external and therefore will not be tagged with the external indicator. In some respects, this is a major advantage of choosing to use a verified domain as users might better accept the content of the messages if they don’t come from an external source. The downside is that users might need to adjust inbox rules to process service messages correctly.

If you use a mail flow rule to protect administrator accounts from external email, remember to update the rule to deal with messages from your chosen domain.

Not a Change to Worry Too Much About

After using this option for a couple of weeks, I don’t see any great downside to using a verified domain to send Microsoft 365 service messages. Something might have slipped my attention (and if so, I’d like to know), but overall I think this is a good change that all tenants should consider.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

2 Replies to “Bring Your Own Domain for Microsoft 365 Service Messages”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.