Chuẩn SPF ghi trong RFC 7208 đặt một giới hạn cứng. Mục 4.6.4 nói rõ: quá trình đánh giá một bản ghi không được vượt quá mười lượt tra cứu DNS. Từ dùng trong văn bản là MUST, tức bắt buộc, không phải khuyến nghị.
Giới hạn đó có lý do. Không có nó, một bản ghi dựng khéo sẽ biến mỗi lá thư gửi tới thành một chuỗi tra cứu dài. Hệ thống thư khi ấy thành công cụ tấn công từ chối dịch vụ. Cùng mục còn khuyên chặn ở hai lượt tra cứu rỗng, phần này thì chỉ là SHOULD.
Vấn đề là rất nhiều tên miền đã vượt mà chủ tên miền không biết. Hãng DMARCguard công bố ngày 15 tháng 3 năm 2026 kết quả quét 5.499.028 tên miền lấy từ danh sách Tranco. Trong đó 3.077.219 tên miền có bật SPF, tức 56%. Và 148.655 tên miền trong nhóm đó vượt mười lượt, tức 4,8%.
Xuất xứ con số cần nói rõ. DMARCguard là hãng bán dịch vụ SPF và DMARC, phép quét dùng bộ phân tích riêng của họ, không qua bình duyệt và không ai dựng lại được. Nguồn duy nhất đo đúng chỉ số này hiện là họ. Đọc nó như số liệu của nhà cung cấp, đừng đọc như một nghiên cứu độc lập.
Bản ghi phình lên mà không ai đụng vào
Nguyên nhân nằm ở cách bản ghi SPF lớn dần theo năm tháng. Ban đầu công ty chỉ có hộp thư, khai một dòng include trỏ tới nhà cung cấp. Rồi bộ phận tiếp thị mua nền tảng gửi thư, thêm một dòng. Bộ phận hỗ trợ dùng hệ thống phiếu yêu cầu, thêm dòng nữa. Phần mềm kế toán gửi hoá đơn, thêm dòng nữa.
Chỗ hiểm nằm ở chỗ mỗi dòng include không tính một lượt. Nó tính bằng toàn bộ chuỗi tra cứu bên trong bản ghi của nhà cung cấp. Một nhà cung cấp lớn có thể tự tiêu ba tới bốn lượt, và có quyền đổi con số đó bất cứ lúc nào mà không báo khách.
Cùng khảo sát trên cho thấy mức độ tập trung. Cơ chế include chiếm 32,3% tổng số cơ chế trong các bản ghi SPF. Microsoft 365 là đích được trỏ tới nhiều nhất, xuất hiện trong 19,6% tên miền có bật SPF. Google Workspace đứng thứ hai với 13,6%. Năm nhà cung cấp đầu bảng gộp lại chiếm 44,8%.
Hàng triệu bản ghi SPF vì thế phụ thuộc vào quyết định hạ tầng của vài công ty. Bản ghi hôm nay còn hợp lệ, tuần sau đã vượt giới hạn mà chủ tên miền không làm gì cả.
PermError không tự động đánh trượt DMARC
Khi vượt giới hạn, kết quả trả về là PermError. RFC 7208 định nghĩa trạng thái đó là bản ghi không đọc được đúng, và phải có người quản trị DNS can thiệp mới xong.
Nhiều tài liệu của nhà cung cấp viết rằng PermError kéo theo trượt DMARC. Cách nói đó gọn nhưng không đúng hẳn. RFC 7489 mục 6.6.2 để việc xử lý lỗi DNS vĩnh viễn cho bên nhận tự quyết. Mục 4.2 nói một lá thư đạt DMARC nếu ít nhất một trong hai cơ chế cho kết quả pass với danh tính căn khớp.
Thư có DKIM ký đúng và căn khớp vẫn qua được DMARC dù SPF trả PermError. Nhưng lớp đỡ đó mỏng. DKIM hỏng khi thư đi qua danh sách gửi thư hoặc bị máy chủ trung gian sửa tiêu đề. Lúc đó thì không còn gì đỡ.
Triệu chứng chập chờn nên khó bắt
Loại lỗi này khó phát hiện vì nó không hỏng đều. Thư vẫn tới nhiều nơi, chỉ vài nhà cung cấp kiểm nghiêm là chặn. Bộ phận kinh doanh báo khách này không nhận được thư, rồi mọi người đổ cho phía khách.
Một phép đo độc lập trên một triệu tên miền đầu bảng Tranco năm 2024 ghi nhận 2% tên miền có cấu hình SPF hỏng, trả về PermError. Nguyên nhân hay gặp nhất ở đó lại là khai hai bản ghi SPF cùng lúc, trong khi chuẩn chỉ cho phép một. Nghiên cứu quét 12 triệu tên miền của nhóm Czybik, Horlboge và Rieck cho con số cùng cỡ: 2,9% bản ghi có lỗi hoặc quy tắc vô nghĩa.
Cách kiểm mất vài giây. Nhiều công cụ trực tuyến miễn phí nhận tên miền rồi đếm hộ số lượt tra cứu thật. Vượt mười thì đó là việc phải sửa ngay chứ không phải việc để dành.
Cách sửa hay được nhắc là làm phẳng bản ghi, tức thay các dòng include bằng danh sách địa chỉ IP đã phân giải sẵn. Nghe gọn nhưng mang theo cái giá. Bản phẳng phải cập nhật lại mỗi lần nhà cung cấp đổi hạ tầng, bỏ sót một lần là thư hỏng. Nó biến một cấu hình tự bảo trì thành một cấu hình cần người trông. Bên chúng tôi trông phần đó cho hệ thống thư của khách.
Bản ghi SPF là thứ ít ai mở ra xem sau lần cấu hình đầu. Nó lại hỏng dần vì lý do nằm ngoài tầm kiểm soát của mình. Một lần đếm lại mỗi quý là mức bảo trì rẻ so với cái giá của một lô thư bị chặn.
