SPF, DKIM và DMARC là gì? Giải thích cho cửa hàng online

Vì sao hộp thư kiểm tra ba bản ghi này#

Ai cũng có thể gõ bất kỳ địa chỉ nào vào dòng From của một email. SPF, DKIM và DMARC là cách hộp thư nhận biết một thư tự nhận là từ ninefold.example có thật sự đến từ Ninefold hay không. Mỗi bản ghi là một bản ghi DNS bạn công bố trên tên miền của mình, và mỗi bản ghi trả lời một câu hỏi khác nhau.

Với một shop, tác động thực tế là thư có vào hộp thư chính hay không. Google yêu cầu mọi người gửi thiết lập SPF hoặc DKIM, và những ai gửi hơn 5.000 thư mỗi ngày đến tài khoản Gmail cá nhân phải có SPF, DKIM và DMARC ^S4. Yahoo đặt cùng mức tối thiểu cho người gửi số lượng lớn ^S5. Ngay cả dưới các mức đó, thư được xác thực sẽ xây dựng uy tín người gửi trên chính tên miền của bạn, và một bản ghi DMARC khiến kẻ khác khó gửi email lừa đảo mạo danh bạn hơn nhiều.

Mỗi bản ghi làm gì#

SPF: máy chủ nào được phép gửi thay bạn

SPF là một bản ghi TXT liệt kê các máy chủ được phép gửi thư cho một tên miền. Máy chủ nhận so sánh địa chỉ IP đã kết nối đến nó với danh sách đó. SPF kiểm tra người gửi trong envelope (địa chỉ MAIL FROM dùng trong quá trình chuyển thư, cũng là nơi nhận bounce), không phải địa chỉ From mà khách hàng của bạn nhìn thấy ^S1. Một bản ghi điển hình cho shop dùng hộp thư workspace và một dịch vụ email marketing trông như sau:

v=spf1 include:spf.mailbox.example include:spf.mailservice.example ~all

Mỗi include kéo vào danh sách của một nhà cung cấp khác. Phần kết thúc cho biết phải làm gì với mọi máy chủ còn lại: -all là fail, ~all là softfail, và máy chủ nhận không nên chỉ dựa vào softfail để từ chối thư ^S1.

DKIM: chữ ký trên mỗi thư

DKIM thêm một chữ ký mã hóa vào header của thư. Chữ ký ghi tên miền ký (d=) và một selector (s=), và máy chủ nhận lấy khóa công khai từ bản ghi DNS tại selector._domainkey.domain ^S2. Nếu các header đã ký hoặc nội dung thư bị thay đổi trên đường đi, việc kiểm tra sẽ thất bại. Nếu chỉ có DKIM, tên miền ký không bắt buộc phải khớp với địa chỉ From ^S2, và đó là lý do DMARC ra đời.

DMARC: chính sách gắn chúng với địa chỉ người gửi hiển thị

DMARC là một bản ghi TXT tại _dmarc.yourdomain. Nó yêu cầu máy chủ nhận xác nhận SPF hoặc DKIM đã đạt với một tên miền khớp với địa chỉ From hiển thị, cho họ biết xử lý thư thất bại thế nào (none, quarantine hoặc reject), và chỉ định nơi gửi báo cáo ^S3. Bản ghi đầu tiên có thể ngắn như v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example.

Cách chúng phối hợp với nhau: alignment#

SPF và DKIM đều có thể đạt cho sai tên miền. Một dịch vụ marketing có thể đạt SPF cho tên miền bounce của chính họ và ký DKIM dưới tên họ, trong khi dòng From ghi ninefold.example. Cả hai kết quả đều không nói lên điều gì về Ninefold.

DMARC lấp khoảng trống đó bằng alignment (căn chỉnh, tức sự khớp tên miền). Một thư đạt DMARC khi SPF đạt với một tên miền khớp với tên miền From, hoặc DKIM đạt với một tên miền khớp với nó ^S3. Mặc định alignment ở chế độ relaxed, nên chữ ký DKIM từ mail.ninefold.example khớp với địa chỉ From tại ninefold.example; chế độ strict yêu cầu khớp chính xác ^S3. Gmail và Yahoo đều nêu cùng một quy tắc cho người gửi số lượng lớn: tên miền From phải khớp với tên miền SPF hoặc tên miền DKIM ^S4S5.

DKIM khớp tên miền quan trọng hơn SPF khớp tên miền. Khi thư được chuyển tiếp, máy chủ chuyển tiếp kết nối từ địa chỉ IP của chính nó, nên SPF của tên miền gốc thường thất bại ^S1. Chữ ký DKIM vẫn còn hiệu lực miễn là thư không bị sửa đổi.

Một shop cần công bố những gì#

Hãy liệt kê mọi dịch vụ gửi email có tên miền của bạn trong địa chỉ From trước khi động vào DNS. Với một thương hiệu thời trang nhỏ như Ninefold, danh sách đó thường gồm hộp thư workspace, email đơn hàng và giao hàng của nền tảng bán hàng, hệ thống hỗ trợ khách hàng, và một công cụ email marketing. Dịch vụ nào cũng cần được bao quát.

1. Một bản ghi SPF duy nhất bao gồm mọi dịch vụ gửi thư dưới tên miền của bạn.
2. Bật DKIM trong từng dịch vụ đó, dùng tên miền của bạn làm tên miền ký. Mỗi dịch vụ cấp cho bạn bản ghi và selector riêng, nên nhiều bản ghi DKIM có thể cùng tồn tại.
3. Một bản ghi DMARC, bắt đầu với p=none kèm địa chỉ nhận báo cáo, để bạn thấy ai đang gửi thư dưới tên bạn trước khi áp dụng bất kỳ chính sách nào. Hướng dẫn thiết lập DMARC đi qua từng bước chuyển sang quarantine và reject.

Xác thực chỉ là một phần trong những gì nhà cung cấp hộp thư mong đợi. Họ còn xem xét hủy đăng ký một lần nhấp và tỷ lệ khiếu nại spam của bạn; hướng dẫn kiến thức cơ bản về khả năng vào hộp thư trình bày phần còn lại.

Những lỗi thường gặp#

• Hai bản ghi SPF. Một tên miền chỉ được có một bản ghi bắt đầu bằng v=spf1; nếu có hai, SPF trả về lỗi vĩnh viễn cho mọi thư ^S1. Hãy gộp chúng thành một bản ghi.
• Quá nhiều lượt tra cứu. Mỗi include, a, mx, ptr, exists và redirect tốn một lượt tra cứu DNS, và SPF dừng lại với lỗi sau 10 lượt ^S1. Hãy bỏ các dịch vụ không còn dùng thay vì chồng thêm include.
• DKIM ký bằng tên miền của nhà cung cấp. Chữ ký vẫn đạt, nhưng không khớp với địa chỉ From của bạn. Hãy thiết lập DKIM trên chính tên miền của bạn trong từng công cụ.
• Nhảy thẳng lên p=reject. Một nguồn gửi bị bỏ sót, chẳng hạn email xác nhận đơn hàng từ nền tảng bán hàng, sẽ bắt đầu thất bại mà không ai hay. Hãy bắt đầu với p=none và đọc báo cáo trước.
• Không có địa chỉ nhận báo cáo. Bản ghi DMARC không có rua không cho bạn dữ liệu nào để hành động. Yahoo đặc biệt khuyến nghị có thẻ rua hoạt động trong quá trình thiết lập ^S5.

Cách kiểm tra các bản ghi#

Bạn có thể kiểm tra những gì đã được công bố bằng một lượt tra cứu DNS, và những gì máy chủ nhận thực sự thấy bằng cách đọc một thư thật.

• Từ terminal: dig +short TXT ninefold.example hiển thị bản ghi SPF, dig +short TXT _dmarc.ninefold.example hiển thị DMARC, và dig +short TXT selector._domainkey.ninefold.example hiển thị khóa DKIM khi bạn đã biết selector.
• Từ trình duyệt: bất kỳ công cụ tra cứu DNS nào truy vấn bản ghi TXT cũng cho kết quả tương tự.
• Từ một thư thật: gửi một email thử đến địa chỉ Gmail, mở thư, chọn Thêm, rồi Hiển thị bản gốc ^S6. Phần header hiển thị kết quả SPF, DKIM và DMARC của thư đó, cùng tên miền mà mỗi kiểm tra đã đạt.

DMARC hiện đã nằm trong lộ trình tiêu chuẩn của IETF: RFC 9989, công bố tháng 5/2026, thay thế RFC 7489 ^S3S7. Bản ghi vẫn bắt đầu bằng v=DMARC1, nên bản ghi viết theo quy tắc cũ vẫn tiếp tục hoạt động ^S3.

Thiết lập xác thực với Tellnod trong Claude hoặc ChatGPT#

Tellnod là một connector MCP để viết, xem trước và gửi email marketing từ Claude hoặc ChatGPT. Ngay ngày đầu, bạn có thể gửi từ một địa chỉ mang tên shop của bạn trên tên miền dùng chung của Tellnod, chẳng hạn hello@yourshop.tellnodmail.com, không cần thay đổi DNS, với giới hạn 500 người nhận mỗi chiến dịch và 1.000 email mỗi tháng. Xác minh tên miền của riêng bạn sẽ gỡ bỏ các giới hạn đó và là cách thiết lập chúng tôi khuyến nghị.

Để xác minh tên miền, hãy yêu cầu trong cuộc trò chuyện, ví dụ: “Thiết lập ninefold.example làm tên miền gửi của tôi.” Tellnod cung cấp cho bạn các bản ghi SPF, DKIM và DMARC và kiểm tra giúp bạn. Nếu người khác quản lý DNS của bạn, hãy yêu cầu: “Tạo link thiết lập cho lập trình viên web của chúng tôi.” Họ có thể thêm các bản ghi chỉ bằng một cú nhấp trên các nhà cung cấp DNS được hỗ trợ, hoặc sao chép chúng, mà không cần tạo tài khoản, và bạn sẽ được thông báo trong cuộc trò chuyện và qua email khi tên miền đã được xác minh. Thay đổi DNS thường mất vài phút và có thể mất đến 48 giờ.

Xác thực không thay đổi cách gửi: mọi chiến dịch đều hiển thị bản xem trước trên máy tính và điện thoại, và không có gì được gửi đi cho đến khi bạn nhấn Confirm trên thẻ xác nhận. Để bắt đầu, hãy kết nối Tellnod với Claude hoặc ChatGPT; trang bảng giá liệt kê gói miễn phí và các gói trả phí.

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