A reply from New Outlook’s All Accounts view shows the wrong From address.
Fastest fix: All Accounts view gathers messages from connected accounts; it does not merge those accounts. Check which account received the original message, then confirm the From address in the reply window. If you want to send from another address, first verify that it belongs to a connected account or is authorized for sending, then test it with a low-risk message.
This guide is for people using multiple mailboxes in New Outlook for Windows and replying from All Accounts view.
It’s especially useful for freelancers and project-based workers who need replies to come from the right business identity.
Long-term alias users will also find a clear distinction between a receiving alias, a forwarding destination, and a permitted sending address.
Last updated November 1, 2026. Microsoft’s rollout status and account guidance were checked against the Microsoft 365 Roadmap entry for All Accounts view, Microsoft’s supported account types documentation, and its instructions for changing the account used to send a message. The feature rollout and reply behavior can vary by account and interface, so check the current view in your own Outlook.
All Accounts view does not make your accounts one mailbox
All Accounts view is a combined place to view and work with messages from connected accounts. It doesn’t turn separate mailboxes into one account, change which address received a message, or grant permission to send from every address visible in the app. Microsoft’s roadmap describes the view as a way to access messages across accounts, not as an account-merging feature. Its entry lists a planned rollout completion by late November 2026; that is a rollout plan, not a guarantee that every account or installation will show the view on the same day. Check the roadmap entry for its current status.
That distinction matters when you reply. The message may appear in a combined list, but it still belongs to the account that received it. Outlook’s general multi-account guidance says replies usually use the account that received the original message. Treat that as the expected behavior, not as a substitute for checking the actual From field. Microsoft’s sender-account instructions explain how to select an available account when composing a message.
| What you see | What it tells you | What to verify before sending |
|---|---|---|
| A message in All Accounts view | The message is visible in the combined view | Which connected account actually received it |
| A reply opened from that message | Outlook has prepared a response | The address shown in From |
| A desired address in the From menu | Outlook offers that address in this compose window | Whether it is authorized and appropriate for this conversation |
| A message forwarded into another mailbox | A copy or redirected message reached that destination | Which account will send the reply, and whether the recipient will recognize it |
If a particular account or control is missing, don’t assume the feature is broken or that the mailbox has been merged. Microsoft’s supported account types reference is a useful check because support depends on the Outlook product and account type. The interface you see may also depend on rollout availability.
Why can the reply use the wrong account?
An unexpected sender identity usually comes from one of a few different points in the message path. Identify which one applies before changing settings. Otherwise, you might fix the wrong layer.
The original message belongs to a different connected account
In All Accounts view, nearby messages can come from different accounts. A conversation list may make them look like part of one working inbox, but the original message still has a specific receiving account.
Open the message details or account folder and confirm which mailbox received it. Then open the reply and inspect From. If the wrong account is selected, use a sending account that is both available in the compose window and appropriate for that message. Microsoft explains the account-selection control in its guide to changing the account used to send email.
A reply usually selecting the original receiving account is convenient, but it is not proof that the correct identity will be used in every case. Account configuration, the message you chose, and what the current compose window permits can affect the result. The From field is the final check before sending.
The From field contains an address you didn’t expect
A reply window may show a different sender from the one you assumed was active. Don’t rely on the mailbox name in the navigation pane, the conversation label, or the address used to sign in. Inspect the actual From value in the draft.
If the From field is hidden, look for the option to show it in the compose window. Then check the full address, not just the display name. Display names can be identical across accounts, while the actual sender address is what the recipient sees in message details.
When Outlook offers more than one address, select the intended one only after confirming it is permitted for sending. If it is not listed, don’t type it into a field and assume that this grants permission. Verify the account configuration or ask the relevant administrator to confirm whether the address is enabled for sending.
The expected alias is missing from From
A mailbox alias, a forwarding address, and a sending identity solve different problems:
- A receiving alias is another address associated with a mailbox. It can help route incoming mail, but receiving a message at that address does not by itself prove that Outlook can send from it.
- A forwarding address sends or redirects incoming messages to a destination mailbox. It describes where mail goes, not which address will appear as the sender of a reply.
- A permitted sending address is an address that the account and mail system allow you to use in the From field.
This is why an alias can receive a message while still being absent from the sender list. Check the settings for the mailbox that owns the address and confirm whether it is configured and authorized for sending. In a managed work account, the administrator may control that permission.
For the same reason, don’t assume a temporary receiving address is suitable as a customer-facing reply identity. A disposable address may be useful for a one-off registration, but client conversations need an address that remains accessible and can reliably send as the business identity. The guide to disposable email versus aliases explains how to choose based on whether you need short-term receiving or an ongoing address relationship.
Check the complete identity, not only the label. A message arriving at an alias confirms a receiving path. It does not confirm that replies can be sent from that alias or that recipients will see it as the From address.
Forwarding changes the destination, not the reply identity
A forwarded message can appear in a mailbox that did not receive it originally. That may create a mismatch between where you read the message and which account you use to reply.
Separate the path into two questions: where did the message first arrive, and which account is about to send the reply? A forwarding rule answers the first question by directing incoming mail to a destination. It does not automatically authorize that destination account to send as the original address. Microsoft’s documentation on turning automatic forwarding on or off covers forwarding configuration; don’t treat that feature as proof of send-as permission.
If a client expects replies from a stable business address, return to the mailbox that owns or is authorized to send from that address. Confirm the From field there. Avoid relying on a forwarding chain to preserve the original sender identity: the forwarded copy and the reply are separate messages with separate sending accounts.
How to confirm the Outlook reply address safely
Use this workflow before replying to a customer, client, or project thread. It separates message ownership from sender permissions and avoids testing with sensitive content.
- [ ] Open the exact message, not just the conversation preview. Check the sender, recipient details, and mailbox or folder associated with the original message.
- [ ] Confirm the receiving account. In All Accounts view, identify the connected account that received the message. If the account is unclear, open its mailbox directly and locate the message there.
- [ ] Open a reply draft and reveal From. Inspect the full address shown in the compose window. Do not infer it from the account name, profile image, or combined inbox.
- [ ] Compare the From address with the intended identity. For customer mail, use the established business address. For personal mail, use the account the recipient expects. If the address is missing, verify account settings or administrator permissions rather than assuming that an alias can send.
- [ ] Send a harmless test from the intended account. Use a mailbox you control, with no confidential information. Reply from All Accounts view and check the received message’s From address and reply context.
- [ ] If the test is wrong, stop and correct the sending path. Open the original receiving account directly or select an authorized sender address. Then repeat the test before replying to the real conversation.
- [ ] Record the reliable route for recurring work. Note which account handles that client or project and which address should appear in From. This prevents a successful one-off workaround from becoming an unreliable habit.
The test should verify the full path, not merely whether the message appears in Sent. Check the received copy in the destination mailbox and inspect its sender details. Confirm that the conversation remains understandable and that a reply from the test mailbox returns to the expected account. If the message does not arrive, check filtering and delivery separately; a sending identity problem and a delivery problem are not the same issue.
For verification emails, also separate sender selection from delivery delay. A code that arrives late does not necessarily mean Outlook replied from the wrong account, and a correct From address does not guarantee that an incoming verification message will arrive promptly. If the test involves a registration code, use the verification email delay troubleshooting guide to check delivery separately from the reply identity.
For a troubleshooting record, keep the useful facts rather than screenshots full of private content: the account that received the original, the From address selected, whether the test arrived, and whether the returned reply reached the expected mailbox. That gives an administrator or support contact enough context to investigate without exposing client messages.
Keep the workflow reliable across accounts
A combined view can save time, but it also makes the account boundary less visible. A small habit helps: before sending a reply that matters, check the original receiving account and the From field. For routine newsletters or low-stakes messages, the risk is lower; for client agreements, invoices, project decisions, and ongoing support, a mistaken sender can confuse the recipient or expose an unrelated personal address.
If a reply needs to come from a specific identity every time, use a mailbox configured for that identity rather than relying on a receive-only alias or a forwarding destination. Confirm that the sender address is available in Outlook and permitted by the mail system. Where an administrator manages the account, ask them to verify the send-as configuration instead of repeatedly trying unapproved addresses.
Do not use a short-lived address as the permanent contact point for work that needs follow-up. A client may need to reach the same address later, and the account may need to support replies, records, and recovery. For a limited registration or a one-time verification message, a temporary inbox can be a better fit than exposing a primary mailbox; for long-running client correspondence, keep using a durable, verified business identity. ZipFwd can be considered for temporary receiving when its current service page confirms that it fits the task. Check its actual address and delivery behavior before using it, and don’t treat receiving capability as permission to send replies from that address.