Sending from email aliases is generally available in Exchange Online — one tenant setting, and every proxy address on a mailbox can put mail on the wire. The part the announcement does not cover is what that does to your sending domains.
In October 2026, the Exchange team announced general availability for sending from email aliases in Exchange Online. A user can now send from any alias or proxy address associated with their mailbox rather than only the primary SMTP address, replies automatically come from the alias the message was addressed to, and supported clients let the user choose which aliases to display. It is switched on tenant-wide with one command, Set-OrganizationConfig -SendFromAliasEnabled $True, or through the Exchange admin center under Settings, Mail Flow, and Microsoft notes the change can take up to an hour to take effect.
The feature was heavily requested, and the reason is easy to sympathise with. For years the workaround economy around Exchange was built out of shared mailboxes and distribution groups standing in for identities that could not send. It is also why the announcement reads, from a deliverability seat, less like a convenience and more like an inventory change.
Everything that decides whether your mail is wanted is counted per sending domain: SPF, DKIM, DMARC alignment, complaint rate, bounce behaviour, and the reputation a mailbox provider attaches to that name. An alias is usually not on the primary domain. It can be a legacy domain kept alive after a rebrand, a regional variant, a different subdomain, or a domain acquired to protect a trademark.
Enabling alias sending does not create new domains. It lets mail leave from domains that have so far only received, and every one of those becomes a sending identity the moment somebody picks it in the From field. Each identity needs authentication that aligns with the name it claims to be, and each one turns up in your DMARC aggregate reports the day it starts sending. Most programs have an incomplete list of their own sending domains, and this is a feature designed to add to it.
SendingFromDomainDisabled and SendingToDomainDisabled parameters of the Set-AcceptedDomain cmdlet. That is a blunt instrument, and a useful one: a domain that should never send can be closed before it does.mail.contoso.onmicrosoft.com address, which is what an out-of-office reply can then come from.Read that list with your own architecture in mind and a pattern shows up: the plumbing you rely on to see what you sent assumed one address per mailbox. Alias sending breaks that assumption at the thin end, where the observability lives, rather than at the thick end where the sending happens. A misalignment you cannot see is worse than one you can.
The first mail to use an alias is almost never a campaign. It is a receipt, a password reset, a shipping notice, or a support identity somebody created because the primary address felt wrong for it. Triggered mail is the mail with the least instrumentation and the highest tolerance for being wrong about authentication — right up until a receiving provider starts refusing or throttling it, and the password resets stop arriving.
That is the asymmetry worth naming. A misaligned sending domain in a marketing stream costs placement. The same misalignment in a transactional stream costs a support queue, and it costs it during the week you least want to explain why.
List every accepted domain that would become able to send. For each one, answer four questions: does it have an SPF record authorising your senders, does it sign with DKIM using a domain aligned with the From address, what does its DMARC policy say, and who is allowed to use it for anything bulk. Close the domains that should never send. Write the answers down once — a two-line record that most programmes do not have today, and the only version of this rollout that is not an experiment on your own deliverability.
Written by the team at LMR — a senior lifecycle marketing studio working in Iterable, Braze, Klaviyo and the tools you already run.
Start a project ↗