A contractor may need to send a project update from your team address without reading earlier customer conversations. In TrekMail, Send as can be granted without Read on a shared mailbox. Name the colleague who receives replies and the date when you will remove access. Treat this as permission to represent your business, even though the contractor can't open the shared inbox.
For example, a contract engineer sends updates from service@example.com while a dispatcher handles incoming replies.
Define the assignment before choosing the address
Write down what the contractor is expected to send, which shared address they may use, and who will handle the response. For the engineer in this example, the job might be a short progress report for a named service order. The dispatcher remains responsible for customer questions and delivery failures. That division is a working agreement between people, not a restriction that limits a new message to one order or one recipient.
Choose the shared mailbox's main address for this plan. Do not build the instructions around one of its aliases and assume the same send-only permission applies. The distinction matters before the contractor prints an address on a report template or gives it to a customer. If another address is required, discuss the actual supported setup before promising the workflow.
Also decide when the assignment ends. A calendar reminder for the person who manages membership can help your company remember the review, but adding a member does not by itself create an expiry date. Name the person who will remove access and confirm that someone else can still read replies. “Temporary” needs an action at the end, not just a label in your notes.
Treat the contractor's personal mailbox as a real account in your organization. Give it to the intended person and keep its access separate from the dispatcher. The shared address is an identity they may send from; it is not a reason to give them the team's login or to let several contractors reuse one person's credentials.
Set the two permissions separately
Create the shared mailbox and a personal mailbox for the contractor first. All must belong to the same TrekMail account, although their domains can differ. Shared mailboxes are available on Starter and above.
Open the shared mailbox's Access tab in the dashboard and add the contractor's personal mailbox. A new member gets both permissions, so immediately turn off Read and leave Send as enabled. Follow the send-only access guide.
Review the other members. At least one person must read the shared mailbox. For the service company, that would be the dispatcher and, ideally, someone who can cover for them.
Sending permission lets someone represent the company from that address. Grant it to people trusted with that correspondence, even if they do not need to read incoming mail. Lack of access to history does not restrict the recipients of a new message.
Send from personal webmail
The engineer signs in to their own mailbox and starts a new message. In From, they select service@example.com, identified as a team address. They don't need to open the shared mailbox or learn another password.
With this permission, the shared mailbox does not appear among available inboxes, in All inboxes, or in email app folders. Its Drive also remains inaccessible. This is expected: the permission applies to the sender address.
Webmail saves a copy of the message in the contractor's personal Sent folder. The engineer can therefore find their own report and check what they sent the customer.
Setup in Outlook and other apps depends on the client's capabilities. Start with webmail, where choosing a team address is part of the interface. If needed, configure a separate app afterwards and test it with a trial message.
Identify the author and decide who receives replies
The recipient sees the shared mailbox's name and address. The contractor can set a personal signature for that identity in Sending addresses, for example with the engineer's name and order number. The team name and email address remain controlled by the administrator.
If the domain enforces a signature, it may replace the personal one. Check the actual received message, especially when the signature needs the responsible person's contact details.
A customer's reply arrives in the shared mailbox. Someone with Send as only cannot see it and does not get a separate notification of the reply. Delivery failure messages may arrive there too.
Agree on how the dispatcher passes these messages to engineers. For example, a question about the work can be passed on using the order number. Without that process, the customer may reply to a report without its author knowing.
Walk through a report, a reply, and the end of the job
Start with a test report to an address you control. In webmail, have the contractor deliberately choose the team identity rather than rely on the sender they last used. Look at the received From address, displayed name, and signature. If the engineer's own contact details matter, check that the domain's signature policy has not replaced them with a different footer.
Reply to that report as a customer would. The dispatcher should find the answer in the shared mailbox and know how to pass the question to the engineer. The engineer should not need access to the whole inbox to learn that one piece of information. Agree on a way to identify the relevant order, so another customer's conversation is not included in an unnecessary handover.
Repeat the check in any mail app the contractor will actually use. An application displaying an extra address is not enough: its sending setup must work with the person's own sign-in. If the app cannot support that arrangement, keep this task in webmail. The webmail signature also does not configure the signature inside a separate application.
When the job ends, remove membership and check a fresh send attempt through the route the contractor used. Keep the distinction between future permission and old copies clear. Revocation stops new use of the team address through that membership; it does not retrieve a report already sent to a customer or erase a copy already saved in the contractor's Sent folder. Your agreement about retaining project records is a separate part of closing the assignment.
Check restricted history and current limits
Then inspect the engineer's personal webmail. Their own sent message should be available, while the service@example.com inbox should not open. If they can see the shared mailbox's history, revisit the Read setting.
The shared mailbox guide also explains adding and removing members.
This access covers the shared mailbox's main address, not its aliases; Message API and AI agents do not currently support sending through this send-only permission. Plan that workflow around webmail or a compatible mail app.
Related reading
- A Shared Mailbox in Outlook and Apple Mail, Without Sharing a Password
- Set Up Mailboxes Without Ever Sharing a Password
- Set up a three-person support inbox without a shared password
- A colleague is leaving: keep incoming mail and close access
- Let a client add their next employee without your login
