Tôi đã học được bài học đắt giá về ý nghĩa thực sự của SPF. Một chiều thứ Sáu, tôi đã chuyển chế độ SPF của miền sản xuất từ softfail sang hardfail, hoàn toàn quên mất rằng chúng tôi đã thiết lập một nền tảng sự kiện từ nhiều tháng trước đó. Những email đó biến mất một cách bí ẩn. Chiều thứ Sáu đó đã dạy tôi một điều quan trọng: bạn có thực sự biết tất cả các nơi gửi mail của mình không, và bạn đã chuẩn bị cho hậu quả khi gửi nhầm chưa?

Kể từ đó, tôi xem các thay đổi SPF giống như cách các phi công kiểm tra danh sách kiểm tra—cẩn thận, có các biện pháp phòng ngừa, và không bao giờ vội vàng.

Hãy để tôi phân tích rõ những gì thực sự xảy ra bên trong. SPF (khung chính sách gửi mail) là một hệ thống xác thực email dựa trên DNS. Bạn đăng ký một bản ghi SPF như một bản ghi TXT DNS tại tên miền của mình, cho biết các máy chủ nào được phép gửi mail thay mặt bạn. Các máy chủ đó sẽ kiểm tra các cơ chế (ip4, ip6, a, mx, include) và các điều kiện, rồi đưa ra kết quả: pass, none, neutral, softfail, hardfail, temperror, hoặc permerror.

Điểm khác biệt chính nằm ở điều kiện cuối cùng. Softfail (~all) nói rằng "có vẻ như không hợp lệ, nhưng cứ tiếp tục cẩn thận." Hardfail (-all) nói rằng "chỉ có các máy chủ đã liệt kê mới hợp lệ—chặn tất cả những máy chủ khác." Chỉ một ký tự này đã thay đổi cách các nhà cung cấp hộp thư xử lý các email của bạn như thế nào.

Đây là phần thực tế. Với softfail, bạn thường thấy email bị chuyển vào thư mục spam hoặc cách ly. Với hardfail, đặc biệt khi có DMARC phù hợp, bạn có thể bị từ chối trực tiếp tại máy chủ gửi mail. Microsoft 365 và Outlook thường kết hợp SPF với DKIM và các bộ lọc nội dung. Google và Yahoo dựa nhiều vào DMARC và uy tín người gửi. Vì vậy, softfail có thể vào mục Khuyến mãi; còn hardfail với DMARC phù hợp có thể dẫn đến việc chặn quyết đoán.

Tôi không bao giờ chuyển trực tiếp sang hardfail. Con đường của tôi luôn là: trung lập (?all) → softfail (~all) → hardfail (-all). Trong quá trình khám phá, khi tôi chưa chắc chắn về luồng email cũ hoặc phạm vi IP của nhà cung cấp, tôi dùng softfail. Nó cảnh báo về việc sử dụng sai miền mà không làm giảm khả năng gửi mail, trong khi tôi kiểm kê tất cả các nguồn gửi—CRM, tự động marketing, ticketing, HR, tài chính, thậm chí cả máy in.

Sau khi xác nhận tất cả các nguồn gửi hợp lệ và DKIM nhất quán ở mọi nơi, tôi mới chuyển sang hardfail. Rủi ro là có thật: softfail giúp bạn gửi mail tốt hơn trong quá trình kiểm kê, nhưng có nguy cơ cao hơn phishing có thể lọt qua như spam thay vì bị chặn. Hardfail mang lại an ninh mạnh hơn nhưng có thể làm gián đoạn email hợp lệ nếu bạn bỏ sót một nguồn gửi.

Tôi đã thấy các nhóm vượt quá giới hạn 10 lần tra DNS bằng cách lồng ghép include quá mức. Tôi đã thấy họ quên các nhà cung cấp mùa vụ như Livestorm hoặc Prismic webhook. Và tôi đã chứng kiến người ta nghĩ rằng DMARC sẽ cứu một bản ghi SPF bị lỗi—nhưng không, trừ khi có sự phù hợp.

Bài học thực sự là: hãy xem SPF, DKIM, và DMARC như một hệ thống, chứ không phải các phần riêng lẻ. Chuyển tiếp email phá vỡ SPF vì địa chỉ IP kết nối thay đổi. Nếu bạn dùng SRS (Sender Rewriting Scheme), bạn ổn. Nếu không, softfail có thể là thứ duy nhất ngăn chặn "đạn lạc" từ phía người gửi không hợp lệ. Đó là lý do tôi theo dõi các báo cáo tổng hợp DMARC một cách cẩn thận và đọc các tiêu đề Authentication-Results khi có sự cố.

Quy trình an toàn của tôi: lập bản đồ tất cả các máy chủ mail và luồng công việc trước, xác thực DKIM ở mọi nơi, bật DMARC ở p=none để thu thập dữ liệu, chuyển SPF sang softfail và theo dõi hai chu kỳ gửi, điều tra tất cả các nguồn gửi không hợp lệ, rồi thử nghiệm chính sách reject trước khi chuyển sang hardfail.

Trong vài năm gần đây, Google và Yahoo đã thắt chặt yêu cầu xác thực. Việc thực thi chính sách ngày càng dựa trên nhiều tín hiệu: chế độ SPF, chữ ký DKIM, chính sách DMARC, nội dung, và uy tín đều quan trọng. Đó là lý do tôi không bao giờ xem SPF như một phần riêng biệt. Một SPF hardfail mà không có DKIM vững chắc vẫn có thể gây rối trong khả năng gửi mail nếu việc chuyển tiếp phổ biến.

Sai lầm lớn nhất tôi vẫn thấy là các nhóm chuyển sang hardfail trước khi DKIM trở nên phổ biến, hoặc họ dựa vào softfail mãi mãi trong khi kẻ tấn công thích nghi và email giả mạo phát triển trong trạng thái mơ hồ đó. Đó là một sự cân bằng, nhưng con đường rõ ràng nếu bạn làm theo phương pháp có hệ thống.