---
title: "SPF, DKIM và DMARC: Hướng Dẫn Toàn Diện Về Xác Thực Email"
description: "Làm chủ xác thực email với hướng dẫn toàn diện này về SPF, DKIM và DMARC. Tìm hiểu mỗi giao thức làm gì, cách thiết lập bản ghi DNS, khắc phục sự cố phổ biến và cải thiện khả năng gửi email."
url: https://tajo.io/vi/blog/spf-dkim-dmarc-guide/
markdown: https://tajo.io/vi/blog/spf-dkim-dmarc-guide.md
lang: vi-VN
author: "Set Noa"
author_url: https://tajo.io/vi/set-noa/
published: 2026-03-08
updated: 2026-05-04
alternates: {en-US: /blog/spf-dkim-dmarc-guide.md, bg-BG: /bg/blog/spf-dkim-dmarc-guide.md, cs-CZ: /cz/blog/spf-dkim-dmarc-guide.md, de-DE: /de/blog/spf-dkim-dmarc-guide.md, da-DK: /dk/blog/spf-dkim-dmarc-guide.md, es-ES: /es/blog/spf-dkim-dmarc-guide.md, fr-FR: /fr/blog/spf-dkim-dmarc-guide.md, el-GR: /gr/blog/spf-dkim-dmarc-guide.md, hi-IN: /hi/blog/spf-dkim-dmarc-guide.md, id-ID: /in/blog/spf-dkim-dmarc-guide.md, hr-HR: /hr/blog/spf-dkim-dmarc-guide.md, it-IT: /it/blog/spf-dkim-dmarc-guide.md, ja-JP: /jp/blog/spf-dkim-dmarc-guide.md, ko-KR: /kr/blog/spf-dkim-dmarc-guide.md, ar-SA: /ar/blog/spf-dkim-dmarc-guide.md, nl-NL: /nl/blog/spf-dkim-dmarc-guide.md, pl-PL: /pl/blog/spf-dkim-dmarc-guide.md, ro-RO: /ro/blog/spf-dkim-dmarc-guide.md, ru-RU: /ru/blog/spf-dkim-dmarc-guide.md, sv-SE: /se/blog/spf-dkim-dmarc-guide.md, zh-CN: /zh-cn/blog/spf-dkim-dmarc-guide.md, sl-SI: /sl/blog/spf-dkim-dmarc-guide.md, sr-Latn-RS: /sr/blog/spf-dkim-dmarc-guide.md, th-TH: /th/blog/spf-dkim-dmarc-guide.md, tr-TR: /tr/blog/spf-dkim-dmarc-guide.md, ur-PK: /ur/blog/spf-dkim-dmarc-guide.md, sk-SK: /sk/blog/spf-dkim-dmarc-guide.md}
---

[Email](https://tajo.io/vi/blog/?category=email)

# SPF, DKIM và DMARC: Hướng Dẫn Toàn Diện Về Xác Thực Email

Làm chủ xác thực email với hướng dẫn toàn diện này về SPF, DKIM và DMARC. Tìm hiểu mỗi giao thức làm gì, cách thiết lập bản ghi DNS, khắc phục sự cố phổ biến và cải thiện khả năng gửi email.

SPF DKIM DMARC

Sự khác biệt giữa SPF, DKIM và DMARC là gì?

SPF chỉ định máy chủ nào có thể gửi email cho domain của bạn. DKIM thêm chữ ký mã hóa chứng minh tính xác thực của tin nhắn. DMARC đặt chính sách về cách người nhận nên xử lý lỗi xác thực và cung cấp báo cáo. Cả ba hoạt động cùng nhau để xác thực email hoàn chỉnh.

[Tìm hiểu thêm](https://tajo.io/vi/blog/spf-dkim-dmarc-guide/#t%E1%BA%A1i-sao-x%C3%A1c-th%E1%BB%B1c-email-quan-tr%E1%BB%8Dng)

Xác thực email là nền tảng của việc gửi email đáng tin cậy. Nếu không cấu hình SPF, DKIM và DMARC đúng cách, những email được soạn thảo công phu của bạn có thể không bao giờ đến được hộp thư đến của khách hàng. Thay vào đó, chúng kết thúc trong thư mục spam hoặc bị từ chối hoàn toàn.

Hướng dẫn toàn diện này giải thích mỗi giao thức xác thực email làm gì, cung cấp hướng dẫn thiết lập DNS từng bước, đề cập đến việc khắc phục sự cố phổ biến và chỉ cho bạn cách xác minh cấu hình đang hoạt động chính xác.

## Tại Sao Xác Thực Email Quan Trọng

Email được thiết kế trong thời đại khi bảo mật không phải là mối quan tâm chính. Giao thức SMTP gốc không có cơ chế xác minh tích hợp để xác nhận rằng email thực sự đến từ người nó tự xưng. Điểm yếu cơ bản này cho phép giả mạo email, tấn công phishing và spam.

Các giao thức xác thực email giải quyết vấn đề này bằng cách cho phép chủ domain chỉ định:

- **Máy chủ nào có thể gửi email thay mặt họ** (SPF)
- **Bằng chứng mã hóa rằng tin nhắn là thật và chưa bị thay đổi** (DKIM)
- **Phải làm gì với tin nhắn không vượt qua xác thực** (DMARC)

### Tác Động Kinh Doanh Của Xác Thực Kém

Không có xác thực email đúng cách:

- **Khả năng giao thấp hơn**: Các nhà cung cấp lớn như Gmail, Microsoft và Yahoo lọc email chưa được xác thực mạnh hơn
- **Tỷ lệ spam cao hơn**: Email hợp lệ của bạn cạnh tranh với tin nhắn giả mạo sử dụng domain của bạn
- **Thiệt hại thương hiệu**: Các cuộc tấn công phishing mạo danh thương hiệu của bạn làm xói mòn lòng tin khách hàng
- **Mất doanh thu**: Các chiến dịch marketing không tiếp cận được người đăng ký đã đăng ký nhận email
- **Rủi ro tuân thủ**: Nhiều quy định hiện yêu cầu xác thực email đúng cách

### Bộ Ba Xác Thực

SPF, DKIM và DMARC hoạt động cùng nhau như một hệ thống xác thực hoàn chỉnh:

| Giao Thức | Làm Gì | Tương Tự |
| --- | --- | --- |
| SPF | Liệt kê các máy chủ gửi được ủy quyền | Tiêu đề công ty với các văn phòng được phê duyệt |
| DKIM | Ký điện tử tin nhắn | Con dấu sáp chứng minh tính xác thực |
| DMARC | Đặt chính sách cho lỗi + báo cáo | Hướng dẫn cách xử lý thư đáng ngờ |

Mỗi giao thức giải quyết các vector tấn công khác nhau. SPF ngăn các máy chủ không được ủy quyền gửi dưới danh nghĩa bạn. DKIM ngăn can thiệp tin nhắn sau khi gửi. DMARC kết hợp chúng lại và cung cấp khả năng hiển thị vào kết quả xác thực.

## Hiểu Về SPF (Sender Policy Framework)

SPF (Sender Policy Framework) là phương pháp xác thực email dựa trên DNS chỉ định máy chủ mail nào được ủy quyền gửi email thay mặt domain của bạn.

### SPF Hoạt Động Như Thế Nào

Khi email đến máy chủ nhận, máy chủ đó tra cứu bản ghi SPF của domain người gửi. Sau đó kiểm tra xem địa chỉ IP gửi email có được liệt kê là được ủy quyền không. Nếu IP khớp, SPF pass. Nếu không, SPF fail.

**Quá trình xác minh SPF:**

1. Bạn gửi email từ nền tảng marketing của mình
2. Máy chủ nhận trích xuất domain của bạn từ Return-Path (người gửi phong bì)
3. Máy chủ truy vấn DNS cho bản ghi SPF của domain bạn
4. Nó so sánh IP gửi với danh sách được ủy quyền trong bản ghi SPF của bạn
5. Máy chủ ghi lại kết quả pass, fail, softfail hoặc neutral

### Cú Pháp Bản Ghi SPF

Bản ghi SPF được xuất bản dưới dạng bản ghi TXT trong DNS của domain bạn. Dưới đây là cấu trúc cơ bản:

```
v=spf1 [mechanisms] [qualifier]all
```

**Thẻ phiên bản:** Luôn bắt đầu với `v=spf1`

**Cơ chế:** Xác định ai có thể gửi

| Cơ Chế | Mô Tả | Ví Dụ |
| --- | --- | --- |
| include: | Tin tưởng SPF của domain khác | include:spf.brevo.com |
| ip4: | Ủy quyền IPv4 cụ thể | ip4:192.168.1.1 |
| ip6: | Ủy quyền IPv6 cụ thể | ip6:2001:db8::1 |
| a | Cho phép IP từ bản ghi A của domain | a |
| mx | Cho phép IP từ máy chủ mail của domain | mx |
| ptr | Reverse DNS (không dùng nữa) | ptr:example.com |
| exists: | Kiểm tra có điều kiện | exists:%{i}.spf.example.com |

**Qualifier:** Xác định cách xử lý kết quả khớp

| Qualifier | Ý Nghĩa | Kết Quả |
| --- | --- | --- |
| + | Pass (mặc định) | Được ủy quyền |
| - | Fail (cứng) | Không được ủy quyền, từ chối |
| ~ | SoftFail | Không được ủy quyền, chấp nhận nhưng đánh dấu |
| ? | Neutral | Không có chính sách |

**Cơ chế all:** Áp dụng cho bất kỳ thứ gì không khớp với các cơ chế trước đó

### Ví Dụ Bản Ghi SPF

**Thiết lập cơ bản với một nhà cung cấp email:**

```
v=spf1 include:spf.brevo.com -all
```

Điều này ủy quyền cho Brevo gửi email cho domain của bạn và từ chối tất cả các người gửi khác.

**Nhiều dịch vụ email:**

```
v=spf1 include:spf.brevo.com include:_spf.google.com include:spf.protection.outlook.com -all
```

Điều này ủy quyền cho Brevo, Google Workspace và Microsoft 365.

**Bao gồm máy chủ mail của bạn:**

```
v=spf1 ip4:203.0.113.10 include:spf.brevo.com -all
```

Điều này ủy quyền cho một địa chỉ IP cụ thể (máy chủ của bạn) cộng với Brevo.

**Bắt đầu với soft fail khi kiểm tra:**

```
v=spf1 include:spf.brevo.com ~all
```

Sử dụng `~all` thay vì `-all` đánh dấu lỗi nhưng không từ chối. Hữu ích trong quá trình thiết lập ban đầu.

### Thiết Lập Bản Ghi SPF

**Bước 1: Xác định nguồn gửi của bạn**

Liệt kê mọi dịch vụ gửi email từ domain của bạn:

- Nền tảng email marketing (Brevo, Mailchimp, v.v.)
- Dịch vụ email giao dịch
- Hệ thống CRM
- Phần mềm help desk
- Email công ty (Google Workspace, Microsoft 365)
- Máy chủ mail của riêng bạn

**Bước 2: Thu thập các câu lệnh include SPF**

Mỗi nhà cung cấp dịch vụ email ghi lại include SPF cần thiết của họ. Ví dụ phổ biến:

| Nhà Cung Cấp | SPF Include |
| --- | --- |
| Brevo | include:spf.brevo.com |
| Google Workspace | include:\_spf.google.com |
| Microsoft 365 | include:spf.protection.outlook.com |
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:mailgun.org |

**Bước 3: Tạo bản ghi SPF của bạn**

Kết hợp tất cả các include vào một bản ghi:

```
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**Bước 4: Thêm bản ghi DNS**

Trong giao diện quản lý DNS:

- Loại: TXT
- Host/Tên: @ (hoặc để trống cho domain gốc)
- Giá trị: Bản ghi SPF đầy đủ của bạn
- TTL: 3600 (hoặc mặc định)

**Bước 5: Xác minh bản ghi**

Sử dụng công cụ tra cứu DNS để xác nhận:

```bash
dig TXT yourdomain.com
```

Hoặc sử dụng các công cụ trực tuyến như MXToolbox SPF Lookup.

### Giới Hạn và Phương Pháp Tốt Nhất với SPF

**Giới hạn 10 lần tra cứu DNS:**

SPF có tối đa 10 lần tra cứu DNS. Mỗi `include:` tính là một lần tra cứu, và các bản ghi được include có thể chứa các include của riêng chúng, tính vào giới hạn của bạn. Vượt quá điều này gây ra SPF permerror (lỗi vĩnh viễn), làm hỏng tất cả các kiểm tra.

**Chiến lược để duy trì dưới giới hạn:**

- Sử dụng địa chỉ IP trực tiếp khi có thể (ip4: không tính là tra cứu)
- Hợp nhất dịch vụ sử dụng cùng nhà cung cấp
- Sử dụng dịch vụ làm phẳng SPF chuyển đổi include thành địa chỉ IP
- Xóa các include không sử dụng từ dịch vụ cũ

**Các phương pháp tốt nhất khác với SPF:**

- Chỉ một bản ghi SPF mỗi domain (nhiều bản ghi gây lỗi)
- Bắt đầu với `~all` (softfail) trong quá trình thiết lập, chuyển sang `-all` sau khi xác nhận
- Cập nhật SPF khi thay đổi nhà cung cấp email
- Không sử dụng cơ chế `ptr` không còn dùng nữa
- Giữ bản ghi đơn giản nhất có thể

### Lỗi SPF Phổ Biến

**Nhiều bản ghi SPF:**

```
Wrong:
v=spf1 include:spf.brevo.com -all
v=spf1 include:_spf.google.com -all

Correct:
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**Vượt quá giới hạn tra cứu DNS:**

Nếu bạn có nhiều include, hãy kiểm tra tổng số lần tra cứu. Sử dụng các công cụ phân tích SPF để xác minh bạn dưới 10.

**Quên cập nhật sau khi thay đổi nhà cung cấp:**

Khi chuyển từ dịch vụ email này sang dịch vụ khác, hãy xóa include cũ và thêm cái mới.

**Sử dụng +all:**

Không bao giờ sử dụng `+all` vì nó ủy quyền cho mọi người gửi dưới danh nghĩa domain của bạn.

## Hiểu Về DKIM (DomainKeys Identified Mail)

DKIM (DomainKeys Identified Mail) thêm chữ ký mã hóa vào email của bạn, chứng minh tin nhắn bắt nguồn từ domain của bạn và không bị sửa đổi trong quá trình truyền.

### DKIM Hoạt Động Như Thế Nào

DKIM sử dụng mã hóa khóa công khai:

1. Nhà cung cấp email của bạn tạo ra cặp khóa công khai/riêng tư
2. Bạn xuất bản khóa công khai trong DNS
3. Nhà cung cấp ký email gửi đi bằng khóa riêng tư
4. Máy chủ nhận lấy khóa công khai của bạn từ DNS
5. Họ sử dụng khóa công khai để xác minh chữ ký
6. Chữ ký hợp lệ chứng minh tính xác thực và toàn vẹn

**DKIM ký gì:**

Chữ ký DKIM thường bao gồm các header cụ thể và nội dung tin nhắn:

- Header From (bắt buộc)
- Header Subject
- Header Date
- Nội dung tin nhắn
- Các header khác tùy cấu hình

Điều này ngăn kẻ tấn công sửa đổi các phần tử này sau khi gửi.

### Cấu Trúc Bản Ghi DKIM

Bản ghi DKIM được xuất bản dưới dạng bản ghi TXT với định dạng đặt tên cụ thể:

```
selector._domainkey.yourdomain.com
```

**Selector** là một định danh duy nhất cho phép bạn có nhiều khóa DKIM. Các dịch vụ email khác nhau sử dụng các selector khác nhau (ví dụ: brevo, google, s1, s2).

**Nội dung bản ghi DKIM:**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
```

| Thẻ | Mô Tả | Ví Dụ |
| --- | --- | --- |
| v= | Phiên bản (luôn là DKIM1) | v=DKIM1 |
| k= | Loại khóa (thường là rsa) | k=rsa |
| p= | Khóa công khai (base64) | p=MIGfMA0… |
| t= | Cờ (tùy chọn) | t=s (chế độ strict) |
| h= | Thuật toán hash (tùy chọn) | h=sha256 |

### Thiết Lập DKIM

**Bước 1: Tạo khóa DKIM**

Nhà cung cấp dịch vụ email của bạn thường tạo khóa cho bạn. Trong Brevo:

1. Vào Settings > Senders, Domains & Dedicated IPs
2. Chọn domain của bạn
3. Điều hướng đến phần DKIM
4. Sao chép bản ghi DNS được cung cấp

Đối với máy chủ mail tự lưu trữ, tạo khóa bằng OpenSSL:

```bash
openssl genrsa -out private.key 2048
openssl rsa -in private.key -pubout -out public.key
```

**Bước 2: Thêm bản ghi DNS DKIM**

Trong quản lý DNS của bạn:

- Loại: TXT
- Host/Tên: selector.\_domainkey (ví dụ: brevo.\_domainkey)
- Giá trị: Bản ghi DKIM từ nhà cung cấp của bạn
- TTL: 3600

**Bước 3: Bật ký DKIM**

Trong cài đặt của nhà cung cấp email, bật ký DKIM cho domain của bạn. Điều này cho nhà cung cấp biết ký các tin nhắn gửi đi.

**Bước 4: Xác minh thiết lập**

Gửi email kiểm tra và kiểm tra header để tìm DKIM-Signature. Sử dụng các công cụ như:

- mail-tester.com
- DKIM Validator
- MXToolbox DKIM Lookup

### Phương Pháp Tốt Nhất với DKIM

**Sử dụng khóa 2048-bit:**

Khóa 1024-bit cũ được coi là yếu. Các tiêu chuẩn bảo mật hiện đại khuyến nghị tối thiểu khóa RSA 2048-bit.

**Xoay khóa định kỳ:**

Mặc dù không yêu cầu nghiêm ngặt, việc xoay khóa DKIM hàng năm là thực hành bảo mật tốt. Thêm khóa mới trước khi xóa khóa cũ để tránh khoảng trống.

**Theo dõi sự xâm phạm khóa:**

Nếu khóa riêng tư của bạn bị xâm phạm, kẻ tấn công có thể ký tin nhắn dưới danh nghĩa bạn. Theo dõi các mẫu xác thực bất thường.

**Sử dụng các selector khác nhau cho các dịch vụ khác nhau:**

Mỗi nhà cung cấp email nên sử dụng một selector duy nhất. Điều này cho phép quản lý khóa độc lập và không xung đột với các dịch vụ khác.

**Kiểm tra lan truyền DNS:**

Khóa DKIM có thể dài. Đảm bảo nhà cung cấp DNS của bạn hỗ trợ bản ghi TXT có đủ độ dài. Một số nhà cung cấp yêu cầu chia khóa thành nhiều chuỗi.

### Đọc Header DKIM

Khi bạn nhận email, header DKIM-Signature hiển thị:

```
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=brevo;
  h=from:to:subject:date:message-id;
  bh=base64hashofbody;
  b=base64signature;
```

| Thẻ | Ý Nghĩa |
| --- | --- |
| v= | Phiên bản (luôn là 1) |
| a= | Thuật toán (rsa-sha256 được khuyến nghị) |
| c= | Chuẩn hóa (relaxed cho phép thay đổi nhỏ) |
| d= | Domain ký |
| s= | Selector |
| h= | Header đã ký |
| bh= | Hash nội dung |
| b= | Chữ ký |

## Hiểu Về DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC xây dựng dựa trên SPF và DKIM để cung cấp thực thi chính sách và báo cáo. Nó cho các máy chủ nhận biết phải làm gì khi xác thực thất bại và gửi cho bạn các báo cáo về kết quả xác thực.

### DMARC Hoạt Động Như Thế Nào

DMARC thêm hai khả năng quan trọng:

1. **Thực thi chính sách**: Xác định cách người nhận nên xử lý thất bại xác thực
2. **Báo cáo**: Nhận dữ liệu về ai đang gửi email sử dụng domain của bạn

**Quá trình xác minh DMARC:**

1. Máy chủ nhận nhận email tự xưng là từ domain của bạn
2. Nó kiểm tra SPF (IP gửi có khớp không?)
3. Nó kiểm tra DKIM (chữ ký có hợp lệ không?)
4. Nó kiểm tra căn chỉnh DMARC (các domain được xác thực có khớp với header From không?)
5. Nếu căn chỉnh thất bại, nó áp dụng chính sách DMARC của bạn
6. Nó gửi cho bạn các báo cáo tổng hợp và/hoặc pháp y

*How DMARC decides what happens to a message*

### Căn Chỉnh DMARC

DMARC yêu cầu **căn chỉnh** giữa domain trong header From và các domain vượt qua SPF hoặc DKIM:

**Căn Chỉnh SPF:** Domain trong Return-Path (người gửi phong bì) phải khớp hoặc là subdomain của domain header From.

**Căn Chỉnh DKIM:** Domain trong chữ ký DKIM (thẻ d=) phải khớp hoặc là subdomain của domain header From.

**Chế độ căn chỉnh:**

| Chế Độ | Mô Tả |
| --- | --- |
| Strict (s) | Yêu cầu khớp domain chính xác |
| Relaxed (r) | Cho phép subdomain (mặc định) |

Với căn chỉnh relaxed, nếu header From của bạn hiển thị `marketing@example.com` và DKIM ký với `brevo.example.com`, căn chỉnh pass vì cả hai chia sẻ domain tổ chức `example.com`.

### Cú Pháp Bản Ghi DMARC

Bản ghi DMARC được xuất bản dưới dạng bản ghi TXT tại `_dmarc.yourdomain.com`:

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

**Thẻ bắt buộc:**

| Thẻ | Mô Tả | Giá Trị |
| --- | --- | --- |
| v= | Phiên bản | DMARC1 (luôn) |
| p= | Chính sách | none, quarantine, reject |

**Thẻ tùy chọn:**

| Thẻ | Mô Tả | Mặc Định |
| --- | --- | --- |
| rua= | Địa chỉ báo cáo tổng hợp | không có |
| ruf= | Địa chỉ báo cáo pháp y | không có |
| pct= | Phần trăm áp dụng chính sách | 100 |
| sp= | Chính sách subdomain | giống như p= |
| adkim= | Chế độ căn chỉnh DKIM | r (relaxed) |
| aspf= | Chế độ căn chỉnh SPF | r (relaxed) |
| fo= | Tùy chọn báo cáo pháp y | 0 |
| ri= | Khoảng báo cáo (giây) | 86400 |

### Giải Thích Các Chính Sách DMARC

**p=none (Chỉ theo dõi):**

Không có hành động nào được thực hiện khi thất bại. Email được giao bình thường. Sử dụng điều này trong khi phân tích báo cáo và sửa các vấn đề xác thực.

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

**p=quarantine (Thư mục spam):**

Email thất bại được gửi đến thư mục spam/junk. Một bước trung gian tốt trước khi từ chối hoàn toàn.

```
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
```

**p=reject (Chặn):**

Email thất bại bị từ chối hoàn toàn. Bảo vệ tối đa nhưng hãy đảm bảo tất cả nguồn hợp lệ đều pass trước.

```
v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
```

### Thiết Lập DMARC

**Bước 1: Đảm bảo SPF và DKIM đang hoạt động**

DMARC phụ thuộc vào SPF và DKIM. Xác minh cả hai được cấu hình đúng trước khi thêm DMARC.

**Bước 2: Bắt đầu với theo dõi (p=none)**

Bắt đầu với chính sách dễ chịu nhất để thu thập dữ liệu mà không ảnh hưởng đến giao hàng:

```
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
```

**Bước 3: Thêm bản ghi DNS**

Trong quản lý DNS của bạn:

- Loại: TXT
- Host/Tên: \_dmarc
- Giá trị: Bản ghi DMARC của bạn
- TTL: 3600

**Bước 4: Phân tích báo cáo trong 2-4 tuần**

Báo cáo tổng hợp DMARC đến hàng ngày dưới dạng tệp XML. Chúng hiển thị:

- IP nào đã gửi email sử dụng domain của bạn
- Tỷ lệ pass/fail SPF và DKIM
- Kết quả căn chỉnh DMARC
- Hành động của máy chủ nhận

Sử dụng các công cụ phân tích báo cáo DMARC để trực quan hóa dữ liệu này:

- DMARC Analyzer
- Postmark DMARC
- Valimail
- dmarcian

**Bước 5: Sửa các vấn đề xác thực**

Các vấn đề phổ biến được tiết lộ bởi báo cáo:

- Dịch vụ hợp lệ bị thiếu trong SPF
- DKIM không được bật cho dịch vụ gửi
- Dịch vụ bên thứ ba gửi mà không có xác thực đúng
- Chuyển tiếp phá vỡ căn chỉnh SPF

**Bước 6: Thực thi dần dần**

Sau khi các nguồn hợp lệ pass liên tục:

1. Chuyển sang `p=quarantine; pct=10` (cách ly 10% lỗi)
2. Tăng pct lên 25, 50, 75, 100
3. Chuyển sang `p=reject; pct=10`
4. Tăng lên từ chối hoàn toàn

**Bước 7: Duy trì và theo dõi**

Tiếp tục xem xét báo cáo. Nguồn gửi mới, thay đổi nhà cung cấp hoặc trôi dạt cấu hình có thể gây ra lỗi xác thực.

### Hiểu Báo Cáo DMARC

**Báo cáo tổng hợp (rua):**

Tóm tắt XML hàng ngày hiển thị:

- Tổ chức báo cáo
- Phạm vi ngày
- Chính sách đã xuất bản của bạn
- Kết quả xác thực theo IP nguồn
- Khối lượng email

Ví dụ trích đoạn:

```xml
<record>
  <source_ip>203.0.113.10</source_ip>
  <count>1250</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>pass</dkim>
    <spf>pass</spf>
  </policy_evaluated>
</record>
```

**Báo cáo pháp y (ruf):**

Chi tiết tin nhắn riêng lẻ cho các lỗi. Chi tiết hơn nhưng nhạy cảm về quyền riêng tư. Nhiều người nhận không gửi báo cáo pháp y.

### Phương Pháp Tốt Nhất với DMARC

**Luôn bắt đầu với p=none:**

Nhảy trực tiếp đến reject có thể chặn email hợp lệ. Hãy theo dõi trước.

**Sử dụng địa chỉ email chuyên dụng cho báo cáo:**

Báo cáo DMARC có thể nhiều. Sử dụng địa chỉ chuyên dụng hoặc dịch vụ bên thứ ba.

**Đặt chính sách subdomain (sp=):**

Nếu bạn không gửi email từ subdomain, hãy đặt `sp=reject` để bảo vệ chúng khỏi giả mạo.

**Sử dụng phần trăm (pct=) cho triển khai dần dần:**

Thẻ pct cho phép bạn thực thi chính sách trên một phần trăm lỗi trong khi theo dõi phần còn lại.

**Cân nhắc dịch vụ DMARC chuyên dụng:**

Đối với các tổ chức lớn, các dịch vụ như Valimail, dmarcian hoặc Postmark DMARC cung cấp phân tích báo cáo tốt hơn so với các tệp XML thô.

## Thiết Lập Bản Ghi DNS: Hướng Dẫn Đầy Đủ

Thiết lập xác thực email yêu cầu thêm các bản ghi DNS cụ thể. Phần này cung cấp hướng dẫn đầy đủ cho các nhà cung cấp DNS lớn.

### Thu Thập Các Giá Trị Cần Thiết

Trước khi bắt đầu, hãy thu thập các giá trị này từ các nhà cung cấp email của bạn:

**Cho SPF:**

- Tất cả câu lệnh include (ví dụ: include:spf.brevo.com)
- Bất kỳ địa chỉ IP cụ thể nào bạn cần ủy quyền

**Cho DKIM:**

- Tên selector (ví dụ: brevo, google, s1)
- Giá trị khóa DKIM đầy đủ

**Cho DMARC:**

- Địa chỉ email báo cáo của bạn

### Thêm Bản Ghi Trong Các Nhà Cung Cấp DNS Phổ Biến

**Cloudflare:**

1. Đăng nhập vào Cloudflare Dashboard
2. Chọn domain của bạn
3. Vào DNS > Records
4. Nhấp Add Record
5. Cho SPF: Type=TXT, Name=@, Content=bản ghi SPF của bạn
6. Cho DKIM: Type=TXT, Name=selector.\_domainkey, Content=khóa DKIM
7. Cho DMARC: Type=TXT, Name=\_dmarc, Content=bản ghi DMARC
8. Nhấp Save

**Google Domains/Squarespace:**

1. Vào cài đặt DNS cho domain của bạn
2. Cuộn xuống Custom Records
3. Nhấp Manage Custom Records
4. Thêm mỗi bản ghi với loại, host và dữ liệu phù hợp
5. Cho SPF: Host=@, Type=TXT, Data=bản ghi SPF
6. Cho DKIM: Host=selector.\_domainkey, Type=TXT, Data=khóa DKIM
7. Cho DMARC: Host=\_dmarc, Type=TXT, Data=bản ghi DMARC

**GoDaddy:**

1. Vào My Products > Domains
2. Nhấp DNS bên cạnh domain của bạn
3. Cuộn xuống phần Records
4. Nhấp Add cho mỗi bản ghi mới
5. Chọn TXT cho Type
6. Nhập Name (@ cho SPF, selector.\_domainkey cho DKIM, \_dmarc cho DMARC)
7. Nhập Value
8. Save

**Namecheap:**

1. Vào Domain List > Manage
2. Nhấp Advanced DNS
3. Add New Record cho mỗi bản ghi
4. Chọn TXT Record
5. Host: @ cho SPF, selector.\_domainkey cho DKIM, \_dmarc cho DMARC
6. Value: Nội dung bản ghi của bạn
7. Save All Changes

### Lan Truyền DNS

Sau khi thêm bản ghi, các thay đổi cần thời gian để lan truyền toàn cầu. Điều này thường mất:

- 5-30 phút để hiển thị ban đầu
- Lên đến 48 giờ để lan truyền toàn cầu đầy đủ

Sử dụng dig hoặc nslookup để xác minh:

```bash
dig TXT yourdomain.com
dig TXT selector._domainkey.yourdomain.com
dig TXT _dmarc.yourdomain.com
```

Hoặc sử dụng các công cụ trực tuyến như whatsmydns.net để kiểm tra lan truyền toàn thế giới.

### Ví Dụ Thiết Lập Đầy Đủ

Cho domain sử dụng Brevo và Google Workspace:

**Bản ghi SPF (TXT tại @):**

```
v=spf1 include:spf.brevo.com include:_spf.google.com -all
```

**Bản ghi DKIM cho Brevo (TXT tại brevo.\_domainkey):**

```
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA... [key from Brevo dashboard]
```

**Bản ghi DKIM cho Google (TXT tại google.\_domainkey):**

```
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA... [key from Google Admin]
```

**Bản ghi DMARC (TXT tại \_dmarc):**

```
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
```

## Khắc Phục Sự Cố Phổ Biến

Ngay cả với thiết lập cẩn thận, xác thực email có thể thất bại. Dưới đây là các vấn đề phổ biến và cách giải quyết.

### Khắc Phục Sự Cố SPF

**Không tìm thấy bản ghi SPF:**

Triệu chứng: Kiểm tra SPF hiển thị “none” hoặc “no record”

Nguyên nhân:

- Bản ghi chưa được thêm vào DNS
- Bản ghi được thêm vào vị trí sai (subdomain thay vì gốc)
- Lan truyền DNS chưa hoàn tất

Giải pháp:

- Xác minh bản ghi tồn tại với `dig TXT yourdomain.com`
- Kiểm tra trường Name/Host (nên là @ hoặc để trống cho domain gốc)
- Chờ lan truyền DNS (lên đến 48 giờ)

**SPF PermError (quá nhiều tra cứu):**

Triệu chứng: Kết quả SPF hiển thị “permerror”

Nguyên nhân:

- Hơn 10 tra cứu DNS trong bản ghi SPF của bạn
- Các include chứa quá nhiều include lồng nhau

Giải pháp:

- Kiểm tra các include của bạn và xóa những cái không sử dụng
- Thay thế include bằng các mục ip4: khi có thể
- Sử dụng dịch vụ làm phẳng SPF
- Hợp nhất dịch vụ trên ít nhà cung cấp hơn

**SPF SoftFail hoặc Fail cho thư hợp lệ:**

Triệu chứng: Email hợp lệ không vượt qua SPF

Nguyên nhân:

- Dịch vụ gửi không được bao gồm trong SPF
- Gửi từ IP không được ủy quyền
- Sử dụng relay thay đổi người gửi phong bì

Giải pháp:

- Thêm include bị thiếu cho dịch vụ gửi của bạn
- Kiểm tra IP nào thực sự gửi email (từ header)
- Liên hệ nhà cung cấp email của bạn để biết cài đặt SPF đúng

**Nhiều bản ghi SPF:**

Triệu chứng: SPF hiển thị permerror hoặc lỗi ngẫu nhiên

Nguyên nhân:

- Hai hoặc nhiều bản ghi TXT chứa v=spf1

Giải pháp:

- Kết hợp tất cả cơ chế thành một bản ghi SPF duy nhất
- Xóa bản ghi SPF trùng lặp

### Khắc Phục Sự Cố DKIM

**Thiếu chữ ký DKIM:**

Triệu chứng: Không có header DKIM-Signature trong email

Nguyên nhân:

- Ký DKIM không được bật trong nhà cung cấp email
- Xác minh domain chưa hoàn tất
- Gửi qua đường không có DKIM

Giải pháp:

- Bật DKIM trong cài đặt nhà cung cấp của bạn
- Hoàn tất các bước xác minh domain
- Kiểm tra tài liệu nhà cung cấp để biết thiết lập DKIM

**Xác minh DKIM thất bại:**

Triệu chứng: DKIM hiển thị “fail” trong kết quả xác thực

Nguyên nhân:

- Bản ghi DNS không được xuất bản hoặc không chính xác
- Sử dụng sai selector
- Không khớp khóa giữa DNS và ký
- Tin nhắn bị sửa đổi trong quá trình truyền

Giải pháp:

- Xác minh bản ghi DNS tồn tại tại selector.\_domainkey.domain
- So sánh selector trong header DKIM-Signature với DNS
- Tạo lại khóa nếu nghi ngờ không khớp
- Kiểm tra các bộ lọc mail hoặc relay sửa đổi tin nhắn

**Khóa DKIM quá dài cho DNS:**

Triệu chứng: Không thể lưu bản ghi DKIM, lỗi cắt ngắn

Nguyên nhân:

- Khóa 2048-bit vượt quá độ dài bản ghi TXT đơn
- Nhà cung cấp DNS có giới hạn ký tự

Giải pháp:

- Chia khóa thành nhiều chuỗi được trích dẫn (hầu hết nhà cung cấp xử lý tự động)
- Kiểm tra xem nhà cung cấp DNS của bạn có hỗ trợ bản ghi TXT dài không
- Sử dụng khóa 1024-bit tạm thời (kém an toàn hơn)

Ví dụ bản ghi DKIM được chia:

```
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...continuation of key..."
```

### Khắc Phục Sự Cố DMARC

**Lỗi căn chỉnh DMARC:**

Triệu chứng: SPF và DKIM pass nhưng DMARC fail

Nguyên nhân:

- Domain được xác thực không khớp với domain header From
- Dịch vụ gửi bên thứ ba sử dụng domain của họ
- Người gửi phong bì được cấu hình sai

Giải pháp:

- Đảm bảo nhà cung cấp email của bạn ký với domain của bạn (DKIM tùy chỉnh)
- Cấu hình Return-Path/người gửi phong bì tùy chỉnh
- Sử dụng chế độ căn chỉnh relaxed (adkim=r; aspf=r)

**Không nhận báo cáo DMARC:**

Triệu chứng: Không có báo cáo tổng hợp đến

Nguyên nhân:

- Địa chỉ rua không chính xác
- Địa chỉ email không thể nhận email bên ngoài
- Báo cáo vào spam
- Máy chủ nhận không gửi báo cáo

Giải pháp:

- Xác minh cú pháp rua: `rua=mailto:address@domain.com`
- Kiểm tra địa chỉ báo cáo có thể nhận thư bên ngoài
- Kiểm tra thư mục spam để tìm báo cáo
- Lưu ý: Không phải tất cả người nhận đều gửi báo cáo DMARC

**Không tìm thấy bản ghi DMARC:**

Triệu chứng: Kiểm tra DMARC hiển thị “no record”

Nguyên nhân:

- Bản ghi được xuất bản tại vị trí sai
- Sử dụng định dạng sai (phải là TXT tại subdomain \_dmarc)

Giải pháp:

- Bản ghi phải ở \_dmarc.yourdomain.com
- Xác minh với `dig TXT _dmarc.yourdomain.com`

### Công Cụ Khắc Phục Sự Cố Chung

**Công cụ xác thực trực tuyến:**

- MXToolbox (mxtoolbox.com) - Tra cứu SPF, DKIM, DMARC
- Mail Tester (mail-tester.com) - Gửi email kiểm tra để phân tích đầy đủ
- DMARC Analyzer - Trực quan hóa báo cáo
- Google Admin Toolbox - Kiểm tra MX, SPF, DKIM

**Công cụ command line:**

```bash
# Check SPF
dig TXT yourdomain.com

# Check DKIM
dig TXT selector._domainkey.yourdomain.com

# Check DMARC
dig TXT _dmarc.yourdomain.com

# Check from specific DNS server
dig @8.8.8.8 TXT yourdomain.com
```

**Phân tích header email:**

Kiểm tra header Authentication-Results trong email đã nhận:

```
Authentication-Results: mx.google.com;
  dkim=pass header.d=example.com header.s=brevo;
  spf=pass smtp.mailfrom=example.com;
  dmarc=pass action=none header.from=example.com
```

## Xác Thực Email và Brevo

Brevo cung cấp hỗ trợ xác thực email toàn diện, giúp việc cấu hình SPF, DKIM và DMARC cho domain gửi của bạn trở nên đơn giản.

### Thiết Lập Xác Thực Trong Brevo

**Bước 1: Thêm domain của bạn**

1. Đăng nhập vào tài khoản Brevo của bạn
2. Điều hướng đến Settings > Senders, Domains & Dedicated IPs
3. Nhấp Add a Domain
4. Nhập tên domain của bạn

**Bước 2: Cấu hình SPF**

Brevo cung cấp include SPF để thêm vào DNS của bạn:

```
include:spf.brevo.com
```

Thêm vào bản ghi SPF hiện có của bạn hoặc tạo mới:

```
v=spf1 include:spf.brevo.com -all
```

**Bước 3: Cấu hình DKIM**

Brevo tạo khóa DKIM tự động. Sao chép bản ghi được cung cấp:

1. Vào cài đặt domain của bạn trong Brevo
2. Tìm phần DKIM
3. Sao chép tên và giá trị bản ghi DNS
4. Thêm bản ghi TXT vào DNS của bạn

**Bước 4: Xác minh cấu hình**

Brevo tự động kiểm tra bản ghi DNS của bạn. Dấu kiểm màu xanh lá cây biểu thị cấu hình thành công.

### Lợi Ích Của Xác Thực Brevo Đúng Cách

Khi bạn cấu hình xác thực đúng cách với Brevo:

- **Tỷ lệ vào hộp thư đến cao hơn**: Gmail, Microsoft và các nhà cung cấp khác tin tưởng các tin nhắn được xác thực
- **Bảo vệ thương hiệu**: DMARC ngăn giả mạo domain của bạn
- **Phân tích tốt hơn**: Theo dõi chính xác các lần mở và nhấp
- **Xây dựng uy tín**: Xác thực nhất quán xây dựng uy tín người gửi

## Kết Luận

Xác thực email qua SPF, DKIM và DMARC không còn là tùy chọn cho các doanh nghiệp phụ thuộc vào giao tiếp email. Các giao thức này bảo vệ thương hiệu của bạn khỏi giả mạo, cải thiện khả năng giao và xây dựng sự tin tưởng cần thiết cho email marketing hiệu quả.

**Những điểm chính cần nhớ:**

- **SPF** ủy quyền các máy chủ gửi qua DNS
- **DKIM** chứng minh tính xác thực của tin nhắn bằng chữ ký mã hóa
- **DMARC** thực thi chính sách và cung cấp khả năng hiển thị qua báo cáo
- Bắt đầu với theo dõi (p=none) trước khi thực thi từ chối
- Tất cả nguồn gửi hợp lệ phải được cấu hình đúng
- Theo dõi thường xuyên ngăn trôi dạt cấu hình

Email giao dịch của bạn tiếp cận khách hàng một cách đáng tin cậy, các chiến dịch marketing của bạn đạt được tỷ lệ vào hộp thư đến tốt hơn và thương hiệu của bạn vẫn được bảo vệ khỏi các cuộc tấn công giả mạo.

Sẵn sàng cải thiện khả năng giao email? Bắt đầu bằng cách kiểm tra thiết lập xác thực hiện tại của bạn với các công cụ được đề cập trong hướng dẫn này, sau đó cấu hình có hệ thống SPF, DKIM và DMARC theo các hướng dẫn từng bước được cung cấp.

## Tajo phù hợp ở đâu

Tajo: công cụ xây dựng tích hợp vận hành bằng tác nhân. Giữ nguyên nhà cung cấp của bạn. Các tác nhân kết nối mọi thứ còn lại, và bạn phê duyệt từng đồng bộ. Tajo đang trong giai đoạn truy cập sớm. [Đăng ký dùng sớm](https://tajo.io/vi/#early-access)

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

**SPF, DKIM và DMARC là gì?**

SPF xác minh máy chủ gửi, DKIM thêm chữ ký số vào email, còn DMARC cho bên nhận biết cách xử lý thư không được xác thực. Kết hợp lại, chúng xác thực email của bạn và bảo vệ khỏi giả mạo.

**Tôi có cần cả ba (SPF, DKIM, DMARC) không?**

Có. Google và Yahoo hiện yêu cầu SPF và DKIM với mọi người gửi, và DMARC với những ai gửi hơn 5.000 email mỗi ngày. Cả ba cùng nhau mang lại khả năng gửi đến hộp thư và bảo mật tốt nhất.

**Làm thế nào để thiết lập SPF, DKIM và DMARC?**

Thêm bản ghi DNS cho tên miền của bạn: SPF là bản ghi TXT liệt kê các máy chủ gửi được phép, DKIM là bản ghi TXT chứa khóa công khai và DMARC là bản ghi TXT chứa chính sách của bạn. Nền tảng email sẽ cung cấp các giá trị cụ thể.

**Sự khác biệt giữa SPF, DKIM và DMARC là gì?**

SPF chỉ định máy chủ nào có thể gửi email cho domain của bạn. DKIM thêm chữ ký mã hóa chứng minh tính xác thực của tin nhắn. DMARC đặt chính sách về cách người nhận nên xử lý lỗi xác thực và cung cấp báo cáo. Cả ba hoạt động cùng nhau để xác thực email hoàn chỉnh.

**Tôi có cần cả ba (SPF, DKIM và DMARC) không?**

Để tối ưu khả năng giao và bảo mật, có. SPF một mình dễ bị giả mạo. DKIM một mình không chỉ định chính sách. DMARC yêu cầu SPF hoặc DKIM để hoạt động. Cùng nhau, chúng cung cấp bảo vệ toàn diện và tỷ lệ vào hộp thư đến tốt nhất.

**Mất bao lâu để xác thực email hoạt động?**

Các thay đổi DNS thường lan truyền trong vòng 30 phút đến 48 giờ. Sau khi lan truyền, xác thực áp dụng ngay lập tức. Tuy nhiên, việc xây dựng uy tín người gửi dựa trên xác thực nhất quán mất hàng tuần đến hàng tháng.

**Việc thiết lập DMARC với p=reject có chặn email hợp lệ của tôi không?**

Có thể nếu cấu hình không đúng. Đây là lý do tại sao bạn luôn nên bắt đầu với p=none (theo dõi), phân tích báo cáo trong 2-4 tuần, sửa các vấn đề, sau đó dần dần chuyển sang quarantine và reject. Không bao giờ bỏ qua giai đoạn theo dõi.

**Căn chỉnh SPF so với căn chỉnh DKIM là gì?**

Căn chỉnh có nghĩa là domain được xác thực khớp với domain header From hiển thị. Căn chỉnh SPF so sánh domain Return-Path. Căn chỉnh DKIM so sánh domain ký (thẻ d=). DMARC yêu cầu ít nhất một phải căn chỉnh.

**Tôi có thể có nhiều khóa DKIM cho một domain không?**

Có. Mỗi dịch vụ email có thể sử dụng selector khác nhau (ví dụ: brevo.\_domainkey, google.\_domainkey). Điều này cho phép nhiều dịch vụ ký bằng DKIM độc lập. Không có giới hạn số lượng selector DKIM.

**Tại sao email của tôi vẫn vào spam sau khi thiết lập xác thực?**

Xác thực là cần thiết nhưng chưa đủ để vào hộp thư đến. Các yếu tố khác bao gồm uy tín người gửi, chất lượng nội dung, tỷ lệ tương tác và vệ sinh danh sách. Xác thực đưa bạn vượt qua bộ lọc đầu tiên; các thực hành tốt xác định vị trí cuối cùng.

**Làm thế nào để đọc báo cáo tổng hợp DMARC?**

Báo cáo tổng hợp DMARC là tệp XML. Sử dụng các công cụ như dmarcian, Postmark DMARC hoặc DMARC Analyzer để phân tích và trực quan hóa chúng. Các công cụ này hiển thị IP nào gửi email dưới danh nghĩa domain của bạn và tỷ lệ pass/fail xác thực của họ.

**Điều gì xảy ra nếu tôi vượt quá giới hạn 10 tra cứu SPF?**

SPF trả về lỗi vĩnh viễn (permerror), và tất cả kiểm tra SPF đều thất bại. Để sửa điều này, hãy xóa các include không sử dụng, thay thế include bằng địa chỉ IP khi có thể, hoặc sử dụng dịch vụ làm phẳng SPF.

**Tôi nên sử dụng -all hay ~all trong bản ghi SPF?**

Sử dụng \`~all\` (softfail) trong khi kiểm tra và xây dựng sự tự tin. Sau khi xác nhận tất cả nguồn hợp lệ đều pass, chuyển sang \`-all\` (hard fail) để bảo vệ mạnh hơn. Softfail đánh dấu lỗi nhưng không từ chối; hard fail ủy quyền từ chối.

**Tôi nên xoay khóa DKIM thường xuyên như thế nào?**

Không có yêu cầu nghiêm ngặt, nhưng xoay hàng năm là thực hành bảo mật tốt. Khi xoay, hãy thêm khóa mới trước, đợi lan truyền DNS, bật ký với khóa mới, sau đó xóa khóa cũ sau một thời gian chuyển tiếp.

**Subdomain có cần xác thực riêng không?**

SPF: Có, mỗi subdomain cần bản ghi SPF riêng nếu gửi email từ nó. DKIM: Khóa có thể được chia sẻ hoặc riêng biệt theo subdomain. DMARC: Subdomain kế thừa chính sách cha trừ khi sp= được đặt hoặc subdomain có bản ghi DMARC riêng.

## Bài viết liên quan

### [Kiểm tra danh sách đen email: Hướng dẫn đầy đủ về phát hiện, xóa và phòng ngừa](https://tajo.io/vi/blog/email-blacklist-check-guide/)

8 thg 3, 2026 · 20 phút đọc

9 phần

### [Email Deliverability: Hướng Dẫn Toàn Diện về Vị Trí Hộp Thư Đến \[2025\]](https://tajo.io/vi/blog/email-deliverability-complete-guide/)

8 thg 3, 2025 · 21 phút đọc

Sau 60 ngày không hoạt động → Sau 90 ngày không hoạt động

### [Máy chủ MCP là gì? MCP và MCP UI hoạt động thế nào năm 2026](https://tajo.io/vi/blog/what-is-an-mcp-server/)

3 thg 10, 2026 · 20 phút đọc

Bước 1 → Bước 6