Exchange Transport News from Microsoft Ignite 2019
Published Nov 07 2019 12:15 PM 73.5K Views

With the number of emails delivered daily worldwide forecast to grow 18% by 2023, the criticality of email for businesses remains as strong as ever! And the Microsoft Exchange Online Transport team loves nothing better than to continue to improve our email service and introduce new and useful email features that help make your organization safe, smart, and secure. In fact, that's what our session at Microsoft Ignite 2019 is all about!

At Microsoft Ignite 2019 the Transport team showcased how the cloud improves the email experience for end-users and email admins. In our session BRK3312 - Office 365 email enhancements that makes your organization smart, safe, and secure we announced the following features, most of which will be coming your way in the first half of 2020.

Exchange Online Email Enhancements for End Users

  • Support for Plus Addressing
  • Send from proxy address (alias)
  • Message Recall in Exchange Online
  • Reply-All Storm Protection

Email Enhancements for Admins

  • Modern Exchange Admin Center (EAC) Portal
  • Customizable Recipient Limits
  • Securing SMTP Auth Submissions

Let's take a look at the awesomeness that each of these brings to the email party.

Support for Plus Addressing in Exchange Online

We love hearing from our customers about what features or improvements they'd like to see in Exchange Online. And boy, did we ever hear from you about this one! Over 5,000 votes for this feature on our User Voice feedback site! (you see, we really do look at that stuff, so make sure you get involved)

Plus address support allows you to add a suffix to the local-part of your email address to create a child address or disposable address which you can use as your email address. For example:

Standard address:

Plus Address:

Now, when Kim signs up for the newsletter, she can use the special  address, to sign up, instead of her standard email address. She can then create an Inbox rule to route all messages sent to this + address ( to a folder of her choice. It's a great way to more easily manage your Inbox, track marketing or sales campaigns, and even help you identify when a Web site or service account sold (or accidentally leaked) your email address to a spammer. . .er. . .uh. . .a legitimate third-party marketer who is now sending you endless emails about loan offers and other items you're most surely interested in. ;)

Plus addressing support is already available for, but it's a bit trickier for Exchange Online. You see, the RFC (the collection of rules for all things interweb) says that having the "+" character in an email address is a perfectly valid character to use in email addresses as part of a standard email address. But plus addressing treats the "+" sign as a special indicator where the standard email address used for routing is to the left of the "+" while everything to the right is ignored for routing purposes. And it turns out there are quite a few Exchange Online customers who have email addresses in their organizations that have "+" signs in them. So, as we roll out plus addressing support in Exchange Online, we'll be working with these customers to make sure we don't inadvertently break any of their mail flow.

Word of advice: If you don't have any email addresses in your organization that have a "+" sign in them already, great! Don't start now! Keep your email addresses free of "+" signs, so that when support for plus addressing rolls out in 2020 you and your organization's end users will be able to take full advantage of the coolness plus addresses offer without anyone's mail flow breaking.

Send from SMTP Proxy Address (alias)

OK, we admit it – sometimes we get a bit embarrassed about some less-than-critical-but-still-annoying issues that have been out there for a while that we haven't addressed yet. Actually, we get a lot embarrassed about it and sometimes would rather slink back to our shared workspace desk (offices are so 20th century) and immerse ourselves in the depths of code so as to not face the torches and pitchforks of real customers. But face it we must, and at Microsoft Ignite 2019 we've got a bunch of email enhancements that we're finally doing something about! Supporting the ability to send from an SMTP proxy address (alias) and having the that address be preserved in the recipient's FROM and REPLY TO is one of those enhancements!

Sending from an SMTP proxy address or alias is useful for multiple scenarios. The first is to send from a team alias rather than your own. Let's say instead of sending from her standard alias, part of Kim's job is to send out emails that appear to come from her team, the Communications Team. So instead of sending from, she wants to send an email from Another common scenario for sending email using an alias is mergers and acquisitions, where one company acquires another company and some employees from each company need to be able to send email from both of the companies' domain names. For example, Contoso acquires Northwind, and Kim now needs the ability to send as both and kimakers@northwind.

While you can set up an SMTP proxy address for Kim, she wouldn't be able to send from it using the native capabilities of Outlook, Outlook on the web, or Outlook Mobile. And even if she used a spiffy Outlook plug-in to send the mail from an alias, in some circumstances the recipient would see her primary address in the FROM and REPLY TO fields,, instead of the intended

Addressing this (no pun intended) is a journey – we're going to start with Outlook on the web (OWA – yes, we know the acronym doesn’t make sense, but we all know it as OWA don’t we?), where coming in the first half of 2020, OWA will natively support the ability to select an alias from a drop-down list in the compose panel in OWA, and when the recipient receives it, the FROM and REPLY TO fields will show that alias instead of the primary SMTP address. It'll look something like this:


Message Recall in Exchange Online

Outlook introduced Message Recall around 20 years ago, and despite the fact we all seem to think it doesn’t work, we’d like to think it's still better than doing nothing at all when you really goof up. In Office 365 we once tracked over 800,000 recall attempts in one day! So yeah, people are still goofing up and to say it's still a popular feature is an understatement! But wouldn't it be great if the recall worked better for more recipients, and was easier to understand for whom it failed and for whom it succeeded? Well. . .here's another of those long-standing issues that we're addressing, thanks to the power of the cloud!

The current Message Recall feature is actually client-based, and only Outlook for Windows supports it today. The sender needs to use Outlook to recall a message, and the recipient needs to use Outlook in order for the recall to work (there are some other conditions that must be met as well, discussed in this article). Not great, we know.

But thanks to the cloud we now host millions of end user mailboxes in Office 365 and are able to implement a cloud-based message recall in the Office 365 datacenters that will recall the message directly from Office 365 mailboxes. It won't matter which email client the recipient uses to sync with their Office 365 mailbox (whether Outlook, OWA, Outlook Mobile, or some other email client)! Our initial testing of this feature with Microsoft employees shows nearly double the number of successful recalls compared to the Outlook client-based version of Message Recall. Yep, Microsoft employees goof just as much as anyone else, and also need this feature to work better than ever! I like to say with Message Recall in Office 365 "It actually now works. . .better.TM" :) It's not 100% - for example, we'll still honor the condition that if the message has been read by the recipient we won't recall it - let's just say a few hours in a windowless room with representatives from our legal team ultimately convinced us of that. ;) But it's a lot better than before, and we plan to continue honing the feature in the future to make it even better and more usable in additional scenarios.

In addition to better recall success, we're also introducing an aggregate recall status report to make it easier to find out for whom it succeeded and for whom it failed. The Outlook feature today sends sindividual email messages for each success or failure it registers – pretty unwieldy if the recall is for more than a dozen recipients. The new aggregate Message Recall status report will look something like this:


Reply-All Storm Protection

Anyone here remember BedlamDL3? Me too! Ha, ha! OK, not everyone was around in 1997 to either experience it or hear about it, but BedlamDL3 was probably the first recorded Reply All storm that hit the news in a big way. A brief history follows.

In 1997 an employee at Microsoft noticed that he was on a distribution list (DL) called BedlamDL3. He couldn't see any members in the list nor the owner, so assuming it was just a random empty DL he sent an email to the DL asking why he was on it and could he be removed from it. The belief was that only the owner would get the mail and then remove him from it. What he didn't know is that the DL included one-quarter of all Microsoft employees, around 13,000 members at that time. So all 13,000 members got a copy of his request to be removed from the DL, and others started to use Reply All to also ask to be removed - the now iconic "Me, too!" requests. Other "heroes" chimed in (using Reply All) to say how bad it was to Reply All to the thread and to please stop, and so on, ad nauseum. Within an hour 15 million messages were generated, 195 GB of data, and it brought Microsoft's Exchange servers to a slow crawl. It took two days to clean it all up.

After the BedlamDL3 incident, the Exchange team introduced a number of features to help reduce the chance of such an occurrence from ever happening again, for Microsoft and for all Exchange customers. Hidden Distribution Lists, Recipient Limits, and DL sender restrictions were just a few of the measures introduced. And since then, the number of Reply-All storms and their severity have been greatly curtailed. Yet, human beings are. . .well, human. So people still get caught up in Reply-All storms, asking to be removed from a DL or to be removed from the thread that's going on and on, etc.

So, the Exchange Online Transport team decided we'd help us poor human beings out, and again thanks to the cloud and the vast scale and telemetry in Office 365 that we're able to evaluate and work with, we're introducing yet another feature to better help thwart, or at least reduce the impact of, Reply-All Mail Storms. We call it: Reply-All Storm Protection.

Reply-All Storm Protection in some ways sounds pretty simple (and cool), but there's some pretty intelligent stuff going on in the background, in the cloud, that makes it possible:

  • For an organization in Office 365, we'll identify what looks like might be a Reply-All storm conversation
  • We'll then temporarily block anyone from replying to all members of the conversation, sending a bounce message (NDR) back to anyone who tries

So when we detect what looks like it might be (or become) a Reply-All storm, anyone who subsequently attempts to reply to everyone will get an NDR back instead, basically telling them to stop trying to Reply All to the thread. Here's an example of what that NDR might look like once we ship the feature in the first half of 2020.


We'll maintain the temporary block (and sending of NDRs) active for a number of hours, a "cool-down" period, to let the storm pass so people can get back to their regular work. Because while the scale and reliability of Exchange Online servers now ensure the service isn't impacted by a Reply-All storm, your business might be – whether because your employees become overly distracted with it, or because the excess mail volumes generated kick in mail throttling specific to your organization. But with Reply-All Storm Protection, the chance of either of these happening in the future will be significantly reduced if not eliminated.

Modern Exchange Admin Center (EAC) Portal

When we introduced the Mail Flow Dashboard, Insights, and Reports a few years ago, there was a compelling argument to place the features inside of the Security and Compliance Center (SCC). A lot of the day-to-day concerns for mail flow management are about email security, fighting spam and viruses, checking for hacked accounts, etc. And we heard from plenty of customers, usually those more focused on security, that they appreciated having the Mail Flow Dashboard and new Message Trace in the SCC, where they spent a lot of their time. Yet, we also heard loud and clear from a lot of email admins that these features should really be in the Exchange Admin Center (EAC), not the SCC.

As you likely know (and saw earlier in the week), the EAC team has been engaged in a modernization of the EAC – to adopt a similar look and feel as the rest of the Office 365 admin centers, make it better organized and improve feature discoverability, and enhance its overall design and user experience. The Transport team decided that now was a good time to address the concerns we'd been hearing from email admins in this area, and we have decided to move all the Mail Flow assets into the new, Modern Exchange Admin Center (EAC) portal. It won't happen overnight, but over the course of the first half of 2020 you'll find more and more of the Mail Flow features (like the Dashboard with some insights and reports, and Message Trace) will appear in the Modern EAC as it moves through Preview and eventually into general availability later in 2020. To see a preview demo of this, check out our Microsoft Ignite 2019 session video here (starts about 25 minutes in).

Customizable Recipient Limits

As mentioned earlier, after the BedlamDL3 Reply-All storm incident in 1997, one of the features Exchange introduced was the Recipient Limits setting. This limits the number of recipients someone can send a message to. In the Office 365 multi-tenant service this is set to 500 for all mailboxes.

Over the last few years, hundreds of customers have opened support tickets asking us to change this limit for some or all of their mailboxes. On the User Voice site, it's also one of the most requested Transport related feature. While some want to increase the limit for a handful of mailboxes (to better support regularly occurring mailings, like end-of-the-month billing statements and such), the majority actually want to reduce the number, to, say, 50 or 20, as a way to better protect against potential spam-like abuse from rogue employees or hacked accounts.

We're excited to announce that we'll be opening this up to customers so they can customize this setting for all mailboxes in their organization! The setting can be found in EAC > Recipients > Mailboxes > Mailbox Features > Mail Flow, and once made available in the first part of 2020, admins will be able to customize the Recipient Limit from 1 to 1000 for individual mailboxes. Bulk editing of multiple mailboxes will become available in the Modern EAC later in 2020. And of course the option to edit this for individual mailboxes, bulk edit for multiple mailboxes, and to set the default for new mailboxes, will all be available via Remote PowerShell. Examples of each are shown below:

Update a single mailbox



Set-Mailbox -RecipientLimits 20



Update multiple mailboxes



(Get-Mailbox | where {$_.RecipientTypeDetails -ne "DiscoveryMailbox"}) | % {Set-Mailbox $_.Identity -RecipientLimits 10}



Update the default for new mailboxes created in the future (all plans)



Get-MailboxPlan | Set-MailboxPlan -RecipientLimits 50



While the Exchange Online Protection service already includes features to help detect abuse by a rogue employee or a hacked email account, making recipient limits customizable for the email admin is another way we're helping to make your organization's email safer.

Securing SMTP Auth Submissions

Something else we're doing to help secure your email in Exchange Online is a taking a multi-phased approach to better secure SMTP authenticated submission. SMTP authenticated submission is most commonly used by applications or devices (printers, scanners, etc.) to submit email into the Office 365 service. It only requires login credentials, and doesn't support modern authentication (e.g. Multi-factor Auth (MFA), certificate-based auth (CBA), etc., enabled in Exchange Online via ADAL and OAuth 2.0). So this leaves any account that's using SMTP authenticated submission more vulnerable to abuse and hacking than accounts that exclusively use the other protocols that do support modern authentication.

To help reduce the potential for exploiting the less secure SMTP authenticated submission protocol, last year we introduced the ability to disable SMTP authenticated submission for both your organization and for individual mailboxes via Remote PowerShell cmdlets:

Disable SMTP authenticated submission at the organization level



Set-TransportConfig -SmtpClientAuthenticationDisabled $true



Disable SMTP authenticated submission per mailbox



Set-CASMailbox <mailboxname> -SmtpClientAuthenticationDisabled $true



While the mailbox level setting has been exposed in the Admin Center UI for a few months now, we discussed this in more detail during our presentation at Microsoft Ignite 2019. Go listen to the recording to hear about the plan and schedule for how we're going to better secure this protocol (disable it) by default, first for new organizations onboarding onto Office 365, then later for tenants with no SMTP authenticated submission usage. We also expect in the future to deliver more tools, reports, and optics to help email admins gain better insight into SMTP authenticated submission usage in their organizations. This will help better plan for possible future disablement of the protocol for those accounts using it, plan for future upgrades to devices that support modern authentication, or more readily monitor any potential abuse or hacks of those accounts.

So we think both admins and end users will find something to like in our roster of enhancements that we announced at Microsoft Ignite! And we're not done yet! It really is a journey, and we plan on doing even more work in the future for both admins and end-users, building on the work we announced this year at Microsoft Ignite, as well as coming up with new enhancements – all of which we believe will continue to help make your organization safe, smart, and secure.

Kevin Shaughnessy

The Exchange Transport Team

Senior Member

Thanks for sharing! Anything you can share with us about Outlook supporting Send from SMTP Proxy Address? Having this in OWA is great, but honestly most of the users use Outlook... Thanks Christian

Occasional Contributor

Hi, this is good news. What about plus addressing and proxy address sender availability in on-prem solutions?

Regular Visitor

This is all great news but far too late, we've enabled Sieve sub-addressing through Mimecast. And the send as proxy address GSuite has had forever. We engineered a way around through Shared Mailboxes. But seeing this made me so happy and so sad that I spent half a year working around it. Will the send as proxy address feature work for calendar invites?

Occasional Contributor

This is some great stuff. We have been wanting the customizable recipient limits.

Senior Member

Excellent news!  Customers have been asking for these features for a long time!


  • Send from proxy address (alias)
  • Message Recall in Exchange Online
Regular Visitor

@Christian Schindler We have no ETA at the moment for Outlook, however today you are able to use the third-party plugin Proxy Manager to send from aliases. OWA is the first priority and after that we will turn our attention to Outlook.


@wkwi108Plus addressing for deliveries via Exchange Online (Protection) will work as we plan to process the emails before sending to on-premises which will allow seamless deliveries. For sending from aliases and the scenarios around that, we are focusing on cloud hosted mailboxes. At a later stage we will review the missing functionality for on-premises mailboxes.


@wesleykirklandmbAs this is a paradigm shift for the service, we will be working with many partner teams to unlock alias scenarios beyond basic mail flow. Our priority is to get out basic functionality as soon as possible and follow up with iterative improvements and additions. As such, I apologise that we cannot commit to supporting Calendar invites from the start.



Occasional Contributor

Where is the Ignite VIDEO ?


@The_Exchange_Team  These are great news and I can't wait to see these implemented, even if initially only in OWA. As @Christian Schindler said, most of our users are using the desktop client, for various reasons, and I hope, once tested, these features will ultimately be made available there, too, as they address a number of pain points we experience regularly in our environment.


Kevin is making several references to the Ignite session's video, which is not available at the provided links. Would you please either provide a working link or a transcript of the content that was presented? Thanks!

Occasional Contributor

Are any of these features going to apply to on-premise Exchange 2019 in a future CU? 

Senior Member

You say: Keep your email addresses free of "+" signs. I just have had a look at our Mailadresses and found our faxadressees are of Type "FAX" and +49xxxx". But probably you are talking only about smtp-adresses, is suppose?

Senior Member

When will 'new' OME work with shared mailbox recipients? This is incredibly frustrating for organisations. We've had to setup an OMEv1 transport rule which relies on users setting the confidential flag to trigger encryption and IT maintaining the recipient address list to trigger said rule, enabling the business to send to external shared mailboxes which then use the OTP to view content. It's a lot of technical debt. 


Viewing in OWA is a work around but some organisations block download of attachments in OWA to prevent data loss to unmanaged devices so it is not ideal at all. 


@Test-RRR Yes, this is for SMTP addresses.


@Mirza Dedic The plan is to get these features out in Exchange Online and then evaluate which feature to add to the next CU for Exchange Server.   

@Kreera House@Grzegorz Wierzbicki - the Ignite video was temporarily unavailable but you can now find it here Cheers!


@KevinShaughnessy  That's great news and I can't wait to watch it ... unfortunately, now it seems that the server hosting the videos is down ... I"m getting this for every single Ignite session video now where in the past I could view others .... :cry:



@KevinShaughnessy  The issue with the video website appears to be a browser-related issue: With Edge Chromium v. 80, the video displays the above error message. With Edge Chromium v. 79, it works fine. Apparently, the new security features in the latest version of Edge is blocking the video ... could you pass this info on?

@Kreera House, how frustrating! I've passed the info along to our Ignite video team. Hoping there's something they can do about it. Meanwhile, dare I say, try it with Chrome or Firefox. :) 

@Kreera House FWIW I tried it on this version of Edge and it's working fine: Version 80.0.345.0 (Official build) dev (64-bit)

Valued Contributor

Well if you wish to send as alias right now, google for "ChooseFrom for Exchange Online/Office 365" .

Occasional Contributor

@KevinShaughnessy @Sean_Stevenson , @The_Exchange_Team  if we are phasing out the ability to do SMTP Auth submissions, what is the guidance going forward on this? Do you recommend we spin up our own SMTP relay server (yuck) or use a 3rd party service like SendGrid?


We still have copiers, business applications, etc. that all need to send SMTP email. Please let us know which direction we should aim for.


@Carlos Capellan The work being done above is aimed at turning off SMTP Auth capabilities for mailboxes that do not need to use it. You can continue to use it for any clients or devices that need to use it. There is a separate effort to disable all basic auth across Office 365. That would have lead to the phasing out of SMTP Auth but an exception was granted because of the widespread usage and lack of a modern auth alternative for SMTP Auth.


There is no need to stop using it anytime soon. Eventually you may have to make the decision between an on-premises relay or a 3rd party service but that is still a few years away. If you were asking from a security point of view, I would suggest hosting your own Exchange Server on-premises that accepts SMTP Auth submissions only from your network and then block all submissions to Office 365.


Hope this clarifies the situation.   

Occasional Contributor

Hello Team, 

Do we have an update on Plus Addressing in Exchange Online - or a road map number that we can monitor? 




@TechAB The roadmap item for plus addressing is here: It should be available by Q4 CY2020. You can track updates on UserVoice here:

On a different note, @Sean_Stevenson , @The_Exchange_Team why do we get only 10 votes on user voice for O365 Admin? On other user voice sites, votes are not restricted.

Occasional Contributor

This is about the "Send from\Receive to SMTP Proxy Address (alias)" feature.  You should be embarrassed (okay just teasing - sorta).  I have been wanting to move our company from GSuite for a few years.  There's been so much progress in so many features, that I think I could convince them, even though change is hard and people will miss some subtle features.   But the single feature why we can't switch, and why we may soon need to to abandon hope and double down on GSuite is the poor\non-existent alias support in M365.  We're a company with multiple identities\domains and operate in the same tenant.  It's not uncommon for companies with multiple subsidiaries.  Every day I'm tweaking which domains a group or individual has and setting up the ability to send from multiple aliases.  I know that over the years, out of necessity those who never were in GSuite found tweaks, but there is no way we could function efficiently without domains\aliases being pretty much interchangeable for sending and receiving mail (and from any and all devices \ mail clients).  I was thrilled to see the announcement this was coming, 8 months ago, but please prioritize this.  I and others want to move our companies to M365 so badly.

@Charles Rube, agreed. :) Great feedback on how significant this feature is for your company and how if we had it now it'd make your case to move to O365 a lot easier. It's definitely a top priority across multiple teams to make this happen before year end (see the O365 Roadmap to track progress). Thanks so much for being a fan of O365 and sharing your story, Charles!


Occasional Contributor

Wondering if there's any news on aliases.  I see it on the roadmap, but it's been quiet.  I have a small window open again to introduce the possibility of an O365 switch, but it would be contingent on sending from aliases from previous and subsidiary company domains.

Thanks, Charlie


@Charles Rube  It's here! Not sure if it's been posted anywhere here in Tech Community, but it was posted on UserVoice:


It's been available in our tenant for a couple of weeks now.

@Charles Rube support for plus addresses is, as Kreera mentions, now available but the ability to send from proxy aliases (via OWA only at first) is still being worked on. The end of 2020 is still the target date for deployment. The O365 roadmap item is kept up to date so you can track progress there:

Valued Contributor

To whom who uses Plus addressing:

PlusAddressReply add-in for Microsoft Outlook.

 This utility will automatically populate the proper From: address when you reply to a message received as a dynamic alias and then convert it to Reply-To address.


FlexAliases Flow for Office 365

FreeWare.  FlexAliases flow moves the incoming plus addressed messages to subfolders under Inbox. The flow creates new subfolder for each new plus address (subaddress).


Version history
Last update:
‎Dec 12 2019 02:58 PM