Support for Dynamic '+' Email Aliases in Office 365
I am familiar with using a plus sign following my email alias to create dynamic unique addresses for a Gmail account. e.g. firstname.lastname@example.org will arrive at my Gmail mailbox, where I can then apply rules based on the 'To:' address. See this page for details: https://support.google.com/mail/answer/22370
I tested this on my Office 365 address and it works, but only for email addresses in my parent domain. Using the aliases on subdomain addresses results in a 'recipient not found' NDR.
Does anyone out there have more information on this feature or if it even is one for 365 / Exchange?
We announced at Ignite that we are actively working on bringing dynamic plus aliases to Office 365.
To get around existing usage, the plan is for an opt-in setting. Our ETA is to have this available for all customers by the third quarter of 2020.
I will keep you updated in Uservoice on our progress.
The announcement at Ignite has an associated EHLO blog post here that you can reference: https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Exchange-Transport-News-from-Microsoft-Ignite-2019/ba-p/993417
Sean S., is there something published that documents that this feature is coming to O365? We are running into an issue with a web software product we use having mixed support for + in e-mail addresses and I pointed out to them that this is coming to Office 365, and they are saying that it isn't an IEEE standard for e-mail so they don't need to support it. Certainly, the potential in 2020 that everyone using O365 will be able to use dynamic aliases will drastically increase the number of users who might enter their e-mail address with a + so I'd like to share whatever is available from Microsoft on this coming feature.
Jason Pearce commented
The "fun" thing about + addresses and . addresses is attempting to unsubscribe from mass-email services like ExactTarget, Constant Contact, Salesforce, etc.
You cannot just ask them to unsubscribe email@example.com. They must also unsubscribe nearly an unlimited number of + and . email aliases too. E.g.:
Those mass-email companies should support wildcard requests for their global blocklists. Something like:
Leandro Teixeira commented
The thinking must be the hard part....
This is a no-brainer, and as Alex points out, below (Sept 24 2019 0911), there's a load of alternatives to the plus sign. :-)
Luke Stevenson commented
Surely you could simply have a flag on an Account which sets whether the plus can be used as a break between the user portion of an email and an optional flag portion.
It's not as though you are making this change for hotmail, where "user+flag" may be an old username.
I would suggest any domain that has a + will have the feature disabled and require an admin to go enable it and reconcile any emails or aliases that exist with the + present.
Might I suggest:
- Make it a feature that can be toggled on/off
- Default it to on for new tenants
- Give an error when trying to enable on existing tenants that contain objects that have email addresses that contain the + character
- Error login in Azure AD Connect when syncing objects from AD on-premises that contain the + character
I would also like to have this to sort mails in receipts using a forward triggered by having a invoice+ in front of my usual mailaddress.
quite easy, add this in the normal rules, do we have a matching local part, no, ok, cut on + do we have a matching now? Oh goodie!
Another issue is to get outlook to show the address an email was addressed to, _not_ which mailbox recived it.
Keep in mind, O Implementers, that it doesn't have to be a plus. Several other email system support the concept other than Gmail, but in some cases just use a different character for the functionality. From the RFCs there are some good options:
RFC 2822 defines these characters as special: "()<>:;@\,." and the double quote, making them useless for the "+suffix" idea.
However, the RFC also defines a mailbox as having a phrase part for the local box built out of words, built out of atoms, which in section 3.2.4 are built from atexts which allow a fairly wide set of characters include the semantically suggestive "+", "/" and "=", and 3.2.5 suggests that quoting might not be required for mailboxes containing such characters.
"+" would be ideal, but if "+" is an issue, what about "/" or "=" ? <joe.smith/forspam123> or <amy.forster=junkbox345> both seem pretty obvious. See the RFC for more options.
Old email servers shouldn't have issues, since RFC 822 defines an atom as:
"*<any CHAR except specials, SPACE and CTLs>", and those three chars aren't in RFC 822 3.3: specials.
The fact that outlook does not support something that has been available with most e-mail systems for at least 15+ years is rather depressing. I hope my organization is paying lots less for the downgrade in service we got by switching to Office365....
Kirk Gleason commented
I would use all 10 votes on this, if I could.
Please for the love of god and all that is holy add this feature ASAP.. Lagging so far behind other providers and trying to re-invent the wheel with O365 is going to cause you to lose even more of the market...
This is a requirement - please add.
Billy Purdue commented
Seems silly Outlook.com has had this for half a decade and Office 365 doesn't have it in Exchange yet.
Seconding Brian's comment - This is a must have for us to support software development, testing, employee alpha and beta testing, and general good security practices. I would love to understand why it has not yet been prioritized and what may be blocking it.
This request is climbing the ladder. To help the MS folks understand this, here are some references for the functionality:
- Wikipedia SMTP Subaddressing: https://en.wikipedia.org/wiki/Email_address#Subaddressing
- RFC 5233: https://tools.ietf.org/html/rfc5233