Use custom domain for email notifications within Microsoft 365

Despite what some commentators have repeatedly “prophesized” over the years, email is here to stay. Within the Microsoft 365 suite, more and more new features and services continue to rely on email as the primary notification method. Over time, some of these notifications started using the user’s own email address, whereas others continue to use a generic “no-reply” address. Examples of the latter category include no-reply@sharepointonline.com, no-reply@planner.com, no-reply@cloudappsecurity.com, and more.

The issue with such announcements is that they’re treated as external messages, which they technically are. But because they traverse the same path as any other external message, it’s harder to determine whether a message coming from Microsoft’s no-reply address is genuine or a spoof/phishing attempt. To address such concerns, and provide some basic branding capabilities, Microsoft is now introducing the Send email notifications from your domain feature, also touted as Bring your own domain (BYOD) for notifications. Let’s see how it works.

For the time being, the feature can only be controlled via the Microsoft 365 Admin center, by navigating to the Settings page > Org settings > Organization profile and clicking the Send email notifications from your domain link. A single on/off toggle is exposed therein, namely Use a custom send-from domain address. Once you toggle this on, you will be prompted to configure the full email address to be used, in the form of username @ domain.com, where domain.com is one of the verified domains within your Microsoft 365 tenant. The username part has a default value of noreply, but you can customize it as needed. You can even use an existing address, i.e. one for which an Exchange Online mailbox already exist.

The important part is of course the domain one, and it is your responsibility to make sure that the domain is correctly configured to handle mailflow. At the very least, consider stamping the required MX and SPF DNS records, with the DKIM and DMARC one also being highly recommended. Even though the official documentation claims that you can use a non-verified domain too, in my tests only verified domain (and subdomains) were allowed for selection.

In case you are interested in how the internals of configuring the feature work, it looks like it’s currently powered by an internal API. That is, no public Graph API endpoint is currently available. To get the status of the feature, a GET request is issued against the https://admin.microsoft.com/admin/api/Settings/company/sendfromaddress. When making changes, A POST request is issued against the same endpoint, with a JSON payload with two elements:

{"ServiceEnabled":true,"TenantSendFromAddress":"noreply@domain.com"}

Apart from the lack of Graph API endpoint, it looks like no Exchange Online cmdlet currently exposes said configuration either.

That’s really all there is to configuring the feature, if we don’t count the steps required to properly configure DNS. Let’s now see how the feature works on the “client” side, i.e. how a branded notification looks like. Since in my case I decided to use an address associated with an already existing mailbox, it’s also interesting to see whether this affects the behavior of the feature in any way. As for generating test notifications, the fastest way to do so is to generate a sharing report for your ODFB site, or assign yourself a tasks within Planner with a due date of today. Well maybe the former, as at least in my experience it took a looooong time for Planner to start respecting the new address. Here’s how the corresponding notification from SharePoint Online looks like:

Few things are immediately obvious. The address was resolved to the name of the mailbox, just like for any other internal message. No info tips warning you that the message was received from outside of the organization is visible either. Considering that all email notifications from supported services will now be coming from a single address, you can easily target them in transport rules to enable additional behaviors and augment your existing “external” protection.

Looking at the message headers reveals even more evidence that delivery was all handled internally:

Return-Path: sharednew@michev.info
From: SharePoint Online <sharednew@michev.info>;

X-MS-Exchange-Organization-AuthAs: Internal
X-MS-Exchange-Organization-SCL: -1

X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=923712ba-352a-4eda-bece-09d0684d0cfb;Ip=[20.31.162.40];Helo=[westeurope0.notifyp.svc.ms]
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TreatMessagesAsInternal-DB5EUR02FT066.eop-EUR02.prod.protection.outlook.com

The “authentication results” header looks like this:

X-MS-Exchange-Authentication-Results: spf=none (sender IP is 20.31.162.40)
smtp.mailfrom=michev.info; dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=michev.info;

Another interesting detail is that no messages are saved to the Sent Items folder of the mailbox “hosting” the chosen address, if you decided to go with such configuration. Looking at the message trace, this is the type of detail you can expect to see:

The message looks and feels like sent from the existing mailbox, which in turn raises the question whether the generic sending limits apply to such scenarios. Just to be on the safe side, you probably want to configure an address not currently in use, at least in tenants of size over thousand users.

Before closing the article, here’s a list of Microsoft 365 services currently supporting the feature:

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

Notable omissions include Microsoft Teams, Azure AD, both the Purview and Defender families of products, and more. Hopefully, we will see the list of supported services/product go over the coming weeks and months. In addition, some known exceptions are noted in the official documentation, such as the issuance of one-time passcodes for the OneDrive for Business and SharePoint Online sharing feature.

Lastly, keep in mind that this feature is currently in preview, so the experience might change without notice, and you are more than likely to encounter the occasional bug. Also, this feature is not related to the generic Azure AD branding controls, though it would be nice if we finally start seeing some examples of said controls being incorporated into notification emails…