Cơ chế ptr của SPF là gì — và tại sao nó vẫn còn trong 950,631 bản ghi? (2026)

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

Số liệu tính đến 2026-06-29 · phương pháp luận v7. Điều tra tổng hợp trên 261 triệu tên miền đã được chấm điểm. Tất cả số liệu đều là tổng hợp — không bao giờ là bản ghi của một doanh nghiệp cụ thể. Xem cách chúng tôi chấm điểm.

ptr là một cơ chế SPF cho phép người gửi được xác thực thông qua tra cứu DNS ngược — và chính tiêu chuẩn SPF đã nói “đừng dùng nó” từ năm 2014. 12 năm sau, 950,631 tên miền vẫn còn công bố nó. Đó là khoảng 1 trên 146 trong số 139 triệu bản ghi SPF trên internet mang một cơ chế mà bản đặc tả đã loại bỏ từ trước khi một số tên miền đó được đăng ký.

ptr đáng lẽ phải làm gì

ptr nói rằng: “chấp nhận thư từ bất kỳ máy chủ nào có DNS ngược phân giải trở về tên miền của tôi.” Nghe có vẻ thanh lịch — không cần duy trì danh sách IP nào. Trên thực tế, nó đòi hỏi bên nhận phải thực hiện một tra cứu ngược trên IP đang kết nối, rồi xác nhận xuôi từng tên máy chủ trả về. RFC 7208 (§5.5) đã loại bỏ nó bằng những lời rõ ràng: cơ chế này “chậm, không đáng tin cậy như các cơ chế khác trong các trường hợp lỗi DNS, và đặt một yêu cầu tài nguyên lớn lên các máy chủ tên .arpa” — và chỉ dẫn rằng nó “KHÔNG NÊN được sử dụng.”

Tại sao nó vẫn là một cái bẫy vào năm 2026

Ba lý do khiến một cơ chế đã bị loại bỏ 12 năm trước vẫn còn quan trọng:

Nó đốt cạn ngân sách tra cứu của bạn. Mỗi ptr được tính vào giới hạn cứng của SPF là 10 lần tra cứu DNS cho mỗi lần kiểm tra — cái ngưỡng mà một khi vượt qua sẽ làm vô hiệu toàn bộ bản ghi với lỗi PermError. Một cơ chế chẳng làm được gì đáng tin cậy vẫn ngốn mất phần ngân sách mà các cơ chế include: thực sự của bạn cần đến.
Nó thất bại một cách khó lường. DNS ngược là góc ít được bảo trì nhất của hầu hết các mạng. Khi tra cứu ptr bị hết thời gian chờ hoặc xác nhận xuôi thất bại, thư hợp lệ của bạn sẽ mất đi lượt vượt qua SPF mà nó đang trông cậy.
Một số bên nhận bỏ qua nó hoàn toàn. Vì tiêu chuẩn đã loại bỏ nó, một số triển khai chỉ đơn giản là phớt lờ ptr — nên những người gửi mà nó đáng lẽ phải xác thực thì ngay từ đầu đã không hề được bảo vệ.

Nó đến từ đâu

Ngày nay hầu như không ai chọn ptr. Nó đến qua sự kế thừa: một hướng dẫn cài đặt viết năm 2009, một mẫu sao chép từ một cấu hình máy chủ cũ, một bản ghi “đang chạy được” được di chuyển nguyên vẹn qua ba lần đổi nhà cung cấp hosting. Đó là khuôn mẫu mà điều tra của chúng tôi thấy ở mọi cơ chế đã-bị-loại-bỏ-nhưng-vẫn-hiện-diện: lời khuyên cũ không chết đi, nó cứ bị sao-chép-dán. Những tên miền mang ptr không phải là bất cẩn — họ đang làm theo những chỉ dẫn đã bị cho về hưu từ 12 năm trước.

Cách khắc phục — miễn phí, năm phút

Tìm bản ghi SPF của bạn (dig TXT yourdomain.com hoặc kiểm tra miễn phí).
Nếu nó chứa ptr, xác định những máy chủ nào đang dựa vào nó.
Thay ptr bằng dạng chính xác: một khối ip4:/ip6: cho các máy chủ bạn kiểm soát, hoặc include: mà nhà cung cấp của bạn ghi trong tài liệu.
Nhân tiện đang ở đó, hãy xác nhận bản ghi kết thúc bằng một định tố thực sự — xem ~all so với -all.

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

ptr có nghĩa là gì trong một bản ghi SPF? Nó cho phép bất kỳ máy chủ nào có DNS ngược phân giải vào tên miền của bạn. RFC 7208 §5.5 đã loại bỏ nó vào năm 2014 vì chậm và không đáng tin cậy, và nói rằng nó KHÔNG NÊN được sử dụng — thế nhưng 950,631 tên miền vẫn còn công bố nó tính đến 2026-06-29.

Cơ chế ptr của SPF có bao giờ hợp lệ không? Nó vẫn phân tích được, và một số bên nhận vẫn đánh giá nó — nhưng tiêu chuẩn khuyến cáo không nên dùng nó trong mọi trường hợp, một số bên nhận phớt lờ nó, và nó tiêu tốn một trong mười lần tra cứu DNS của bạn. Không có cấu hình hiện đại nào mà ptr là câu trả lời đúng.

Tôi nên dùng gì thay cho ptr? Các khối ip4:/ip6: cho các máy chủ bạn kiểm soát, hoặc include: được ghi trong tài liệu của nhà cung cấp bạn. Cả hai đều xác định, nhanh và đáng tin cậy — mọi thứ mà ptr không có.

ptr có được tính vào giới hạn 10 lần tra cứu của SPF không? Có — mỗi ptr tốn ít nhất một trong mười lần tra cứu DNS mà bên nhận sẽ thực hiện trước khi bỏ cuộc với lỗi PermError. Trên những bản ghi đã chồng chất các cơ chế include:, cái cơ chế chết này có thể chính là thứ đẩy bạn vượt quá giới hạn.

Kiểm tra bản ghi của bạn xem có bóng ma nào không

Một cơ chế đã bị loại bỏ 12 năm trước, vẫn còn nằm trong DNS của bạn, chính xác là loại thứ mà chẳng ai tìm đến. Việc tìm chỉ mất nửa phút.

Kiểm tra tên miền của bạn → · Sửa SPF → · Hai bản ghi SPF = không có bản ghi nào → · Mô hình trưởng thành SPF → · Chỉ dữ liệu tổng hợp. Dữ liệu được lưu trữ và xử lý tại EU.