Kiểm tra SPF, DKIM, DMARC cho từng domain trước khi gửi cold email

Nhiều đội sales chỉ kiểm tra SPF/DKIM/DMARC một lần khi mua domain, rồi quên mất khi thêm domain phụ hoặc đổi nền tảng gửi. Kết quả là email rơi vào spam hàng loạt mà không ai hiểu vì sao, vì bản ghi DNS đúng ở domain gốc nhưng sai ở domain phụ mới tạo. Bài này hướng dẫn quy trình kiểm tra có hệ thống bằng dmarc checker tool, theo từng domain và từng nền tảng gửi cụ thể.

Vì sao phải kiểm tra theo từng domain, không chỉ domain chính

Khi một công ty B2B mở rộng gửi cold email bằng domain phụ — ví dụ dùng outreach.congty.vn thay vì congty.vn để bảo vệ domain chính — nhiều người mặc định domain phụ sẽ 'ăn theo' uy tín và cấu hình của domain gốc. Thực tế, SPF, DKIM, DMARC là các bản ghi DNS độc lập theo từng subdomain hoặc domain riêng biệt, không tự kế thừa.

Một dmarc checker tool giúp phát hiện nhanh domain nào đang thiếu SPF, DKIM chưa được publish đúng selector, hoặc DMARC record trỏ sai địa chỉ nhận report. Vấn đề phổ biến nhất ở các đội mở rộng nhiều domain phụ cùng lúc là quên đồng bộ cấu hình, dẫn đến một số domain gửi tốt còn một số khác vào spam ngay từ ngày đầu.

Quy trình kiểm tra SPF, DKIM, DMARC theo domain

Dùng một spf dkim dmarc record checker (dạng công cụ online hoặc lệnh dig/nslookup thủ công) để tra cứu ba loại bản ghi TXT sau cho từng domain gửi:

Sau khi có kết quả tra cứu, cần đối chiếu với nền tảng gửi thực tế đang dùng — vì một domain có thể gửi qua nhiều nguồn (Google Workspace cho email cá nhân của sale, SMTP riêng cho công cụ automation), và mỗi nguồn cần được khai báo trong SPF.

• SPF: tra TXT record tại domain gốc, kiểm tra có include đúng nền tảng gửi (ví dụ _spf.google.com cho Google Workspace) và không vượt quá 10 lượt DNS lookup
• DKIM: kiểm tra selector._domainkey.domain.vn có tồn tại và public key khớp với private key nền tảng đang ký
• DMARC: tra _dmarc.domain.vn, xem policy hiện tại (none/quarantine/reject) và địa chỉ rua/ruf nhận report
• Đối chiếu domain phụ (subdomain) riêng — mỗi subdomain cần SPF và DKIM record của chính nó, DMARC có thể kế thừa từ domain gốc nếu không khai báo riêng

Kiểm tra theo từng nền tảng gửi cụ thể

Một email spf dkim dmarc checker chỉ báo record có tồn tại hay không, chưa nói lên record đó có đúng với nền tảng đang gửi thực tế. Mỗi nền tảng có cách khai báo DKIM khác nhau, và nếu công ty dùng song song nhiều nền tảng, SPF phải liệt kê đủ tất cả.

Với đội sales gửi cold email B2B, tình huống phổ biến là dùng Google Workspace cho hộp thư cá nhân của từng SDR, đồng thời dùng một nền tảng gửi automation riêng (SMTP hoặc API) cho phần còn lại của chiến dịch. Nếu chỉ khai báo SPF cho Google mà quên IP của nền tảng automation, toàn bộ email gửi qua automation sẽ fail SPF.

Đọc report DMARC để đánh giá thực tế, không chỉ nhìn record

Kiểm tra record tồn tại mới là bước đầu. Bước quan trọng hơn là đọc aggregate report (rua) do các nhà cung cấp mail lớn gửi về hàng ngày, cho biết nguồn gửi nào pass, nguồn nào fail SPF/DKIM alignment. Nhiều dmarc checker dmarcian và công cụ tương tự có tính năng tổng hợp report này thành bảng dễ đọc thay vì phải parse XML thô.

Với domain mới bắt đầu gửi cold email, nên đặt DMARC ở policy p=none trong 2-4 tuần đầu để chỉ theo dõi, không chặn email nào cả — kể cả email hợp lệ bị fail alignment do cấu hình sai. Sau khi report cho thấy tỷ lệ pass ổn định, mới nâng dần lên p=quarantine rồi p=reject.

Lỗi thường gặp khi mở rộng nhiều domain phụ

Đội ngũ mở rộng nhanh cold email B2B trên nhiều domain phụ thường gặp vài lỗi lặp lại, phần lớn xuất phát từ việc coi cấu hình SPF/DKIM/DMARC là việc làm một lần rồi thôi.

• Copy nguyên SPF record của domain gốc sang domain phụ mà không kiểm tra nền tảng gửi có giống nhau không
• Bật DMARC p=reject ngay từ đầu, chặn luôn cả email hợp lệ gửi qua nền tảng chưa được alignment đúng
• Không kiểm tra lại sau khi đổi ESP hoặc thêm công cụ automation mới — SPF cũ không còn include IP của nguồn gửi mới
• Vượt quá giới hạn 10 lượt DNS lookup của SPF khi include quá nhiều nền tảng, khiến SPF bị bỏ qua hoàn toàn (permerror)
• Quên đặt rua report về địa chỉ có người theo dõi thực sự, khiến vấn đề tồn tại nhiều tuần mà không ai biết

Cách LDM kiểm tra domain trước khi bật chiến dịch

Trước khi bật bất kỳ chiến dịch cold email B2B nào cho khách hàng, LDM chạy audit SPF, DKIM, DMARC cho từng domain gửi và từng nền tảng liên quan — không chỉ domain chính mà cả mọi domain phụ dự kiến dùng cho outreach. Đây là bước bắt buộc, không phải tuỳ chọn, vì domain mất uy tín rất khó phục hồi khi đã bị các nhà cung cấp mail lớn đánh dấu.

Sau audit ban đầu, LDM tiếp tục theo dõi report DMARC định kỳ trong suốt chiến dịch, đặc biệt khi khách hàng thêm domain phụ mới hoặc đổi nền tảng gửi giữa chừng — vì đây chính là hai thời điểm dễ phát sinh lỗi cấu hình nhất.

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