SPF checker: kiểm tra bản ghi SPF để email không bị giả mạo

Có một khoảnh khắc rất khó chịu: khách hàng nhận được email mang tên bạn, nhưng nội dung thì bạn chưa từng viết. Người gửi có thể đang mạo danh domain của bạn để lừa đảo, gửi thư rác hoặc làm tổn hại uy tín mà bạn dày công gây dựng. Và điều đáng nói là nhiều doanh nghiệp chỉ phát hiện ra chuyện này khi đã có người phản hồi, khiếu nại hoặc khi tỷ lệ email vào hộp thư bắt đầu tụt dốc.

SPF checker không phải là một món đồ công nghệ xa vời. Nó giống như việc bạn kiểm tra lại danh sách người được phép bước vào cửa hàng của mình. Một dòng cấu hình nhỏ trong DNS có thể giúp máy chủ nhận biết ai được phép gửi thay bạn, ai không, và từ đó giảm nguy cơ bị giả mạo. Bài viết này sẽ đi từ chuyện dễ hiểu nhất đến những lỗi cấu hình thường gặp, để bạn có thể tự kiểm tra và biết mình cần sửa gì tiếp theo.

SPF là gì và vì sao nó đáng được quan tâm?

SPF, tên đầy đủ là Sender Policy Framework, là một chuẩn xác thực email được định nghĩa trong RFC 7208. Cách hiểu đơn giản: chủ sở hữu domain công bố một danh sách các máy chủ hoặc dịch vụ được phép gửi email cho domain đó, thường nằm trong một bản ghi TXT trên DNS. Khi thư đến, máy chủ nhận sẽ tra cứu bản ghi này để xem địa chỉ IP đang gửi có nằm trong danh sách được phép hay không.

Nếu bạn từng tự hỏi vì sao thư của mình vào hộp thư chậm, dễ rơi vào thư mục spam hoặc bị đánh dấu đáng ngờ, câu trả lời có thể nằm ở đây. SPF lookup giúp hệ thống nhận biết thư nào đến từ nguồn hợp lệ. Khi bản ghi SPF rõ ràng, việc xác thực email có nền tảng tốt hơn, uy tín domain cũng được bảo vệ tốt hơn trước các nỗ lực mạo danh.

Nhưng SPF không nên đứng một mình. Nó hiệu quả nhất khi đi cùng DKIM và DMARC. DKIM xác minh tính toàn vẹn của thư bằng chữ ký mã hóa, còn DMARC bổ sung quy tắc căn chỉnh và báo cáo để chủ domain biết ai đang gửi thư, thư nào đang thất bại và máy chủ nhận đang xử lý ra sao. Nói cách khác, SPF là một lớp khóa cửa, còn DKIM và DMARC là camera và sổ ghi chép giúp bạn biết chuyện gì đang diễn ra.

SPF checker thực chất kiểm tra những gì?

Một SPF checker tử tế không chỉ trả về dòng chữ có bản ghi hay không có bản ghi. Nó truy vấn DNS, đọc TXT record, phân tích cú pháp và đối chiếu các cơ chế bên trong để đưa ra kết quả dễ hiểu. Công cụ còn có thể chỉ ra bản ghi có bị trùng, có vượt giới hạn tra cứu DNS hay không, và các include có còn trỏ đúng dịch vụ bạn đang dùng hay đã lỗi thời.

Kết quả đáng đọc thường gồm: bản ghi SPF đã công bố, các tag nhận diện, số lần tra DNS, cơ chế đang dùng, modifier và kết quả cuối cùng. Với người quản trị hệ thống, đây là bức ảnh chụp nhanh về hiện trạng email của domain. Với người làm kinh doanh, đó là cách để trả lời câu hỏi rất thực tế: khách hàng có đang nhận đúng thư do mình gửi không?

• Bản ghi SPF có tồn tại đúng chỗ trong DNS hay không.
• Có nhiều hơn một bản ghi SPF trên cùng domain hay không.
• Cú pháp có bắt đầu bằng v=spf1 và kết thúc bằng cơ chế all hợp lý không.
• Các include, IP4, IP6, A, MX có đang trỏ tới nguồn gửi thật hay không.
• Số lần tra DNS có vượt giới hạn 10-DNS-lookup được nêu trong chuẩn SPF hay không.

Đừng xem công cụ như một chiếc máy chấm điểm để rồi sửa cho đẹp. Hãy xem nó như tấm gương phản chiếu cấu hình thật. Nếu kết quả báo lỗi cú pháp hoặc quá giới hạn tra cứu, việc cần làm trước tiên là liệt kê lại toàn bộ dịch vụ đang gửi email cho domain, chứ không phải thêm bừa một dòng include mới.

Chạy một lần kiểm tra SPF đúng cách

Trước khi mở công cụ, hãy dành vài phút ghi ra những nơi đang gửi email thay bạn. Có thể là Google Workspace, Microsoft 365, Zoho Mail, một nền tảng CRM, hệ thống help desk, dịch vụ email giao dịch hoặc công cụ tiếp thị như Mailchimp. Bỏ sót một nguồn gửi hợp lệ cũng đủ khiến kết quả kiểm tra về sau trở nên khó hiểu.

1. Nhập tên miền của bạn, ví dụ tenmien.vn, vào công cụ kiểm tra SPF.
2. Chạy SPF record lookup để công cụ truy vấn bản ghi TXT trên DNS.
3. Đọc bản ghi SPF được trả về, chú ý các cơ chế include, IP4, IP6, A, MX và cơ chế all ở cuối.
4. Xem cảnh báo về bản ghi trùng, lỗi cú pháp, giới hạn tra cứu DNS và các include có thể đã lỗi thời.
5. Đối chiếu danh sách nguồn gửi bạn vừa ghi với những gì bản ghi đang cho phép.
6. Sửa DNS nếu cần, sau đó chạy lại kiểm tra để xác nhận thay đổi đã có hiệu lực.

Một lần kiểm tra sẽ không có nhiều ý nghĩa nếu bạn vừa thêm dịch vụ mới, vừa đổi nhà cung cấp DNS hoặc vừa chuyển từ Zoho Mail sang Microsoft. Hãy tạo thói quen chạy lại SPF validation sau mỗi thay đổi liên quan đến email. Công việc này mất vài phút, nhưng có thể cứu bạn khỏi một chiến dịch email hỏng hoặc một sự cố mạo danh khó chịu.

Nếu bạn không rành DNS, đừng ngại nhờ người phụ trách kỹ thuật đọc cùng. Điều quan trọng là hiểu bản ghi đang nói gì, chứ không phải chỉ nhìn thấy dấu tích xanh rồi yên tâm. Công cụ như MXToolbox, EasyDMARC hay SuperTool có thể hữu ích, nhưng kết luận cuối cùng vẫn phải dựa trên việc bạn biết ai đang gửi email cho domain của mình.

Đọc kết quả Pass, Fail, SoftFail, Neutral và lỗi

Kết quả SPF pass là tình huống đẹp nhất: địa chỉ IP gửi thư nằm trong danh sách được domain cho phép. Điều này hỗ trợ xác thực email tốt hơn, giúp uy tín domain ổn định và tăng khả năng thư đến đúng hộp thư người nhận. Nhưng pass chỉ có ý nghĩa khi bản ghi SPF của bạn thật sự chính xác, chứ không phải được cấu hình rộng đến mức ai gửi cũng được.

SPF fail xảy ra khi nguồn gửi không được phép. Cơ chế -all thường được dùng để báo rằng những người gửi không có trong danh sách nên bị từ chối hoặc bị xem là đáng ngờ. Đây là cách bảo vệ mạnh trước mạo danh, nhưng cũng là con dao hai lưỡi: nếu bạn quên một dịch vụ hợp lệ, chính thư của bạn có thể bị đánh trượt.

• Pass: IP gửi nằm trong danh sách được phép.
• Fail: IP gửi không được phép, thường gắn với cơ chế -all.
• SoftFail: thư không được xác nhận mạnh, thường dùng ~all để đánh dấu đáng ngờ thay vì từ chối thẳng.
• Neutral: domain không đưa ra khẳng định rõ ràng, thường gắn với cơ chế all.
• Error: lỗi cú pháp, vượt giới hạn tra DNS, include trỏ sai hoặc DNS tạm thời không phản hồi.

Đừng vội đổi mọi thứ sang -all chỉ vì muốn điểm kiểm tra cao hơn. Hãy chắc rằng bạn đã liệt kê đủ các nguồn gửi hợp lệ, kể cả hệ thống nội bộ, công cụ tiếp thị và ứng dụng tự động. Một bản ghi quá chặt nhưng thiếu nguồn gửi sẽ khiến email hợp lệ bị chặn, còn bản ghi quá lỏng thì gần như mở cửa cho kẻ mạo danh.

Những lỗi SPF thường gặp và cách sửa

Lỗi phổ biến nhất là có nhiều bản ghi SPF trên cùng một domain. Chuẩn SPF yêu cầu chỉ một bản ghi; nếu có hai bản ghi trở lên, máy chủ nhận có thể trả về lỗi vĩnh viễn và khiến việc xác thực thất bại. Cách sửa không phải là thêm bản ghi thứ ba, mà là gộp tất cả nguồn gửi hợp lệ vào một bản ghi duy nhất.

Một lỗi khác là thiếu bản ghi SPF hoàn toàn. Khi đó, máy chủ nhận không có cơ sở để biết ai được phép gửi thay domain, làm tăng nguy cơ bị giả mạo và lừa đảo qua email. Ngoài ra, bản ghi quá dài hoặc dùng quá nhiều include cũng có thể vượt giới hạn tra cứu DNS, khiến SPF không thể đánh giá đúng.

• Nhiều bản ghi SPF: gộp về một TXT record duy nhất, xóa bản ghi thừa sau khi đã sao lưu cấu hình.
• Thiếu bản ghi: bổ sung bản ghi bắt đầu bằng v=spf1, chỉ rõ nguồn gửi và kết thúc bằng cơ chế all phù hợp.
• Bản ghi quá lớn: loại bỏ dịch vụ không còn dùng, giảm include thừa, kiểm tra lại số lần tra DNS.
• Include lỗi thời: xóa include của nền tảng bạn đã ngừng sử dụng, tránh trao quyền gửi cho dịch vụ bên ngoài không cần thiết.
• Cú pháp sai: kiểm tra v=spf1, cơ chế và dấu all ở cuối; sửa lỗi trước khi thay đổi thêm bất cứ điều gì.

Một ví dụ dễ gặp: bạn từng dùng Mailchimp, sau đó chuyển sang công cụ khác nhưng vẫn để include của Mailchimp trong bản ghi. Nhìn qua thì không thấy vấn đề, nhưng thực tế domain vẫn đang cho phép một nền tảng bạn không còn kiểm soát gửi thay mình. Những chi tiết nhỏ như vậy là lý do vì sao kiểm tra định kỳ quan trọng hơn một lần cấu hình ban đầu.

Giữ bản ghi SPF khỏe mạnh: đừng cài rồi quên

SPF không phải công việc một lần. Mỗi khi bạn thêm dịch vụ email, đổi nhà cung cấp, mở chiến dịch mới hoặc thay đổi hạ tầng, bản ghi cũ có thể không còn phản ánh đúng thực tế. Hãy xem việc kiểm tra SPF như một thói quen vận hành, giống như bạn kiểm tra sao lưu dữ liệu hay gia hạn chứng chỉ bảo mật.

Để bảo vệ tốt hơn, hãy kết hợp SPF với DKIM và DMARC. DMARC giúp đảm bảo domain hiển thị trên thư khớp với kết quả SPF hoặc DKIM, đồng thời cung cấp báo cáo để bạn phát hiện nguồn gửi lạ. Báo cáo DMARC là nguồn thông tin rất đáng đọc: nó cho thấy nguồn nào đang pass, nguồn nào fail và nguồn nào đang gửi mà bạn chưa biết.

• Chạy kiểm tra SPF định kỳ, tối thiểu mỗi tháng một lần.
• Chạy lại ngay sau khi thêm hoặc xóa một nền tảng email.
• Xác nhận mọi nhà cung cấp bên thứ ba vẫn còn cần thiết.
• Giữ DNS hiện hành và đối chiếu với nhà cung cấp DNS của bạn.
• Theo dõi báo cáo DMARC để tìm nguồn gửi không quen.
• Đọc cảnh báo từ công cụ kiểm tra thay vì chỉ nhìn kết quả pass hoặc fail.
• Chỉ dùng -all khi bạn thật sự chắc chắn đã liệt kê đủ nguồn gửi hợp lệ.

Một bản ghi SPF tốt thường không cần quá cầu kỳ. Nó cần đúng, gọn và được cập nhật. Càng nhiều include không cần thiết, bạn càng khó kiểm soát ai đang có quyền gửi thay domain. Sự đơn giản có kỷ luật thường an toàn hơn một bản ghi dài với đủ thứ dịch vụ đã từng được dùng trong quá khứ.

Một góc nhìn phản biện: SPF không cứu được cấu hình cẩu thả

Có một hiểu lầm khá phổ biến: cài SPF xong là email được bảo vệ. Thực tế, SPF chỉ là một lớp trong hệ thống xác thực. Nếu bản ghi được sao chép từ tài liệu cũ, chứa include không còn dùng, hoặc không được cập nhật sau khi đổi nhà cung cấp, nó có thể tạo cảm giác an toàn giả tạo. Điều nguy hiểm là bạn nghĩ mình đã ổn, trong khi cấu hình thật vẫn đang mở những cánh cửa không cần thiết.

Mình không tin vào cách làm đối phó kiểu chạy công cụ một lần, thấy dấu tích xanh rồi bỏ qua. Một bản ghi SPF chỉ đáng tin khi bạn biết nó đang cho phép ai gửi thay mình. Nếu chưa trả lời được câu hỏi đó, kết quả pass trên màn hình chưa nói lên nhiều điều. Hãy bắt đầu từ danh sách nguồn gửi thật, rồi dùng công cụ để kiểm chứng, chứ đừng dùng công cụ để đoán mò.

Bạn đã kiểm tra bản ghi SPF của domain mình lần cuối khi nào? Bạn có nghĩ một cấu hình từng đúng vào năm ngoái vẫn còn đúng vào hôm nay, khi bạn đã thêm vài công cụ mới và bỏ đi một dịch vụ cũ? Nếu câu trả lời là chưa chắc, hãy dành vài phút chạy lại SPF record check ngay hôm nay. Và nếu bạn từng phát hiện một lỗi SPF khiến email của mình lao đao, hãy kể lại ở phần bình luận để người khác học cùng. Mình rất muốn nghe câu chuyện thật của bạn, vì đôi khi một chi tiết nhỏ trong DNS lại là bài học lớn cho cả một hệ thống email.