Định nghĩa
Bản ghi SPF (bản ghi Sender Policy Framework) là một bản ghi tài nguyên DNS TXT được công bố trong vùng DNS công cộng của tên miền liệt kê các địa chỉ IP, tiền tố IPv6 và tên máy chủ thư được ủy quyền gửi email thay mặt cho tên miền đó. Khi một máy chủ thư nhận chấp nhận một thông điệp đến, nó truy vấn DNS của người gửi cho bản ghi SPF và so sánh địa chỉ IP kết nối với chính sách. Nếu IP không được liệt kê, máy chủ nhận có thể đánh dấu thông điệp là softfail, từ chối hoàn toàn hoặc đánh dấu để đánh giá thêm — tùy thuộc vào chỉ định chính sách được đặt bởi chủ sở hữu tên miền.
SPF lần đầu được chính thức hóa thành một tiêu chuẩn IETF trong RFC 4408 (2006) và sau đó được cập nhật thành đặc tả có thẩm quyền hiện tại trong RFC 7208, được công bố bởi Internet Engineering Task Force (IETF) vào tháng 4 năm 2014. Đó là một trong ba tiêu chuẩn xác thực email bổ sung cùng với DKIM (DomainKeys Identified Mail) và DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Cách hoạt động
Quy trình đánh giá SPF liên quan đến nhiều bước tuần tự được thực hiện bởi công cụ SMTP của máy chủ thư nhận trong giai đoạn MAIL FROM của bắt tay SMTP.
Chủ sở hữu tên miền công bố một bản ghi SPF TXT trong DNS. Một bản ghi điển hình tuân theo cú pháp này: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Các thành phần là: v=spf1 (định danh phiên bản), một hoặc nhiều cơ chế (include, ip4, ip6, a, mx, exists) và một chỉ định cuối cùng (+all, -all, ~all, ?all). Chỉ định -all có nghĩa là một thất bại cứng — bất kỳ máy chủ nào không được liệt kê rõ ràng đều không được ủy quyền. Chỉ định ~all (softfail) cho phép thông điệp đi qua nhưng ghi lại sự không nhất quán của chính sách, thường được sử dụng trong các giai đoạn di chuyển.
Khi một thông điệp đến, MTA nhận (Mail Transfer Agent) trích xuất tên miền người gửi phong bì (địa chỉ MAIL FROM, còn gọi là địa chỉ RFC5321.MailFrom) và thực hiện một tra cứu DNS TXT cho _spf.<domain> hoặc trực tiếp trên gốc tên miền. Thư viện SPF đánh giá từng cơ chế theo thứ tự cho đến khi một cơ chế khớp hoặc giới hạn của mười tra cứu DNS được đạt đến (giới hạn “SPF PermError” được xác định trong RFC 7208 phần 4.6.4). Kết quả — Pass, Fail, SoftFail, Neutral, TempError hoặc PermError — được chèn vào tiêu đề Received-SPF của thông điệp và được chuyển đến bộ lọc thư rác và bất kỳ công cụ chính sách DMARC nào.
Điều quan trọng cần lưu ý là SPF xác thực người gửi phong bì (MAIL FROM), không phải tiêu đề From có thể nhìn thấy trong thân thông điệp. Sự phân biệt này có nghĩa là SPF một mình không ngăn cản việc giả mạo tên hiển thị trong các khách hàng email, đó là lý do tại sao sự liên kết DMARC — yêu cầu cả kết quả SPF và/hoặc DKIM khớp với tên miền RFC5322.From — là cần thiết cho sự bảo vệ hoàn chỉnh.
Bạn gặp Bản ghi SPF ở đâu
Các bản ghi SPF xuất hiện trong bất kỳ ngữ cảnh nào mà khả năng phân phối email và danh tiếng người gửi quan trọng. Cơ sở hạ tầng email giao dịch được vận hành bởi các dịch vụ như Amazon SES, SendGrid, Mailgun, Postmark và SparkPost yêu cầu chủ sở hữu tên miền thêm các cơ chế SPF include chỉ đến cơ sở hạ tầng gửi của nhà cung cấp trước khi các thông điệp sẽ vượt qua các kiểm tra xác thực.
Các nền tảng cuộc thi gửi email xác nhận phiếu bầu — bao gồm Woobox, ShortStack và các hệ thống được xây dựng tùy chỉnh sử dụng Mailchimp Transactional (Mandrill) — dựa vào việc tên miền gửi có một bản ghi SPF hợp lệ. Các nhà cung cấp hộp thư bao gồm Google (Gmail), Microsoft (Outlook / Exchange Online Protection) và Yahoo Mail đánh giá SPF như một đầu vào cho các thuật toán khả năng phân phối của họ. Một bản ghi SPF bị thiếu hoặc cấu hình sai làm tăng đáng kể xác suất các email xác nhận âm thầm được giao đến các thư mục thư rác hoặc bị từ chối hoàn toàn, khiến các phiếu bầu không được xác nhận.
Các bảng điều khiển lưu trữ DNS từ các nhà cung cấp như Cloudflare, AWS Route 53, GoDaddy và Namecheap cung cấp chỉnh sửa bản ghi SPF TXT thông qua các giao diện quản lý của họ. Các công cụ chẩn đoán như MXToolbox SPF Lookup, Google Admin Toolbox và SPF Surveyor của DMARCIAN cho phép chủ sở hữu tên miền kiểm tra và xác thực các bản ghi đã công bố.
Ví dụ thực tế
Một nền tảng cuộc thi gửi email xác nhận bỏ phiếu từ [email protected]. Tên miền votes.example.com có bản ghi SPF v=spf1 include:sendgrid.net -all. Khi Gmail nhận được một thông điệp xác nhận, máy chủ SMTP đầu vào của nó truy vấn DNS cho bản ghi SPF của votes.example.com, mở rộng cơ chế include sendgrid.net và kiểm tra IP kết nối với danh sách máy chủ được ủy quyền của SendGrid. Nếu IP khớp, kết quả SPF là Pass và thông điệp tiến đến hộp thư đến. Nếu tên miền không có bản ghi SPF, bộ lọc của Gmail sẽ coi thông điệp là không được xác thực, giảm xác suất đặt hộp thư đến.
Một cuộc thi của tờ báo khu vực thay đổi nhà cung cấp email giao dịch của mình từ Mailchimp sang Amazon SES mà không cập nhật bản ghi SPF của mình. Các email xác nhận bắt đầu thất bại các kiểm tra SPF tại Microsoft Outlook và bị thư mục rác hàng loạt, khiến những người bỏ phiếu bỏ lỡ cửa sổ xác nhận. Quản trị viên cuộc thi chẩn đoán vấn đề bằng cách sử dụng MXToolbox, thêm include:amazonses.com vào bản ghi SPF, và khả năng phân phối phục hồi trong cửa sổ truyền bá DNS (thường là 0-48 giờ tùy thuộc vào các cài đặt TTL).
Khái niệm liên quan
SPF là một trong những trụ cột của ngăn xếp xác thực email ba tiêu chuẩn: xem DKIM để xác minh chữ ký mật mã và DMARC cho lớp chính sách hoạt động dựa trên kết quả SPF và DKIM. Tác động thực tế đến hoạt động cuộc thi được mô tả trong Email Confirmation Vote, nơi khả năng phân phối của thông điệp xác nhận là sự phụ thuộc hoạt động quan trọng nhất duy nhất. BIMI (Brand Indicators for Message Identification), một tiêu chuẩn mới hơn xây dựng trên DMARC, cho phép những người gửi đã xác minh hiển thị logo thương hiệu trong các nhà cung cấp hộp thư hỗ trợ — một tín hiệu tin cậy mới nổi không được đề cập ở đây.
