Cách cấu hình DMARC: ví dụ bản ghi từ p=none đến reject

Các bước#

1. 1

   Kiểm tra SPF và DKIM trước

   Liệt kê mọi dịch vụ gửi email với tên miền của bạn trong địa chỉ From và xác nhận từng dịch vụ đạt SPF hoặc DKIM cho chính tên miền của bạn. Google khuyên nên thiết lập cả hai ít nhất 48 giờ trước khi cấu hình DMARC ^S3.

2. 2

   Chọn hộp thư nhận báo cáo

   Tạo một địa chỉ như dmarc@ninefold.example, hoặc dùng một dịch vụ báo cáo. Báo cáo được gửi đến dưới dạng tệp XML nén ^S2.

3. 3

   Công bố bản ghi giám sát

   Thêm một bản ghi TXT với host _dmarc và giá trị v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example. Chính sách none không thay đổi cách xử lý email ^S1.

4. 4

   Xác minh bản ghi

   Chạy dig +short TXT _dmarc.ninefold.example hoặc dùng một công cụ tra cứu DNS, và kiểm tra rằng chỉ có đúng một bản ghi được trả về và bản ghi đó bắt đầu bằng v=DMARC1.

5. 5

   Đọc báo cáo

   Xem lại các báo cáo tổng hợp cho đến khi mọi người gửi hợp lệ đều cho thấy SPF hoặc DKIM đã căn chỉnh (aligned). Google khuyên ít nhất một tuần; RFC 9989 khuyên khoảng một tháng trước khi áp dụng chính sách ^S1S3.

6. 6

   Chuyển sang quarantine

   Đổi chính sách thành p=quarantine, để email không đạt sẽ vào thư mục spam. Tiếp tục đọc báo cáo.

7. 7

   Chuyển sang reject

   Sau một khoảng thời gian tương tự với báo cáo sạch, đổi chính sách thành p=reject, để máy chủ nhận từ chối email không đạt ^S1.

Những gì bạn cần trước khi bắt đầu#

Bản thân DMARC không xác thực điều gì. DMARC đọc kết quả SPF và DKIM, rồi kiểm tra xem ít nhất một trong hai đã đạt cho một tên miền căn chỉnh với địa chỉ From hiển thị ^S1. Nếu công cụ marketing của bạn ký bằng tên miền của chính họ thay vì của bạn, DMARC sẽ không đạt dù DKIM đã đạt. Hãy khắc phục điều đó trước, nếu không các báo cáo sẽ toàn là email của chính bạn.

Với một thương hiệu thời trang nhỏ như Ninefold, danh sách người gửi thường gồm hộp thư nhân viên, email đơn hàng và vận chuyển từ nền tảng cửa hàng, hệ thống hỗ trợ khách hàng và công cụ email marketing. Mỗi dịch vụ cần thiết lập SPF hoặc DKIM trên ninefold.example. Bài giải thích SPF, DKIM và DMARC trình bày cách hoạt động của từng bản ghi.

Gmail yêu cầu bản ghi DMARC đối với người gửi hơn 5.000 email mỗi ngày đến tài khoản Gmail cá nhân, và chấp nhận chính sách none ^S4. Yahoo cũng yêu cầu người gửi số lượng lớn có ít nhất p=none ^S5. Bản ghi chỉ mất vài phút để công bố, nên bạn nên thêm bản ghi này dù gửi với số lượng bao nhiêu.

Cú pháp bản ghi DMARC#

Bản ghi DMARC là một bản ghi TXT được công bố tại _dmarc trên tên miền của bạn. Đó là một danh sách các thẻ phân tách bằng dấu chấm phẩy. Thẻ v=DMARC1 phải đứng đầu tiên, nếu không máy chủ nhận sẽ bỏ qua toàn bộ bản ghi ^S1. Đây là các thẻ một shop cần:

Hãy bỏ qua adkim và aspf trừ khi bạn có lý do. Căn chỉnh relaxed, mức mặc định, cho phép email được ký bởi một tên miền phụ như mail.ninefold.example căn chỉnh với địa chỉ From tại ninefold.example ^S1, và Yahoo chấp nhận căn chỉnh relaxed ^S5.

Ví dụ bản ghi DMARC cho từng giai đoạn#

Các ví dụ này dùng ninefold.example. Hãy thay tên miền và địa chỉ nhận báo cáo bằng của bạn, và công bố từng bản ghi dưới host _dmarc.

Giám sát

v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example

Quarantine

v=DMARC1; p=quarantine; rua=mailto:dmarc@ninefold.example

Reject

v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@ninefold.example

Các hướng dẫn cũ hơn, bao gồm trang hướng dẫn triển khai của Google, dùng pct= để áp dụng chính sách trên một tỷ lệ phần trăm email ^S3. RFC 9989 đã loại bỏ thẻ này vì các máy chủ nhận chỉ áp dụng nó một cách đáng tin cậy ở mức 0 hoặc 100, và thay vào đó bổ sung t=y cho giai đoạn thử nghiệm ^S1. Máy chủ nhận phải bỏ qua các thẻ mà chúng không nhận biết, nên máy chủ nào chưa hỗ trợ np hoặc t sẽ đơn giản là bỏ qua chúng ^S1.

Báo cáo rua cho bạn biết điều gì#

Các nhà cung cấp hộp thư gửi báo cáo tổng hợp thường gửi một báo cáo mỗi ngày cho mỗi tên miền, dưới dạng tệp XML nén ^S2. Mỗi báo cáo liệt kê các địa chỉ IP đã gửi email bằng tên miền của bạn, số lượng email từ mỗi địa chỉ, kết quả SPF và DKIM, việc chúng có căn chỉnh hay không, và máy chủ nhận đã xử lý email như thế nào ^S2.

• Một nguồn bạn nhận ra nhưng không căn chỉnh là một dịch vụ gửi bạn quên thiết lập. Hãy bật DKIM cho tên miền của bạn trong dịch vụ đó, hoặc thêm nó vào SPF.
• Một nguồn bạn không nhận ra hoặc là một dịch vụ ai đó trong nhóm của bạn đã đăng ký, hoặc là ai đó đang giả mạo tên miền của bạn. Hãy hỏi lại mọi người trước khi áp dụng chính sách.
• Email được chuyển tiếp thường không đạt SPF nhưng đạt DKIM ^S1. Điều đó là bình thường, và cũng là lý do DKIM đã căn chỉnh quan trọng hơn cả.

XML thô rất khó đọc thủ công, nên nhiều shop gửi rua đến một dịch vụ báo cáo để chuyển nó thành biểu đồ. Nếu dịch vụ đó dùng tên miền khác, nó phải công bố một bản ghi ủy quyền, nếu không máy chủ nhận sẽ bỏ qua địa chỉ đó ^S2. Các dịch vụ báo cáo tự thiết lập điều này ở phía họ.

Chuyển từ p=none sang quarantine rồi reject#

Thứ tự luôn giống nhau: giám sát, rồi quarantine, rồi reject. Điều thay đổi là mỗi giai đoạn kéo dài bao lâu. Google khuyên ít nhất một tuần ở none ^S3. RFC 9989 khuyên ít nhất một tháng ở none và một khoảng thời gian tương tự ở quarantine trước khi chuyển sang reject ^S1. Một shop chỉ có vài dịch vụ gửi và báo cáo sạch có thể chuyển nhanh hơn một shop dùng cả chục công cụ.

Trước mỗi lần thay đổi, hãy kiểm tra báo cáo của tuần gần nhất để tìm các nguồn không đạt mà bạn nhận ra. Nếu nhân viên gửi bài vào các mailing list từ tên miền của shop, RFC 9989 khuyên không nên dùng p=reject: email từ mailing list bị máy chủ nhận từ chối gây ra vấn đề cho danh sách đó và có thể khiến người đăng ký bị loại khỏi danh sách ^S1. Trong trường hợp đó, dừng ở quarantine là lựa chọn hợp lý.

DMARC cho tên miền phụ#

Khi không có bản ghi riêng, một tên miền phụ như news.ninefold.example sẽ dùng chính sách của ninefold.example. Dùng sp để đặt chính sách khác cho các tên miền phụ hiện có, và np cho các tên không tồn tại, vốn là một cách phổ biến để giả mạo thương hiệu ^S1.

Một số shop gửi email marketing từ một tên miền phụ để tách biệt với email của nhân viên. Tên miền phụ đó có thể có bản ghi _dmarc riêng. RFC 9989 mô tả việc thử nghiệm một tên miền phụ với p=quarantine; t=y, sau đó chuyển sang p=reject và gỡ bỏ cờ thử nghiệm ^S1.

Cấu hình DMARC 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. Bạn có thể gửi ngay từ một địa chỉ trên tên miền dùng chung của Tellnod, như hello@yourshop.tellnodmail.com, trong 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 đó.

Hãy nhắn trong cuộc trò chuyện: “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 chúng giúp bạn. Nếu người khác quản lý DNS của bạn, hãy yêu cầu một liên kết thiết lập để gửi cho họ: họ có thể thêm các bản ghi chỉ bằng một cú nhấp với các nhà cung cấp được hỗ trợ, hoặc sao chép chúng, mà không cần tạo tài khoản. 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. Nếu bạn đã có bản ghi DMARC, chỉ giữ một bản ghi duy nhất và đảm bảo email gửi qua Tellnod đã căn chỉnh trước khi siết chặt chính sách.

Mọi chiến dịch vẫn phải qua bản xem trước trên máy tính và điện thoại cùng một thẻ xác nhận mà chỉ bạn mới có thể bấm. Kết nối Tellnod để bắt đầu với gói miễn phí, hoặc so sánh các gói trên trang bảng giá. Về những yêu cầu khác của Gmail và Yahoo, xem kiến thức cơ bản về khả năng vào hộp thư.

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