Bảo mật email doanh nghiệp

Mục lục

1. Email doanh nghiệp bị tấn công theo những kiểu nào?
2. SPF, DKIM, DMARC phối hợp với nhau thế nào?
3. Cấu hình SPF đúng cách và những lỗi thường gặp
4. DKIM: thêm bản ghi chưa đủ, phải bật ký
5. DMARC: lộ trình siết từng bước dựa trên báo cáo
6. Gmail, Yahoo và Microsoft đang bắt buộc điều gì?
7. Bảo vệ tài khoản: MFA và các cổng hay bị bỏ quên
8. Lọc thư ở cổng vào và bảo vệ người nhận
9. Mã hoá email: TLS đủ chưa, khi nào cần mã hoá đầu cuối?
10. Khi nghi ngờ hộp thư bị chiếm: xử lý theo thứ tự nào?
11. Checklist rà soát nhanh cho quản trị viên
12. Quy trình xác minh cho nhóm kế toán và tài chính
13. Lựa chọn nền tảng: dùng dịch vụ đám mây hay tự vận hành?
14. Câu hỏi thường gặp

Email doanh nghiệp bị tấn công theo những kiểu nào?

Trước khi chọn công cụ, bạn cần phân biệt bốn kiểu tấn công. Mỗi kiểu bị chặn bởi một lớp khác nhau.

Kiểu tấn công	Cách diễn ra	Lớp chặn chính
Giả mạo tên miền (spoofing)	Kẻ gian gửi thư mang địa chỉ @congty.vn thật mà không cần vào hệ thống của bạn	SPF, DKIM, DMARC
Tên miền gần giống	Đăng ký tên miền khác một ký tự (ví dụ minh hoạ: congty.vn thành cong-ty.vn hoặc congtv.vn)	Cảnh báo người nhận, giám sát tên miền, lọc thư
Chiếm hộp thư (account takeover)	Lấy mật khẩu qua trang đăng nhập giả rồi vào hộp thư thật	MFA, chặn giao thức cũ, giám sát đăng nhập
Thư chứa tệp hoặc liên kết độc hại	Đính kèm mã độc hoặc dẫn tới trang thu thập mật khẩu	Cổng lọc thư, sandbox, bảo vệ máy trạm

Chiếm hộp thư nguy hiểm hơn giả mạo tên miền, vì thư gửi đi từ hộp thư thật nên qua được SPF, DKIM và DMARC. Kẻ gian đọc lịch sử trao đổi, chờ đúng thời điểm có hoá đơn rồi chèn một thư đổi số tài khoản nhận tiền. Đây là dạng lừa đảo thư công việc (business email compromise, BEC). Phần lớn thiệt hại thực tế đến từ kiểu này chứ không đến từ mã độc.

Các thủ thuật tâm lý đứng sau những thư này (khẩn cấp, mạo danh lãnh đạo, mạo danh đối tác) được mô tả trong bài kỹ thuật tấn công social engineering. Dấu hiệu nhận biết thư lừa đảo nằm ở bài nhận biết phishing. Bài này tập trung vào phần hạ tầng email mà người quản trị phải cấu hình.

SPF, DKIM, DMARC phối hợp với nhau thế nào?

Ba bản ghi này đều nằm trong DNS của tên miền (cơ chế DNS xem ở bài DNS là gì). Mỗi bản ghi trả lời một câu hỏi riêng của máy chủ nhận.

• SPF (Sender Policy Framework): khai báo máy chủ nào được phép gửi email thay mặt domain của bạn. SPF kiểm tra địa chỉ trong phần phong bì thư (envelope sender, còn gọi là Return-Path), không phải địa chỉ From mà người dùng nhìn thấy.
• DKIM (DomainKeys Identified Mail): máy chủ gửi ký số lên các phần của thư bằng khóa riêng, bên nhận lấy khóa công khai trong DNS để kiểm tra. Chữ ký hợp lệ chứng minh thư không bị sửa trên đường đi và đúng từ domain của bạn.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): là bản ghi TXT nói cho bên nhận biết phải làm gì với thư không qua được SPF và DKIM, đồng thời yêu cầu họ gửi báo cáo về cho bạn.

Điểm hay bị hiểu sai là khái niệm căn chỉnh (alignment). Thư chỉ đạt DMARC khi SPF hoặc DKIM đạt và tên miền được xác thực trùng với tên miền trong dòng From. Tên miền trong From phải căn chỉnh với tên miền SPF hoặc tên miền ký DKIM. Vì vậy một dịch vụ gửi thư thuê ngoài có thể qua SPF của chính nhà cung cấp đó nhưng vẫn trượt DMARC của bạn, nếu họ không ký DKIM bằng tên miền của bạn.

Cấu hình SPF đúng cách và những lỗi thường gặp

SPF là một bản ghi TXT tại tên miền gốc, bắt đầu bằng v=spf1 và kết thúc bằng một cơ chế all. Ví dụ minh hoạ cho công ty dùng Google Workspace: v=spf1 include:_spf.google.com ~all. Nếu có thêm dịch vụ gửi thư khác, bạn thêm một mục include cho dịch vụ đó vào cùng một bản ghi.

Bốn lỗi hay gặp:

1. Hai bản ghi SPF trên cùng tên miền. Giao thức chỉ chấp nhận một bản ghi; có hai bản ghi thì bên nhận coi là lỗi cố định. SPF chỉ được có một bản ghi. Hãy gộp các include vào một dòng.
2. Vượt giới hạn 10 lần tra cứu DNS. Mỗi include, a, mx, redirect đều tính vào giới hạn trong RFC 7208. Công ty dùng song song mail chính, phần mềm CRM, công cụ gửi thư hàng loạt và hệ thống hoá đơn rất dễ vượt. Khi vượt, SPF trả về lỗi và có thể làm trượt DMARC.
3. Dùng +all hoặc ?all. Hai cách này gần như cho phép mọi máy chủ gửi thay bạn. Mục tiêu cuối là -all hoặc ~all.
4. Quên nguồn gửi phụ. Máy in quét tài liệu gửi mail, phần mềm kế toán, hệ thống chăm sóc khách hàng, website gửi thư xác nhận đơn hàng. Những nguồn này thường không có trong bản ghi ban đầu.

Lưu ý rằng SPF có điểm yếu: khi thư bị chuyển tiếp qua máy chủ trung gian, IP gửi thay đổi và SPF thường trượt. DKIM chịu được chuyển tiếp tốt hơn, nên đừng chỉ dựa vào SPF.

DKIM: thêm bản ghi chưa đủ, phải bật ký

Với Microsoft 365, bạn thêm hai bản ghi CNAME lấy từ trang quản trị rồi mới bật DKIM cho tên miền. Lỗi phổ biến là dừng ở bước đầu: thêm bản ghi mà không bật thì chưa có tác dụng gì. Với Google Workspace, bạn tạo khóa trong trang quản trị rồi dán giá trị TXT vào DNS, sau đó bấm bắt đầu xác thực. Google lưu ý bản ghi có thể mất tới 48 giờ để cập nhật hoàn chỉnh.

Với từng dịch vụ bên thứ ba gửi thư nhân danh bạn (công cụ email marketing, phần mềm hoá đơn), hãy yêu cầu họ cung cấp bản ghi DKIM cho tên miền của bạn. Nếu họ chỉ ký bằng tên miền của họ, thư sẽ không có căn chỉnh DMARC.

Về độ dài khóa, hãy dùng 2048 bit nếu nhà cung cấp hỗ trợ. Một số bảng quản trị DNS cắt chuỗi TXT dài, nên sau khi lưu phải kiểm tra lại bằng cách gửi thư thử tới hộp thư ngoài và xem tiêu đề thư có dòng dkim=pass.

DMARC: lộ trình siết từng bước dựa trên báo cáo

Nhiều doanh nghiệp đặt luôn p=reject theo hướng dẫn cũ rồi phát hiện thư báo giá hoặc hoá đơn của chính mình bị trả lại. Cách an toàn hơn là đi từng nấc. Hướng dẫn cho Microsoft 365 cũng nhấn mạnh điều này: DMARC đi ba nấc, đừng siết ngay.

Giai đoạn 1: p=none và đọc báo cáo

Bản ghi TXT đặt tại _dmarc.tenmiencuaban.vn, ví dụ minh hoạ: v=DMARC1; p=none; rua=mailto:[email protected]. Thẻ rua nhận báo cáo tổng hợp (XML) từ các nhà cung cấp hộp thư. Báo cáo thô khó đọc bằng mắt, nên dùng công cụ phân tích; với doanh nghiệp vừa và nhỏ, một dịch vụ miễn phí để đọc báo cáo là đủ, không cần thuê dịch vụ quản lý DMARC.

Trong 2 đến 4 tuần, hãy lập danh sách mọi nguồn gửi thư nhân danh tên miền: mail chính, hệ thống hoá đơn điện tử, CRM, máy in, website, đối tác marketing. Nguồn nào trượt thì sửa SPF hoặc bật DKIM cho nguồn đó. Nguồn nào bạn không nhận ra thì rất có thể là kẻ giả mạo.

Giai đoạn 2: quarantine và tăng dần tỷ lệ

Thẻ pct cho phép áp chính sách lên một phần thư không đạt. Bạn có thể bắt đầu với pct=10, theo dõi phản hồi từ phòng kinh doanh và kế toán, rồi tăng dần. Thư bị đưa vào thư rác vẫn còn để cứu, trong khi thư bị từ chối thì không.

Giai đoạn 3: reject

Khi báo cáo nhiều tuần liên tiếp không còn nguồn hợp lệ nào trượt, chuyển sang p=reject. Nếu tên miền chính chỉ dùng để nhận thư mà không gửi, hoặc là tên miền dự phòng, bạn có thể đặt reject ngay từ đầu để chống kẻ gian mượn tên.

Gmail, Yahoo và Microsoft đang bắt buộc điều gì?

Từ năm 2024, các nhà cung cấp hộp thư lớn đặt ra yêu cầu cho bên gửi nhiều thư. Điều này ảnh hưởng cả doanh nghiệp Việt gửi thư marketing hoặc thông báo cho khách ở nước ngoài, hay khách dùng Gmail và Outlook trong nước.

• Yêu cầu áp dụng cho bên gửi trên 5.000 thư mỗi ngày, gồm triển khai SPF, DKIM, DMARC và hủy đăng ký dễ dàng.
• Từ tháng 11/2025, Google bắt đầu siết dần việc thực thi các yêu cầu đã áp dụng từ 2024. Các thông báo của Google cho biết thư không đạt có thể bị từ chối tạm thời hoặc vĩnh viễn.
• Microsoft công bố yêu cầu tương tự ngày 2/4/2025 cho Outlook.com, Hotmail, Live, MSN: SPF đạt, DKIM đạt, DMARC tối thiểu p=none và có căn chỉnh. Các nguồn tổng hợp mô tả mức xử lý khác nhau (đưa vào thư rác hay từ chối hẳn), nên bạn hãy xem thông báo mới nhất của Microsoft khi cần.
• Về tỷ lệ khiếu nại thư rác, các hướng dẫn tổng hợp khuyến nghị giữ dưới 0,3%.

Ở thời điểm tháng 9/2026, một nguồn theo dõi ghi nhận chưa nhà cung cấp hộp thư nào đòi hỏi chính sách cao hơn p=none. Nhưng p=none không ngăn được ai giả mạo bạn, nó chỉ giúp bạn quan sát. Về chuẩn kỹ thuật, một nguồn tổng hợp cho biết ngày 21/5/2026 IETF công bố DMARCbis dưới dạng RFC 9989, 9990 và 9991, thay thế RFC 7489; các bản ghi DMARC hiện có vẫn hoạt động, nhưng người quản trị nên theo dõi thay đổi về thẻ khi nhà cung cấp cập nhật công cụ.

Bảo vệ tài khoản: MFA và các cổng hay bị bỏ quên

Xác thực tên miền không cứu được hộp thư đã bị lấy mật khẩu. Lớp này gồm các việc sau.

Bật MFA cho mọi hộp thư, ưu tiên khoá chống phishing

Mã gửi qua SMS có thể bị chặn hoặc lừa đọc. Ứng dụng tạo mã TOTP tốt hơn, còn passkey hoặc khoá bảo mật FIDO2 chống được trang đăng nhập giả vì khoá chỉ trả lời đúng tên miền thật. So sánh các phương thức có trong bài xác thực đa yếu tố MFA. Hãy ưu tiên trước cho nhóm tài khoản kế toán, tài chính, quản trị hệ thống và lãnh đạo.

Chặn xác thực kiểu cũ

Các giao thức như POP3, IMAP cơ bản và SMTP AUTH cũ gửi tên đăng nhập và mật khẩu mà không hỗ trợ MFA. Kẻ gian thử mật khẩu bị lộ từ nơi khác (credential stuffing) qua các cổng này để né MFA. Nếu công ty không còn dùng phần mềm đọc thư đời cũ, hãy tắt các giao thức đó trong trang quản trị. Với máy in hoặc ứng dụng cần gửi thư, dùng tài khoản dịch vụ riêng, quyền hạn hẹp.

Kiểm soát quy tắc chuyển tiếp

Sau khi vào hộp thư, kẻ gian thường tạo quy tắc tự động chuyển tiếp thư có chữ như hóa đơn, thanh toán, chuyển khoản ra địa chỉ bên ngoài, hoặc tự xoá thư cảnh báo. Quản trị viên nên tắt chuyển tiếp tự động ra ngoài theo mặc định, và định kỳ rà soát danh sách quy tắc inbox cùng ứng dụng bên thứ ba được cấp quyền OAuth vào hộp thư.

Giám sát đăng nhập bất thường

Dấu hiệu cần cảnh báo: đăng nhập từ quốc gia công ty không hoạt động, hai địa điểm xa nhau trong thời gian ngắn, hoặc đăng nhập thành công ngay sau hàng loạt lần thất bại. Nếu có hệ thống thu thập log tập trung, khái niệm được nêu ở bài SIEM, hãy đưa nhật ký đăng nhập email vào đó.

Lọc thư ở cổng vào và bảo vệ người nhận

Dịch vụ lọc thư (secure email gateway hoặc bộ lọc tích hợp trong Microsoft 365, Google Workspace) làm các việc sau, và bạn nên kiểm tra từng chức năng có được bật chưa:

• Quét tệp đính kèm trong môi trường cô lập (sandbox) trước khi chuyển cho người nhận, đặc biệt tệp Office có macro, tệp nén có mật khẩu, tệp ISO.
• Viết lại và kiểm tra liên kết lúc bấm thay vì lúc nhận, vì kẻ gian có thể đổi đích sau khi thư vượt qua lọc.
• Cảnh báo thư từ bên ngoài bằng nhãn nổi bật. Nhãn này giúp nhận ra thư mạo danh giám đốc nhưng gửi từ địa chỉ ngoài.
• Bảo vệ mạo danh người dùng và tên miền gần giống, nhất là cho danh sách lãnh đạo và kế toán.
• Chặn định dạng tệp rủi ro, ví dụ tệp thực thi hoặc script, khỏi hộp thư thông thường.

Mã độc đi theo email thường được chặn tiếp ở máy trạm. Phần này thuộc về bảo vệ thiết bị đầu cuối. Nếu bạn cần phối hợp nhiều lớp, hãy tham khảo cách tổ chức trong bài an toàn thông tin.

Mã hoá email: TLS đủ chưa, khi nào cần mã hoá đầu cuối?

Có hai mức khác nhau, và nhiều bài trên mạng gộp chúng làm một.

• Mã hoá đường truyền (TLS): mã hoá thư khi đi giữa các máy chủ. Dùng SSL/TLS để mã hóa khi email gửi nhận giữa client và server, giữa server và server, nhằm giảm nguy cơ nghe lén. Điểm yếu là TLS cơ hội: nếu máy chủ nhận không hỗ trợ, thư có thể bị gửi dạng không mã hoá. MTA-STS và TLS-RPT cho phép bạn yêu cầu bên gửi đến bạn chỉ dùng kết nối TLS hợp lệ và nhận báo cáo lỗi.
• Mã hoá nội dung (S/MIME, PGP, hoặc mã hoá thư của nền tảng): chỉ người nhận có khoá mới đọc được, kể cả nhà cung cấp dịch vụ. Chỉ nên dùng cho nhóm thư đặc biệt như hợp đồng, dữ liệu nhân sự, hồ sơ khách hàng, vì quản lý khoá và chứng thư phức tạp.

Nguyên lý khoá công khai, khoá riêng được giải thích ở bài mã hoá dữ liệu. Với tài liệu nhạy cảm, nhiều công ty chọn gửi liên kết có hạn dùng, yêu cầu đăng nhập, thay vì đính kèm tệp. Cách này cũng giúp thu hồi quyền truy cập khi gửi nhầm.

Khi nghi ngờ hộp thư bị chiếm: xử lý theo thứ tự nào?

Đây là quy trình cho quản trị viên. Mục tiêu là cắt quyền kẻ gian trước, thu thập bằng chứng, rồi mới khôi phục.

1. Đăng xuất mọi phiên và thu hồi token. Chỉ đổi mật khẩu thôi chưa đủ nếu phiên đã đăng nhập vẫn còn hiệu lực.
2. Đổi mật khẩu và kiểm tra MFA. Xem kẻ gian có đăng ký thêm một thiết bị MFA hoặc số điện thoại của họ không.
3. Rà soát quy tắc hộp thư: quy tắc chuyển tiếp, quy tắc xoá thư, địa chỉ chuyển tiếp ở cấp tài khoản, quyền uỷ quyền truy cập hộp thư, ứng dụng OAuth lạ.
4. Xuất nhật ký đăng nhập và nhật ký kiểm toán để xác định thời điểm bị vào, IP và thư đã bị đọc hoặc gửi đi.
5. Liên hệ ngay đối tác đã nhận thư lạ bằng kênh khác (điện thoại), đặc biệt nếu có thư đổi tài khoản thanh toán. Với khoản đã chuyển nhầm, báo ngân hàng càng sớm càng tốt.
6. Tìm nguồn gốc: người dùng bấm liên kết nào, trang đăng nhập giả nào. Chặn tên miền độc hại ở lọc thư và cổng web.
7. Đánh giá dữ liệu bị lộ. Nếu hộp thư chứa dữ liệu cá nhân của khách hàng hoặc nhân viên, hãy xem nghĩa vụ thông báo ở bài Nghị định 13/2023 và xác định xem việc đọc trộm hộp thư có phải sự cố lộ dữ liệu cần ghi nhận hay không.

Các sự cố liên quan hộp thư dùng chung (kế toán@, hr@) khó truy vết hơn, vì nhiều người cùng đăng nhập. Hãy chuyển sang hộp thư dùng chung có uỷ quyền, mỗi người đăng nhập bằng tài khoản riêng.

Checklist rà soát nhanh cho quản trị viên

Hạng mục	Cách kiểm tra	Kết quả mong muốn
SPF	Tra bản ghi TXT tên miền gốc, đếm lượt tra cứu	Một bản ghi, không quá 10 lượt, kết thúc bằng ~all hoặc -all
DKIM	Gửi thư thử tới hộp thư ngoài, xem tiêu đề	dkim=pass, tên miền ký trùng tên miền gửi
DMARC	Tra _dmarc.tenmien, đọc báo cáo rua	Có bản ghi; lộ trình hướng tới quarantine rồi reject
Nguồn gửi bên thứ ba	Đối chiếu báo cáo DMARC với danh sách dịch vụ	Mọi nguồn hợp lệ đều đạt căn chỉnh
MFA	Báo cáo người dùng chưa đăng ký MFA	Tỷ lệ chưa bật bằng 0 cho nhóm tài chính và quản trị
Giao thức cũ	Xem nhật ký đăng nhập theo giao thức	POP3, IMAP cơ bản, SMTP AUTH cũ bị tắt nếu không cần
Chuyển tiếp ngoài	Rà soát quy tắc hộp thư và địa chỉ chuyển tiếp	Không có chuyển tiếp ra ngoài ngoài danh sách đã duyệt
Cảnh báo thư ngoài	Gửi thử từ Gmail cá nhân	Thư hiện nhãn thư từ bên ngoài

Quy trình xác minh cho nhóm kế toán và tài chính

Công nghệ không chặn được hoàn toàn thư lừa đảo từ hộp thư thật bị chiếm, nên cần một quy tắc nghiệp vụ cụ thể. Ví dụ minh hoạ cho công ty có bộ phận thanh toán nhà cung cấp: mọi yêu cầu đổi số tài khoản nhận tiền phải được gọi lại cho nhà cung cấp theo số điện thoại đã lưu trong hợp đồng, không dùng số trong thư. Khoản thanh toán vượt một ngưỡng do công ty quy định cần hai người duyệt trên hệ thống. Nhân viên được phép từ chối yêu cầu khẩn cấp từ lãnh đạo gửi qua email nếu chưa xác minh qua kênh thứ hai, và việc từ chối đó không bị coi là sai.

Nhân viên cũng cần biết kiểm tra địa chỉ thật của người gửi thay vì chỉ nhìn tên hiển thị, đưa chuột lên liên kết để xem đích, và báo thư đáng ngờ qua nút báo cáo thay vì chỉ xoá. Doanh nghiệp nhỏ chưa có bộ phận chuyên trách có thể bắt đầu từ danh mục trong bài an ninh mạng cho doanh nghiệp nhỏ.

Lựa chọn nền tảng: dùng dịch vụ đám mây hay tự vận hành?

Với hầu hết doanh nghiệp vừa và nhỏ, dịch vụ email đám mây (Microsoft 365, Google Workspace và các dịch vụ trong nước) giúp có sẵn lọc thư, MFA, nhật ký kiểm toán và cập nhật vá lỗi do nhà cung cấp lo. Tự vận hành máy chủ mail cho bạn toàn quyền kiểm soát vị trí lưu dữ liệu, nhưng đòi hỏi người am hiểu về vá lỗi, quản lý danh tiếng IP, chống spam và sao lưu. Máy chủ mail đặt trực tiếp ra internet là mục tiêu quen thuộc của kẻ khai thác lỗ hổng; khi có lỗi chưa vá, bạn chịu rủi ro lớn như trong bài lỗ hổng zero-day.

Khi chọn nhà cung cấp, hãy hỏi cụ thể: vị trí lưu trữ dữ liệu, thời gian giữ nhật ký kiểm toán, có hỗ trợ khoá chống phishing không, cách xuất dữ liệu khi chuyển đi, và cam kết dịch vụ. Nếu người dùng bị khách hàng báo thư rơi vào spam, đừng vội đổ cho nhà cung cấp; hãy kiểm tra trước SPF, DKIM, DMARC và danh tiếng IP gửi.

Câu hỏi thường gặp

Doanh nghiệp nhỏ có cần cấu hình DMARC không?

Có. Quy định bắt buộc của Google, Yahoo, Microsoft nhắm vào bên gửi trên 5.000 thư mỗi ngày, nhưng kẻ giả mạo không quan tâm quy mô của bạn. Một bản ghi DMARC p=none kèm báo cáo cho bạn biết ai đang dùng tên miền của mình, và là bước đầu để tiến tới quarantine.

SPF và DKIM đã đạt mà thư vẫn vào thư rác, vì sao?

Xác thực chỉ là một tín hiệu. Bên nhận còn xét danh tiếng IP và tên miền, nội dung, tỷ lệ người dùng đánh dấu spam, và liên kết trong thư. Hãy kiểm tra căn chỉnh DMARC, bản ghi PTR của IP gửi và tỷ lệ khiếu nại.

p=reject có làm mất thư hợp lệ không?

Có thể, nếu còn nguồn gửi hợp lệ chưa được khai trong SPF hoặc chưa ký DKIM. Vì vậy phải đọc báo cáo ở giai đoạn p=none và tăng dần tỷ lệ ở giai đoạn quarantine trước khi chuyển sang reject.

Đã bật MFA thì có an toàn tuyệt đối không?

Không. Kẻ gian có thể dùng trang đăng nhập giả chuyển tiếp cả mã MFA theo thời gian thực, hoặc lợi dụng giao thức cũ không hỗ trợ MFA. Khoá bảo mật FIDO2 hoặc passkey và việc tắt xác thực kiểu cũ giảm đáng kể rủi ro này.

Thư giả mạo có tên giám đốc nhưng gửi từ Gmail thì DMARC có chặn được không?

Không. DMARC bảo vệ tên miền của bạn, còn địa chỉ Gmail là tên miền của Google. Trường hợp này cần cảnh báo thư ngoài, tên hiển thị trùng lãnh đạo nội bộ, và quy tắc xác minh qua kênh thứ hai.

Khi nào cần mã hoá nội dung email thay vì chỉ TLS?

Khi thư chứa thông tin cực kỳ nhạy cảm mà bạn không muốn nhà cung cấp hay máy chủ trung gian đọc được, ví dụ hợp đồng, hồ sơ nhân sự, dữ liệu tài chính chưa công bố. Với phần còn lại, TLS kết hợp MTA-STS và kiểm soát truy cập thường là đủ.