A colleague can read the finance mailbox but cannot send from it

A new finance colleague may be able to open a shared mailbox, read supplier messages and organize folders, yet receive an error when trying to send from that address. In Exchange Online, that behavior can be consistent with the assigned permissions. Reading the mailbox and sending as its identity are separate capabilities that need separate approval.

Microsoft describes Full Access as allowing a delegate to open the mailbox and manage its contents. It does not grant permission to send from it. Send As and Send on Behalf provide different sending behavior. Start by identifying the intended task and existing delegation before treating the error as a broken email client.

Also establish whether sending should be permitted. An analyst who assembles remittance evidence may need to read the mailbox without communicating payment instructions. A collections specialist may need to send approved reminders but lack authority to negotiate a settlement. The technical correction should follow a defined business role rather than expand it by accident.

Send As makes the message appear to come directly from the mailbox or group, without identifying the delegate in the From presentation described by Microsoft. Send on Behalf identifies the delegate acting on behalf of the mailbox or group. For that latter permission, Microsoft's documentation says replies go to the mailbox or group rather than the delegate.

Decide which presentation serves the finance process. A general receivables address may be intended to represent a continuing team. Another workflow may need the recipient to see the named colleague acting for that team. Neither choice independently establishes who approved the content. Record the intended presentation and the separate internal approval evidence required for sensitive communications.

Review combinations rather than assuming the most recent grant determines the result. Microsoft states that if a user has both Send As and Send on Behalf, Send As is used. An administrator should therefore inspect the full effective arrangement. Adding a second permission without understanding the first can produce a different external identity than the business requested.

Provide the shared mailbox, the colleague's company identity, required activity and approved sender behavior through the authorized access process. Include the business owner and any end date for temporary coverage. Avoid a vague request to make the person an administrator or give them everything another employee has. The intended capability can usually be described much more narrowly.

Ask the administrator to check existing grants and the method through which they apply, including relevant group-based arrangements. Do not copy another user's access blindly because both work in finance. One may manage the mailbox while another only handles a defined category of correspondence. The access decision should reflect the actual work assigned today.

Record whether the person needs access to existing content as well as permission to send. Those needs often occur together but are not identical. A request to send a particular notification should not silently become permission to inspect every historical tax, payroll or supplier message stored in the mailbox. Where the required restriction needs a different workflow, have the systems owner design it explicitly.

After an authorized change, use an internal test recipient and a clearly labeled test message. Verify the selected From identity before sending, then inspect the received presentation and reply route. Do not use a customer, live payment request or confidential attachment merely to establish that delegated sending now works.

Confirm where the process retains its sent-message evidence under the configured client and mailbox behavior. The team should know how to find a communication later without relying on the sender's personal recollection. Ask the administrator to establish the supported configuration rather than assuming that every client stores the copy in the same place.

If the test still fails, preserve the error wording, time, client and selected sender identity for the administrator. Keep actual confidential message bodies out of a general troubleshooting ticket. Permission propagation, address-list visibility or client configuration may require investigation; repeatedly granting broader rights is not a diagnosis. Use the product's current guidance for the observed arrangement.

A mailbox permission authorizes a software action. It does not, by itself, authorize the employee to change bank details, forgive a receivable or agree revised commercial terms. Put those decisions in the relevant finance procedure, with the evidence and approver required before a message is issued. The recipient sees a communication, not the internal control that should precede it.

Define what the delegate may answer independently. For a fictional collections role, sending an already approved invoice copy and confirming receipt of a dispute may be routine. Offering a discount or accepting a payment plan may require another owner. Describe the boundary using actual message categories so staff can recognize when they need a decision.

Use the shared mailbox to preserve continuity without sharing a personal account password. Microsoft's shared-mailbox guidance describes delegation through the user's own identity and says new shared mailboxes have sign-in blocked by default. Have the administrator manage the supported access arrangement. A sending problem should not lead the team to distribute a reusable mailbox credential.

Include the delegated permissions in the handback for leave coverage, contractor work or a role change. Reading access and both forms of sending permission should be reviewed explicitly. Removing only a mailbox shortcut from the user's email client is not the same as removing the underlying grant administered by the service.

Have an authorized administrator confirm the final access state and keep the change record with the business owner's instruction. Preserve the necessary correspondence under the company's retention process. The completed handoff should leave the team able to identify who can read the mailbox, who can speak through it and which finance decisions still require separate approval.