Kiểm tra xác thực, phản hồi của nhà cung cấp hộp thư, chất lượng đối tượng và cơ chế hủy đăng ký để hiểu vì sao email bị từ chối hoặc rơi vào spam.
Gửi đến và vào hộp thư đến là hai chuyện khác nhau. Máy chủ nhận có thể tiếp nhận một email rồi đưa nó vào thư mục spam. Bảng điều khiển chiến dịch hiển thị “đã gửi đến” không chứng minh được rằng người đọc đã thấy email.
Khi có vấn đề, hãy thu thập bằng chứng trước khi sửa nội dung hay đổi nhà cung cấp. Khâu gặp lỗi có thể là xác thực, uy tín, đối tượng nhận hoặc chính email.
Với email bị từ chối hoặc bị trì hoãn, hãy xem phản hồi SMTP thực tế và mã trạng thái mở rộng (enhanced status code). Lỗi tạm thời và từ chối vĩnh viễn cần được xử lý khác nhau. Trang câu hỏi thường gặp dành cho người gửi của Google mô tả cả hai trường hợp; trang này không nói rằng mọi trường hợp không tuân thủ giờ đây đều dẫn đến lỗi vĩnh viễn.
Nếu email được tiếp nhận nhưng nằm trong spam, hãy xem kết quả xác thực trong header của email nhận được, dữ liệu uy tín từ nhà cung cấp hộp thư (nếu có), và những thay đổi gần đây về đối tượng hoặc khối lượng gửi. Một vài hộp thư thử nghiệm giúp chẩn đoán vấn đề, nhưng không đo được tỷ lệ vào hộp thư đến trên toàn bộ danh sách.
Mã trạng thái mở rộng gồm ba con số phân tách bằng dấu chấm, được định nghĩa trong RFC 3463. Số đầu tiên là nhóm lỗi. Mã bắt đầu bằng 4 là lỗi tạm thời, và máy chủ gửi nên thử lại sau. Mã bắt đầu bằng 5 là lỗi vĩnh viễn, nên gửi lại nguyên email đó cũng không giúp được gì.
Số thứ hai thu hẹp phạm vi vấn đề. Các mã trong nhóm X.1.X liên quan đến địa chỉ, và 5.1.1 thường có nghĩa là hộp thư không tồn tại. Hãy chặn gửi tới địa chỉ đó. Các mã trong nhóm X.7.X liên quan đến bảo mật hoặc chính sách, cũng là nơi các vấn đề về xác thực và uy tín thường xuất hiện.
Google liệt kê các phản hồi mà Gmail trả về trong tài liệu tham khảo về lỗi SMTP. Hãy đọc toàn bộ nội dung phản hồi chứ không chỉ mã lỗi, vì một mã có thể ứng với nhiều lý do khác nhau.
Google Postmaster Tools cho biết Gmail đánh giá tên miền gửi của bạn ra sao, bao gồm tỷ lệ spam do người dùng báo cáo mà các yêu cầu của Google nhắc đến. Bạn xác minh tên miền bằng một bản ghi DNS. Gmail chỉ hiển thị dữ liệu khi tên miền gửi đủ lượng email mỗi ngày tới người dùng Gmail, nên người gửi nhỏ có thể chỉ thấy bảng điều khiển trống.
Smart Network Data Services của Microsoft, thường gọi là SNDS, báo cáo về email từ các địa chỉ IP cụ thể gửi tới hộp thư cá nhân trên Outlook.com, bao gồm tỷ lệ khiếu nại và số lần dính bẫy spam. Bạn đăng ký những địa chỉ IP mình kiểm soát, nên công cụ này hữu ích nhất khi bạn dùng IP riêng. Nếu dùng IP chung, hãy hỏi nhà cung cấp dịch vụ gửi email xem họ theo dõi những gì.
Không công cụ nào cho bạn biết một chiến dịch cụ thể đã rơi vào đâu. Chúng cho thấy xu hướng theo ngày, đúng thứ bạn cần khi một vấn đề tích tụ dần qua nhiều lượt gửi.
SPF cấp quyền cho hạ tầng gửi email thay mặt một tên miền phong bì (envelope). DKIM ký email bằng danh tính của một tên miền. DMARC kiểm tra sự căn chỉnh (alignment) với tên miền From hiển thị, đồng thời công bố chính sách và cơ chế báo cáo. Không cơ chế nào trong số này đảm bảo email vào hộp thư đến.
Hãy dùng các bản ghi do nhà cung cấp dịch vụ gửi email cung cấp và kiểm tra kết quả trên một email thật đã nhận. Đừng thêm các bản ghi SPF xung đột nhau, cũng đừng cho rằng có bản ghi DNS là mọi đường gửi đều dùng nó đúng cách. Hạ tầng của bạn cũng cần có DNS ngược (reverse DNS) phù hợp và kênh truyền bảo mật.
Trong Brew, hãy làm theo quy trình xác minh tên miền và công bố các bản ghi được yêu cầu. Kiểm tra lại địa chỉ From mà chiến dịch hoặc tự động hóa thực tế sử dụng, nhất là khi một agent vận hành nhiều thương hiệu.
Chính sách DMARC là một bản ghi TXT tại host _dmarc của tên miền trong địa chỉ From. Hãy bắt đầu với p=none. Chính sách này yêu cầu bên nhận không áp dụng hành động cụ thể nào với thư không đạt, nhưng họ vẫn gửi báo cáo tổng hợp tới địa chỉ rua.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"Báo cáo liệt kê mọi nguồn đang gửi email dưới tên miền của bạn và cho biết từng nguồn có đạt SPF hoặc DKIM kèm căn chỉnh hay không. Bạn sẽ gặp những công cụ mình đã quên, như hệ thống thanh toán hay phần mềm hỗ trợ khách hàng. Hãy sửa hoặc loại bỏ từng nguồn không đạt.
Khi mọi email hợp lệ đều đạt, hãy chuyển sang p=quarantine. Chính sách này yêu cầu bên nhận coi thư không đạt là đáng ngờ, thường có nghĩa là đưa vào spam.
_dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"Chính sách nghiêm ngặt nhất, p=reject, yêu cầu bên nhận từ chối thư không đạt. Chỉ chuyển sang chính sách này sau khi quarantine đã chạy một thời gian mà không có email hợp lệ nào bị lỗi. Hãy tiếp tục đọc báo cáo ở mọi giai đoạn. Công cụ mới nào bắt đầu gửi email dưới tên miền của bạn sẽ xuất hiện ở đó trước tiên.
Tên miền phụ chuyên để gửi, như mail.example.com, là ngoại lệ. Khi không có gì khác gửi từ tên miền đó và nhà cung cấp của bạn đã xác minh SPF và DKIM của nó, bạn có thể bắt đầu ngay với p=reject. Brew khuyến nghị p=reject cho tên miền phụ chuyên dụng do Brew thiết lập, và p=none cho tên miền chính nơi các dịch vụ khác có thể cũng gửi email.
Hướng dẫn của Google phân biệt các yêu cầu đối với mọi người gửi với những quy định chặt chẽ hơn dành cho những người gửi đạt khoảng 5.000 email mỗi ngày tới tài khoản Gmail cá nhân. Google yêu cầu tỷ lệ spam dưới 0,1% và cảnh báo không để chạm mức 0,3%. Yêu cầu đối với người gửi hàng loạt bao gồm SPF và DKIM, DMARC, căn chỉnh và hủy đăng ký một chạm cho các email đăng ký nhận có liên quan.
Danh sách yêu cầu của Google đối với mọi người gửi, ở bất kỳ khối lượng nào, bao gồm:
Người gửi hàng loạt còn phải:
p=none.Khi áp dụng ngưỡng, Google cộng gộp email từ cùng một tên miền chính, và tên miền nào đã vượt ngưỡng một lần sẽ giữ nhãn người gửi hàng loạt. Trang câu hỏi thường gặp dành cho người gửi của Google giải thích cách tính.
Hướng dẫn của Yahoo cũng đề cập đến xác thực, khiếu nại và hủy đăng ký. Yahoo không công bố một ngưỡng số lượng tương tự cho người gửi hàng loạt; hãy tham khảo trang câu hỏi thường gặp của Yahoo thay vì áp con số của Gmail cho mọi nhà cung cấp.
Microsoft đã thông báo vào năm 2025 rằng các tên miền gửi hơn 5.000 email mỗi ngày tới hộp thư cá nhân của Microsoft, tức các địa chỉ outlook.com, hotmail.com và live.com, phải đạt SPF và DKIM và công bố DMARC. Chính sách DMARC có thể là p=none, và tên miền From phải căn chỉnh với SPF hoặc DKIM.
Hướng dẫn của các nhà cung cấp được rà soát ngày 28/9/2026. Hãy kiểm tra các trang được dẫn liên kết khi chẩn đoán một sự cố mới.
Hủy đăng ký một chạm theo RFC 8058 là một cơ chế dựa trên header và yêu cầu HTTPS POST. Liên kết hiển thị ở chân email cũng hữu ích và là yêu cầu của các quy định liên quan, nhưng chỉ có trang tùy chọn nhận email thì chưa triển khai giao thức này.
Email hỗ trợ hủy đăng ký một chạm mang hai header:
List-Unsubscribe: <https://example.com/unsubscribe/opaque-token>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickKhi người đọc nhấp hủy đăng ký ngay trong hộp thư, nhà cung cấp hộp thư sẽ gửi một yêu cầu POST tới URL HTTPS với nội dung List-Unsubscribe=One-Click. Địa chỉ mailto: là phương án thay thế cho phần mềm email không hỗ trợ hủy đăng ký một chạm. RFC 8058 cũng yêu cầu một chữ ký DKIM hợp lệ bao phủ cả hai header. Hãy tạo URL riêng cho từng người nhận và khó đoán. Trình quét bảo mật thường truy cập các liên kết trong email đến, nên một yêu cầu GET thông thường tới URL đó không được hủy đăng ký bất kỳ ai.
Brew thêm header List-Unsubscribe và List-Unsubscribe-Post vào các lượt gửi email tiếp thị, trỏ tới một URL HTTPS có chữ ký, riêng cho từng người nhận và chấp nhận yêu cầu POST một chạm.
Hãy xác nhận rằng một lượt hủy đăng ký nhận email tiếp thị sẽ chặn các lượt gửi email tiếp thị sau đó qua mọi đường gửi bạn dùng. Giữ nguyên danh sách chặn khi nhập liên hệ hoặc chuyển nền tảng. Tách riêng các email giao dịch thiết yếu cả về mục đích lẫn cấu hình gửi.
Hãy xem lại các địa chỉ đến từ đâu và người đăng ký mong đợi điều gì khi đăng ký. Loại bỏ địa chỉ không hợp lệ qua quy trình chặn gửi của nhà cung cấp, điều tra các đợt khiếu nại tăng đột biến, và tránh gửi lại cho ai đó chỉ vì dữ liệu theo dõi cho thấy họ chưa mở email.
Không có tuổi danh sách, tỷ lệ hình ảnh trên văn bản hay từ cấm nào áp dụng cho mọi trường hợp để đảm bảo email được gửi đến. Đột ngột tăng khối lượng gửi tới một danh sách bạn chưa hiểu rõ là vấn đề nghiêm trọng hơn việc dùng chữ “miễn phí”.
Nếu agent gửi chiến dịch thay bạn, các bước kiểm tra trên vẫn áp dụng. Hãy dùng dữ kiện đã xác minh, đối tượng phù hợp và một địa chỉ trả lời có người theo dõi. Khắc phục nguyên nhân đã xác định, gửi một đợt thử nghiệm có kiểm soát và xem lại phản hồi của nhà cung cấp trước khi mở rộng trở lại.
