Tôi đã học về SPF theo cách khó khăn—đã chuyển đổi một tên miền sản xuất từ softfail sang hardfail vào chiều thứ Sáu và chứng kiến toàn bộ luồng email biến mất. Hóa ra tôi đã quên mất một nền tảng sự kiện mà tôi đã thiết lập từ vài tháng trước. Sai lầm đó đã dạy tôi một điều cực kỳ quan trọng: trước khi bạn chỉnh sửa bản ghi SPF của mình, bạn cần biết rõ mọi nơi gửi mail của bạn xuất phát từ đâu, và bạn phải chấp nhận hậu quả nếu làm sai.

Hãy để tôi phân tích những gì thực sự quan trọng ở đây. SPF (Sender Policy Framework) về cơ bản là tên miền của bạn thông báo cho các máy chủ nhận: đây là bản ghi DNS TXT của tôi liệt kê các máy chủ hợp lệ gửi mail thay mặt tôi. Khi một email đến, máy nhận kiểm tra bản ghi SPF của bạn so với tên miền Return-Path, đánh giá các cơ chế (ip4, ip6, a, mx, include), và quyết định xử lý như thế nào. Quyết định đó dựa trên một yếu tố duy nhất: trình định dạng (qualifier) ở cuối—chế độ bạn chọn.

Đây là điểm khác biệt cốt lõi khiến nhiều người nhầm lẫn. Softfail (~all) có nghĩa là "có vẻ không hợp lệ, nhưng có thể chấp nhận được—hãy cẩn thận." Thường thì nó sẽ kích hoạt bộ lọc spam, chứ không phải từ chối hoàn toàn. Hardfail (-all) có nghĩa là "chỉ các máy chủ tôi liệt kê mới hợp lệ—chặn tất cả những cái khác." Đây là cách xác định rõ ràng, và khi kết hợp với DMARC phù hợp, bạn sẽ nhận được phản hồi từ chối thực sự.

Tôi nghĩ về nó như giai đoạn thử nghiệm so với sản xuất. Softfail là chế độ thử nghiệm cẩn trọng khi bạn vẫn đang tìm hiểu. Hardfail là việc bật công tắc trong môi trường sản xuất và chấp nhận hậu quả.

Con đường thực tế tôi theo đuổi là theo phương pháp có hệ thống: bắt đầu với ?all để quan sát thuần túy, chuyển sang softfail (~all) khi bạn bắt đầu xem các báo cáo tổng hợp DMARC, rồi mới chuyển sang hardfail (-all) chỉ sau khi xác nhận tất cả các nguồn gửi hợp lệ và các báo cáo sai lệch gần như bằng 0. Tôi không bao giờ vội vàng. Tôi liệt kê tất cả—CRM, tự động hóa marketing, hệ thống vé, HR, thanh toán, thậm chí những thứ kỳ quặc như máy in. Tôi xác nhận các nhà cung cấp hỗ trợ DKIM và DMARC phù hợp. Tôi ghi chép rõ ai là người sở hữu mỗi thay đổi.

Một điều sẽ khiến bạn nhanh chóng gặp rắc rối: SPF có giới hạn 10 lần tra cứu DNS. Tôi đã thấy người chồng chéo các include đến mức vượt quá giới hạn đó đột ngột, rồi mọi thứ đổ vỡ. Hãy giảm bớt các include, ưu tiên các phạm vi IP hơn các chuỗi chồng chéo, và loại bỏ các dịch vụ không còn hoạt động. Nếu một nhà gửi hàng loạt thay đổi IP liên tục, hãy yêu cầu họ cung cấp một include ổn định với SLA rõ ràng.

Chuyển tiếp (forwarding) là một vấn đề khác. Nó phá vỡ SPF vì IP kết nối thay đổi. Nếu nhà chuyển tiếp sử dụng SRS (Sender Rewriting Scheme), bạn ổn. Nếu không, softfail có thể là cách duy nhất để tránh gây rối không mong muốn. Đó là lý do tại sao tôi dựa nhiều hơn vào DKIM và DMARC để kiểm soát các đường truyền này.

Danh sách kiểm tra triển khai thực tế tôi đã tinh chỉnh theo thời gian: lập bản đồ tất cả các máy chủ gửi mail và quy trình làm việc, xác nhận 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 ít nhất hai chu kỳ gửi, điều tra mọi nguồn gửi không hợp lệ và hoặc cấp phép cho chúng hoặc loại bỏ luồng gửi, rồi triển khai dần chính sách reject với thực thi DMARC trước khi chuyển sang hardfail. Bước cuối cùng—chỉ chuyển sang hardfail khi phạm vi gửi hợp lệ đã đầy đủ—là không thể thương lượng.

Một điều nữa tôi nhận thấy: Google và Yahoo đã siết chặt tiêu chuẩn đáng kể. Chính sách email giờ đây kết hợp chế độ SPF, chữ ký DKIM, chính sách DMARC, phân tích nội dung và điểm danh tiếng. Đây là lý do tại sao tôi không bao giờ xem SPF đơn lẻ. Một SPF hardfail mà không có hỗ trợ DKIM vững chắc vẫn có thể gây rối trong việc gửi mail nếu môi trường của bạn thường xuyên chuyển tiếp.

Những sai lầm lớn nhất tôi thấy mọi người mắc phải: chồng chéo include vượt quá giới hạn 10 tra cứu, quên các nhà cung cấp theo mùa gửi mail dưới tên miền của bạn, nghĩ rằng DMARC sẽ cứu vớt một cấu hình SPF hỏng, dựa vào softfail mãi mãi trong khi kẻ tấn công thích nghi, hoặc chuyển sang hardfail trước khi DKIM đã được triển khai đầy đủ. Đặc biệt là bước cuối—chuyển sang hardfail khi phạm vi gửi hợp lệ chưa hoàn chỉnh—đúng là an toàn cho bảo mật, nhưng cực kỳ tai hại cho khả năng gửi mail khi có nhiều chuyển tiếp.

Nếu bạn đang dùng softfail và đang tự hỏi có nên chuyển không, câu trả lời là: chỉ khi nào bạn đã sẵn sàng. Bạn đã xác nhận tất cả các nguồn gửi chưa? DKIM đã phù hợp chưa? Các báo cáo sai lệch gần như bằng 0 chưa? Nếu tất cả đều có câu trả lời là có, thì chuyển sang hardfail là hợp lý. Nếu không, hãy kiên nhẫn. Softfail không phải là trạng thái vĩnh viễn—nó chỉ là một điểm kiểm tra.