Using Tenant Domains for OME Email is Sensible
As a fan of Office 365 Message Encryption (OME), I was bemused by Office 365 notification MC196886 published on November 27. The notification covers some updates intended to improve the authenticity of OME messages. In other words, to make sure that messages generated by OME (for example, to send recipients a one-time code to enable them to decrypt a message) were delivered and not treated as spam or junk mail.
These updates are due to begin rolling out to tenants in January 2020 and be complete in February 2020. The updates fulfill Office 365 roadmap item 59001.
The OME Updates
The updates coming next month are:
- OME will use a different layout for encrypted messages. No problem there. You can either accept Microsoft’s default layout or customize it.
- OME will use the customer domain. See the explanation below.
- Reduced odds that OME email will be identified as spam. This is associated with point 2.
- Capture non-delivery receipt (NDR) email. NDR is normally referred to as a non-delivery notification, but the explanation that you should create a bounces@ mailbox to capture NDRs was a tad terse, so we go into it below.
Using Tenant Domains for OME Service Messages
After the updates are applied, service messages generated by OME will use the sender’s domain. Today, OME messages originate from addresses like firstname.lastname@example.org (Figure 1).
In an era when it is easy for an attacker to spin up a new Office 365 tenant and use it to send phishing messages that look very similar to authentic messages, the potential existed for receiving email systems to consider OME service messages to be spam and redirect the messages to recipients’ junk email folder.
The change to use the sender domain means that receiving systems apply the same tests to OME messages as they do to other messages sent from the tenant. If sender domains are correctly configured for SPF, DMARC, and DKIM (including each domain having a valid DKIM signature), it is much more likely that OME messages are deemed to be authentic and delivered to inboxes.
OME Bounces Mailbox
When a recipient uses the OME portal to open a protected message, they can take whatever actions are assigned to them over the message. For instance, if a recipient opens a message protected with Encrypt-Only, they can reply to the message or forward it to someone else (Figure 2).
However, if they make a mistake and add a recipient that doesn’t exist or enter an incorrect email address, OME won’t be able to deliver the reply and the original recipient won’t know that the message failed because they won’t receive a non-delivery notification (NDR) as they would for normal messages. To get around the problem, tenants can create a bounces mailbox to receive NDRs for failures generated by recipient interaction with the OME portal. The intention is that someone with access to the mailbox can review NDRs and advise users what they should do next.
A bounces mailbox is any mailbox with the proxy address email@example.com. A shared mailbox is a good choice for this task, and you should assign proxy addresses to the mailbox for all domains used by the tenant. For example, the bounces mailbox for the Office 365 for IT Pros tenant has the proxy addresses:
Interpreting Microsoft announcements about new Office 365 functionality is what we do to keep the Office 365 for IT Pros eBook updated. That’s why you should subscribe to keep yourself informed.