Exchange Online aliases: evidence checks

Exchange Online aliases are additional email addresses configured on a mailbox in Microsoft's hosted business email service. A mailbox holds messages and has its own access arrangements. An alias gives that mailbox another address; it does not automatically create a separate mailbox, team work queue or approval process.

If your business uses different addresses for brands, teams or services, sending from an alias may be useful. Before changing the workflow, establish whether the intended sender address, routing and retained records still meet your requirements. A message reaching its recipient answers only part of that question.

Microsoft's Exchange team announced general availability of sending from email aliases on 7 October 2026, after a period of public preview. Its announcement, updated on 8 October, describes both client support and known gaps. This guide turns those limits into a change-acceptance decision for a business owner and the people responsible for email administration and records.

Establish the workflow and the scope of the change

Microsoft describes enablement at tenant level. A tenant is the organisation's Microsoft cloud environment. The announcement says the setting can take up to 60 minutes to take effect. It does not establish an enablement setting restricted to a chosen pilot user.

A test involving one user is therefore not the same as a change affecting only that user. Review the wider tenant impact before enabling the feature. A person's choice of sender address in an email client is not an administrative restriction on everyone else's use.

The announcement covers Exchange Online-hosted mailboxes and Outlook web, desktop and mobile experiences. Shared mailboxes have a narrower boundary: Microsoft says sending from their aliases works in Outlook on the web when the delegate uses "Open another mailbox". It is not supported for shared mailboxes in Outlook clients. Do not apply the general user-mailbox client list to a shared mailbox without reading that distinction.

Describe what staff actually need to do. A person answering under another address is a different requirement from colleagues jointly managing a queue of enquiries. An existing shared-mailbox workflow may remain appropriate for the latter, subject to its actual access and operating arrangements. An alias alone does not resolve assignment, absence cover or who approves a reply.

Separate routing, journaling and message trace

Routing determines where messages go and which handling rules apply. Some rules identify an address explicitly; others work with the identity of the mailbox. These approaches need different checks when one mailbox uses several addresses.

Journaling is a mechanism for capturing message records through configured rules and a journaling destination. If your organisation uses it, the question is whether the relevant messages enter the required records process. Do not assume that the name of a feature proves that every business record is captured or retained for the required purpose.

Message trace is an administrator's view of email transport activity. It helps investigate what happened to a message in the mail service. It is not, by itself, evidence that a complete message has been retained in an archive or other required records system.

Microsoft warns that rules targeting particular addresses may not match aliases. Its examples include hygiene, journaling and mail-flow rules. Other features use mailbox identity and cannot distinguish aliases. This is a reason to inspect the actual configuration, not proof that all alias messages bypass archives or that every policy fails.

The announcement also identifies a search limitation: a Message Trace query using only the primary SMTP address omits messages sent from an alias. SMTP addresses are the email addresses involved in sending and receiving mail. Include the relevant alias when investigating its traffic. An empty result from the wrong address search is not proof of failed delivery or lost retained content. Microsoft explains the rule and trace limitations in its announcement.

Work through one business change decision

Consider a fictional design practice that wants quotations to show a particular trading address. Its team currently handles quotation correspondence through an established shared mailbox. Staff use desktop Outlook and rely on an agreed records process for quotation correspondence.

All people, settings, test records and findings in this example are hypothetical. They are not client findings or evidence of a fault in your tenant.

The operations manager owns the quotation workflow. The records owner states the practice's requirement to retain the correspondence needed to explain a quotation decision. That is this fictional organisation's requirement, not a universal legal retention period. Its administrator assesses the mail configuration, while its email and archive suppliers explain the parts they operate. The director approves or rejects the proposed business change.

The initial proposal is to enable alias sending and let one member of staff try the new address. The administrator rejects that as a description of an isolated production pilot: the setting is tenant-wide. The director instead authorises preparation of a change assessment, with any technical validation confined to a separately authorised representative test environment. Production remains on the existing workflow while the evidence is incomplete.

The proposed assessment must establish which other mailboxes, address-based rules, clients and connected services could be affected. The practice cannot infer that a test of its quotations covers every other team in the tenant.

A trace correction does not close a records gap

The fictional evidence pack contains two fabricated cases for an Exchange Online user mailbox in the representative test environment. One uses its primary address; the other uses a configured alias. These records illustrate how the reviewer interprets evidence, rather than providing instructions to send test emails.

The administrator initially searches Message Trace using only the primary address. The alias case is absent. After correcting the search to include the alias, the administrator finds that case's trace entry. The initial finding becomes "incorrect search scope", not "message failed".

The records check remains separate. The primary-address case has a corresponding record in the test journaling destination. The team has not established a matching retained record for the alias case. The configured journal rule names a specific address, so the administrator and archive supplier must assess that rule's applicability and the complete capture path. The trace entry does not resolve this missing evidence or prove its cause.

The operations manager records the results as follows.

There are two fabricated message cases in this pack. Correcting the trace search accounts for both at the transport-evidence level; only the primary case has established journaling evidence. The reviewer does not convert two trace entries into two accepted retained records.

Choose an outcome the business can support

The director decides to retain the existing shared-mailbox process and withhold the proposed production alias change. That is the completed decision. The corrected trace procedure is useful, but the records gap, client mismatch and wider impact review prevent acceptance of the proposed change.

The administrator owns the configuration assessment. The archive supplier must explain what its service captured, what it did not and which evidence supports that explanation. If a change is proposed to the journal or routing arrangements, it needs a supported design and fresh acceptance evidence. This guide does not supply an unverified rule recipe.

The records owner will decide whether the resulting evidence meets the practice's stated requirement. The operations manager will reassess the staff workflow, including absence cover and client choice. The director will reconsider only when those owners have returned their findings and the tenant-wide change scope is understood. A revised sender address or a successful demonstration alone will not reopen approval.

Continuing the existing workflow does not certify it as compliant or promise that it never needs improvement. It avoids replacing it with a proposal whose important conditions remain unresolved. If a shared-mailbox change is still needed, define that task separately rather than treating aliases as a substitute for permission and workflow design.

Keep the acceptance record useful after the decision

Retain the requested business outcome, the mailbox and addresses in scope, the affected client paths and the references linking the evidence to each case. Record failed checks and their owners alongside the approved outcome. Keep real message content and configuration records in an appropriately restricted location; a general change summary can point to those records without reproducing confidential correspondence.

If the organisation later approves a change, its administrator must plan how it is introduced, observed and, if necessary, reversed. Agree who can stop the change and how records or outstanding investigations will be preserved. Reversing a setting is not evidence that every message created during the change has been reconciled.

Hybrid arrangements need their own assessment. Microsoft describes cases where on-premises or hybrid handling can rewrite aliases and affect automatic replies. Do not carry a result from a cloud-only test into a different environment without checking the actual path. The announcement also lists features under investigation. Treat those as open product questions, not promised delivery dates or a basis for accepting today's design.

For supplier evidence that does not answer your specific records question, the ICT supplier risk management guide explains how to record what a document supports and assign the unresolved decision. The useful result is an accountable next step, not a folder of unchecked assurances.

Discuss the evidence needed for your change

Bring the proposed email workflow, relevant supplier responsibilities and the acceptance question you cannot yet answer. Separate evidence of transport, rule behaviour and retained records. Name the business owner who can decide whether to proceed, keep the existing arrangement or request more work.

My IT compliance consulting can help identify control gaps, organise evidence and agree responsibilities and a prioritised remediation plan. Discuss your email change evidence with that scope. Technical email administration and any independent assessment need their own agreed responsibilities; the discussion does not guarantee certification or a particular audit outcome.