Cách tìm lỗi khi Email Marketing không vào Inbox với quy trình kiểm tra SPF, DKIM, Reputation

Email Marketing báo gửi thành công nhưng vẫn không vào Inbox là lỗi khiến nhiều doanh nghiệp khó xác định nguyên nhân. Vấn đề có thể đến từ SPF, DKIM, DMARC, DNS, SMTP, Reputation, database hoặc cách tăng volume gửi. Nếu chỉ sửa Subject hay nội dung, doanh nghiệp rất dễ xử lý sai điểm lỗi.

Hãy cùng chuyên gia của Bizfly theo dõi các bước kiểm tra theo từng lớp để tìm đúng nguyên nhân và khắc phục hiệu quả nhanh chóng và chính xác.

Bước 1: Kiểm tra SPF, DKIM và DMARC trước tiên

Nếu Email Marketing không vào Inbox, hãy bắt đầu bằng Authentication.

SPF, DKIM và DMARC giúp Gmail, Yahoo, Outlook và các mailbox provider xác minh email có thực sự đến từ domain mà nó tuyên bố hay không.

Google hiện yêu cầu tất cả người gửi tới Gmail phải có ít nhất SPF hoặc DKIM. Với bulk sender gửi khoảng 5.000 email/ngày trở lên tới Gmail cá nhân, yêu cầu tăng lên SPF + DKIM + DMARC, đồng thời From domain phải align với SPF hoặc DKIM.

• Cách kiểm tra SPF: SPF được lưu dưới dạng TXT record trong DNS. Trên Windows, có thể mở Command Prompt và chạy:

nslookup -type=TXT yourdomain.com

Trên macOS/Linux:

dig TXT yourdomain.com

Sau đó tìm record bắt đầu bằng:

v=spf1

Ví dụ:

v=spf1 include:_spf.example.com ~all

Điều quan trọng không phải chỉ là “có SPF”, mà là hệ thống Email Marketing bạn đang dùng có nằm trong SPF record hay không.

Ví dụ doanh nghiệp gửi bằng một ESP mới nhưng SPF vẫn chỉ chứa server cũ. Email có thể được gửi ra ngoài nhưng SPF sẽ không xác thực đúng.

Google cảnh báo nếu third-party sender không được đưa vào SPF record, email từ sender đó có khả năng cao hơn bị đánh dấu Spam.

• Cách kiểm tra DKIM: DKIM thường nằm ở:

selector._domainkey.yourdomain.com

Bạn cần biết selector do ESP cung cấp.

Sau đó kiểm tra:

nslookup -type=TXT selector._domainkey.yourdomain.com

Nếu không có record trả về, hãy kiểm tra lại:

Selector → DNS hostname → public key → trạng thái enable DKIM trên ESP

Một lỗi khá phổ biến là marketer đã tạo DKIM record nhưng chưa bật DKIM signing ở phía công cụ gửi.

• Cách kiểm tra DMARC: DMARC nằm tại: _dmarc.yourdomain.com. Có thể kiểm tra bằng: nslookup -type=TXT _dmarc.yourdomain.com. Record cơ bản có dạng: v=DMARC1; p=none;

Với Gmail bulk sender, DMARC policy có thể bắt đầu từ p=none, miễn DMARC được cấu hình hợp lệ. Tuy nhiên, có DMARC record vẫn chưa đủ.

• Kiểm tra DMARC Alignment

Giả sử người nhận nhìn thấy From: marketing@brand.com. Trong khi SPF authenticate bằng mailer.thirdparty.com và DKIM cũng ký bằng một domain không liên quan. Khi đó, DMARC có thể fail vì không alignment với domain trong From. Google yêu cầu đối với direct mail của bulk sender, organizational domain trong From phải align với SPF hoặc DKIM.

• Cách kiểm tra ngay trên Gmail: Gửi một email test tới Gmail. Sau đó mở email, chọn More → Show original. Ở đây bạn có thể thấy kết quả:

• SPF: PASS
• DKIM: PASS
• DMARC: PASS

Nếu có FAIL, hãy xử lý trước khi tối ưu Subject hay nội dung. Google cũng sử dụng phần “Show original” trong quy trình lấy thông tin message khi sender báo lỗi Deliverability.

Kết luận ở bước Authentication: Mục tiêu cần kết luận: “Domain đã có SPF" và SPF PASS + DKIM PASS + DMARC PASS + Alignment đúng. Nếu Authentication chưa ổn, hãy dừng ở đây và sửa trước.

Bước 2: Kiểm tra DNS, PTR/rDNS, Sending Hostname và TLS

Nếu Authentication đã Pass nhưng email vẫn bị reject hoặc delay, bước tiếp theo là kiểm tra hạ tầng gửi. Bước kiểm tra này thường bị bỏ qua do các thông số nằm ở phía server kỹ thuật. Google yêu cầu sending IP phải có forward DNS và reverse DNS hợp lệ, đồng thời email phải được truyền bằng TLS.

• PTR/rDNS là gì? Giả sử server gửi có IP: 203.0.113.10

PTR record phải trả về hostname, ví dụ: mail.brand.com. Sau đó hostname đó phải resolve ngược trở lại đúng IP: mail.brand.com → 203.0.113.10

Google yêu cầu sending IP khớp với hostname trong PTR record và hostname đó phải có A/AAAA record quay lại cùng IP.

• Cách kiểm tra Reverse DNS: Trên Windows: nslookup 203.0.113.10

Nếu kết quả không có hostname hoặc hostname không liên quan đến server gửi, hãy kiểm tra với nhà cung cấp SMTP/ESP. Với Shared IP, bạn thường không tự cấu hình PTR. ESP chịu trách nhiệm. Với Dedicated IP, doanh nghiệp cần đảm bảo bên cung cấp đã cấu hình rDNS đúng.

• Kiểm tra TLS: Google yêu cầu email được truyền bằng kết nối TLS.

Nếu gửi qua ESP lớn, TLS thường đã được cấu hình. Tuy nhiên, với SMTP server tự vận hành hoặc relay nội bộ, cần kiểm tra log SMTP hoặc cấu hình mail server.

Nếu Gmail trả lỗi: 4.7.29. Google cho biết đây có thể là dấu hiệu bulk sender không sử dụng TLS đúng yêu cầu.

• Khi nào nên nghi ngờ hạ tầng? Nếu cùng một nội dung và database nhưng:

• nhiều domain nhận email đều reject;
• 4xx tăng đồng loạt;
• SPF/DKIM liên tục fail;
• Gmail báo lỗi liên quan TLS/PTR;

thì vấn đề lỗi email gửi nhiều khả năng nằm ở hệ thống hơn là nội dung.

Bước 3: Đọc SMTP Response thay vì chỉ nhìn Bounce Rate

Bounce Rate chỉ cho biết có email không gửi được. SMTP Response mới giúp bạn biết tại sao email không gửi được. Theo RFC 5321, mã phản hồi SMTP được chia theo chữ số đầu. 2xx thể hiện thành công, 4xx là lỗi tạm thời, còn 5xx là lỗi mang tính permanent hơn.

Ví dụ:

• Không chỉ nhìn số 550: Các mailbox provider thường trả thêm Enhanced Status Code. Ví dụ: 550 5.7.26. Google cho biết email không đáp ứng yêu cầu authentication có thể bị Spam hoặc reject với lỗi 5.7.26. Hoặc: 4.7.27 có thể liên quan SPF failure đối với bulk sender Gmail. 4.7.30 có thể liên quan DKIM failure. Những thông tin này giá trị hơn rất nhiều so với chỉ nhìn: Bounce Rate = 7%.

Cách thao tác kiểm tra:

Trong ESP, tìm các khu vực như: Delivery Logs / Bounce Logs / Message Logs / SMTP Logs

Tên menu tùy phần mềm. Sau đó export dữ liệu gồm: Recipient domain → SMTP code → Error text → Timestamp

Tiếp theo nhóm lỗi theo Gmail, Outlook, Yahoo và corporate domains.

Ví dụ:

• Gmail: 4.7.x tăng mạnh
• Outlook: bình thường
• Yahoo: bình thường

Khi đó không nên kết luận toàn bộ hệ thống SMTP đang lỗi. Hãy tập trung vào Gmail.

Bước 4: Kiểm tra Domain Reputation và IP Reputation

Nếu SMTP cho thấy email được server nhận chấp nhận nhưng thư vẫn vào Spam, hãy chuyển sang kiểm tra Reputation.

Authentication trả lời:

“Bạn là ai?”

Reputation trả lời:

“Bạn có đáng tin không?”

Đây là lý do SPF, DKIM, DMARC Pass đầy đủ vẫn không đảm bảo Inbox.

• Dùng Google Postmaster Tools

Google Postmaster Tools cung cấp dữ liệu về:

• Spam Rate;
• Domain Reputation;
• IP Reputation;
• Authentication;
• Delivery Errors;
• Compliance.

Dữ liệu chỉ áp dụng cho thư gửi tới tài khoản Gmail cá nhân và chỉ hiển thị khi traffic đủ để Google đảm bảo privacy. Nếu chưa có Postmaster Tools, nên cài cho sending domain trước khi doanh nghiệp tăng quy mô Email Marketing.

• Domain Reputation nên đọc thế nào?

Postmaster có thể hiển thị reputation ở các mức khác nhau. Nếu từ trạng thái tốt giảm mạnh sau một campaign, hãy kiểm tra: Campaign nào gửi → source audience nào → volume bao nhiêu → Spam Rate bao nhiêu. Lưu ý, không nên tiếp tục gửi toàn bộ database với cùng tốc độ trong khi reputation đang giảm.

• Kiểm tra Spam Rate

Google khuyến nghị giữ Spam Rate trong Postmaster Tools dưới 0,1%, đồng thời yêu cầu tránh đạt mức 0,3% trở lên. Điều này có nghĩa: 0,29% không nên được coi là “ổn”. Nếu Spam Rate tăng từ: 0,02% → 0,18% hãy xem đó là cảnh báo sớm dù chưa vượt 0,3%.

• Khi Reputation email giảm, doanh nghiệp nên làm gì?

Lúc này, đừng cố sửa Reputation bằng cách gửi nhiều hơn. Một chiến lược phục hồi hợp lý hơn là: Giảm volume → loại audience kém → ưu tiên engaged contacts → giảm complaint → duy trì sending pattern ổn định

Google cũng lưu ý sau khi Spam Rate được cải thiện, việc Gmail điều chỉnh lại Spam Classification có thể mất một khoảng thời gian. Reputation không thay đổi tức thì.

Bước 5: Kiểm tra chất lượng Audience và nguồn Data

Nếu technical setup ổn nhưng complaint hoặc bounce vẫn tăng, hãy kiểm tra database. Đây thường là nguyên nhân marketer ít muốn xem nhất vì database càng lớn thường được coi là tài sản. Tuy nhiên, trong Deliverability: Database lớn nhưng không có engagement có thể trở thành liability.

• Hãy phân tách audience theo nguồn

Không phân tích toàn bộ database như một khối. Hãy chia nhóm này theo:

Google khuyến nghị không gửi tới người không đăng ký nhận thư và không mua địa chỉ email từ các công ty khác.

• Cách tìm source đang gây lỗi: Giả sử complaint toàn campaign là: 0,12% Nhìn tổng thể chưa chắc thấy vấn đề. Nhưng khi chia theo nguồn:

• Organic Signup: 0,02%
• CRM Active Customer: 0,03%
• Trade Show Import: 0,15%
• Purchased List: 0,65%

Nguồn gây vấn đề đã rất rõ. Trong trường hợp này, không cần dừng toàn bộ hệ thống gửi. Hãy tách nguồn Purchased List, ngừng traffic đó và theo dõi reputation của các source còn lại.

• Kiểm tra inactive subscriber: Người từng đăng ký hợp lệ nhưng không tương tác trong 12–18 tháng cũng có thể trở thành tệp chất lượng thấp. Không nhất thiết xóa ngay.

Có thể chuyển sang: Re-engagement → giảm frequency → sunset. Nếu vẫn không phản hồi, tiếp tục gửi thường đem lại ít conversion nhưng vẫn tạo thêm rủi ro Deliverability.

Bước 6: Kiểm tra Sending Pattern và biến động Volume

Một domain gửi tốt ở volume 10.000 email/ngày không có nghĩa nó có thể lập tức xử lý 500.000 email/ngày mà không có thay đổi về reputation hoặc throttling. Google khuyến nghị sender ramp up slowly vì tăng volume quá nhanh có thể gây Delivery Issue.

• So sánh volume theo thời gian: Thay vì chỉ nhìn campaign hôm nay, hãy xuất dữ liệu 30 ngày:

• Ngày 1–20: 5.000–8.000/ngày
• Ngày 21: 120.000
• Ngày 22: 200.000
• Ngày 23: Gmail 4xx tăng

Correlation lúc này rất đáng chú ý.

• Kiểm tra theo provider: Đừng chỉ nhìn total volume. Một campaign 200.000 email có thể gồm:

• Gmail: 130.000
• Outlook: 40.000
• Yahoo: 10.000
• Corporate: 20.000

Vấn đề volume có thể chỉ xuất hiện với Gmail.

• Khi 4xx tăng: Nếu temporary rejection tăng khi campaign bắt đầu scale, hãy giảm tốc độ gửi. Hãy để queue retry thay vì liên tục tạo thêm traffic mới. Google cung cấp nhiều 4.7.x response để rate-limit bulk sender không đáp ứng các yêu cầu kỹ thuật.

Bước 7: Cuối cùng mới kiểm tra Subject, HTML, Link và nội dung

Đây là bước marketer thường làm đầu tiên, nhưng trong troubleshooting Deliverability nên đặt gần cuối. Nếu email chưa vượt qua SPF/DKIM hoặc sender reputation thấp, đổi: SALE 50% thành: Ưu đãi dành riêng cho bạn thì khó có thể giải quyết nguyên nhân gốc. Bởi vì, khi các lớp kỹ thuật đã ổn, lúc này mới phân tích content.

• Kiểm tra Subject: Subject cần phản ánh đúng nội dung và tránh gây hiểu lầm. Vấn đề không phải một từ riêng lẻ như “Free” hay “Sale”, mà là sự kết hợp giữa content, reputation và hành vi người nhận.

• Kiểm tra CTA và Link: Kiểm tra URL thực tế sau redirect. Một CTA hiển thị: brand.com/product nhưng click lại đi qua nhiều redirect domain lạ có thể gây vấn đề về trust hoặc tracking. Doanh nghiệp nên ưu tiên branded tracking domain khi nền tảng hỗ trợ.

Kiểm tra HTML:

Hãy đảm bảo file html của email:

• không có HTML lỗi;
• layout hiển thị đúng;
• mobile responsive;
• image link hoạt động;
• không nhúng script không cần thiết;
• email không quá nặng.

Kiểm tra Landing Page: Mailbox provider không chỉ nhìn email. Một email dẫn tới domain bị cảnh báo, website có malware hoặc URL kém uy tín có thể ảnh hưởng tới đánh giá toàn campaign.

Kiểm tra Attachment: Nếu không thực sự cần thiết, tài liệu marketing lớn nên được đặt trên landing page hoặc file hosting đáng tin cậy và dùng link thay vì đính kèm trực tiếp.

Cách đọc nhanh lỗi Email Marketing theo triệu chứng: Sau khi hiểu 7 lớp trên, doanh nghiệp có thể rút ngắn thời gian troubleshooting bằng cách bắt đầu từ triệu chứng.

Email bị Reject ngay: Nếu server từ chối trước khi nhận message, hãy kiểm tra: SMTP → SPF/DKIM/DMARC → PTR → Policy, không nên bắt đầu từ nội dung.

Delivered cao nhưng vào Spam: Đây là bài toán Inbox Placement. Ưu tiên: Domain Reputation → Spam Rate → Audience → Volume → Tracking Domain → Content

Chỉ Gmail có vấn đề: Đăng nhập Google Postmaster Tools và xem: Compliance → Spam Rate → Domain Reputation → Authentication → Delivery Errors. Dữ liệu Postmaster không hoàn toàn realtime. Google cho biết dữ liệu Compliance thường cập nhật trong khoảng 24 giờ nhưng có thể lâu hơn.

Vì vậy không nên thay đổi cấu hình rồi kiểm tra sau vài phút và kết luận chưa có tác dụng.

Bounce tăng ngay sau khi import data mới: Đây là một tín hiệu rất mạnh cho thấy vấn đề có thể nằm ở data. So sánh cách yếu tố sau, nếu infrastructure không thay đổi, database mới cần được điều tra trước template.

• Campaign trước: Bounce 0,8%
• Sau import: Bounce 7,4%

Open Rate giảm nhưng Delivery ổn: Không đủ dữ liệu để kết luận email vào Spam. Open Rate chịu ảnh hưởng bởi subject, audience, image loading, privacy technology và cách ESP ghi nhận open.

Hãy xem thêm: Click → Reply → Conversion → Unsubscribe → Complaint. Nếu click/conversion vẫn ổn, Open Rate giảm một mình chưa chắc là Deliverability Issue.

Checklist lỗi Email không vào Inbox

Trước khi kết luận “tool gửi mail bị lỗi”, hãy kiểm tra lần lượt:

1. SPF có Pass không?
2. DKIM có Pass không?
3. DMARC có Pass và align không?
4. PTR/rDNS có hợp lệ không?
5. TLS có hoạt động không?
6. SMTP trả 2xx, 4xx hay 5xx?
7. Domain Reputation đang ở mức nào?
8. Spam Rate có tăng không?
9. Campaign có tăng volume đột biến không?
10. Bounce đến từ nguồn data nào?
11. Complaint đến từ segment nào?
12. Tracking domain có đáng tin cậy không?
13. Landing page có vấn đề không?
14. HTML/email có lỗi hiển thị không?
15. Vấn đề xảy ra với Gmail, Outlook hay tất cả provider?

Nếu trả lời được 15 câu hỏi này, phần lớn sự cố Email Deliverability sẽ không còn là tình trạng “không biết email vì sao vào Spam”.

Góc nhìn chuyên gia: Đừng tìm lỗi gửi Email Marketing bằng cảm giác, hãy dựa vào con số. Email vào Inbox không được quyết định bởi một yếu tố đơn lẻ. Nó là kết quả của: Identity + Infrastructure + Reputation + Permission + Sending Behaviour + Content + Engagement. Vì vậy cách xử lý: “Email vào Spam → đổi Subject” là quá đơn giản.

Quy trình hợp lý hơn là Authentication → DNS → SMTP → Reputation → Audience → Volume → Content.

• Nếu Authentication Fail, sửa Authentication.
• Nếu SMTP bị rate limit, xử lý volume.
• Nếu Spam Rate tăng ở một data source, xử lý data source.
• Nếu tất cả technical signal đều tốt nhưng click thấp, lúc đó mới tập trung vào creative và offer.

Đây chính là sự khác biệt giữa tối ưu Email Marketing theo cảm giác và quản trị Email Deliverability dựa trên dữ liệu.

Câu hỏi thường gặp về lỗi gửi email:

Khi nào nên dừng hoặc giảm gửi cho chiến dịch email?

Nếu chỉ một vài email bounce, chưa cần dừng toàn bộ chiến dịch. Nhưng nếu xuất hiện đồng thời: 4xx tăng mạnh + Spam Rate tăng + Reputation giảm + Bounce bất thường thì việc tiếp tục đẩy volume có thể làm vấn đề nghiêm trọng hơn.

Khi đó nên giảm sending rate → xác định provider → cô lập audience → kiểm tra SMTP/reputation → sửa lỗi → tăng lại dần. Đừng cố “gửi hết database cho xong”, bởi vì vừa gửi cố email cũng không được gửi tới người nhận, chưa kể sẽ tốn nhiều chi phí gửi cho doanh nghiệp mà không mang lại hiệu quả.

Trong Email Deliverability, bảo vệ domain reputation thường có giá trị dài hạn hơn hoàn thành một campaign ngắn hạn.

Sau khi sửa lỗi, kiểm tra lại như thế nào?

Không nên lập tức gửi lại toàn bộ database. Hãy tạo một nhóm test có engagement cao. Ví dụ: 1.000–5.000 người đã click/open gần đây. Hãy gửi trước cho nhóm này và theo dõi: SMTP response → Delivery → Bounce → Complaint → Click

Nếu các chỉ số ổn định, tăng volume dần. Nếu reputation vừa gặp vấn đề nghiêm trọng, quá trình hồi phục có thể mất thời gian. Google cũng xác nhận ngay cả sau khi Spam Rate cải thiện, hệ thống có thể cần thời gian để điều chỉnh Spam Classification.

Kết luận

Email Marketing không vào Inbox hiếm khi chỉ do một yếu tố đơn lẻ. Doanh nghiệp nên kiểm tra theo thứ tự Authentication → DNS/PTR/TLS → SMTP → Reputation → Audience → Sending Pattern → Content. Cách tiếp cận này giúp xác định nguyên nhân gốc, hạn chế sửa lỗi theo cảm tính và bảo vệ Sender Reputation lâu dài. Quan trọng hơn, Deliverability cần được kiểm soát xuyên suốt từ data, domain, volume đến engagement sau khi gửi.