My automated emails come from me instead of the shared mailbox
A Microsoft 365 power user needs automated Power Automate emails to come from a shared mailbox such as support, HR, finance, invoices, or no-reply. The visible problem appears when the email comes from the maker's personal account, fails with a Send As permission error, lands in the wrong Sent Items folder, or leaves colleagues unable to verify what the shared mailbox sent. The root issue is the interaction between the Outlook action selected, the connection account, Exchange Send As or Send on Behalf permissions, and sent-items configuration.
Reviewed by Helen JonesContext
The blocker, in a nutshell
If this blocker is unfamiliar, start here.
Power Automate can send email through the Office 365 Outlook connector, but the visible sender is not only a field in the flow designer. It depends on the action used, the account behind the Outlook connection, and Exchange permissions on the mailbox or group. Shared mailbox automations become confusing because 'send as', 'send on behalf', 'full access', and 'where the sent copy is stored' are separate choices.
Key Terms
Industry jargon explained
Click any term to see its definition.
The Reality
A day in their life
Operations coordinator, HR admin, finance coordinator, project manager, or Microsoft 365 power user responsible for department email automations
I start the morning in the HR shared mailbox, clearing the same kind of request for the tenth time this week. I already have the SharePoint list and message wording ready, so I build a small Power Automate flow to send the reply automatically. The first test lands, and for a second it feels like a proper win.
Then I notice the From line. It is my name, not the HR mailbox. I try typing the shared mailbox into the sender field, but the next run either fails or sends in a way the rest of the team cannot see in the shared mailbox. Manual Outlook messages from the mailbox do not behave like my flow, which makes the whole thing feel unfairly slippery.
By lunchtime, I am switching between Power Automate, Outlook on the web, and messages to IT. I can explain the business need, but I am not sure whether I should ask for Send As, Send on behalf, Full Access, or a different Power Automate action. I also do not want to give the flow account access to read every mailbox message if all it needs to do is send.
The painful part is not writing the email. It is proving that the automated message will look official, send from the right place, route replies correctly, and leave a shared record the team can find. What I want is a small sender test and a precise admin request before this goes anywhere near real staff or customers.
The People
Who experiences this blocker
Operations coordinator, HR admin, finance coordinator, project manager, or Microsoft 365 power user responsible for department email automations
28-55 • Beginner to intermediate Power Automate maker with strong process knowledge but limited Exchange admin access
Skills
Builds simple cloud flows
Uses Outlook, SharePoint, Teams, Forms, and Excel
Can test a flow and inspect run history
Can ask IT/admin for a permission change when the request is specific
Frustrations
- The flow works but the email looks like it came from the maker personally
- The From field sounds simple until Exchange permissions block it
- Manual Outlook emails from the shared mailbox behave differently from the flow
Goals
- Send automated replies and notifications from the correct shared mailbox
- Avoid personal-name sender confusion in official department emails
- Prove where replies and sent messages will land
Microsoft 365 or Exchange administrator
Receives the permission request and must decide whether to grant Send As, Send on behalf, Full Access, sent-items copy settings, or recommend a different mailbox pattern.
Also affected by this blocker. Often shares the same frustrations or creates additional pressure.
Top Objections
- I am not an Exchange admin
- I thought adding the shared mailbox in From was enough
- I do not want the flow account to read the whole mailbox
- I need replies to go to the department, not to me
- I need a test I can show before using this with real customers or staff
How They Talk
Use These Words
shared mailboxSend an email (V2)From (Send as)Send an email from a shared mailbox (V2)Send Assend on behalfSent Itemsflow connectionOffice 365 Outlook connectorservice account
Avoid
OAuth delegation modelGraph mail.send permissionsapplication permissionstenant-wide DLPmanaged identity
Learning Pathway
Shared Mailbox Sender Trust
Send department emails from Power Automate with the right sender identity, reply path, and sent-item proof.
Showing 1 of 1 recommendation
Briefing
Briefing Built
◆◆◆◆◇Good Fit
Choose Send As, Shared Mailbox V2, or Mailbox Auto-Reply
You'll build: A one-page sender-pattern decision record with chosen action, required permission, risks, and test checks.
Sender pattern decisionMailbox permissionsReply path+2 more
Root Cause
Finding where this blocker actually starts
We traced backward through five layers of "why" until we hit the source. Here's what's really driving this.
1
Why do the automated emails come from me?
Because the email action sends through the Outlook connection account unless the flow uses a supported shared mailbox pattern and the connection account has the right Exchange permission.
2
Why does adding the shared mailbox address not always fix it?
The From field is not just text. Exchange must allow the connection account to Send As or Send on behalf of the mailbox, and some actions store sent items differently.
3
Why is the right action hard to choose?
Send an email (V2) with From (Send as), Send an email from a shared mailbox (V2), mailbox-level automatic replies, and a service account can all look plausible, but they have different permission, privacy, reply, and Sent Items consequences.
4
Why do non-admin makers get stuck?
The maker can build and test flow logic, but Send As, Send on behalf, Full Access, and sent-items copy settings live in Exchange admin controls they may not own.
5
Why does this keep appearing in teams?
Department email workflows start as quick automations, then become official communication. Sender identity, reply routing, and shared audit trail are often tested after the first embarrassing or confusing email, not before launch.
Root Cause
The root cause is a sender-context mismatch: Power Automate sends through a connection account, while the business expects a department shared mailbox identity. The fix depends on action choice, Exchange delegate permissions, and sent-items settings, not only on changing the visible From field.
The Numbers
How this stacks up
Editorial assessments based on the available evidence. Scores do not establish demand, purchases or measured financial impact.
76
8
9
6
7
"Can I use my email address and personal login..."
User asks whether a personal login with shared mailbox access can create a Power Automate flow and send a shared-mailbox auto-reply. — Microsoft Q&A, 2026-05-07
More Evidence
What others are saying
"Flow trigger but it unable to send notification email from user email id"
User reports a flow that triggers from Power Apps/SharePoint but fails to send from the expected sender identity. — Power Platform Community, 2026-04-21
"Other staff... cannot see the email in Inbox"
User reports shared mailbox emails sent by Power Automate are visible to the owner/admin but not to other delegates as expected. — Power Platform Community, 2026-05-15
"send official email notifications from a departmental shared mailbox"
Practitioner describes a least-privilege production requirement for shared mailbox sending without granting Full Access. — Power Platform Community Blog, 2026-01-12
The Landscape
What solutions exist today?
Current market solutions and where there are opportunities.
S
Send an email (V2) with From (Send as)
Approach: Use the common Outlook email action and set the advanced sender field to another mailbox or address.
Pricing: Included with the relevant Microsoft 365/Power Automate entitlement
Weakness: Requires the connection account to have the right Exchange permission, and sent items may still be associated with the sender/connection account depending on configuration.
S
Send an email from a shared mailbox (V2)
Approach: Use the dedicated shared mailbox action and specify the shared mailbox address.
Pricing: Included with the relevant Microsoft 365/Power Automate entitlement
Weakness: Still requires permission to the shared mailbox and can be confused with the normal email action; some requirements may need different patterns if mailbox access must stay least-privilege.
E
Exchange mailbox delegation and sent-items settings
Approach: Grant Send As, Send on behalf, or Full Access and configure sent-items copy settings where needed.
Pricing: Admin configuration inside Exchange Online
Weakness: Often outside the maker's permissions; the maker needs to ask for the exact permission and prove the business reason.
M
Mailbox-level automatic replies or rules
Approach: Configure the shared mailbox itself for simple replies instead of sending from a flow.
Pricing: Microsoft 365 mailbox capability
Weakness: Useful for broad auto-replies, but not enough when the message depends on Power Automate conditions, dynamic content, approvals, or SharePoint data.
The Gap
Why existing solutions keep failing
The pattern they all miss — and how to beat it.
Common Failure Mode
Most guidance explains either the Power Automate action or the Exchange permission. The gap is a practical maker-owned test and admin-request workflow that connects action choice, connection identity, sender display, reply routing, mailbox privacy, and Sent Items proof in one small package.
How to Beat Them
Win by turning the email action into a sender-pattern decision: choose the right action, map the connection account, request the exact Exchange permission, configure sent-items behavior when needed, and run a test that proves sender, reply, and evidence trail before launch.
The Fix
What a solution needs to succeed
The non-negotiables and nice-to-haves for any product or service tackling this blocker.
The 3 Wishes
A maker can prove an automated email comes from the right shared mailbox, replies go where expected, and the team can find the sent record before the flow reaches real recipients.
Must Have
Plain-English decision between Send an email (V2) with From (Send as), Send email from shared mailbox (V2), mailbox automatic reply, and leaving the sender as the connection account
Connection-account check
Exchange permission checklist for Send As, Send on behalf, Full Access, and sent-items copy settings
Least-privilege warning for mailbox read access
Safe internal test that verifies From display, reply path, and Sent Items location
Admin request template with mailbox, connection account, permission needed, and business reason
Nice to Have
Screenshots of both Power Automate email actions
Example of a failed Send As permission error
Template for an evidence screenshot pack
Short note on service account tradeoffs
Out of Scope
Graph API mail sending
Tenant-wide shared mailbox policy
Long-term flow ownership and handover
Premium connector licensing strategy
Changing Exchange settings without admin approval
Success Metrics
Chosen sender pattern documented: selected pattern versus rejected alternatives
Test email sender proof: expected sender display captured
Reply path proof: replies route to the intended mailbox or documented alternative
Sent Items proof: message appears in expected location or admin setting needed is named
Admin request quality: request names exact permission or setting required
Solution Strategy
Which approach fits you?
A briefing can explain the difference between Send As, Send on behalf, shared mailbox V2, and mailbox automatic replies, but it will not prove the learner's flow. A build spec or SaaS is not earned because the problem is a configuration and testing workflow, not a new software product. A done-for-you service could fix one tenant, but the repeatable member asset is a guided course with a short decision aid.
What we recommend
Create one atomic technical workflow course as the main solution, supported by an optional briefing-style decision guide. The course should produce a tested sender pack and an admin request, not promise tenant-wide governance changes.
The Future
What might make this blocker obsolete
Technologies and trends that could disrupt this space. Factor these into your timing.
medium probability
0-12 months
Connector UI labels change again
Designer changes could make screenshots stale and move where sender settings appear. The underlying need to choose a sender pattern and prove mailbox behavior should remain. Course materials should be checked before publication.
SaaS: Low risk
Course: Low risk
Consulting: Opportunity
Content: Opportunity
medium probability
6-18 months
Admins standardize service accounts or shared mailbox request forms
Standard request forms could reduce ad hoc confusion. They would also increase the value of clear maker-side evidence: mailbox, connection account, desired sender display, and sent-items expectation.
SaaS: Medium risk
Course: Opportunity
Consulting: Opportunity
Content: Opportunity
medium probability
12-24 months
AI-assisted flow building suggests sender patterns
Copilot may reduce setup friction by suggesting the right action. The maker will still need tenant-specific permissions, least-privilege decisions, and a real proof test before official messages go out.
SaaS: Low risk
Course: Low risk
Consulting: Opportunity
Content: Opportunity
For Creators
Content Ideas
Marketing hooks, SEO keywords, and buying triggers to help you create content around this blocker.
Buying Triggers
Events that make people search for solutions
- A customer or employee replies to the maker instead of the shared mailbox
- A manager asks why official department automation is coming from one person's name
- The flow fails with a Send As or unauthorized permission error
- The team cannot find automated sent messages in the shared mailbox
- IT asks the maker to clarify whether they need Send As, Send on behalf, Full Access, or sent-items copy settings
Content Angles
Attention-grabbing hooks for your content
- Why Power Automate emails still come from your account
- The shared mailbox sender test before you send official emails
- Send As, Send on behalf, or shared mailbox V2 in plain English
- The From field is not just a field
- How to ask IT for the right shared mailbox permission
Search Keywords
What people type when looking for solutions
Power Automate email comes from me instead of shared mailboxPower Automate Send an email V2 From Send As shared mailboxPower Automate shared mailbox Sent Items not visiblePower Automate Send As permission shared mailboxSend email from shared mailbox V2 Power AutomateExchange MessageCopyForSentAsEnabled Power Automate
The Evidence
Where this came from
Every claim in this report is backed by public sources. Verify anything.
1.2.3.4.5.
Power Automate Flow for shared mailbox - Microsoft Q&A
learn.microsoft.com
My flow failed for sending an email using Send an email V2
community.powerplatform.com
Flow Reminder - Send an email
community.powerplatform.com
Send Emails from a Shared Mailbox in Power Automate (Without Full Access)
community.powerplatform.com
Create flows for popular email scenarios in Power Automate
learn.microsoft.com
9 sources referenced
Source note
Blocker published by Collab365 Spaces, reviewed by Helen Jones on . Cite as "My automated emails come from me instead of the shared mailbox", Collab365 Spaces. 9 sources referenced.
Have a question or correction?
No comments yet