SPF là gì? Cách bảo vệ email doanh nghiệp khỏi giả mạo

Nếu từng nhận một email trông y hệt thư ngân hàng hay thư của sếp — nhưng thật ra là kẻ giả mạo gửi — bạn đã chạm đúng vấn đề mà SPF security sinh ra để xử lý. Email là huyết mạch của gần như mọi doanh nghiệp, và cũng chính vì thế nó là mục tiêu ưa thích của phishing cùng các cuộc tấn công mạng.

Tin tốt là bạn không cần trở thành chuyên gia bảo mật để hiểu và triển khai SPF. Một bản ghi DNS đúng, chút kiên nhẫn khi kiểm thử và vài thói quen bảo trì định kỳ là đủ để dựng lớp gạch đầu tiên khá vững cho hệ thống thư của mình.

SPF là gì, hiểu theo cách đơn giản nhất

SPF (Sender Policy Framework) là chuẩn cho phép chủ tên miền công bố máy chủ nào được phép gửi thư thay mặt mình. Bạn tạo một bản ghi DNS TXT bắt đầu bằng v=spf1, liệt kê các địa chỉ IP và cơ chế được phép gửi. Khi Gmail, Outlook hay gateway doanh nghiệp nhận thư, nó tra bản ghi này rồi đối chiếu với IP đang kết nối. Khớp thì kết quả là spf=pass — lá thư có thêm tín hiệu đáng tin để vượt bộ lọc spam; lệch thì fail, và thư dễ bị đánh dấu hoặc chặn hẳn.

Điểm nhiều người hiểu sai: SPF xác thực envelope from (MAIL FROM / Return-Path), hoặc tên máy chủ HELO/EHLO nếu MAIL FROM rỗng — chứ không phải dòng “From” mà người dùng nhìn thấy. Nghĩa là SPF chặn giả mạo ở tầng kỹ thuật, nhưng không tự nó ngăn được việc mạo danh tên hiển thị. Việc đó cần tới DMARC và các quy tắc alignment.

Vì sao SPF đáng để bạn bận tâm ngay hôm nay

Kẻ tấn công thường làm giả danh tính MAIL FROM để mạo danh thương hiệu và phát tán phishing. Khi bạn công bố một bản ghi SPF chặt chẽ, hệ thống nhận đã có căn cứ để từ chối thư giả mạo ngay ở tầng SMTP. Lý do thứ hai ít kịch tính hơn nhưng liên quan trực tiếp tới doanh thu: khả năng vào hộp thư. Các nhà cung cấp hộp thư lớn chấm điểm spam rất nặng phần xác thực, nên một bản ghi SPF chuẩn giúp tăng deliverability, giữ uy tín tên miền và để chiến dịch hợp lệ gửi qua SendGrid hay Mailgun đến đúng inbox.

SPF không làm thư của bạn hay hơn. Nó chỉ giúp người nhận tin rằng thư ấy thật sự đến từ bạn — mà đôi khi, niềm tin ấy là tất cả.

Nhưng đừng đặt cược sai chỗ, vì SPF cần thiết mà chưa đủ:

• Không chặn được lạm dụng tên hiển thị, khi kẻ xấu để “From” là thương hiệu của bạn nhưng tên miền lại khác.
• Không ngăn được hộp thư bị chiếm quyền rồi gửi thư độc hại từ tài khoản hợp lệ.
• Không xử lý nguy cơ ở tầng nội dung như mã độc hay email xâm phạm nghiệp vụ (BEC).

Bên trong bản ghi SPF: cơ chế, qualifier và trần 10 tra cứu

Một chính sách SPF là chuỗi cơ chế mô tả những IP, máy chủ được phép gửi thư. Những cái tên bạn sẽ gặp nhiều nhất gồm:

• ip4, ip6: khai báo trực tiếp địa chỉ hoặc dải IP được phép.
• a, mx: cho phép máy chủ trùng với bản ghi A hoặc MX của tên miền.
• include: uỷ quyền cho bên thứ ba, ví dụ include:sendgrid.net.
• redirect: chuyển chính sách sang tên miền phụ khi cần quản lý tập trung ở quy mô lớn.
• exists và ptr dùng cho tình huống đặc biệt; ptr bị khuyến cáo hạn chế vì chậm và kém ổn định.

Đi kèm mỗi cơ chế là qualifier: dấu + là pass, dấu - là hard fail, dấu ~ là soft fail, dấu ? là neutral. Kinh nghiệm thực tế là bắt đầu bằng ~all để hạn chế gián đoạn, rồi chuyển sang -all khi đã chắc danh sách máy chủ gửi đầy đủ. Máy chủ nhận sẽ trả về Pass, Fail, SoftFail, Neutral, None (chưa có bản ghi), TempError (lỗi DNS tạm thời) hoặc PermError (sai định dạng, vượt trần tra cứu). Nhắc tới trần: SPF chỉ cho phép 10 lần tra cứu DNS để mở rộng include/a/mx/redirect; vượt ngưỡng sẽ thành PermError và thư của bạn có thể bị xử như fail ngoài ý muốn.

Dựng bản ghi SPF cho doanh nghiệp: bốn bước thực tế

Cú pháp không phải phần khó nhất. Phần khó là bạn có biết hết những hệ thống đang gửi thư thay mặt mình hay không. Hãy đi theo trình tự sau:

1. Kiểm kê mọi nguồn gửi thư: máy chủ mail nội bộ, cloud relay, nền tảng marketing, ticketing/CRM, máy chủ ứng dụng, thiết bị mạng, máy scan và các tích hợp bên thứ ba.
2. Ghi lại IP cùng tên máy chủ được phép, rồi chọn mức thực thi: ~all cho lần đầu, -all khi đã xác nhận đủ.
3. Ghép thành một bản ghi duy nhất ở tên miền gốc, ví dụ v=spf1 ip4:198.51.100.20 a mx include:sendgrid.net -all, rồi xuất bản dưới dạng DNS TXT.
4. Đặt TTL khoảng 1–4 giờ để cân bằng tốc độ lan truyền với tải truy vấn, sau đó kiểm thử trước khi công bố rộng.

Hai điều dễ bỏ qua nhưng có thể phá hỏng mọi thứ: mỗi tên miền chỉ được có đúng một bản ghi SPF, vì nhiều bản ghi sẽ gây PermError; và nếu ứng dụng gửi thư từ tên miền phụ, hãy tạo chính sách riêng cho tên miền phụ đó. Khi hệ thống lớn dần, nhiều đội ngũ chọn cách tập trung hoá bằng redirect về một host _spf riêng cho dễ quản lý.

Kiểm tra, bảo trì và những lỗi hay mắc

SPF không phải việc làm một lần rồi quên. Hãy kiểm tra cú pháp và hành vi thật bằng công cụ tra cứu SPF uy tín, rồi xác nhận kết quả trong header email: với Gmail, tìm dòng Authentication-Results và xem spf=pass hay spf=fail. Song song đó, theo dõi bounce và log máy chủ để phát hiện sớm các trường hợp fail hoặc soft fail.

Thời điểm cần cập nhật thường đến từ chuyện rất đời thường: IP thay đổi, thêm nhà cung cấp gửi thư mới, hoặc ngừng dùng máy chủ cũ. Bỏ quên bước này là cách nhanh nhất để chính thư hợp lệ của bạn bị đánh dấu. Đây là những lỗi lặp đi lặp lại:

• Dùng ptr hoặc để a/mx quá rộng, vô tình cho phép cả máy chủ bạn không kiểm soát.
• Xếp chuỗi include mà không tính tới trần tra cứu DNS, đến lúc vượt mới phát hiện.
• Nhầm tưởng SPF xác thực header From hiển thị, trong khi nó xác thực danh tính đường đi.
• Công bố nhiều bản ghi SPF trên cùng tên miền, khiến chính sách vô hiệu.

SPF chưa đủ: DKIM, DMARC và lộ trình ba giai đoạn

DKIM thêm chữ ký mật mã đi kèm lá thư, giúp xác thực nội dung và vẫn sống sót khi thư được chuyển tiếp. DMARC đặt chính sách cùng cơ chế báo cáo lên trên cả SPF lẫn DKIM, đồng thời yêu cầu sự khớp giữa danh tính được xác thực và header From mà người dùng nhìn thấy. Ba chuẩn này cộng lại thành lớp bảo vệ nhiều tầng.

Một chi tiết khiến SPF mong manh hơn bạn tưởng: vì nó xác thực IP đang kết nối, việc chuyển tiếp thư có thể làm SPF fail khi IP bên chuyển tiếp không nằm trong danh sách. Sender Rewriting Scheme (SRS) giúp giữ SPF nguyên vẹn bằng cách viết lại envelope from, còn DMARC alignment có thể bỏ qua vấn đề này nếu DKIM vẫn pass. Lộ trình thực dụng thường đi theo ba giai đoạn:

1. Xuất bản SPF với ~all, ký thư bằng DKIM, đặt DMARC ở mức p=none để thu thập báo cáo.
2. Sửa các lệch alignment mà báo cáo chỉ ra, tinh gọn include không cần thiết, xác nhận lại danh sách IP.
3. Chuyển SPF sang -all và nâng DMARC lên quarantine hoặc reject khi đã đủ tự tin.

Điều tôi muốn bạn mang theo không phải một bản ghi SPF hoàn hảo ngay lập tức, mà là cách nghĩ: bảo mật email là quá trình nhiều lớp, được duy trì đều đặn, chứ không phải tệp cấu hình dán vào rồi quên.

Nếu chưa biết bắt đầu từ đâu, hãy mở trang quản trị DNS, tìm bản ghi TXT bắt đầu bằng v=spf1 và kiểm tra xem tên miền của bạn có đang công bố nhiều hơn một bản ghi SPF không. Việc nhỏ, chưa tới mười phút, nhưng có thể tiết kiệm cho bạn vài tuần xử lý hậu quả.

Còn bạn thì sao — tên miền của bạn đã chuyển SPF sang hard fail chưa, hay vẫn sống chung với soft fail vì sợ làm rơi mất thư quan trọng? Nếu từng có lần thư nội bộ bị đẩy vào spam vì bản ghi SPF, hãy kể lại ở phần bình luận nhé — kinh nghiệm thật của bạn có thể giúp một đội ngũ khác tránh đúng vết xe đó.