Thiết lập SPF, DKIM và DMARC: Hướng dẫn từng bước cho cold email

Nếu bạn gửi cold email từ tên miền của riêng mình, ba bản ghi DNS quyết định liệu các máy chủ nhận có tin rằng thư đó thực sự là của bạn hay không: SPF, DKIM và DMARC. Nếu thiếu chúng, ngay cả một email đầu tiên được viết tốt cũng có thể bị lọc trước khi có ai đọc.

Hướng dẫn này dành cho những người sáng lập và đội kinh doanh gửi email tiếp cận từ một địa chỉ như you@yourcompany.com, thường thông qua Google Workspace. Chúng tôi (Outreach) đi qua từng bản ghi theo đúng thứ tự bạn nên thiết lập, trình bày định dạng bản ghi đúng như các trang trợ giúp của Google và các RFC công bố, và chỉ ra những lỗi khiến một bản ghi trông có vẻ ổn trong khi âm thầm không hoạt động.

Bạn không cần là chuyên gia DNS. Bạn cần quyền truy cập vào cài đặt DNS của tên miền (tại nhà đăng ký tên miền hoặc nhà cung cấp DNS) và, với DKIM, quyền quản trị Google Workspace.

SPF, DKIM và DMARC là gì, mỗi thứ trong một câu?

SPF liệt kê các máy chủ được phép gửi thư cho tên miền của bạn, DKIM thêm một chữ ký mật mã chứng minh thư không bị giả mạo hay bị sửa đổi, còn DMARC cho bên nhận biết phải làm gì khi một thư không vượt qua các kiểm tra đó. Cả ba đều được công bố dưới dạng bản ghi TXT trong DNS của tên miền bạn.

Ba bản ghi này phối hợp với nhau. SPF và DKIM mỗi thứ chỉ chứng minh một điều hẹp; DMARC gắn những bằng chứng đó với địa chỉ mà mọi người thực sự thấy ở dòng From.

Những bản ghi này có thực sự bắt buộc đối với cold email không?

Có — mọi người gửi đến Gmail và Yahoo ít nhất phải có SPF hoặc DKIM, và người gửi hàng loạt cần cả ba. Đây không phải là một gợi ý về thực hành tốt nhất; nó nằm trong các quy tắc dành cho người gửi mà cả hai nhà cung cấp đã công bố.

Hướng dẫn dành cho người gửi email của Google nêu rằng mọi người gửi phải “Thiết lập xác thực email SPF hoặc DKIM cho các tên miền gửi của bạn.” Những người gửi “hơn 5.000 thư mỗi ngày đến các tài khoản Gmail” còn phải “Thiết lập SPF và DKIM” cùng với “xác thực email DMARC cho tên miền gửi của bạn,” và tên miền From phải được căn chỉnh với tên miền SPF hoặc DKIM. Các quy tắc này có hiệu lực từ ngày 1 tháng 2 năm 2024.

Các thực hành tốt nhất của Sender Hub của Yahoo cũng tương tự: mọi người gửi phải “Triển khai tối thiểu SPF hoặc DKIM,” còn người gửi hàng loạt phải “Triển khai cả SPF và DKIM” và “Công bố một chính sách DMARC hợp lệ với tối thiểu p=none.”

Một chương trình cold email nhỏ có thể không bao giờ đạt đến 5.000 thư mỗi ngày. Dù vậy, hãy thiết lập cả ba: không tốn chi phí, chỉ mất một buổi chiều, và bạn sẽ không bao giờ phải tìm hiểu ranh giới nằm ở đâu.

Thiết lập SPF như thế nào?

Thêm một bản ghi TXT tại tên miền gốc của bạn, bắt đầu bằng v=spf1, liệt kê mọi dịch vụ gửi thư cho bạn và kết thúc bằng ~all. Với một tên miền chỉ gửi thư qua Google Workspace, trang thiết lập SPF của Google đưa ra đúng bản ghi sau:

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

Các bước:

1. Đăng nhập vào cài đặt DNS của nhà cung cấp tên miền của bạn.
2. Tạo một bản ghi TXT. Với trường host hoặc tên, Google cho biết hãy nhập @ nếu bạn thêm nó vào tên miền gốc chứ không phải tên miền phụ.
3. Dán bản ghi vào làm giá trị rồi lưu.
4. Hãy chờ. Google lưu ý rằng “Có thể mất tới 48 giờ để xác thực SPF bắt đầu hoạt động.”

Nếu các dịch vụ khác cũng gửi thư từ tên miền của bạn — một công cụ bản tin, một CRM, một dịch vụ thư giao dịch — thì mỗi dịch vụ cần có include: riêng trong cùng một bản ghi. Trang của Google đưa ra các ví dụ kết hợp sau:

v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all

Hãy dùng giá trị include mà chính mỗi dịch vụ gửi thư công bố trong tài liệu của họ; đừng đoán.

Bản ghi SPF nên kết thúc bằng ~all hay -all?

Hướng dẫn thiết lập của Google dùng ~all, và đó là mặc định an toàn trong lúc bạn vẫn đang tìm ra mọi dịch vụ gửi thư cho bạn. Hai kiểu kết thúc này có ý nghĩa khác nhau trong RFC 7208, tiêu chuẩn của SPF:

• ~all (softfail) là “Một tuyên bố yếu của ADMD công bố rằng máy chủ có lẽ không được ủy quyền.”
• -all (fail) là “Một tuyên bố rõ ràng rằng máy khách không được ủy quyền sử dụng tên miền trong danh tính đã cho.”

Với -all, một dịch vụ gửi thư mà bạn quên đưa vào sẽ nhận kết quả thất bại dứt khoát. Khi DMARC đã được thiết lập và các báo cáo của nó cho thấy mọi nguồn hợp lệ đều vượt qua, phần kết thúc của SPF ít quan trọng hơn, vì chính sách của DMARC trở thành chỉ dẫn mà bên nhận làm theo.

Vì sao SPF hỏng khi có quá nhiều include?

Vì một lần kiểm tra SPF chỉ được phép kích hoạt tối đa 10 lần tra cứu DNS; vượt quá mức đó, toàn bộ kết quả trở thành lỗi. RFC 7208, mục 4.6.4 nêu rằng các bên triển khai “PHẢI giới hạn tổng số các thuật ngữ đó ở mức 10 trong quá trình đánh giá SPF” và “Nếu vượt quá giới hạn này, bên triển khai PHẢI trả về ‘permerror’.”

Các thuật ngữ được tính là include, a, mx, ptr, exists và bộ sửa đổi redirect. Điều quan trọng là phép đếm bao gồm toàn bộ quá trình đánh giá — nên một include: mà bản thân nó chứa thêm các include khác sẽ dùng hết nhiều lượt trong 10 lượt của bạn. Trang của chính Google diễn đạt điều này là “Một bản ghi SPF có thể có tối đa 10 thẻ include:”; RFC là cách đọc chặt chẽ hơn vì các lần tra cứu lồng nhau cũng được tính.

Nếu qua nhiều năm bạn đã thêm nhiều công cụ bán hàng và tiếp thị, hãy xóa những công cụ bạn không còn dùng trước khi thêm include mới.

Điều gì xảy ra nếu một tên miền có hai bản ghi SPF?

SPF thất bại với một lỗi — hai bản ghi bị coi là cấu hình hỏng, chứ không phải hai danh sách để gộp lại. RFC 7208 nêu rằng khi một tên miền có nhiều hơn một bản ghi v=spf1, phép kiểm tra “cho ra kết quả ‘permerror’.”

Một cách thường gặp dẫn đến điều này: ai đó thêm bản ghi TXT thứ hai cho một công cụ mới thay vì sửa bản ghi hiện có. Cách khắc phục là gộp chúng thành một bản ghi có nhiều thuật ngữ include:, như trong các ví dụ ở trên.

Bật DKIM trong Google Workspace như thế nào?

Tạo một khóa trong Admin console (Bảng điều khiển dành cho quản trị viên), công bố nó dưới dạng bản ghi TXT tại google._domainkey, rồi nhấp “Start authentication” (bắt đầu xác thực). Trang thiết lập DKIM của Google trình bày các bước:

1. Trong Google Admin console, hãy vào Ứng dụng (Apps) > Google Workspace > Gmail > Xác thực email (Authenticate email). (Bạn cần có đặc quyền quản trị Cài đặt Gmail (Gmail Settings).)
2. Chọn tên miền và tạo một bản ghi mới.
3. Chọn độ dài khóa. Google nói hãy chọn 2048 “Nếu nhà cung cấp tên miền của bạn hỗ trợ khóa 2048 bit” vì “Khóa dài an toàn hơn khóa ngắn,” và chỉ chọn 1024 “Nếu nhà cung cấp tên miền của bạn không hỗ trợ khóa 2048 bit.”
4. Giữ nguyên selector tiền tố mặc định, google — Google gọi đó là “tùy chọn được khuyến nghị” cho Workspace.
5. Google hiển thị cho bạn một tên máy chủ DNS, google._domainkey, và một giá trị TXT bắt đầu bằng v=DKIM1. Hãy sao chép cả hai vào một bản ghi TXT mới tại nhà cung cấp DNS của bạn.
6. Quay lại Admin console, nhấp Start authentication.

Giá trị TXT mà Google tạo ra có dạng như sau (bản thân khóa là một chuỗi dài, duy nhất cho tên miền của bạn):

v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)

Thời gian: Google cho biết “có thể mất tới 48 giờ để xác thực DKIM bắt đầu hoạt động” sau khi bạn thêm khóa. Nếu bạn vừa mới thiết lập Gmail cho một tên miền mới, Google lưu ý rằng bạn “phải chờ 24–72 giờ” thì khóa DKIM mới có sẵn trong Admin console.

Nếu một dịch vụ khác gửi thư cho bạn, dịch vụ đó sẽ cung cấp bản ghi DKIM riêng với selector riêng. Hãy công bố cả bản ghi đó — nhiều khóa DKIM với các selector khác nhau có thể cùng tồn tại, không giống SPF.

Thiết lập DMARC như thế nào để không chặn chính thư của bạn?

Hãy công bố một bản ghi TXT tại _dmarc.yourcompany.com với p=none trước, đọc các báo cáo, rồi mới siết chặt chính sách. Trang thiết lập DMARC của Google nêu: “Khi bạn bắt đầu dùng DMARC, chúng tôi khuyến nghị đặt tùy chọn chính sách (p) là none.” Trang này cũng khuyên bạn “Hãy chờ 48 giờ sau khi thiết lập SPF và/hoặc DKIM rồi mới thiết lập DMARC.”

Trang của Google đưa ra bản ghi ví dụ đầy đủ sau:

v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s

Ví dụ đó cho thấy trạng thái hoàn chỉnh và nghiêm ngặt nhất. Với bản ghi đầu tiên, cùng định dạng đó với chính sách giám sát và một địa chỉ nhận báo cáo là đủ — ví dụ v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. Thẻ rua gửi các báo cáo tổng hợp đến hộp thư đó; Google khuyến nghị dùng một hộp thư hoặc nhóm riêng, vì báo cáo có thể đến với số lượng lớn.

Ba giá trị chính sách, theo định nghĩa trong đặc tả DMARC:

Một tên miền chỉ có một bản ghi DMARC. Theo RFC 9989, nếu có nhiều bản ghi DMARC được trả về, “tất cả đều bị loại bỏ” — nghĩa là không có chính sách nào được áp dụng.

“Alignment” (căn chỉnh tên miền) nghĩa là gì, và vì sao DMARC thất bại khi SPF vượt qua?

DMARC chỉ vượt qua khi SPF hoặc DKIM vượt qua đối với một tên miền khớp với địa chỉ From mà mọi người nhìn thấy. SPF có thể vượt qua đối với tên miền riêng của dịch vụ gửi thư trong khi dòng From hiển thị tên miền của bạn — và khi đó DMARC vẫn thất bại, vì tên miền vượt qua kiểm tra không được căn chỉnh.

Đặc tả DMARC nêu rằng một thư vượt qua khi có ít nhất một phương thức xác thực cho kết quả đạt “dựa trên một định danh nằm trong sự căn chỉnh” (RFC 7489, nay được tiếp nối trong RFC 9989). Theo mặc định, căn chỉnh ở chế độ nới lỏng (adkim và aspf mặc định là r): mail.yourcompany.com và yourcompany.com được tính là khớp vì chúng có cùng tên miền tổ chức. Chế độ nghiêm ngặt (s), như trong ví dụ của Google, yêu cầu khớp chính xác.

Trên thực tế, đây là lý do DKIM quan trọng đến vậy đối với cold email: khi dịch vụ gửi thư ký bằng tên miền của bạn, căn chỉnh DKIM vượt qua ngay cả khi căn chỉnh SPF không vượt qua.

Tiêu chuẩn DMARC có thay đổi trong năm 2026 không?

Có. RFC 9989, được công bố vào tháng 5 năm 2026 dưới dạng tài liệu thuộc Standards Track (lộ trình tiêu chuẩn), thay thế RFC 7489 ban đầu — và loại bỏ thẻ pct. Các bản ghi v=DMARC1 hiện có vẫn tiếp tục hoạt động.

Thay đổi chính mà hầu hết người gửi sẽ nhận thấy: pct (chỉ áp dụng chính sách cho một phần trăm thư thất bại) đã bị loại bỏ. RFC giải thích rằng “Kinh nghiệm vận hành cho thấy thẻ ‘pct’ thường không được áp dụng chính xác, trừ khi giá trị được chỉ định là 0 hoặc 100.” Thay vào đó là một cờ thử nghiệm, t=y, yêu cầu bên nhận không áp dụng chính sách bạn đã nêu trong lúc bạn đang thử nghiệm nó.

Trang trợ giúp của Google vẫn hiển thị pct=100 trong ví dụ của mình. Điều đó không làm hỏng gì: RFC 9989 nêu rằng “các thẻ không xác định PHẢI bị bỏ qua,” nên một pct còn sót lại chỉ đơn giản bị bỏ qua. Lần tới khi chỉnh sửa bản ghi, bạn có thể bỏ nó đi.

Làm sao để kiểm tra mọi thứ có hoạt động không?

Hãy tra cứu các bản ghi bạn đã công bố, rồi gửi một thư thật đến một địa chỉ Gmail và đọc kết quả xác thực của thư đó. Hai cách kiểm tra nhanh:

1. Tra cứu các bản ghi DNS. Công cụ kiểm tra miễn phí của chúng tôi tra cứu các bản ghi SPF, DKIM và DMARC của tên miền thuộc địa chỉ bạn nhập — không cần đăng ký. Công cụ kiểm tra selector DKIM mặc định của Google (google._domainkey); nếu dịch vụ gửi thư của bạn dùng selector khác, công cụ sẽ báo DKIM là chưa xác nhận được ngay cả khi nó đã được thiết lập. Công cụ có bằng tiếng Anh và tiếng Hàn; hãy nhập địa chỉ email gửi của bạn.
2. Kiểm tra một thư thật. Gửi một email đến một tài khoản Gmail mà bạn kiểm soát, mở thư, chọn “Hiện thư gốc,” rồi tìm SPF: PASS, DKIM: PASS và DMARC: PASS.

Sau đó hãy cho các báo cáo DMARC một hoặc hai tuần. Khi mọi nguồn hợp lệ mà bạn dùng đều hiển thị là vượt qua, hãy chuyển từ p=none sang p=quarantine, và sau đó sang p=reject nếu bạn muốn có sự bảo vệ mạnh nhất chống giả mạo.

Những lỗi nào làm hỏng xác thực thường xuyên nhất?

Hai bản ghi SPF, quá nhiều lần tra cứu SPF, DKIM được tạo ra nhưng không bao giờ được khởi động, và DMARC được công bố trước khi SPF và DKIM kịp có thời gian hoạt động. Danh sách kiểm tra:

• Một bản ghi SPF, với mọi dịch vụ gửi thư là một include: bên trong nó, và không quá 10 thuật ngữ tra cứu.
• Nhấp “Start authentication” sau khi công bố khóa DKIM — chỉ riêng bản ghi DNS là chưa đủ.
• Chờ khoảng 48 giờ sau SPF và DKIM trước khi thêm DMARC, và công bố nó tại _dmarc, không phải tại tên miền gốc.
• Gửi từ một tên miền do bạn kiểm soát. Bạn không thể công bố DMARC cho một địa chỉ @gmail.com.

Xác thực giúp thư của bạn được xem xét; nó không khiến người nhận muốn nhận thư. Các khiếu nại thư rác vẫn được tính — Google và Yahoo đều nói hãy giữ tỷ lệ thư rác dưới 0.3%, như chúng tôi đã trình bày trong vì sao cold email rơi vào thư rác. Và việc gửi đến những địa chỉ không tồn tại tạo ra thư bị trả lại, đó là lý do chúng tôi khuyên bạn xác minh địa chỉ trước khi gửi.

Tóm tắt ngắn gọn

• Google và Yahoo yêu cầu SPF hoặc DKIM từ mọi người gửi, và cả ba cùng với căn chỉnh tên miền từ người gửi hàng loạt (hơn 5.000 thư mỗi ngày đến Gmail).
• SPF: một bản ghi TXT tại @, ví dụ v=spf1 include:_spf.google.com ~all; giữ trong phạm vi 10 thuật ngữ tra cứu DNS.
• DKIM: khóa 2048 bit, selector google, TXT tại google._domainkey, rồi Start authentication.
• DMARC: một bản ghi TXT tại _dmarc, bắt đầu ở p=none với một địa chỉ nhận báo cáo, siết chặt sau. RFC 9989 (tháng 5 năm 2026) đã thay pct bằng t=y.
• Kiểm tra các bản ghi của bạn bằng công cụ kiểm tra xác thực thư miễn phí của chúng tôi, rồi xác nhận trên một thư thật.