Defaults.Exposed

Defaults.Exposed › Cách khắc phục › SPF (Sender Policy Framework)

Cách khắc phục SPF (Sender Policy Framework)

SPF là một dòng trong cài đặt tên miền của bạn, liệt kê những dịch vụ thư nào được phép gửi email thay mặt doanh nghiệp. Không có SPF, bất kỳ ai trên thế giới đều có thể gửi email trông như từ bạn — và chính email thật của bạn lại dễ rơi vào thư rác của khách hàng.

Điểm mấu chốt với doanh nghiệp bạn: Bất kỳ ai cũng có thể giả mạo gửi email nhân danh doanh nghiệp bạn — đến khách hàng, nhân viên và nhà cung cấp — kể cả hóa đơn, yêu cầu thay đổi thông tin thanh toán, v.v. Đồng thời, những email thật như báo giá và hóa đơn của bạn lại dễ bị xếp vào spam, khiến giao dịch lặng lẽ đổ vỡ.

Điều này có thể gây thiệt hại gì

Tại sao điều này quan trọng. Giả mạo địa chỉ 'from' trong email cực kỳ dễ và tốn không một xu của kẻ tấn công. SPF là cách rẻ nhất và nhanh nhất để khiến tên miền của bạn khó bị giả mạo hơn và giữ cho email hợp lệ của bạn thoát khỏi thư rác. Google và Yahoo hiện đang tích cực đưa vào spam hoặc từ chối email từ các tên miền chưa xác thực — đây không còn là tùy chọn nữa, đây là điều kiện tối thiểu để email của bạn được giao.

Tóm tắt nhanh

Ngay lúc này, trừ khi bạn đã thiết lập SPF đúng cách, bất kỳ ai trên thế giới đều có thể gửi email trông như từ doanh nghiệp của bạn. Họ có thể gửi hóa đơn giả cho khách hàng, yêu cầu thanh toán giả cho nhân viên, và gửi thư cho nhà cung cấp như thể họ là bạn — các tin nhắn sẽ trông thật, vì tên miền của bạn không có gì nói khác.

SPF (Sender Policy Framework) là giải pháp. Đây là một dòng văn bản trong cài đặt DNS của tên miền, liệt kê những dịch vụ thư nào thực sự được phép gửi email thay mặt bạn. Nhà cung cấp thư nhận — Gmail, Outlook, tất cả — kiểm tra danh sách đó trước khi quyết định thư có thật không. Không có danh sách, hoặc danh sách yếu, và họ không có gì để dựa vào.

Trang này đề cập đến hai điều phải đúng cả hai: liệu bản ghi SPF có tồn tại không, và liệu nó có được đặt đủ nghiêm ngặt để thực sự làm việc của nó không.

Điều này có thể khiến bạn mất gì

Đây là những cách thực tế, hàng ngày mà bản ghi SPF thiếu hoặc yếu biến thành tiền và niềm tin thoát ra khỏi cửa. Chúng tôi không bao giờ nêu tên doanh nghiệp thật — đây là những mô hình chúng tôi thấy trong dữ liệu.

Điểm chung xuyên suốt: kẻ tấn công không tốn gì, và doanh nghiệp của bạn chịu chi phí và trách nhiệm.

Thực ra nó là gì

Khi email đến, máy chủ thư nhận muốn biết một điều: liệu đây có thực sự từ người gửi như đã tuyên bố không? SPF trả lời một phần câu hỏi đó.

Bạn xuất bản một dòng văn bản ngắn trong cài đặt DNS của tên miền — một “bản ghi TXT” — đặt tên các dịch vụ thư được phép gửi thay mặt bạn. Ví dụ:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Diễn đạt đơn giản: “Thư hợp lệ từ chúng tôi đến từ máy chủ của Google và SendGrid — từ chối bất cứ thứ gì khác tự nhận là chúng tôi.”

Hai phần quan trọng cho điểm của bạn:

  1. Bản ghi có tồn tại không? Đây là điều quan trọng nhất (nó chiếm tỷ trọng lớn nhất trong bất kỳ kiểm tra email đơn lẻ nào). Không có bản ghi có nghĩa là máy chủ nhận không có danh sách để kiểm tra, vì vậy việc giả mạo không bị hạn chế. Cũng có một lỗi tinh tế ở đây: nếu tên miền của bạn có hai hoặc nhiều hơn bản ghi SPF, các quy tắc nói tất cả đều không hợp lệ — vì vậy bạn thực sự không có SPF, mặc dù trông như có.

  2. Chính sách có đủ nghiêm ngặt không? Bản ghi có thể tồn tại nhưng vẫn không có tác dụng. Phần kết thúc — cơ chế “all” — là hướng dẫn cho máy chủ nhận:

    • -all (hard fail) — từ chối bất cứ thứ gì không có trong danh sách. Mạnh nhất. Đạt điểm tối đa.
    • ~all (soft fail) + DMARC đặt ở reject — cài đặt hiện đại được khuyến nghị. Bảo vệ tương đương hard fail, không có rủi ro email chuyển tiếp bị trả lại. Đạt điểm tối đa.
    • ~all + DMARC đặt ở quarantine — chấp nhận được, hơi yếu hơn; chuyển DMARC sang reject để bảo vệ đầy đủ.
    • ~all một mình (không có DMARC) — yếu. Điều này nói “có thể giả, giao đi vẫn được.” Thư giả mạo vẫn lọt qua. Đây là cái bẫy nhiều doanh nghiệp rơi vào khi nghĩ mình được bảo vệ.
    • ?all (neutral) — không cung cấp bảo vệ.
    • +all — nguy hiểm tích cực: nó nói với thế giới rằng bất kỳ ai đều có thể gửi thay mặt bạn. Không bao giờ dùng cái này.

Còn một lỗi ẩn nữa: SPF chỉ được phép kích hoạt tối đa 10 tra cứu DNS khi được đánh giá. Chồng chất quá nhiều mục include: và bản ghi vượt quá giới hạn đó, lúc đó máy chủ nhận xử lý toàn bộ như bị hỏng — và bạn quay lại không có bảo vệ. Đây là vấn đề phổ biến, âm thầm đối với các doanh nghiệp sử dụng nhiều công cụ marketing và SaaS.

“Tốt” trông như thế nào: chính xác một bản ghi SPF, liệt kê mọi dịch vụ hợp lệ gửi thư thay mặt bạn, kết thúc bằng -all (hoặc ~all kết hợp với DMARC ở p=reject), và ở thoải mái dưới giới hạn 10 tra cứu.

Cách sửa (miễn phí, ~10 phút)

Chuyển phần này cho người quản lý tên miền hoặc website của bạn — và lưu ý rằng việc sửa là miễn phí. Đây là thay đổi cài đặt DNS, không phải sản phẩm bạn mua. Chúng tôi chỉ tính phí để theo dõi rằng nó luôn đúng theo thời gian, không phải để thực hiện thay đổi.

Bước 1 — Liệt kê mọi dịch vụ gửi email thay mặt bạn. Đây là phần người ta hay mắc sai lầm. Viết ra tất cả: nhà cung cấp hộp thư (Google Workspace, Microsoft 365, v.v.), cộng với bất kỳ công cụ newsletter, CRM, helpdesk, nền tảng thương mại điện tử, ứng dụng hóa đơn/kế toán, và hệ thống đặt lịch. Nếu một dịch vụ gửi thư mang tên bạn và bạn quên nó, SPF của bạn sẽ chặn thư của nó khi bạn siết chặt chính sách.

Bước 2 — Xuất bản một bản ghi TXT tại tên miền gốc của bạn. Kết hợp các dòng “include” cho tất cả người gửi thành một bản ghi duy nhất. Theo nền tảng phổ biến:

Bản ghi kết hợp trông như:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Nơi thêm vào, theo nhà cung cấp:

Bước 3 — Bắt đầu an toàn, sau đó thực thi. Trong khi xác nhận danh sách người gửi đầy đủ, xuất bản với ~all (soft fail) để không có gì hợp lệ bị chặn nhầm. Sau khi đã xác nhận toàn bộ thư hợp lệ vẫn chạy, siết chặt thành -all (hard fail) — hoặc tốt hơn, giữ ~all và thêm chính sách DMARC p=reject, đây là cặp đôi hiện đại được khuyến nghị.

Bước 4 — Đảm bảo bạn chỉ có MỘT bản ghi. Nếu bản ghi SPF cũ đã tồn tại, hãy chỉnh sửa bản đó thay vì thêm bản thứ hai. Hai bản ghi v=spf1 triệt tiêu nhau và để bạn không được bảo vệ.

Bước 5 — Theo dõi số lần tra cứu. Nếu bạn có nhiều người gửi, bạn có thể vượt quá giới hạn 10 tra cứu. Nếu điều đó xảy ra, hãy hợp nhất — một số nhà cung cấp cung cấp “SPF flattening,” hoặc loại bỏ những người gửi bạn không còn sử dụng.

Bước 6 — Kiểm tra lại tên miền để xác nhận nó hiện vượt qua, với bản ghi hiện diện và chính sách nghiêm ngặt.

Các lỗi phổ biến

Vị trí trong bức tranh tổng thể

SPF là nền tảng, nhưng chỉ là một trong ba lớp. DKIM thêm chữ ký mật mã chứng minh tin nhắn không bị giả mạo, và DMARC là hướng dẫn kết hợp SPF và DKIM và nói với máy chủ nhận phải làm gì với thư thất bại — bao gồm cả chặn giả mạo tên ‘from’ hiển thị mà khách hàng thấy. Sửa SPF trước (đây là chiến thắng nhanh nhất và quan trọng nhất), sau đó thêm DKIM và DMARC để đóng hoàn toàn cánh cửa. Cả ba bản sửa đều miễn phí.

Cài đặt trên nhà cung cấp hosting của bạn

Từng bước cho các nhà cung cấp phổ biến:

FAQ

Tôi không rành kỹ thuật — tôi có thể tự xử lý việc này không?

Bạn không cần hiểu chi tiết kỹ thuật. Thay đổi chỉ là một hoặc hai dòng thêm vào cài đặt tên miền, do người quản lý website hoặc nhà cung cấp IT thực hiện. Chuyển phần 'Cách sửa' bên dưới cho họ — thường chỉ mất vài phút và hoàn toàn miễn phí. Chúng tôi chỉ tính phí theo dõi để đảm bảo nó luôn đúng theo thời gian.

Chúng tôi đã có bản ghi SPF rồi — vậy có nghĩa là chúng tôi được bảo vệ chưa?

Chưa chắc. Có bản ghi là bước đầu; đặt nó đủ nghiêm ngặt mới là bước hai. Bản ghi kết thúc bằng '~all' (soft fail) mà không có DMARC đằng sau thực tế là nói với máy chủ nhận 'thư này có thể giả, nhưng vẫn giao đi' — gần như không bảo vệ được gì. Hai bản ghi SPF, hoặc một bản ghi quá nhiều lần tra cứu, được xử lý như bị hỏng và không bảo vệ bạn dù có vẻ tồn tại. Cả hai bước đều phải đúng.

Việc sửa này có vô tình phá vỡ email của chính tôi không?

Có thể nếu bản ghi bỏ sót một người gửi hợp lệ — ví dụ ứng dụng hóa đơn hoặc công cụ newsletter gửi thư dùng tên bạn. Đó chính xác là lý do tại sao cách tiếp cận an toàn là liệt kê mọi dịch vụ gửi thư thay mặt bạn trước, xuất bản với soft '~all' trong khi xác nhận không bỏ sót gì, sau đó mới siết chặt thành hard fail. Làm theo thứ tự đó sẽ không phá vỡ gì.

Sự khác biệt giữa '~all' và '-all' là gì, và chúng tôi nên dùng cái nào?

'-all' (hard fail) yêu cầu máy chủ từ chối bất cứ thứ gì không có trong danh sách — cài đặt mạnh nhất. '~all' (soft fail) có nghĩa là 'có thể không hợp lệ, nhưng vẫn chấp nhận.' Khuyến nghị hiện đại nhất là '~all' kết hợp với chính sách DMARC 'reject' — cặp đôi này cho bạn sự bảo vệ tương đương '-all' mà không có rủi ro email chuyển tiếp bị trả lại. '~all' một mình, không có DMARC, là cấu hình yếu cần tránh.

SPF có ngăn chặn được toàn bộ hành vi giả mạo email không?

Không — đây là lớp nền tảng thiết yếu, không phải toàn bộ giải pháp. SPF cho biết máy chủ nào được phép gửi cho bạn, nhưng không nói với máy chủ nhận phải làm gì khi thư thất bại, và không bảo vệ tên 'from' hiển thị mà người dùng thấy. Để khóa hoàn toàn việc giả mạo, bạn cần thêm DKIM và DMARC. SPF là bước đầu nhanh và hiệu quả nhất, vì vậy hãy bắt đầu ở đây, rồi thêm hai cái kia.

Mất bao lâu để có hiệu lực, và có tốn tiền không?

Thay đổi DNS thường có hiệu lực trong vài phút đến vài giờ. Bản thân việc sửa luôn miễn phí — chỉ là chỉnh sửa một cài đặt tại nhà cung cấp DNS của bạn. Bất kỳ ai nói với bạn rằng cần mua sản phẩm trả phí để thêm bản ghi SPF là đang hiểu sai.