Defaults.Exposed › Cách khắc phục › Guides

"Không Tìm Thấy Bản Ghi SPF" — Nhưng Bạn Đã Có Bản Ghi Rồi? 5 Nguyên Nhân Thực Sự (2026)

Đã xuất bản 2026-07-08

Số liệu tính đến 2026-06-29 · phương pháp v7. Dữ liệu tổng hợp trên 261 triệu tên miền được chấm điểm. Xem cách chúng tôi chấm điểm.

Nếu một công cụ kiểm tra báo “SPF record not found” nhưng bạn chắc chắn đã đăng ký, bản ghi thường là vô hình chứ không phải bị thiếu: 1,013,416 tên miền — khoảng một trong 138 tên miền có cố gắng dùng SPF — đăng ký hai bản ghi SPF trở lên, một PermError (RFC 7208 §3.2) mà nhiều công cụ kiểm tra báo là không-tìm-thấy, theo thống kê của Defaults.Exposed trên 261 triệu tên miền.

Có năm nguyên nhân thực sự, tất cả đều có thể khắc phục trong một buổi: sai máy chủ, bản ghi trùng lặp, loại DNS sai hoặc dấu ngoặc kép bị lỗi, máy chủ tên miền không nhất quán, hoặc xung đột độ dài/CNAME. Dưới đây: bài kiểm tra 60 giây cho mỗi nguyên nhân, theo thứ tự kiểm tra, rồi đến các bước khắc phục.

Bạn có chắc bản ghi thực sự tồn tại không?

Hãy bắt đầu từ khả năng đáng xấu hổ nhất, vì đây là trường hợp phổ biến nhất: trong số 261,086,232 tên miền được chấm điểm trong thống kê của Defaults.Exposed, 121,145,609 — 46.4% — không có bản ghi SPF nào cả. Rất nhiều trường hợp “nhưng tôi đã cài đặt rồi” hóa ra là bản ghi được thêm vào vùng staging hoặc một nhà cung cấp DNS cũ không còn là thẩm quyền nữa. Kiểm tra nhà cung cấp DNS mà máy chủ tên miền của bạn thực sự trỏ đến (thường không phải nhà đăng ký) để tìm bản ghi TXT bắt đầu bằng v=spf1. Nếu thực sự không có, bỏ qua phần điều tra và đi thẳng đến sửa bản ghi SPF của bạn.

Làm thế nào để kiểm tra bản ghi SPF đúng cách?

Các công cụ kiểm tra web truy vấn DNS qua bộ phân giải đệm của riêng họ. Để xem sự thật, hãy hỏi trực tiếp máy chủ tên miền có thẩm quyền của tên miền bạn:

# tìm máy chủ tên miền có thẩm quyền
dig NS yourdomain.com +short

# hỏi trực tiếp một trong số chúng về bản ghi TXT
dig TXT yourdomain.com @ns1.yourdnshost.com +short

Trên Windows: nslookup -type=TXT yourdomain.com ns1.yourdnshost.com.

Hai quy tắc giải thích. Thứ nhất, đếm số dòng bắt đầu bằng v=spf1 — số lượng quan trọng không kém nội dung. Thứ hai, kiểm tra xem bạn đã truy vấn đúng tên chưa: các máy chủ nhận đánh giá SPF dựa trên tên miền trong Return-Path (RFC5321.MailFrom, địa chỉ “envelope from”) — không phải địa chỉ From mà người nhận thấy. Nếu công cụ newsletter của bạn trả thư qua bounce.yourdomain.com, một bản ghi hoàn hảo tại apex không phải là bản ghi mà máy chủ nhận tra cứu.

Năm nguyên nhân thực sự là gì?

Dữ liệu tính đến 2026-06-29.

1. Bản ghi có ở sai máy chủ không?

Trường hợp điển hình: SPF được thêm vào mail.yourdomain.com khi mail được khai báo là đến từ yourdomain.com, hoặc ngược lại. SPF không kế thừa xuống dưới — một bản ghi tại apex không nói gì về subdomain, và ngược lại. Đăng ký chính xác tại tên trong Return-Path của bạn. Một nhà cung cấp gửi từ subdomain bounce của riêng họ cần một bản ghi trên subdomain đó — thường là CNAME hoặc TXT mà nhà cung cấp cung cấp (hướng dẫn cài đặt SPF GoDaddy cho thấy các trường này ở đâu).

2. Bạn có hai bản ghi SPF không?

Đây là nguyên nhân chính, và là thông báo lỗi gây nhầm lẫn nhất trong xác thực email. RFC 7208 §3.2 nói thẳng: một tên miền phải có đúng một bản ghi SPF. Hai bản ghi trở lên là PermError — máy chủ nhận coi SPF của bạn là vô hiệu. Một số công cụ báo cáo chính xác trạng thái đó (“nhiều bản ghi được tìm thấy”); những công cụ khác báo cáo hiệu ứng thực tế: không tìm thấy bản ghi SPF hợp lệ. Bạn thấy bản ghi trong bảng điều khiển và kết luận công cụ bị hỏng. Không phải — bạn có thừa một bản ghi.

Thống kê tìm thấy 1,013,416 tên miền có hai bản ghi SPF trở lên — khoảng một trong 138 tên miền có cố gắng dùng SPF — mỗi tên miền trong số đó đã tắt SPF một cách hiệu quả. Điều này thường xảy ra trong quá trình đổi nhà cung cấp: trình hướng dẫn của nhà cung cấp mới thêm bản ghi mới thay vì chỉnh sửa bản cũ. Cách khắc phục là gộp lại, không bao giờ thêm bản ghi thứ hai: kết hợp tất cả thành một dòng v=spf1 … ~all và xóa phần còn lại. Bài báo cáo dữ liệu của chúng tôi hai bản ghi SPF bằng không có bản ghi nào phân tích cách một triệu tên miền rơi vào đây; nếu vấn đề bắt đầu sau khi di chuyển, xem SPF ngừng hoạt động sau khi đổi nhà cung cấp. Khi gộp, đừng ghép mù quáng từng include: — mỗi cái tốn DNS lookups so với giới hạn cứng 10 của SPF, đổi trạng thái không-tìm-thấy thành PermError: quá nhiều DNS lookups.

3. Bạn có đăng ký sai loại bản ghi — hoặc giao diện làm hỏng nó không?

SPF ban đầu có loại bản ghi DNS riêng (type 99, theo nghĩa đen gọi là “SPF”). Nó đã bị loại bỏ: RFC 7208 yêu cầu TXT, và máy chủ nhận không truy vấn type 99. Một số bảng điều khiển DNS vẫn cung cấp “SPF” trong menu thả xuống loại bản ghi; chọn nó và bản ghi của bạn là thực, đúng định dạng, và vô hình. Kiểm tra cột loại và đăng ký lại dưới dạng TXT.

Trường hợp tinh vi hơn là dấu ngoặc kép. Dán một giá trị được bao trong dấu ngoặc kép vào một trường cũng tự thêm dấu ngoặc kép tạo ra ""v=spf1 …"" — không còn bắt đầu bằng v=spf1, nên với bộ xác thực nó không tồn tại. Đầu ra dig của bạn hiển thị sự thật; bảng điều khiển DNS thường ẩn điều đó về mặt hiển thị.

4. Nó có thực sự “vẫn đang lan truyền” không?

“Đợi 24-48 giờ để lan truyền” là lời khuyên được kê đơn nhiều nhất trong DNS. Lan truyền chỉ là bộ nhớ đệm hết hạn: một khi TTL của bản ghi đã trôi qua (thường 1 giờ, hiếm khi hơn 24 giờ), mọi bộ phân giải đều có thể thấy câu trả lời mới. Vẫn không tìm thấy sau 24 giờ? Lan truyền không phải nguyên nhân.

Hai nguyên nhân thực sự: bộ đệm âm — một bộ phân giải đã tra cứu bạn trước khi bạn thêm bản ghi lưu câu trả lời “không có bản ghi như vậy” cho đến khi TTL âm hết hạn — và máy chủ tên miền không nhất quán sau khi di chuyển, khi tên miền vẫn liệt kê máy chủ tên miền của nhà cung cấp cũ cùng với máy chủ mới và nửa thế giới đọc vùng bạn không còn chỉnh sửa nữa. Truy vấn từng máy chủ tên miền được liệt kê trực tiếp; nếu các câu trả lời khác nhau, bạn đã tìm thấy nguyên nhân. Sửa phân quyền NS của nhà đăng ký để chỉ nhà cung cấp bạn thực sự chỉnh sửa mới là thẩm quyền.

5. Bản ghi có quá dài, hoặc bị chặn bởi CNAME không?

Một chuỗi đơn trong bản ghi TXT tối đa 255 ký tự. Bản ghi SPF dài hơn là hợp lệ nhưng phải được chia thành nhiều chuỗi được trích dẫn trong một bản ghi — và giao diện nhà cung cấp DNS thường xuyên làm hỏng việc chia tách, cắt ngắn giá trị hoặc phá vỡ nó giữa chừng cơ chế nên nó không còn phân tích được nữa. Nếu bản ghi của bạn dài, kiểm tra đầu ra dig để xem giá trị kết thúc đột ngột.

Ngoài ra, DNS cấm bản ghi TXT tại một tên đã có CNAME. Nếu mail.yourdomain.com là CNAME đến nhà cung cấp của bạn, bạn không thể đặt SPF ở đó — một số bảng điều khiển chấp nhận nó và sau đó chỉ phục vụ CNAME. Đặt bản ghi ở chỗ CNAME trỏ đến (nếu bạn kiểm soát nó), hoặc cấu trúc lại để tên gửi không có CNAME. Các nhà cung cấp có xử lý TXT tốt làm cả hai dễ dàng hơn — xem hướng dẫn cài đặt SPF Cloudflare.

Làm thế nào để khắc phục, từng bước?

1. Chạy quét miễn phí tại defaults.exposed — nó đọc DNS trực tiếp và cho biết bạn đang ở trạng thái nào trong năm trạng thái trước khi bạn chỉnh sửa bất cứ điều gì.
2. Xác nhận máy chủ tên miền nào là thẩm quyền (dig NS) và chúng đều đồng thuận.
3. Truy vấn TXT tại máy chủ tên miền có thẩm quyền cho tên miền Return-Path chính xác.
4. Đếm số dòng v=spf1: bằng không → đăng ký một; hai trở lên → gộp thành một.
5. Xác nhận loại là TXT, giá trị bắt đầu chính xác bằng v=spf1, và không có dấu ngoặc kép thừa hoặc bị cắt ngắn.
6. Chờ một TTL, rồi quét lại để xác nhận nó phân giải đúng ở mọi nơi.

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

Tại sao công cụ kiểm tra báo “không tìm thấy” trong khi tôi có thể thấy bản ghi trong bảng điều khiển DNS? Thường là nguyên nhân 2 hoặc 4: một bản ghi v=spf1 thứ hai làm cả hai vô hiệu — một PermError mà một số công cụ báo là không-tìm-thấy, trạng thái mà 1,013,416 tên miền đang trong tính đến 2026-06-29 — hoặc bảng điều khiển của bạn không phải DNS thực sự có thẩm quyền.

Bao lâu thì các công cụ kiểm tra thấy bản sửa lỗi của tôi? Một TTL — thường một giờ, tối đa 24 giờ. Sau đó, “lan truyền” không phải giải thích; hãy kiểm tra lại năm nguyên nhân, bắt đầu từ tính nhất quán của máy chủ tên miền.

Tôi có nên dùng loại bản ghi “SPF” mà bảng điều khiển DNS cung cấp không? Không. Type 99 đã bị loại bỏ; RFC 7208 chỉ yêu cầu TXT. Một bản ghi type-99 vô hình với các máy chủ nhận hiện đại.

Bản ghi đã được tìm thấy rồi — tại sao mail của tôi vẫn không vượt qua SPF? Vì SPF được kiểm tra dựa trên tên miền Return-Path, không phải tiêu đề From, và bản ghi phải thực sự liệt kê các máy chủ gửi mail cho bạn. Tìm thấy là bước một; hướng dẫn sửa bản ghi SPF của bạn trình bày cách vượt qua.

Không có bản ghi SPF nào có phổ biến không? Có — 121,145,609 tên miền, 46.4% trong số 261,086,232 tên miền được chấm điểm trong thống kê Defaults.Exposed (tính đến 2026-06-29), không đăng ký SPF nào cả. Không-tìm-thấy là trạng thái mặc định của internet.

Gửi báo cáo cho chủ sở hữu

Một khi bản ghi phân giải đúng, hãy chạy lại quét và chuyển tiếp báo cáo có điểm số cho chủ doanh nghiệp hoặc khách hàng có tên miền này. Báo cáo cho thấy, bằng ngôn ngữ đơn giản, điều gì bị hỏng, bạn đã khắc phục gì, và tên miền hiện đứng ở đâu — chính xác bằng chứng họ sẽ cần cho các đợt gia hạn bảo hiểm mạng và bảng câu hỏi bảo mật nhà cung cấp. Báo cáo là biên lai cho công việc.

Kiểm tra bản ghi SPF miễn phí

Xem tên miền của bạn đang ở trạng thái nào trong năm trạng thái không-tìm-thấy — riêng tư và chỉ dành cho chủ sở hữu.

Kiểm tra tên miền của bạn → · Sửa SPF → · SPF bị hỏng sau khi đổi nhà cung cấp → · Cách chúng tôi chấm điểm → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.