SPF và DKIM khai báo thế nào để thư không vào spam

Một bản ghi SPF viết sai một ký tự vẫn được DNS chấp nhận, nhưng máy chủ email bên nhận đọc ra kết quả khác hẳn. SPF và DKIM là hai bản ghi xác thực người gửi, khai trong vùng DNS của tên miền, chứng minh thư gửi đi thật sự xuất phát từ hệ thống được cho phép. Thiếu một trong hai, hoặc khai đúng cú pháp nhưng thiếu một nguồn gửi, email hợp lệ vẫn có thể rơi vào thư mục spam. Bài viết đi qua cú pháp khai SPF, cách DKIM ký vào từng thư, lỗi hay gặp và cách tự kiểm sau khi khai.

SPF và DKIM là gì, vì sao email cần khai cả hai

SPF là bản ghi TXT liệt kê những máy chủ được phép gửi thư thay tên miền. DKIM là chữ ký số gắn vào từng thư, chứng minh nội dung chưa bị chỉnh sửa giữa đường. SPF trả lời ai được gửi, DKIM trả lời thư có đúng bản gốc, bên nhận cần cả hai để tính điểm tin cậy.

Hai cơ chế hoạt động độc lập. SPF kiểm địa chỉ IP của máy chủ gửi so với danh sách khai trong DNS, không quan tâm nội dung thư. DKIM kiểm chữ ký gắn ở tiêu đề, không quan tâm thư đi từ IP nào, miễn nội dung còn nguyên vẹn lúc tới nơi. Vì độc lập nên một thư có thể qua được SPF mà trượt DKIM, hoặc ngược lại.

Bản ghi DMARC là lớp nằm trên cả hai, quy định nên làm gì khi SPF hoặc DKIM trượt: từ chối thẳng, đưa vào spam, hay vẫn nhận nhưng gửi báo cáo về cho quản trị tên miền. Bài viết riêng về DMARC chống mạo danh tên miền giải thích kỹ phần này, ở đây chỉ tập trung vào cách khai đúng hai bản ghi. Doanh nghiệp dùng email doanh nghiệp theo tên miền riêng nên khai đủ cả hai ngay từ ngày đầu, tránh phải sửa DNS nhiều lần sau khi đã gửi thư ổn định.

Bản ghi SPF khai báo trong DNS theo cú pháp nào

Bản ghi SPF là một dòng TXT gắn vào tên miền gốc, bắt đầu bằng v=spf1, liệt kê các nguồn được phép rồi kết bằng cơ chế xử lý phần còn lại. Cú pháp phổ biến: v=spf1 include:_spf.tencongty.com ip4:1.2.3.4 -all, trong đó -all từ chối hẳn nguồn ngoài danh sách.

Dấu ~all chỉ đánh dấu nghi ngờ, không chặn hẳn như -all, nhiều nơi dùng tạm lúc mới khai để tránh chặn nhầm nguồn còn sót.

Cơ chế include cho phép nhúng danh sách nguồn của bên thứ ba, ví dụ include:_spf.google.com khi công ty dùng Gmail gửi thay, hoặc include của nền tảng gửi chiến dịch. Mỗi include kéo theo ít nhất một lần tra cứu DNS. Theo RFC 7208 của IETF, tài liệu chuẩn cho SPF, tổng số lần tra cứu DNS trong toàn bộ chuỗi include và redirect không được vượt quá 10 lần; vượt ngưỡng này, máy chủ nhận trả về lỗi permerror và coi cả bản ghi SPF là không hợp lệ, kể cả phần khai đúng phía trước.

Lỗi khai SPF hay gặp nhất là gì

Lỗi phổ biến nhất là khai hai bản ghi TXT loại SPF cho cùng một tên miền, một dòng cho hosting web, một dòng cho phần mềm gửi thư. RFC 7208 chỉ chấp nhận một bản ghi SPF mỗi tên miền, có hai dòng thì máy chủ nhận coi cả hai đều không hợp lệ.

Lỗi thứ hai là quên nguồn gửi thứ hai. Tên miền gửi thư qua nhiều kênh: hộp thư nhân viên qua gói email theo tên miền riêng, phần mềm kế toán tự gửi hoá đơn, form liên hệ trên website gửi qua SMTP riêng của hosting, và nền tảng gửi chiến dịch cho bản tin định kỳ. Mỗi nguồn phải có mặt trong bản ghi SPF bằng include hoặc ip4 riêng. Bỏ sót nguồn nào, thư từ nguồn đó trượt SPF, dù tên miền vẫn đúng.

DKIM ký vào từng email bằng cách nào

DKIM dùng một cặp khoá: khoá riêng nằm ở máy chủ gửi, ký vào phần tiêu đề của mỗi thư; khoá công khai đặt trong DNS dưới dạng bản ghi TXT gắn với một selector, ví dụ selector1._domainkey.tencongty.com. Bên nhận tải khoá công khai về, khớp chữ ký thì xác nhận thư chưa bị chỉnh sửa.

Theo RFC 6376, tài liệu chuẩn DKIM Core, khoá dùng thuật toán RSA có thể chọn 1024 bit hoặc 2048 bit. Nhiều nhà cung cấp email lớn khuyến nghị dùng 2048 bit, vì khoá 1024 bit đã bắt đầu bị xem là yếu trước năng lực tính toán hiện nay. Selector cho phép đổi khoá định kỳ mà không phải đụng tới bản ghi SPF, hai bản ghi tách biệt hoàn toàn về cú pháp lẫn vòng đời.

Email chuyển tiếp có làm hỏng chữ ký DKIM không

Có, đây là nguyên nhân hay gặp nhất khi DKIM trượt dù khai đúng bản ghi. Chữ ký DKIM tính trên tiêu đề và nội dung cố định lúc gửi đi lần đầu. Hộp thư chuyển tiếp thường chèn thêm dòng tiêu đề hoặc chữ ký vào cuối thư, đổi nội dung so với bản gốc khiến DKIM fail.

Trường hợp này gần như không tránh được từ phía người gửi, vì thay đổi nằm ở hộp thư trung gian chứ không phải lỗi cấu hình. Doanh nghiệp cần kiểm soát chặt selector và khoá, đặc biệt khi thư đi qua danh sách gửi nội bộ (mailing list), nên cân nhắc dịch vụ email server riêng mailUltra để tự quản trị cấu hình DKIM thay vì phụ thuộc hạ tầng dùng chung.

Tự kiểm tra hai bản ghi này đã khai đúng chưa bằng cách nào

Cách kiểm nhanh nhất là gửi một thư thử tới hộp thư ngoài công ty, ví dụ một địa chỉ Gmail, rồi mở phần chi tiết kỹ thuật để đọc dòng Authentication-Results. Cả SPF và DKIM ghi pass là bản ghi đã đúng; ghi fail hoặc none thì quay lại kiểm cú pháp bản ghi TXT vừa thêm.

Bản ghi TXT mới thêm không có hiệu lực ngay lập tức, còn phải chờ hết TTL (thời gian sống) do máy chủ DNS đặt, thường 3.600 giây tức một giờ, có nơi đặt tới một ngày. Kiểm tra ngay sau khi lưu dễ thấy kết quả none dù bản ghi đã khai đúng, chỉ cần đợi thêm rồi kiểm lại. Doanh nghiệp gặp email vẫn vào spam sau khi đã khai đủ nên đọc thêm nguyên nhân khiến email vào spam, vì hai bản ghi đúng chỉ là một phần trong bức tranh uy tín gửi.

Câu hỏi thường gặp về SPF và DKIM

Chốt vài ý trước khi khai lại SPF và DKIM

Hai bản ghi này là việc kỹ thuật nhỏ nhưng ảnh hưởng tới khả năng thư tới được hộp thư đến. SPF liệt kê nguồn được phép gửi, giới hạn 10 lần tra cứu DNS, chỉ khai một bản ghi mỗi tên miền. DKIM ký vào từng thư bằng cặp khoá theo selector, dễ trượt khi thư qua chuyển tiếp.

Gửi thử tới một hộp thư ngoài và đọc dòng Authentication-Results là cách xác nhận nhanh nhất, nhớ chờ hết TTL trước khi kết luận bản ghi sai.

Doanh nghiệp chưa có nền tảng email riêng có thể xem bốn gói mailBus Email doanh nghiệp, cấu hình SPF DKIM DMARC được dựng sẵn ngay lúc khởi tạo, không phải tự dò từng dòng bản ghi TXT.