Khi doanh nghiệp sử dụng Microsoft 365, đặc biệt với các mailbox dùng chung như:
IT thường cần cấp quyền để nhiều nhân viên có thể gửi email từ cùng một địa chỉ.
Trong Microsoft 365/Exchange Online, hai quyền thường gặp là:
Send As
và
Send on Behalf
Hai quyền này đều cho phép một người gửi email từ mailbox khác, nhưng cách người nhận nhìn thấy người gửi hoàn toàn khác nhau. Microsoft phân biệt rõ Send As, Send on Behalf và Full Access thành các quyền riêng biệt.
Send As là gì?
Send As cho phép người dùng gửi email giống như chính mailbox đó gửi.
Ví dụ:
Mailbox chung:
Nhân viên:
Nếu Huân được cấp quyền Send As cho support@company.com và gửi email cho khách hàng, người nhận sẽ thấy:
From: support@company.com
Người nhận thông thường không thấy Huân là người trực tiếp gửi thư.
Microsoft mô tả Send As là quyền cho phép delegate gửi email như thể thư được gửi trực tiếp từ mailbox hoặc group đó, không hiển thị dấu hiệu rằng một delegate khác đã gửi.
Có thể hiểu đơn giản:
Huân → gửi dưới danh nghĩa Support
Khách hàng thấy:
Support support@company.com
Send on Behalf là gì?
Send on Behalf cũng cho phép nhân viên gửi thư thay cho mailbox khác.
Tuy nhiên người nhận sẽ nhìn thấy cả:
- Người thực sự gửi.
- Mailbox mà người đó đại diện.
Ví dụ:
Huân on behalf of Support
hoặc:
Huân thay mặt Support
Tùy ứng dụng email của người nhận, phần From có thể được hiển thị tương đương:
Huan Nguyen on behalf of Support
Microsoft xác nhận với Send on Behalf, địa chỉ From thể hiện rõ delegate gửi thư thay mặt mailbox hoặc group. Phản hồi của người nhận vẫn được gửi về mailbox/group được đại diện chứ không mặc định gửi về mailbox cá nhân của delegate.
Có thể hiểu:
Huân → thay mặt Support gửi
thay vì:
Support → gửi
Ví dụ thực tế để thấy ngay sự khác nhau
Giả sử SMNET có mailbox:
và nhân viên:
Nếu cấp Send As
Lan gửi báo giá cho khách hàng.
Khách hàng thấy:
From: Sales Department sales@company.com
Nhìn từ bên ngoài, email được xem như đến trực tiếp từ bộ phận Sales.
Nếu cấp Send on Behalf
Khách hàng có thể thấy:
Lan Tran on behalf of Sales Department
Người nhận biết rõ Lan là người gửi nhưng đang gửi thay mặt cho bộ phận Sales.
Đây là khác biệt quan trọng nhất giữa hai quyền.
So sánh nhanh Send As và Send on Behalf
| Tiêu chí | Send As | Send on Behalf |
|---|---|---|
| Có thể gửi từ mailbox khác | Có | Có |
| Người nhận thấy mailbox chung | Có | Có |
| Người nhận thấy người gửi thực tế | Thông thường không | Có |
| Hiển thị kiểu “on behalf of” | Không | Có |
| Phù hợp mailbox phòng ban | Rất phù hợp | Tùy trường hợp |
| Phù hợp trợ lý gửi thay quản lý | Có thể | Rất phù hợp |
| Tính đại diện thương hiệu | Cao | Thấp hơn |
| Tính minh bạch về người gửi | Thấp hơn với người nhận | Cao |
Khi nào nên dùng Send As?
Trong môi trường doanh nghiệp, Send As thường phù hợp hơn cho Shared Mailbox đại diện cho một phòng ban hoặc chức năng chung.
Ví dụ:
Khách hàng không nhất thiết cần biết nhân viên nào trong nhóm đã trực tiếp gửi thư.
Điều quan trọng là email được gửi từ:
Support Department
hoặc:
Sales Department
Ví dụ khách hàng gửi:
Dear Support,
Một kỹ sư tiếp nhận và trả lời từ:
Với Send As, toàn bộ trao đổi giữ được hình ảnh thống nhất:
Customer ↔ Support
thay vì:
Customer ↔ nhân viên A on behalf of Support
Đây thường là cách phù hợp với các mailbox dịch vụ khách hàng.
Khi nào nên dùng Send on Behalf?
Send on Behalf phù hợp khi doanh nghiệp muốn người nhận biết:
Ai là người thực sự gửi email.
Ví dụ:
CEO:
Trợ lý:
Nếu trợ lý gửi thư thay CEO bằng Send on Behalf, người nhận có thể thấy:
Assistant on behalf of Director
Điều này thể hiện đúng bản chất:
Trợ lý đang gửi thư thay mặt Giám đốc.
Một trường hợp khác là thư ký phòng ban gửi:
Lan on behalf of Management Team
Lúc này Send on Behalf giúp tăng tính minh bạch.
Với Shared Mailbox doanh nghiệp nên chọn quyền nào?
Với các mailbox chức năng như:
support@
sales@
accounting@
customer.service@
thông thường nên cân nhắc:
Full Access + Send As
Microsoft cũng mô tả Full Access cho phép người dùng mở, đọc và quản lý nội dung shared mailbox, nhưng Full Access không tự động cấp quyền gửi; người dùng vẫn cần Send As hoặc Send on Behalf để gửi từ mailbox đó.
Mô hình phổ biến:
Full Access
→ đọc và quản lý mailbox
Send As
→ gửi email dưới địa chỉ mailbox chung
Full Access không phải Send As
Đây là một nhầm lẫn rất thường gặp.
IT cấp:
Full Access
cho nhân viên rồi nghĩ rằng nhân viên có thể gửi thư từ Shared Mailbox.
Không nhất thiết.
Microsoft xác nhận Full Access cho phép delegate:
- Mở mailbox.
- Đọc email.
- Thêm/xóa nội dung.
- Quản lý mailbox.
Nhưng không tự cấp Send As hoặc Send on Behalf.
Vì vậy có thể xảy ra trường hợp:
Mở được support@company.com
nhưng khi gửi:
From: support@company.com
thì Outlook báo không có quyền gửi.
Khi đó cần kiểm tra:
Send As
hoặc:
Send on Behalf
Send As cũng không có nghĩa là Full Access
Điều ngược lại cũng đúng.
Một người có quyền:
Send As
không đồng nghĩa họ có quyền đọc toàn bộ mailbox.
Microsoft quy định Send As là quyền gửi riêng và không tự cho phép delegate đọc nội dung mailbox.
Ví dụ IT có thể cấu hình:
User A → Send As sales@company.com
nhưng không cấp:
Full Access
Khi đó User A có quyền gửi dưới địa chỉ Sales nhưng không nhất thiết được mở và quản lý toàn bộ mailbox Sales.
Đây là lý do IT cần hiểu rõ từng quyền thay vì cấp tất cả quyền theo thói quen.
Nếu cấp cả Send As và Send on Behalf thì sao?
Theo Microsoft, nếu cùng một delegate có cả:
Send As
và:
Send on Behalf
cho cùng một mailbox hoặc group, Send As được ưu tiên sử dụng.
Vì vậy không nên cấp cả hai quyền nếu doanh nghiệp không thực sự cần.
IT nên xác định trước:
Muốn người nhận nhìn thấy ai là người gửi?
Rồi cấp quyền phù hợp.
Ví dụ cho phòng Sales
Doanh nghiệp có:
Nhân viên:
Nếu mục tiêu là khách hàng chỉ giao tiếp với thương hiệu:
Sales Department
thì có thể sử dụng:
Full Access + Send As
Khách hàng nhận:
From: Sales sales@company.com
Ví dụ cho phòng Support
Mailbox:
Có 5 kỹ sư IT cùng xử lý.
Với:
Full Access + Send As
kỹ sư A có thể trả lời:
From: support@company.com
Kỹ sư B cũng có thể trả lời:
From: support@company.com
Khách hàng luôn giao tiếp với một địa chỉ thống nhất:
Điều này phù hợp với mô hình Helpdesk hoặc Managed IT Support.
Ví dụ cho trợ lý Giám đốc
Mailbox:
Trợ lý:
Nếu trợ lý chỉ hỗ trợ gửi thư thay mặt Giám đốc, doanh nghiệp có thể cân nhắc:
Send on Behalf
Người nhận thấy:
Assistant on behalf of Director
Điều này minh bạch hơn so với việc thư xuất hiện như chính Giám đốc trực tiếp gửi.
Nên dùng Send As hay dùng luôn password của Shared Mailbox?
Không nên chia sẻ password của mailbox cho nhiều nhân viên.
Với Shared Mailbox trong Microsoft 365, cách quản trị phù hợp là:
User đăng nhập bằng tài khoản cá nhân
↓
Microsoft 365 kiểm tra quyền
↓
User truy cập Shared Mailbox
↓
Send As / Send on Behalf
Microsoft thiết kế Shared Mailbox để người dùng được cấp quyền truy cập thông qua mailbox cá nhân; shared mailbox mới mặc định cũng bị chặn đăng nhập trực tiếp.
Điều này tốt hơn việc:
5 nhân viên cùng biết password support@company.com
vì doanh nghiệp có thể:
- Thu hồi quyền từng người.
- Quản lý người nào được truy cập.
- Không cần chia sẻ mật khẩu chung.
- Dễ dàng onboarding/offboarding.
Nhân viên nghỉ việc thì xử lý thế nào?
Ví dụ nhân viên Sales nghỉ việc.
Nếu doanh nghiệp đang sử dụng Shared Mailbox đúng cách, IT chỉ cần:
Remove Full Access
và:
Remove Send As / Send on Behalf
khỏi tài khoản nhân viên đó.
Mailbox:
vẫn tiếp tục hoạt động bình thường cho những thành viên khác.
Đây là một lợi ích lớn so với việc nhiều người cùng sử dụng chung một username/password.
Cấu hình ở đâu?
Trong Exchange Online, các quyền mailbox có thể được quản lý qua Exchange Admin Center và Exchange Online PowerShell tùy loại mailbox, group và quyền cần cấp. Microsoft sử dụng các quyền chính:
- Full Access.
- Send As.
- Send on Behalf.
Với Shared Mailbox, administrator thường quản lý delegation từ khu vực:
Exchange Admin Center → Recipients → Mailboxes → Shared Mailbox → Mailbox Delegation
Tên menu có thể thay đổi theo giao diện Microsoft 365 tại từng thời điểm, nhưng nguyên tắc quyền vẫn như trên.
IT nên chọn quyền theo nguyên tắc nào?
Có thể sử dụng quy tắc đơn giản:
Muốn khách hàng chỉ thấy tên phòng ban
Chọn:
Send As
Ví dụ:
Support support@company.com
Muốn khách hàng biết nhân viên nào gửi thay
Chọn:
Send on Behalf
Ví dụ:
Lan on behalf of Accounting
Muốn nhân viên đọc và xử lý email trong mailbox
Cấp:
Full Access
Muốn vừa đọc mailbox vừa gửi dưới danh nghĩa mailbox
Cấp:
Full Access + Send As
Đây thường là mô hình phù hợp với:
- Support.
- Sales.
- Accounting.
- HR.
- Customer Service.
Câu hỏi thường gặp
Full Access có gửi email được không?
Không tự động.
Full Access cho phép mở và quản lý mailbox nhưng cần thêm Send As hoặc Send on Behalf nếu muốn gửi thư từ mailbox đó.
Send As có đọc được mailbox không?
Không tự động.
Send As là quyền gửi thư, không phải quyền đọc mailbox.
Send on Behalf có hiện tên nhân viên không?
Có.
Người nhận sẽ thấy delegate gửi on behalf of mailbox hoặc group.
Khách hàng trả lời email Send on Behalf thì thư về đâu?
Microsoft cho biết phản hồi được gửi về mailbox hoặc group được đại diện, không phải mặc định về mailbox cá nhân của delegate.
Shared Mailbox support@ nên dùng quyền nào?
Trong phần lớn trường hợp Helpdesk/Support:
Full Access + Send As
là mô hình dễ sử dụng.
Nhân viên có thể:
- Đọc email Support.
- Xử lý email.
- Gửi thư dưới địa chỉ Support.
- Giữ một địa chỉ giao tiếp thống nhất với khách hàng.
Kết luận
Sự khác biệt giữa Send As và Send on Behalf có thể tóm tắt rất đơn giản:
Send As
“Tôi là mailbox này.”
Send on Behalf
“Tôi đang gửi thay mặt mailbox này.”
Với những mailbox đại diện cho phòng ban như:
support@, sales@, accounting@
thì Send As thường phù hợp hơn vì khách hàng nhìn thấy một danh tính doanh nghiệp thống nhất.
Với các trường hợp như:
Trợ lý → Giám đốc
hoặc:
Thư ký → Ban quản lý
thì Send on Behalf có thể phù hợp hơn vì người nhận biết rõ ai thực sự thực hiện việc gửi thư.
Quan trọng nhất là IT không nên cấp quyền theo thói quen.
Hãy xác định:
Ai được đọc? → Full Access
Ai được gửi như mailbox? → Send As
Ai được gửi thay mặt mailbox? → Send on Behalf
Đó là cách quản lý Shared Mailbox rõ ràng và dễ kiểm soát hơn trong Microsoft 365.
SMNET hỗ trợ Microsoft 365 cho doanh nghiệp
SMNET cung cấp dịch vụ triển khai và quản trị Microsoft 365, bao gồm:
- Tư vấn Microsoft 365 License.
- Tạo và cấu hình Shared Mailbox.
- Phân quyền Full Access.
- Send As.
- Send on Behalf.
- Distribution Group.
- Microsoft 365 Group.
- Cấu hình Outlook.
- Migration email POP/IMAP sang Microsoft 365.
- Chuyển dữ liệu PST.
- SPF, DKIM và DMARC.
- MFA và bảo mật tài khoản.
- Hỗ trợ và quản trị Microsoft 365.
SMNET – Đối tác công nghệ của doanh nghiệp
Website: smnet.vn
Hotline: 028 7301 6068
Email: hello@smnet.vn
