1) Mẫu lỗi xác thực: SPF/DKIM/DMARC sai hoặc “đúng nửa vời”

Đây là nhóm lỗi kinh điển. Nhiều hệ thống “có SPF, có DKIM” nhưng vẫn fail vì không align, hoặc record chồng chéo, hoặc thay đổi nhà cung cấp gửi mà quên cập nhật DNS. Với các nhà cung cấp mailbox lớn, xác thực yếu thường kéo theo phân loại Spam, thậm chí từ chối nhận.

Dấu hiệu thường thấy

• Email vào Spam chủ yếu ở Gmail/Yahoo/Outlook trong khi một số mailbox nhỏ vẫn nhận bình thường.
• Header hiển thị SPF=softfail/neutral hoặc DKIM=fail/intermittent.
• DMARC báo “fail” hoặc “none” kéo dài, không có báo cáo aggregate hoặc có nhưng toàn lỗi alignment.

Cách kiểm tra nhanh

• Đọc header của email test: SPF result, DKIM result, DMARC result, alignment (From domain vs d=, Return-Path).
• Kiểm tra DNS record: SPF có vượt giới hạn lookup, có record trùng, có include sai, có quên loại bỏ nhà gửi cũ.
• DKIM selector có tồn tại và đúng khóa; email có ký DKIM ổn định hay lúc được lúc không (đổi route/cluster).

Hướng xử lý

• Ưu tiên “đúng và align”: From domain phải align với DKIM d= hoặc SPF domain (Return-Path) theo chính sách DMARC.
• Giảm rủi ro: tránh SPF phức tạp quá mức, gom nhà gửi, tránh include dây chuyền.
• Nâng DMARC theo lộ trình: từ none → quarantine → reject sau khi đã ổn định và theo dõi báo cáo.

2) Mẫu lỗi danh tiếng: domain/IP mới, “ấm” chưa đủ hoặc bị dính lịch sử xấu

Deliverability chịu ảnh hưởng mạnh bởi danh tiếng. Một domain mới tinh gửi lượng lớn đột ngột rất dễ bị nghi ngờ. Ngược lại, domain/IP đã từng bị dùng sai mục đích (spam/abuse) cũng kéo theo điểm tín nhiệm thấp. Với shared IP, rủi ro còn đến từ “hàng xóm” gửi bậy.

Dấu hiệu thường thấy

• Tỷ lệ Inbox thấp ngay cả khi SPF/DKIM/DMARC đều pass.
• Một phần nhà cung cấp nhận rất chậm, hoặc báo throttling (4xx), hoặc “temp fail” liên tục.
• Chiến dịch đầu tiên hoặc sau thời gian dài không gửi bỗng rớt mạnh.

Cách kiểm tra nhanh

• So sánh theo mailbox provider: Gmail vs Outlook vs Yahoo vs domain công ty.
• Kiểm tra log MTA/ESP: phản hồi 4xx (tạm hoãn) hay 5xx (từ chối), mã lỗi cụ thể.
• Đối chiếu lịch gửi: có spike bất thường không, có tăng đột biến sau khi import list không.

Hướng xử lý

• Warm-up có chiến lược: tăng lưu lượng theo bậc thang, ưu tiên gửi người có tương tác tốt.
• Tách luồng: transactional/OTP nên tách khỏi marketing để tránh “lây” danh tiếng xấu.
• Hạn chế shared IP nếu bạn không kiểm soát được chất lượng hệ sinh thái gửi chung.

3) Mẫu lỗi hạ tầng: rDNS/PTR, HELO, TLS và cấu hình máy chủ gửi không “đáng tin”

Một email có thể pass xác thực nhưng vẫn bị đánh giá thấp nếu hạ tầng gửi trông “lỏng lẻo”: thiếu rDNS/PTR, HELO không nhất quán, reverse không khớp, hoặc TLS cấu hình kém. Với hệ thống tự vận hành (self-hosted), nhóm lỗi này xuất hiện rất thường xuyên.

Dấu hiệu thường thấy

• Outbound SMTP bị từ chối bởi một số tổ chức lớn hoặc mail gateway doanh nghiệp.
• Log trả về lỗi liên quan đến reverse DNS, HELO/EHLO hoặc policy yêu cầu TLS.
• Email đến được nhưng bị chấm điểm thấp, hay bị “quarantine” ở tầng gateway.

Hướng xử lý

• Thiết lập rDNS/PTR cho IP gửi, đồng nhất với hostname máy chủ.
• HELO/EHLO nên là hostname hợp lệ, có forward DNS trỏ đúng IP.
• Luôn bật TLS và ưu tiên cấu hình hiện đại; nếu có thể, bật thêm các chính sách bảo mật miền khi phù hợp.

4) Mẫu lỗi nội dung: từ khóa nhạy, cấu trúc “giống spam”, và tỷ lệ HTML/Text thiếu cân bằng

Bộ lọc nội dung ngày nay không chỉ dựa vào “từ khóa cấm”, mà còn dựa vào pattern: cách bố trí, tỷ lệ hình ảnh, số lượng link, tracking quá dày, câu chữ mang tính thúc ép, và cả sự bất nhất giữa subject/preview/body. Nhiều đội test thấy “gửi được” nhưng không hiểu vì sao inbox lại thấp; nguyên nhân nằm ở đây.

Dấu hiệu thường thấy

• Inbox một số người, spam một số người dù gửi cùng một nội dung.
• Email có nhiều link rút gọn, nhiều redirect, hoặc link đến domain mới/ít uy tín.
• Subject kiểu “khẩn cấp”, “miễn phí”, “giảm sốc”, “click ngay” lặp lại theo chiến dịch.

Cách kiểm tra nhanh

• So sánh A/B: cùng danh sách, thay subject + giảm link + giảm tracking xem cải thiện không.
• Đảm bảo có phiên bản text/plain hợp lý, không phải text trống hoặc chỉ vài ký tự.
• Kiểm tra URL: domain đích có uy tín không, có bị chặn bởi bộ lọc doanh nghiệp không.

Hướng xử lý

• Viết nội dung “giống người thật”: rõ ràng, không giật tít quá, giảm spammy CTA.
• Tối giản link: ưu tiên ít link nhưng rõ ràng; hạn chế link rút gọn trong email marketing.
• Giữ cấu trúc sạch: header hợp lý, bố cục đọc được trên mobile, tránh nhồi hình ảnh.

Mẹo thực tế: Khi nghi ngờ nội dung gây spam, hãy gửi một bản “siêu tối giản” (chỉ text, 1 link, không banner). Nếu Inbox tăng rõ, bạn đã khoanh vùng đúng lớp vấn đề.

5) Mẫu lỗi HTML/CSS: lỗi markup, tracking pixel lỗi, hoặc template bị “vỡ” trong client

Nhiều email template dùng HTML giống web, nhưng email client không phải trình duyệt đầy đủ. CSS support hạn chế, cách xử lý bảng/inline style khác nhau, và chỉ cần một lỗi đóng tag cũng có thể làm email hiển thị kỳ quặc, kích hoạt bộ lọc hoặc khiến người dùng xóa ngay.

Dấu hiệu thường thấy

• Email hiển thị tốt trên webmail nhưng lỗi trên Outlook desktop hoặc app iOS/Android.
• Nội dung bị cắt, button biến mất, font/spacing loạn, hình không tải.
• Tracking mở mail sai lệch vì pixel bị chặn hoặc lỗi tải tài nguyên.

Hướng xử lý

• Ưu tiên email HTML “chuẩn email”: inline CSS, cấu trúc đơn giản, hạn chế script và CSS hiện đại.
• Luôn test đa client: Gmail web/app, Outlook web/desktop, Apple Mail, Yahoo…
• Ảnh nên có alt text, kích thước hợp lý; đừng phụ thuộc 100% vào ảnh để truyền tải nội dung.

6) Mẫu lỗi URL & tracking: domain theo dõi bị đánh giá xấu, redirect chuỗi dài

Nhiều hệ thống marketing thêm tracking vào mọi link. Nếu tracking domain bị đánh giá kém, hoặc redirect quá nhiều bước, email có thể bị “đánh tụt” dù nội dung sạch. Đây là lỗi khó thấy vì team thường chỉ nhìn nội dung, không nhìn đường đi của URL.

Dấu hiệu thường thấy

• Email chứa nhiều link, đặc biệt là link redirect qua nhiều miền trung gian.
• Cùng một nội dung, khi bỏ tracking thì Inbox tăng.
• Gateway doanh nghiệp chặn click, người dùng báo “link không mở được”.

Hướng xử lý

• Giảm số lượng link và giảm độ phức tạp của redirect.
• Dùng tracking domain ổn định, có danh tiếng tốt, cấu hình HTTPS đúng.
• Ưu tiên link trực tiếp về domain chính, nhất là với email transactional/OTP.

7) Mẫu lỗi danh sách gửi: list bẩn, bounce cao, spam complaint tăng

Nếu bạn nhập danh sách mua sẵn, hoặc thu thập thiếu kiểm soát, hoặc không dọn dẹp bounce, deliverability sẽ “tụt” rất nhanh. Các mailbox provider đánh giá bạn không chỉ theo nội dung, mà còn theo phản ứng người nhận: mở, trả lời, chuyển tiếp, xóa, đánh dấu spam.

Dấu hiệu thường thấy

• Bounce tăng mạnh, đặc biệt là hard bounce (địa chỉ không tồn tại).
• Complaint tăng, người nhận đánh dấu spam hoặc unsub nhiều.
• Inbox giảm dần theo thời gian dù template không đổi.

Hướng xử lý

• List hygiene: loại hard bounce ngay, giảm gửi đến người không tương tác lâu ngày.
• Double opt-in khi có thể, và minh bạch tần suất gửi.
• Unsubscribe rõ ràng, “thoát” dễ; đừng cố giấu vì nó làm complaint tăng.

8) Mẫu lỗi throttling/greylisting: email không mất nhưng đến rất chậm

Có trường hợp email không rớt spam, cũng không bị reject, nhưng lại đến trễ. Với OTP/transactional, vài phút trễ là trải nghiệm thất bại. Nguyên nhân thường là throttling (nhận thư có giới hạn), greylisting (tạm hoãn để kiểm tra), hoặc bạn gửi quá nhanh trong một khoảng ngắn.

Dấu hiệu thường thấy

• Log có nhiều phản hồi 4xx “try again later” hoặc “rate limited”.
• Người dùng nhận OTP sau 2–10 phút, đôi khi nhận trùng nhiều mã vì bấm gửi lại.
• Tình trạng nặng hơn ở giờ cao điểm hoặc khi chiến dịch bắn hàng loạt.

Hướng xử lý

• Thiết kế retry thông minh: backoff, giới hạn gửi lại OTP, tránh spam resend.
• Tách luồng OTP/transactional khỏi marketing bulk để tránh queue bị nghẽn.
• Quan sát theo provider và theo thời gian: throttling thường có “nhịp” khá rõ.

9) Một quy trình test deliverability “đáng tin” (áp dụng cho QA/Marketing/DevOps)

Để tránh kiểu test cảm tính, bạn có thể đi theo trình tự sau. Mục tiêu là xác định vấn đề nằm ở lớp nào: xác thực, danh tiếng, hạ tầng, nội dung, hay danh sách.

1. Test header trước: SPF/DKIM/DMARC pass và align. Nếu fail, xử lý DNS/cấu hình gửi trước khi làm gì khác.
2. So sánh theo provider: gửi cùng nội dung đến Gmail/Outlook/Yahoo/mail doanh nghiệp để thấy pattern.
3. Giảm nội dung để khoanh vùng: thử bản text-only, ít link, không tracking; xem Inbox có tăng không.
4. Kiểm tra hạ tầng: rDNS/PTR, HELO, TLS, log 4xx/5xx, độ trễ, retry.
5. Đo list quality: bounce/complaint/unsub/engagement; dọn dẹp và phân nhóm theo tương tác.
6. Tách luồng: marketing bulk tách khỏi transactional/OTP để không ảnh hưởng lẫn nhau.

Khi bạn làm đúng quy trình, việc tối ưu deliverability sẽ giống như tinh chỉnh hệ thống: thay vì “đoán mò”, bạn sẽ có tín hiệu rõ ràng cho từng lớp vấn đề và biết phải sửa ở đâu trước.