Cấu hình Email cho WordPress: Gửi thử, chuẩn hóa SPF/DKIM/DMARC và kết nối SMTP

Lưu ý về phạm vi thực nghiệm: Kết quả xác nhận nhận thư thành công trong bài viết này chỉ áp dụng đối với hộp thư cố định đã qua xác minh (verified destination). Phiên thực hành dừng lại ở ranh giới này; chưa bao gồm bước mổ xẻ chi tiết bản ghi header trong hộp thư đến, bấm nút Reply trực tiếp trong trình duyệt mail hay hoàn tất trọn vẹn chu trình đặt lại mật khẩu mới. Khi triển khai cho website thực tế, bạn vẫn cần tự mình nghiệm thu đầy đủ các mắt xích bên dưới.

Phạm vi thực hành: Ubuntu 24.04 LTS trên VPS thử nghiệm độc lập; tên miền minh họa lab-cf02.localhost.vn. Chỉ thao tác trên tài sản do bạn quản lý. Hệ thống Email Routing được thiết lập vào ngày 01/10/2026. Đến ngày 06/10/2026, nhánh gửi thư miễn phí thông qua Cloudflare Worker tới địa chỉ hộp thư đã xác minh được xác nhận vào thẳng Inbox, bao gồm cả email bắn ra từ biểu mẫu WordPress trên máy chủ LAB03. Riêng phương thức kết nối qua cổng SMTP truyền thống, đối chiếu chữ ký trong header thư nhận và thao tác đổi mật khẩu hoàn tất vẫn nằm ngoài phạm vi nghiệm thu của lab ngân sách 0 đồng.

Có một bi kịch thầm lặng diễn ra hàng ngày trên hàng ngàn website WordPress mới dựng trên VPS: khách hàng bấm gửi biểu mẫu liên hệ, màn hình hiện thông báo xanh mướt “Cảm ơn bạn, tin nhắn đã được gửi thành công!”, chủ web ngồi rung đùi chờ khách gọi chốt đơn… nhưng tuyệt nhiên không có lấy một bóng hồng nào xuất hiện trong hộp thư cả. Vì sao vậy? Bởi vì mặc định hàm wp_mail() của WordPress chỉ biết gọi chương trình gửi thư nội bộ trên máy chủ và đẩy bức thư đi tay không mà chẳng có chứng minh thư hay giấy thông hành nào cả. Trong mắt các “ông lớn” gác cổng khó tính như Gmail hay Outlook, một bức thư bắn ra từ IP VPS lạ hoắc, không có xác thực SMTP, thiếu vắng bộ ba SPF, DKIM, DMARC chẳng khác nào thư rác giả mạo, và kết cục là bị ném thẳng vào hố đen Spam hoặc bị chặn đứng ngay từ vòng gửi xe. Do đó, nguyên tắc bất di bất dịch là phải theo dõi email từ WordPress đi đến tận hộp thư người nhận. Bài viết này sử dụng hệ sinh thái Cloudflare Email Service để minh họa trực quan. Chúng tôi đã thử nghiệm thành công tuyến đường WordPress → Cloudflare Worker → Hộp thư cố định đã xác minh và được chủ hộp thư xác nhận email từ biểu mẫu đã nằm gọn trong Inbox vào ngày 06/10/2026 (lưu ý kết quả này thuộc nhánh Worker miễn phí, chưa đại diện cho cổng SMTP trả phí hay việc gửi thư tới địa chỉ khách hàng bất kỳ).

Phân biệt rạch ròi hai chiều: Nhận thư (Routing) và Gửi thư (Sending)

Khi bước vào bảng điều khiển của Cloudflare Email Service, bạn sẽ bắt gặp hai mảnh ghép mang nhiệm vụ hoàn toàn khác nhau: Email Routing chuyên lo chiều nhận và chuyển tiếp thư đến, còn Email Sending (Beta) đảm nhận chiều bắn thư giao dịch (transactional email) đi ra ngoài. Tính năng Email Routing được cung cấp miễn phí cho mọi gói tài khoản. Ngược lại, ở chiều gửi đi với Email Sending, nếu bạn muốn gửi thư tự do tới bất kỳ địa chỉ email nào của khách hàng trên Internet thì tài khoản bắt buộc phải đăng ký gói trả phí Workers Paid; còn nếu chỉ gửi thông báo về một vài địa chỉ hộp thư nội bộ đã được xác minh sẵn (verified destination) trong cùng tài khoản thì bạn được hưởng nhánh miễn phí. Việc nắm chắc ranh giới này sẽ giúp bạn không bị bất ngờ về chi phí hay quyền hạn. Đặc biệt, dịch vụ hiện đã hỗ trợ đầy đủ cả REST API, Workers binding lẫn giao thức SMTP có xác thực, vì vậy quan niệm cũ kỹ từng truyền tai nhau rằng “Cloudflare chỉ biết chuyển tiếp thư đến chứ không biết gửi thư đi” đã chính thức lỗi thời khi đối chiếu với tài liệu kỹ thuật ngày 30/09/2026 tại Cloudflare Email Service.

Để bắt đầu thử nghiệm việc gửi mail từ WordPress, bạn hoàn toàn không cần phải đập đi xây lại hay chuyển đổi hệ thống hộp thư doanh nghiệp (như Google Workspace hay Microsoft 365) đang dùng ổn định sang nhà cung cấp khác. Những gì bạn cần chuẩn bị là một tên miền hoặc tên miền phụ (subdomain) được phép cấu hình bản ghi mail, một hộp thư nhận do chính bạn nắm quyền kiểm soát, tài khoản đủ điều kiện dịch vụ và mức trần ngân sách đã thống nhất. Hãy luôn xác nhận trạng thái mở tính năng beta thực tế trên tài khoản trước khi chốt kiến trúc cho môi trường sản phẩm (production). Nếu chưa hội tụ đủ các điều kiện này, bạn chỉ nên dừng ở mức chuẩn bị sẵn bản thiết kế cấu hình chứ đừng vội đánh dấu nghiệm thu gửi thư thành công.

Sơ đồ kiến trúc phân luồng nhận và gửi thư do localhost.vn biên soạn nhằm minh họa nguyên lý kỹ thuật, không phải ảnh chụp màn hình từ môi trường lab.

Email Routing đã bật xanh, nhưng chiều nhận thư vẫn phải nghiệm thu thực tế

Trong khung giờ từ 08:35 đến 08:42 ngày 01/10/2026 (giờ Việt Nam), sau khi chủ sở hữu tên miền xác nhận đã ngưng sử dụng máy chủ mail cũ và đồng ý cho phép thay đổi bản ghi định tuyến thư (MX records), chúng tôi đã tiến hành cập nhật cấu hình DNS. Tổ hợp bản ghi mới bao gồm 3 bản ghi MX của Cloudflare, chữ ký DKIM và một bản ghi SPF hợp nhất (vẫn giữ lại các cơ chế cho phép cũ để tránh đứt gãy). Lưu ý rằng việc thay đổi bản ghi MX chỉ cần thiết khi bạn muốn đổi hướng nhận thư đến; nếu website của bạn chỉ cần thêm một kênh SMTP để gửi thông báo ra ngoài, bạn tuyệt đối không cần và không nên đụng vào bản ghi MX đang hoạt động.

Ảnh chụp giao diện thực tế lúc 08:41 ngày 01/10/2026 (giờ Việt Nam), giữ nguyên độ phân giải pixel vùng chụp kèm logo ở chân ảnh. Dù trạng thái Routing đã báo Enabled xanh mượt nhưng khu vực thống kê lưu lượng vẫn báo No data available; bức ảnh này chỉ xác nhận cấu hình đã bật chứ chưa chứng minh thư đã chuyển phát thành công. Bấm vào ảnh để xem kích thước đầy đủ.

Địa chỉ hộp thư đích nhận chuyển tiếp do chủ sở hữu cấp riêng cho mục đích thử nghiệm nên được bảo mật danh tính. Có một cái bẫy rất thú vị mà nhiều anh em hay mắc phải khi test chuyển tiếp thư: lấy luôn hộp thư Gmail cá nhân `A@gmail.com` gửi một bức thư vào địa chỉ alias `info@tenmien.com` (vốn đang cấu hình chuyển tiếp ngược về chính `A@gmail.com`), rồi ngồi đợi mãi không thấy thư đến đâu cả! Tài liệu chính thức của Cloudflare đã cảnh báo rất rõ: bạn phải dùng một tài khoản gửi hoàn toàn khác với địa chỉ hộp thư đích, bởi các nhà cung cấp dịch vụ hộp thư (như Gmail) thường tự động nhận diện bức thư vừa đi một vòng quay về chính chủ là thư lặp (loop/self-send) và âm thầm ẩn nó khỏi mục Inbox mà không báo lỗi. Dù nhật ký hệ thống (Activity log) trên Cloudflare sau đó đã nhảy sang trạng thái Forwarded — xác nhận Cloudflare đã làm tròn vai trò người đưa thư trung gian — chúng ta vẫn cần dùng một tài khoản người gửi độc lập để nghiệm thu trọn vẹn từ đầu tới cuối. Xem thêm tại Cloudflare: Route emails (đối chiếu ngày 01/10/2026).

Ảnh chụp màn hình Overview thực tế lúc 08:48:37 ngày 01/10/2026 (giờ Việt Nam): bộ đếm ghi nhận Total received 1, Delivered/Forwarded 1 và trạng thái Routing Enabled. Đây là số liệu ghi nhận tại trạm trung chuyển Cloudflare, chưa thay thế cho việc mở trực tiếp hộp thư đích để đọc nội dung và kiểm tra header. Ảnh đã được cắt bỏ vùng thông tin cá nhân nhạy cảm và giữ nguyên pixel gốc.

Đúng 08:44 cùng ngày, khi chuyển sang tab Email Sending, giao diện quản trị hiển thị thông báo yêu cầu gói cước Workers Paid kèm nút bấm Purchase Workers Paid. Do tài khoản thực hành tuân thủ kỷ luật ngân sách 0 đồng (chỉ sử dụng gói Cloudflare Free), chúng tôi không thực hiện nâng cấp gói trả phí hay khởi tạo thông tin đăng nhập SMTP (credentials/token). Tuy nhiên, đừng nhìn thông báo đòi nâng cấp gói ở màn hình đó mà vội kết luận mọi ngả đường gửi thư qua Cloudflare đều tốn tiền. Tại thời điểm ngày 01/10, biểu mẫu liên hệ, luồng khôi phục mật khẩu và bản ghi xác thực trong header thư nhận vẫn chưa được nghiệm thu. Bước đột phá sử dụng nhánh gửi miễn phí qua Worker vào ngày 06/10 sẽ được trình bày chi tiết ngay phần tiếp theo.

Khai thác nhánh gửi thư miễn phí tới hộp thư đích đã xác minh (Verified Destination)

Khi tra cứu kỹ tài liệu chính sách giá vào ngày 02/10/2026, có một chi tiết cực kỳ đáng giá dành cho dân kỹ thuật: việc gửi thư thông qua Worker tới các địa chỉ đích đã xác minh (verified destination addresses) được miễn phí hoàn toàn trên mọi gói cước, kể cả khi tài khoản của bạn chỉ đang dùng gói Free với Email Routing! Tính năng này cực kỳ lý tưởng để website WordPress bắn thông báo quản trị (như báo có khách điền form liên hệ, cảnh báo hệ thống) về thẳng hộp thư cố định của người quản lý mà không tốn một xu. Tất nhiên, bạn cần tỉnh táo: nhánh miễn phí này không cho phép bạn gửi thư tự do (như email xác nhận đơn hàng hay link đặt lại mật khẩu) tới địa chỉ email bất kỳ của khách vãng lai. Tham khảo chi tiết tại Chính sách giá và phạm vi miễn phí của Cloudflare Email Service.

Ảnh chụp tài liệu công khai của Cloudflare ngày 02/10/2026 (bản tài liệu cập nhật ngày 09/06/2026). Bí quyết nằm ở dòng ghi chú ngoại lệ dành cho verified destination ngay phía trên bảng so sánh, giúp bạn hiểu vì sao dòng Outbound bên dưới ghi Not available nhưng vẫn gửi về hộp thư quản trị miễn phí được. Ảnh chỉ đóng vai trò dẫn chứng tài liệu, không phải ảnh chụp kết quả gửi mail.

Để khóa chặt phạm vi gửi về đúng một hộp thư cố định đã xác minh, đoạn mã Cloudflare Worker sẽ sử dụng cấu hình kết nối (binding) kiểu send_email đi kèm thuộc tính destination_address. Địa chỉ người gửi (From) bắt buộc phải thuộc tên miền đã hoàn tất thủ tục khai báo (onboard) trên hệ thống. Nhờ vậy, bạn vừa giữ nguyên được gói Free 0 đồng, vừa kiểm soát chặt chẽ danh sách người nhận và hạn mức thực thi trước khi bắt cầu nối từ WordPress sang. Xem hướng dẫn kỹ thuật tại Cấu hình Send Email Bindings cho Cloudflare Workers.

Ảnh chụp tài liệu kỹ thuật công khai cùng ngày 02/10/2026, chỉ rõ cơ chế dùng thuộc tính destination_address để khóa cứng một địa chỉ nhận cố định trong cấu hình binding. Trong ảnh hoàn toàn không chứa khóa bí mật hay địa chỉ hộp thư thực tế.

Cập nhật kết quả thực nghiệm ngày 06/10/2026: Quyền kết nối binding mang tên LAB_EMAIL đã chính thức được cấp cho Worker thử nghiệm. Cả bức thư thăm dò (probe) lẫn bức thư bắn ra từ biểu mẫu WordPress mang mã định danh LAB03-FORM-20261006-R2 đều đã được chủ sở hữu hộp thư xác nhận nằm gọn gàng trong mục Inbox! Lưu ý rằng việc đối chiếu chi tiết chữ ký SPF/DKIM/DMARC trong phần nguyên gốc của bức thư và thao tác bấm link hoàn tất đặt lại mật khẩu vẫn chưa được thực hiện trong phiên này. Ngoài ra, cơ chế Worker binding hoạt động qua giao thức HTTP nội bộ chứ không sinh ra bộ thông số Host / Username / Password để bạn điền vào các plugin SMTP truyền thống. Do đó, phần hướng dẫn cấu hình SMTP ở nửa sau bài viết đóng vai trò tài liệu tham khảo chuẩn mực cho những dự án có ngân sách trả phí, còn bản thân môi trường lab 0 đồng không bật cổng SMTP này.

Bắc cầu từ WordPress qua Cloudflare Worker: Kết quả thực tế ngày 06/10/2026

Bài kiểm tra thực địa ngày 06/10/2026 được tiến hành trên một bản clone WordPress độc lập tại máy chủ LAB03, truy cập qua đường dẫn HTTPS lab-net03.localhost.vn/kiem-email-lab03/. Thay vì dùng plugin cồng kềnh, biểu mẫu trên trang sử dụng một shortcode gọn nhẹ tự viết gọi trực tiếp vào hàm lõi wp_mail() của WordPress. Một MU-plugin (Must-Use plugin) đóng vai trò cầu nối sẽ đón lõng các lệnh gọi gửi thư hợp lệ và chuyển phát qua kết nối HTTPS sang Cloudflare Worker; tại đó Worker gọi tiếp binding LAB_EMAIL để đẩy thư về địa chỉ người nhận cố định được cất giữ an toàn trong biến bí mật (secret). Toàn bộ luồng chạy mượt mà không cần tới mật khẩu SMTP, không tốn phí nâng cấp gói và không làm xáo trộn bất kỳ bản ghi DNS email nào đang vận hành.

Để đảm bảo an ninh tuyệt đối cho môi trường thử nghiệm, Worker được lập trình chỉ chấp nhận yêu cầu gửi tới từ đúng địa chỉ IP của máy chủ LAB03, khống chế chặt chẽ chủng loại thư và dung lượng nội dung, đồng thời cài đặt bộ đếm thời gian tự động vô hiệu hóa vào lúc 13:20 ngày 06/10/2026 (giờ Việt Nam). Đặc biệt, địa chỉ email do khách gõ vào ô biểu mẫu trên web tuyệt đối không được dùng để quyết định người nhận thư (tránh biến form thành công cụ phát tán spam). Khi áp dụng mô hình cầu nối Worker này vào dự án thực tế của riêng mình, bạn nhớ thiết kế cơ chế xác thực token, giới hạn tần suất gửi (rate limiting) và hệ thống ghi nhật ký lỗi tương xứng.

Một kinh nghiệm thiết kế giao diện rất đáng lưu tâm: sau khi người dùng bấm gửi biểu mẫu, thông báo trên màn hình chỉ ghi chuẩn xác rằng “Dịch vụ gửi đã tiếp nhận yêu cầu, vui lòng kiểm tra hộp thư” — tuyệt đối tránh thói quen xấu là hễ thấy API trả về mã HTTP 202 đã vội tuyên bố chắc nịch “Thư đã tới tay người nhận”. Chỉ đến khi chủ hộp thư mở màn hình xác nhận thấy bức thư nằm trong mục Inbox thì bằng chứng chuyển phát thành công mới thực sự hoàn tất. Đối với trường Reply-To, mã nguồn Worker đã được tinh chỉnh để bảo toàn địa chỉ người gửi giả lập submitter@example.invalid phục vụ mục đích đối chiếu (với đuôi tên miền .invalid chuẩn RFC để đảm bảo không bao giờ phát sinh thư trả lời nhầm ra ngoài Internet).

Lưu ý thêm rằng các bức ảnh chụp tài liệu và màn hình Email Routing trong bài viết được ghi nhận từ ngày 01–02/10/2026, không phải là ảnh chụp hộp thư Inbox của phiên gửi ngày 06/10. Ngay sau khi khép lại bài thực nghiệm ngày 06/10, chúng tôi đã tháo gỡ sạch sẽ MU-plugin cầu nối, trang thử nghiệm cùng tài khoản user tạm; khôi phục cấu hình WordPress/NGINX về nguyên trạng và xóa bỏ hoàn toàn Worker cùng biến secret thử nghiệm, đồng thời giữ nguyên vẹn các bản ghi DNS MX/SPF/DKIM đang vận hành của tên miền chính.

Bước 1: Khảo sát kỹ hiện trạng các bản ghi DNS Mail trước khi đụng tay

Trước khi cấu hình thêm bất kỳ dịch vụ gửi thư nào cho tên miền, việc đầu tiên của một kỹ sư cẩn trọng là xuất và lưu trữ toàn bộ các bản ghi MX, SPF (TXT), DKIM và DMARC hiện hành. Hãy nhớ quy tắc sống còn: nếu tên miền của công ty đang nhận email hàng ngày qua Google Workspace, Microsoft 365 hay Zoho Mail, bạn phải giữ nguyên vẹn các bản ghi MX đó! Việc lắp thêm một ống dẫn để website WordPress gửi thông báo ra ngoài hoàn toàn độc lập với đường nhận thư đến, đừng bao giờ nghe theo các hướng dẫn mù mờ mà xóa mất bản ghi MX đang chạy.

Trong bảng điều khiển Cloudflare, bạn truy cập vào mục Email Service → Email Sending và thực hiện quy trình khai báo tên miền (onboarding domain). Khi hệ thống liệt kê danh sách các bản ghi DNS dự kiến sẽ thêm vào, hãy đọc chậm rãi từng dòng, đối chiếu tên miền và đánh giá xem nó có xung đột với bản ghi hiện có hay không trước khi bấm nút xác nhận. Dịch vụ Email Sending sử dụng các bản ghi xử lý thư trả về (bounce) và xác thực chữ ký riêng biệt; hãy luôn sử dụng bộ khóa công khai (public key) sinh ra từ chính tài khoản của bạn chứ đừng bao giờ copy-paste chuỗi DKIM từ một bài viết hướng dẫn trên mạng. Xem chi tiết tại Hướng dẫn kích hoạt Cloudflare Email Sending.

Tiếp theo, hãy quy hoạch rõ địa chỉ người gửi (From) thuộc tên miền vừa khai báo (ví dụ no-reply@tenmien.com hoặc thongbao@tenmien.com) cùng địa chỉ hộp thư nhận dùng để kiểm thử. Hãy nhớ rằng địa chỉ From về bản chất chỉ là một danh tính khai báo khi gửi thư đi; việc bật tính năng Sending không tự động biến địa chỉ đó thành một hộp thư đến có khả năng nhận thư. Nếu bạn muốn khách hàng bấm Reply mà thư quay về được, bạn bắt buộc phải cấu hình thêm Email Routing, tạo hộp thư thực sự hoặc gắn một địa chỉ Reply-To đang hoạt động.

Bước 2: Nắm vững bản chất bộ ba hộ chiếu SPF, DKIM và DMARC

Nhiều anh em nghe tới SPF, DKIM và DMARC là thấy đau đầu vì toàn chữ viết tắt, nhưng nếu hình dung theo đời thực thì cơ chế của chúng vô cùng thú vị và logic:

• SPF (Sender Policy Framework): Đóng vai trò như một “danh sách bảo vệ trực cổng” công bố công khai trên DNS, liệt kê rõ những địa chỉ IP hoặc máy chủ nào được phép gửi thư nhân danh tên miền của bạn (dựa trên danh tính phong bì thư Return-Path / Mail From).
• DKIM (DomainKeys Identified Mail): Giống như một “con dấu sáp niêm phong kỹ thuật số”. Máy chủ gửi dùng khóa bí mật (private key) đóng dấu vào bức thư; máy chủ nhận sẽ tra cứu khóa công khai (public key) trên DNS của bạn để kiểm chứng xem bức thư có đúng chính chủ ký và nội dung có bị ai tráo đổi dọc đường hay không.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Là “vị thẩm phán tối cao” đứng ra đối chiếu xem tên miền đã vượt qua bài kiểm tra SPF và/hoặc DKIM có khớp (alignment) với tên miền hiển thị ở dòng From: mà người đọc nhìn thấy bằng mắt thường hay không, đồng thời chỉ đạo cho máy chủ nhận biết phải xử lý thế nào (cho qua, ném vào Spam hay từ chối thẳng thừng) nếu phát hiện kẻ mạo danh. Theo đặc tả kỹ thuật, để vượt qua ải DMARC, bức thư cần đạt ít nhất một trong hai cơ chế (SPF hoặc DKIM) kèm theo điều kiện khớp tên miền (alignment), chứ không bắt buộc cả hai phải cùng pass một lúc. Xem chuẩn quốc tế tại RFC 7489 (DMARC) — Mục 3.1.

Một lỗi sơ đẳng nhưng cực kỳ phổ biến khi cấu hình DNS là tạo hai bản ghi TXT SPF cùng tên cho một tên miền khi dùng nhiều dịch vụ gửi mail khác nhau — làm vậy sẽ khiến cả hai bản ghi SPF bị vô hiệu hóa ngay lập tức (lỗi PermError). Thay vào đó, bạn phải gộp tất cả các nguồn gửi hợp lệ (ví dụ cả Google Workspace lẫn Cloudflare) vào chung trong một dòng bản ghi SPF duy nhất. Đối với chính sách DMARC, khi mới bắt đầu bạn nên để mức giám sát nhẹ nhàng (p=none) để theo dõi và rà soát hết các nguồn gửi hợp lệ của doanh nghiệp rồi mới nâng dần lên mức cách ly (quarantine) hoặc từ chối (reject). Ngược lại, nếu tên miền đang chạy thực tế đã có sẵn chính sách DMARC nghiêm ngặt, tuyệt đối đừng hạ thấp mức bảo vệ của hệ thống chỉ để làm bài tập thử nghiệm. Tìm hiểu thêm tại Tổng quan về xác thực Email trên Cloudflare.

Sau khi bức thư thử nghiệm đã hạ cánh xuống hộp thư nhận, bạn đừng chỉ đọc nội dung bên ngoài mà hãy bấm mở chế độ “Xem thư gốc” (Show original / View message source) để kiểm tra tận mắt ba dòng trạng thái SPF: PASS, DKIM: PASS và DMARC: PASS cũng như đối chiếu tên miền ký xác thực. Hãy luôn nhớ: việc khai báo đúng bản ghi trên DNS mới chỉ là điều kiện cần ở vạch xuất phát, còn kết quả chấm điểm trong header của bức thư thực tế mới là điều kiện đủ.

Bước 3: Thông số kết nối cổng SMTP của Cloudflare (Tài liệu tham khảo ngoài phạm vi Lab 0đ)

Đối với các dự án thương mại sử dụng gói trả phí có bật đầy đủ tính năng Email Sending, Cloudflare cung cấp bộ thông số kết nối giao thức SMTP chuẩn mực như bảng dưới đây:

Khi cấu hình kết nối SMTP này, bạn cần ghi nhớ ba điểm đặc thù: thứ nhất, tài khoản phải được kích hoạt dịch vụ Sending và tên miền gửi phải hoàn tất onboarding; thứ hai, tên đăng nhập luôn là chuỗi chữ api_token cố định kèm mật khẩu là mã API Token chuyên dụng (tuyệt đối không điền email và mật khẩu đăng nhập tài khoản Cloudflare của bạn vào đây!); và thứ ba, máy chủ này chỉ làm việc qua cổng 465 với Implicit TLS chứ không sử dụng cổng 587 (STARTTLS). Vì một mã API Token có thể nắm quyền gửi thư cho nhiều tên miền nằm trong phạm vi tài khoản được cấp phép, bạn hãy giới hạn quyền hạn (scope) của token chặt chẽ nhất có thể trước khi gắn vào website. Xem tài liệu gốc tại Cấu hình gửi thư qua Cloudflare SMTP.

Về mặt bảo mật vận hành, hãy cất giữ chuỗi API Token trong kho lưu trữ bí mật hoặc khai báo qua hằng số trong file cấu hình trên máy chủ theo hướng dẫn của plugin, tuyệt đối không để lộ token trong ảnh chụp màn hình hay gõ trực tiếp trên dòng lệnh shell (vì sẽ lưu lại trong .bash_history). Nếu nghi ngờ lộ khóa, hãy thu hồi (revoke) ngay lập tức và xoay vòng tạo khóa mới. Trong hồ sơ bàn giao hệ thống, chỉ ghi chép tên quyền hạn, ngày khởi tạo và người chịu trách nhiệm quản lý chứ không bao giờ chép chuỗi giá trị token vào tài liệu chung.

Sơ đồ tóm tắt thông số kết nối Cloudflare SMTP do localhost.vn biên soạn để minh họa tài liệu, không phải ảnh chụp từ môi trường lab.

Bước 4: Kết nối WordPress với máy chủ gửi thư thông qua Plugin SMTP

Để thay thế hàm gọi mail mặc định mong manh của PHP bằng kết nối SMTP đàng hoàng, lựa chọn phổ biến và quen thuộc nhất trong cộng đồng là plugin WP Mail SMTP với chế độ Other SMTP. Sau khi cài đặt plugin từ kho chính thức của WordPress.org theo quy chuẩn ở bài 41, bạn mở phần Settings của plugin. Tại đây, hãy khai báo địa chỉ From Email thuộc đúng tên miền đã xác thực cùng From Name rõ ràng để người nhận dễ dàng nhận diện thương hiệu. Bạn có thể bật tùy chọn Force From Email để ép toàn bộ các plugin khác trên website (như WooCommerce, form liên hệ) phải dùng chung một danh tính người gửi hợp lệ này, trong khi vẫn giữ nguyên địa chỉ Reply-To linh hoạt theo từng biểu mẫu.

Tiếp theo, bạn điền lần lượt các thông số máy chủ theo bảng ở Bước 3. Có một chi tiết giao diện rất dễ gây hiểu lầm: nhiều plugin SMTP trên WordPress (bao gồm cả WP Mail SMTP) vẫn gắn nhãn tùy chọn mã hóa ở cổng 465 là “SSL” thay vì ghi chuẩn thuật ngữ hiện đại là Implicit TLS / SMTPS. Khi gặp giao diện như vậy, bạn cứ yên tâm tích chọn mục “SSL” đi kèm cổng 465, bật công tắc Authentication, điền Username là api_token và dán mã API Token vào ô Password. Cái nhãn “SSL” trên giao diện plugin thực chất vẫn thiết lập kết nối TLS hiện đại chứ không phải bắt máy chủ dùng lại giao thức SSLv3 cổ lỗ sĩ đâu nhé. Xem hướng dẫn từng bước của nhà phát triển tại Hướng dẫn cấu hình Other SMTP trong WP Mail SMTP.

Hãy tuân thủ nguyên tắc “một núi không thể có hai hổ”: tại một thời điểm, chỉ để duy nhất một plugin hoặc một MU-plugin nắm quyền điều phối hàm wp_mail(). Ngoài ra, hãy nhớ rằng nếu bạn nhập trực tiếp mật khẩu SMTP trên giao diện web của plugin, chuỗi mật khẩu đó sẽ nằm trong bảng wp_options của cơ sở dữ liệu — nghĩa là bất kỳ ai cầm được file backup SQL cũng sẽ thấy luôn chìa khóa gửi thư của bạn. Vì vậy, cách làm chuyên nghiệp nhất là khai báo thông tin nhạy cảm qua các hằng số (constants) trong file wp-config.php nằm trên máy chủ.

Bước 5: Gửi thư thử nghiệm có kiểm soát và đối chiếu “Tam giác bằng chứng”

Khi mọi thiết lập đã vào khuôn khổ, bạn hãy mở công cụ Email Test để bắn thử đúng một bức thư về địa chỉ hộp thư mà bạn đang mở sẵn. Bí quyết của dân chuyên nghiệp là luôn gắn kèm một mã định danh duy nhất cùng mốc thời gian vào tiêu đề hoặc nội dung (ví dụ: [LAB-TEST-20261006-1015] Thư kiểm tra kết nối), đồng thời tuyệt đối không lấy email của khách hàng thật ra làm chuột bạch. Hãy kiên nhẫn theo dõi trọn vẹn đường đi của một bức thư duy nhất trước khi bấm gửi thêm, tránh việc bắn liên thanh chục bức thư cùng lúc khiến việc tra cứu nhật ký trở thành mớ bòng bong.

Một quy trình nghiệm thu chuẩn mực bắt buộc phải khớp đủ ba đỉnh của tam giác bằng chứng:

1. Đỉnh 1 (Tại ứng dụng WordPress): Hàm gửi thư xử lý yêu cầu trơn tru không văng lỗi (lưu ý: giá trị trả về true của hàm wp_mail() chỉ có nghĩa là hàm đã bàn giao yêu cầu xong ở tầng ứng dụng, hoàn toàn không đảm bảo bức thư đã bay tới hộp thư người nhận! Xem tài liệu gốc tại WordPress Code Reference: wp_mail()).
2. Đỉnh 2 (Tại trạm trung chuyển / Dịch vụ gửi): Hệ thống gửi thư (Cloudflare Worker / SMTP Server) ghi nhận mã trạng thái tiếp nhận thành công (như HTTP 202 hoặc Message ID trong nhật ký).
3. Đỉnh 3 (Tại hộp thư người nhận cuối): Bức thư thực sự xuất hiện trong mục Inbox, hiển thị đúng nội dung tiếng Việt có dấu và khi mở xem phần header gốc thì các chỉ số xác thực SPF/DKIM/DMARC đều đạt chuẩn.

Khi chụp ảnh hoặc lưu trữ phần header của bức thư để làm báo cáo nghiệm thu, hãy chú ý che mờ các địa chỉ IP nội bộ hoặc địa chỉ hộp thư cá nhân không cần thiết. Và sau khi bức thư thử nghiệm đơn lẻ đã qua ải, hãy tiếp tục thử nghiệm riêng biệt luồng bấm “Quên mật khẩu” của một tài khoản thử nghiệm cấp thấp cùng luồng gửi biểu mẫu liên hệ ngoài trang chủ — bởi mỗi tính năng này trên WordPress có thể đi qua những bộ lọc (hooks/filters) tạo tiêu đề và người gửi rất khác nhau.

Sơ đồ tam giác ba điểm nghiệm thu gửi email do localhost.vn biên soạn nhằm tóm tắt quy trình kiểm chứng, không phải ảnh chụp kết quả từ môi trường lab.

Xử lý sự cố khi thư “mất tích” và quy trình khôi phục (Rollback) an toàn

Nếu bấm gửi thử mà chờ đỏ mắt vẫn không thấy thư đâu, bạn hãy bình tĩnh lần theo dấu vết từng chặng:

• Lỗi kết nối quá thời gian (SMTP Connection Timeout): Hãy kiểm tra xem tường lửa chiều ra (outbound/egress) trên VPS hoặc chính sách của nhà cung cấp máy chủ đám mây có đang chặn kết nối đi ra cổng 465 (hoặc 587) hay không. Lưu ý một nhầm lẫn kinh điển: khi WordPress gửi thư đi qua SMTP bên ngoài, VPS của bạn đóng vai trò là máy khách (client) gọi đi ra, vì vậy bạn không cần và không được mở cổng 465 chiều vào (inbound) trên tường lửa UFW của VPS!
• Lỗi xác thực (Authentication Failed): Rà soát lại chuỗi Username (đã gõ đúng chữ api_token chưa?), quyền hạn của API Token và trạng thái kích hoạt dịch vụ trên tài khoản.
• Lỗi từ chối người gửi (Sender Rejected): Kiểm tra xem tên miền ở địa chỉ From đã hoàn tất thủ tục onboarding và xác thực DNS trên dịch vụ gửi thư hay chưa.
• Dịch vụ báo đã gửi nhưng hộp thư trống trơn: Hãy kiểm tra danh sách thư bị trả lại (bounce list), danh sách chặn (suppression list), lục tìm trong hòm thư Rác (Spam/Junk) của người nhận và đối chiếu cấu hình SPF/DMARC.

Trong trường hợp cần khôi phục (rollback) về cấu hình gửi thư cũ trước khi thay đổi, hãy nạp lại thiết lập đã sao lưu và thực hiện gửi một bức thư thực tế để xác nhận hệ thống cũ hoạt động trở lại. Tuyệt đối đừng chỉ gỡ plugin SMTP ra để mặc cho hệ thống rơi về hàm PHP mail mặc định rồi tự huyễn hoặc rằng mình đã “khôi phục thành công” trong khi chẳng có bức thư nào tới được tay người nhận. Cuối cùng, đừng quên thu hồi các khóa API Token thử nghiệm khi không còn sử dụng và chỉ xóa đúng những bản ghi DNS thử nghiệm đã ghi chép, bảo toàn tuyệt đối các bản ghi MX/SPF/DKIM đang phục vụ hoạt động kinh doanh.

Câu hỏi thường gặp 1: Cứ cấu hình SPF, DKIM và DMARC báo PASS xanh lét là 100% thư sẽ vào thẳng Inbox chứ không bao giờ rơi vào Spam đúng không?
Rất tiếc là Không! Bộ ba SPF/DKIM/DMARC giống như tấm căn cước công dân chứng minh bạn là người thật chứ không phải kẻ giả mạo. Nhưng việc bức thư của bạn được mời vào phòng khách (Inbox) hay bị tống xuống nhà kho (Spam) còn phụ thuộc vào “nhân phẩm” (uy tín tên miền và IP gửi), nội dung bức thư có chứa từ ngữ nhạy cảm kiểu quảng cáo quá đà không, tần suất gửi có đột biến không và cách người nhận tương tác với thư của bạn trước đó.

Câu hỏi thường gặp 2: Dùng Cloudflare Email Routing miễn phí có thay thế hoàn toàn được một dịch vụ hộp thư doanh nghiệp (như Google Workspace) không?
Bạn cần tách bạch rõ ba nhu cầu: (1) chuyển tiếp thư gửi đến về hộp thư cá nhân, (2) lưu trữ và quản lý hộp thư độc lập để nhân viên đăng nhập soạn thư trả lời hàng ngày, và (3) bắn thư giao dịch tự động từ website. Email Routing giải quyết cực tốt bài toán số (1), kết hợp với Worker/Sending giải quyết bài toán số (3), nhưng nếu doanh nghiệp cần một không gian hộp thư độc lập đầy đủ tính năng cho nhân sự làm việc thì vẫn nên trang bị dịch vụ mailbox chuyên dụng.

Tổng kết giới hạn thực nghiệm: Trong phạm vi bài viết này, luồng gửi thư từ WordPress qua Cloudflare Worker về hộp thư cố định đã xác minh (cùng bài gửi từ biểu mẫu LAB03) đã được chủ hộp thư xác nhận vào thẳng Inbox. Chiều nhận thư qua Email Routing vào ngày 01/10 mới dừng ở trạng thái log Forwarded tại Cloudflare (không lấy kết quả gửi ra của ngày 06/10 để kết luận bắc cầu cho chiều nhận vào). Phương thức kết nối qua cổng SMTP trả phí, việc đọc chi tiết header xác thực trong hộp thư nhận và bước bấm link hoàn tất đổi mật khẩu mới vẫn chưa được nghiệm thu trong lab 0 đồng. Trước khi áp dụng cho website sản phẩm, hãy luôn kiểm chứng quyền hạn, chi phí và nhận thư thực tế trên chính tài khoản của bạn.

Tài liệu tham khảo chính thức và hành trình tiếp theo

Các nguồn tài liệu kỹ thuật chính thống đã đối chiếu ngày 30/09/2026: Cloudflare Email Service Overview, Cloudflare SMTP Configuration, Cloudflare Email Authentication (SPF/DKIM/DMARC), WP Mail SMTP: Other SMTP Mailer, và WordPress Code Reference: wp_mail(). Toàn bộ các tình huống thực nghiệm và bảng ghi nhận kết quả trong bài được biên soạn độc lập phục vụ chuỗi bài hướng dẫn.

Mời bạn xem lại tổng thể lộ trình cài đặt và vận hành WordPress trên VPS từ A đến Z. Bài viết trước: Chuyển WordPress sang HTTPS và xử lý triệt để lỗi Mixed Content. Bài viết tiếp theo: Kiểm thử biểu mẫu liên hệ (Form) và thông báo quản trị trước giờ mở cửa đón khách.