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

> Để cấu hình DMARC, hãy đảm bảo SPF và DKIM đạt yêu cầu với mọi dịch vụ gửi email dưới tên miền của bạn, công bố một bản ghi TXT tại _dmarc.tenmiencuaban, ví dụ v=DMARC1; p=none; rua=mailto:dmarc@tenmiencuaban, đọc các báo cáo hằng ngày trong vài tuần, rồi siết chặt chính sách sang quarantine và cuối cùng là reject.

Canonical: https://tellnod.com/vi/guides/how-to-set-up-dmarc  
Last updated: 2026-10-22  
Author: Tellnod team

## Các bước

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](https://tellnod.com/glossary#spf) hoặc [DKIM](https://tellnod.com/glossary#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. **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. **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. **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. **Đọ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 [S1][S3].
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. **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](https://tellnod.com/glossary#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](https://tellnod.com/vi/guides/spf-dkim-dmarc-explained) 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:

| Thẻ | Ví dụ | Tác dụng |
| --- | --- | --- |
| v | v=DMARC1 | Phiên bản; phải đứng trước mọi thẻ khác |
| p | p=none | Chính sách cho tên miền của bạn: none, quarantine hoặc reject |
| rua | rua=mailto:dmarc@ninefold.example | Nơi gửi các báo cáo tổng hợp hằng ngày |
| sp | sp=reject | Chính sách cho các tên miền phụ hiện có, nếu khác với p |
| np | np=reject | Chính sách cho các tên miền phụ không tồn tại |
| adkim / aspf | adkim=r | Căn chỉnh DKIM và SPF: relaxed (mặc định) hoặc strict |
| t | t=y | Thử nghiệm: yêu cầu máy chủ nhận áp dụng thấp hơn một mức so với chính sách đã nêu |

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ụ.

| Chính sách | Email không đạt | Khi nào dùng |
| --- | --- | --- |
| p=none | Vẫn được chuyển đến như bình thường; chỉ ghi nhận vào báo cáo | Trong khi bạn tìm ra mọi dịch vụ gửi |
| p=quarantine | Bị coi là đáng ngờ, thường bị đưa vào thư mục spam | Khi báo cáo cho thấy mọi dịch vụ gửi của bạn đã căn chỉnh |
| p=reject | Bị máy chủ nhận từ chối | Sau một giai đoạn sạch ở quarantine |

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](https://tellnod.com/glossary#mcp-connector) để 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](https://tellnod.com/vi/connect) để 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á](https://tellnod.com/vi/pricing). 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ư](https://tellnod.com/guides/email-deliverability-basics).

## FAQ

### Bản ghi DMARC nào phù hợp để bắt đầu?

Bắt đầu với v=DMARC1; p=none; rua=mailto: kèm theo một địa chỉ mà bạn thường xuyên kiểm tra. Bản ghi này không ảnh hưởng đến việc gửi email, và bạn sẽ bắt đầu nhận báo cáo hằng ngày [S1].

### p=none có đủ cho Gmail và Yahoo không?

Có, đối với yêu cầu dành cho người gửi số lượng lớn. Cả hai đều chấp nhận chính sách none, miễn là tên miền From căn chỉnh với SPF hoặc DKIM [S4][S5]. Áp dụng chính sách chặt hơn về sau sẽ tăng khả năng bảo vệ chống giả mạo.

### Nên giữ p=none trong bao lâu?

Cho đến khi báo cáo cho thấy mọi dịch vụ gửi hợp lệ đều đã căn chỉnh. Google khuyên ít nhất một tuần, và RFC 9989 khuyên khoảng một tháng trước khi áp dụng chính sách [S1][S3].

### Có thể có hai bản ghi DMARC không?

Không. Chỉ công bố một bản ghi TXT tại _dmarc. Nếu một lượt tra cứu trả về nhiều hơn một bản ghi DMARC, máy chủ nhận sẽ loại bỏ tất cả, vì vậy hãy gộp chúng thành một [S1].

### Bản ghi DMARC đặt ở tên miền gốc hay tên miền phụ?

Đặt ở host _dmarc của tên miền trong địa chỉ From của bạn. Bản ghi trên tên miền chính cũng áp dụng cho các tên miền phụ không có bản ghi riêng, thông qua thẻ p, sp hoặc np [S1].

## Sources

- [S1] RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC): <https://www.rfc-editor.org/rfc/rfc9989> (checked 2026-10-22)
- [S2] RFC 9990: DMARC aggregate reporting: <https://www.rfc-editor.org/rfc/rfc9990> (checked 2026-10-22)
- [S3] Google Workspace Admin Help: Recommended DMARC rollout: <https://knowledge.workspace.google.com/admin/security/recommended-dmarc-rollout> (checked 2026-10-22)
- [S4] Google Workspace Admin Help: Email sender guidelines: <https://support.google.com/a/answer/81126> (checked 2026-10-22)
- [S5] Yahoo Sender Hub: Sender best practices: <https://senders.yahooinc.com/best-practices/> (checked 2026-10-22)