Email từ ứng dụng và thiết bị trên Microsoft 365: cần kiểm tra gì trước thay đổi tháng 12 năm 2026

Trước khi duyệt thay đổi cho máy quét, hệ thống lập hóa đơn hoặc ứng dụng báo cáo, hãy xác định xem thiết bị hay ứng dụng đó có gửi qua Exchange Online bằng xác thực cơ bản SMTP AUTH hay không. Chính sự phụ thuộc này chịu ảnh hưởng từ thay đổi của Microsoft vào tháng 12 năm 2026. Một tổ chức sử dụng Microsoft 365 không có nghĩa là đã biết từng ứng dụng gửi email theo cách nào.

Việc cần làm là xác định các bên gửi bị ảnh hưởng, xác nhận một phương thức tiếp tục được hỗ trợ và kiểm tra một email công việc tiêu biểu trước khi thay đổi cấu hình đang hoạt động. Nhờ vậy, người phụ trách hoặc người duyệt ngân sách có cơ sở để quyết định công việc nào là cần thiết.

Thay đổi gì vào cuối tháng 12

Lịch trình SMTP AUTH cập nhật của Microsoft cho biết cách hoạt động sẽ giữ nguyên đến hết tháng 12 năm 2026. Cuối tháng đó, xác thực cơ bản SMTP AUTH sẽ bị tắt theo mặc định đối với các tenant hiện có. Quản trị viên vẫn có thể bật lại khi cần. Thay đổi mặc định này tách biệt với việc loại bỏ hoàn toàn sau này.

Đối với tenant mới được tạo sau tháng 12 năm 2026, tính năng này sẽ không khả dụng theo mặc định và OAuth là phương thức xác thực được hỗ trợ. Microsoft cho biết sẽ công bố ngày loại bỏ cuối cùng trong nửa cuối năm 2027. Đây là khoảng thời gian công bố một ngày cụ thể, không phải ngày loại bỏ.

Lịch trình này áp dụng cho xác thực cơ bản SMTP AUTH trong Exchange Online. Điều đó không có nghĩa SMTP sẽ chấm dứt hoặc mọi hộp thư và thiết bị Microsoft 365 đều có cùng sự phụ thuộc. Lịch trình sửa đổi tạo thời gian chuẩn bị, nhưng vẫn có một thay đổi cấu hình cụ thể cần được đánh giá.

Bắt đầu từ email công việc

Với mỗi email quan trọng, hãy yêu cầu nhà cung cấp hoặc quản trị viên xác nhận đường gửi thực tế. Ứng dụng lập hóa đơn có thể gửi thẳng đến Exchange Online, dùng relay cục bộ hoặc gửi qua dịch vụ của nhà cung cấp. Đây là các ví dụ giả định và mỗi trường hợp cần bằng chứng khác nhau. Chỉ nhìn thấy địa chỉ Microsoft 365 ở trường người gửi thì chưa thể xác định được.

Lập danh mục ngắn gọn với các trường sau:

• Email công việc: nội dung được gửi, thời điểm cần gửi và tệp đính kèm hoặc nội dung nào là quan trọng.
• Bên gửi và đường gửi: ứng dụng hoặc thiết bị, dịch vụ gửi thực tế và phương thức xác thực.
• Người nhận: người trong tổ chức, người nhận bên ngoài hoặc cả hai.
• Chủ sở hữu hệ thống: người chịu trách nhiệm về bên gửi và quan hệ với nhà cung cấp.
• Phương án tiếp tục: phương thức được hỗ trợ cùng các câu hỏi còn bỏ ngỏ về tương thích hoặc cấu hình.
• Người xác minh: người sẽ xác nhận email cần thiết đã đến người nhận.

Ghi rõ những điều chưa biết và giao người xử lý. Việc này giúp phân biệt trường hợp đã xác nhận phụ thuộc vào xác thực cơ bản với bên gửi cần được tìm hiểu riêng. Đồng thời, nhà cung cấp sẽ nhận được câu hỏi cụ thể cần trả lời trước khi mua sắm hoặc đổi cấu hình.

Chọn phương thức theo người nhận và môi trường lưu trữ

Gửi từ ứng dụng bằng OAuth là một phương án để tiếp tục. Tài liệu OAuth cho SMTP của Microsoft mô tả hỗ trợ xác thực, bao gồm đăng ký ứng dụng và token. Ứng dụng hoặc thiết bị cụ thể phải triển khai hỗ trợ cần thiết, và cấu hình tenant phải cho phép sử dụng. Tuyên bố sản phẩm “hỗ trợ SMTP” quá rộng để xác nhận tương thích. Hãy hỏi nhà cung cấp về đúng mẫu thiết bị hoặc phiên bản phần mềm.

Hướng dẫn gửi email từ ứng dụng và thiết bị của Microsoft phân biệt các phương thức theo phạm vi người nhận và yêu cầu vận hành. Gửi từ ứng dụng và relay qua connector đủ điều kiện có thể gửi đến người nhận nội bộ lẫn bên ngoài. Trong phần so sánh này, High Volume Email và Direct Send chỉ dành cho người nhận nội bộ. Giới hạn người nhận khiến hai phương thức này không phù hợp với hóa đơn hoặc nhắc thanh toán gửi cho khách hàng bên ngoài tổ chức.

Relay qua connector có các điều kiện riêng. Phương thức này cần inbound connector, xác thực bằng chứng chỉ hoặc địa chỉ IP công khai tĩnh phù hợp, và cổng 25 phải khả dụng. Microsoft không hỗ trợ relay theo phương thức này từ các dịch vụ do bên thứ ba lưu trữ như Azure. Vì vậy, cần kiểm tra môi trường lưu trữ của ứng dụng trên nền tảng đám mây trước khi xem relay qua connector là một lựa chọn.

Direct Send cũng đi kèm trách nhiệm quản trị máy chủ email. Một dịch vụ gửi khác, bao gồm phương án Azure Communication Services mà Microsoft mô tả cho email nội bộ và bên ngoài, cần được đánh giá riêng về tính tương thích và vận hành. Danh sách người nhận, môi trường lưu trữ và hỗ trợ sẵn có sẽ quyết định phương án nào đáng được xem xét. Chỉ nên quyết định thay phần cứng sau khi đã kiểm tra các lựa chọn được hỗ trợ.

Kiểm tra email trước khi thay đổi chính thức

Thống nhất ai sẽ thực hiện thay đổi, ai kiểm tra kết quả công việc và ai xử lý sự cố sau đó. Dùng một email tiêu biểu với danh tính người gửi, nội dung và tệp đính kèm cần thiết. Theo dõi email từ lúc gửi đến khi người nhận dự kiến nhận được, bao gồm người nhận bên ngoài nếu quy trình công việc yêu cầu.

Xác thực thành công chỉ xác nhận một phần của quá trình. Xác nhận hỗ trợ từ nhà cung cấp và kiểm tra kết nối thành công của quản trị viên vẫn cần được bổ sung bằng việc kiểm tra người nhận thực tế đã nhận email. Lên lịch thay đổi chính thức khi đã làm rõ sự phụ thuộc, phương thức tương thích và trách nhiệm xác minh.

Nếu cần hỗ trợ đánh giá yêu cầu của ứng dụng hoặc thiết bị gửi email, chúng tôi có thể trao đổi về phạm vi qua dịch vụ hạ tầng email của chúng tôi.