Vì sao email giao dịch vào spam dù code đã chạy đúng
Tình huống này bên mình gặp khá thường xuyên. Khách hàng gọi lên, bảo rằng thư xác nhận đơn hàng không hề thấy trong hộp thư. Chúng tôi mở log ra thì máy chủ báo gửi thành công, không có lỗi nào. Thế nhưng người nhận vẫn không thấy thư đâu.
Lý do nằm ở một câu hỏi mà máy chủ nhận thư luôn đặt ra: người gửi này có thật sự được phép dùng tên miền đó không? Nếu câu trả lời không rõ ràng, thư sẽ bị đẩy vào spam, hoặc bị từ chối ngay từ đầu. Code của bạn vẫn chạy đúng. Vấn đề là chưa có cơ chế nào chứng minh điều đó với máy chủ nhận. Đó là lúc cấu hình xác thực tên miền trở thành việc không thể bỏ qua.
Theo kinh nghiệm của chúng tôi, có hai nguyên nhân phổ biến nhất. Thứ nhất là gửi chung IP với rất nhiều người gửi khác. Thứ hai là tên miền chưa được xác thực. Thư xác nhận đơn hay thư quên mật khẩu là loại thư người dùng đang chờ đợi. Khi chúng bị chặn, khách sẽ nghĩ shop của bạn thiếu chuyên nghiệp, và niềm tin có thể mất ngay từ lần đầu tiên.
Cần phân biệt rõ email giao dịch với email quảng cáo. Thư giao dịch báo cho người dùng điều họ đang cần ngay lúc đó, nên phải đến nhanh và đến chắc. Một email khuyến mãi đến muộn vài tiếng vẫn chấp nhận được. Còn thư đặt lại mật khẩu đến muộn thì khách có thể đã rời đi mất rồi.
Các lựa chọn gửi email giao dịch hiện có
Trước khi đụng vào DNS, bạn cần chọn dịch vụ gửi thư. Hiện có ba nhóm chính: dịch vụ quốc tế như Resend, SendGrid và Amazon SES; dịch vụ nội địa có hỗ trợ người Việt như MONA Mail; và phương án tự dựng trên máy chủ riêng.
Dịch vụ quốc tế thường mạnh về hạ tầng và tốc độ. Tuy vậy, tài liệu tiếng Việt khá hiếm. Khi gặp sự cố, hỗ trợ thường chỉ có bằng tiếng Anh, và giao diện quản trị không dễ làm quen với người không chuyên.
MONA Mail đi theo hướng ngược lại. Bộ tài liệu và SDK khá đầy đủ, đội hỗ trợ trao đổi được bằng tiếng Việt. Điều cần cân nhắc là hệ sinh thái còn non so với các đàn anh trong ngành. Nếu bạn dự kiến gửi hàng triệu thư mỗi ngày, hãy thử tải trước khi cam kết lâu dài.
Khi chọn, hãy đọc tài liệu và SDK trước. Nếu đọc hai trang tài liệu mà vẫn thấy rối, khả năng cao quá trình tích hợp sau này sẽ tốn thêm vài ngày.
Chi phí và hạn mức theo nhu cầu thực tế
Bảng giá thay đổi liên tục, nên các con số dưới đây chỉ đúng tại thời điểm bên mình viết bài. Trước khi quyết định, bạn nên đối chiếu lại trên trang giá chính thức của từng nhà cung cấp.
Gói miễn phí của phần lớn dịch vụ đủ dùng cho một website nhỏ đang thử nghiệm. Với MONA Mail, bạn được gửi miễn phí 3.000 email mỗi tháng, sau đó là các gói 99.000đ, 299.000đ và 799.000đ.
Chi phí thực tế thường không nằm ở gói cơ bản, mà ở ngày bạn chạy khuyến mãi. Có những buổi tối số lượng thư tăng gấp mười chỉ trong vài giờ. Vì vậy, hãy tính trước mức vượt hạn mức và xem nhà cung cấp tính phí ra sao trong trường hợp đó.
Ưu điểm và hạn chế của từng lựa chọn
Ưu điểm dễ nhận thấy nhất là tốc độ tích hợp. Một SDK hỗ trợ nhiều ngôn ngữ, kèm ví dụ mẫu cho Node.js và PHP, giúp bạn gửi được thư thử nghiệm chỉ trong vài phút. Với người mới, đây là khác biệt rất lớn so với việc phải tự viết toàn bộ lớp gửi thư.
Hạn chế thì ít ai nhắc tới. Giao diện quản trị của một số dịch vụ quốc tế khá phức tạp, và hỗ trợ tiếng Việt cũng chưa đồng đều. Có một việc bạn bắt buộc phải làm: bật xác thực DKIM. Nhiều dịch vụ không cho gửi thư thật cho đến khi DKIM hoàn tất.
Nếu đội của bạn có lập trình viên quen đọc tài liệu tiếng Anh và lượng thư lớn, dịch vụ quốc tế là lựa chọn hợp lý. Còn nếu bạn điều hành một shop nhỏ và cần người hỗ trợ nói tiếng Việt, dịch vụ nội địa sẽ tiết kiệm thời gian đáng kể.
SPF, DKIM, DMARC: ba bản ghi, ba nhiệm vụ khác nhau
Ba cái tên này nghe rất kỹ thuật, nhưng ý nghĩa khá đơn giản. Đó là ba bản ghi DNS, mỗi bản ghi trả lời một câu hỏi khác nhau mà máy chủ nhận thư đặt ra khi nhận một bức thư.
SPF khai báo danh sách các máy chủ được quyền gửi thư thay mặt tên miền của bạn. Nó trả lời câu hỏi: máy gửi này có quyền dùng domain này hay không?
DKIM là chữ ký số gắn vào từng bức thư. Nếu nội dung bị sửa trên đường đi, chữ ký sẽ không còn khớp. Nhờ vậy, máy nhận biết được thư thật sự xuất phát từ domain của bạn và chưa bị can thiệp.
DMARC là lớp chính sách đứng trên hai cơ chế kia. Nó quy định máy nhận cần làm gì khi SPF hoặc DKIM thất bại: bỏ qua, đưa vào spam hay từ chối hẳn. Có ba mức là none, quarantine và reject, và bạn nên nâng dần từ mức nhẹ nhất.
Cấu hình DNS từng bước
Bước đầu tiên là thêm bản ghi TXT cho SPF. Đây là chỗ dễ sai nhất. Mỗi tên miền chỉ được phép có đúng một bản ghi SPF. Đội ngũ chúng tôi từng gặp trường hợp người dùng thêm một bản ghi mới thay vì gộp vào bản cũ, và kết quả là xác thực thất bại hoàn toàn dù từng bản ghi riêng lẻ đều đúng.
Bước thứ hai là DKIM. Nhà cung cấp sẽ cấp cho bạn một selector, thường là một chuỗi ngắn, cùng với một khóa công khai. Bạn tạo bản ghi TXT có tên đúng theo selector đó, rồi dán giá trị khóa vào phần nội dung. Chỉ cần sai một ký tự là chữ ký sẽ không được xác nhận.
Bước thứ ba là DMARC. Chúng tôi khuyên bắt đầu ở chế độ p=none, tức chỉ theo dõi và chưa chặn thư nào. Sau vài tuần đọc báo cáo, bạn mới nên nâng dần lên quarantine rồi reject. Làm ngược lại thường khiến thư hợp lệ bị loại oan.
Kiểm tra cấu hình bằng lệnh dig
Dig là công cụ hỏi DNS trực tiếp từ dòng lệnh. Thay vì đoán xem bản ghi đã có hiệu lực hay chưa, bạn hỏi thẳng và nhận kết quả ngay.
Để kiểm tra SPF, gõ dig TXT yourdomain.com +short rồi tìm dòng bắt đầu bằng v=spf1. Để kiểm tra DMARC, gõ dig TXT _dmarc.yourdomain.com +short. Nếu thấy v=DMARC1 xuất hiện, bạn đã đi đúng hướng.
Với DKIM, bạn cần đúng selector. Lệnh có dạng dig TXT selector._domainkey.yourdomain.com +short. Nếu kết quả rỗng, khả năng cao bạn gõ sai selector hoặc chưa lưu bản ghi.
Nếu kết quả vẫn rỗng, đừng vội kết luận cấu hình sai. DNS có thể chưa lan truyền xong, hoặc bạn đang truy vấn nhầm tên miền. Hãy kiểm tra lại tên bản ghi trước, rồi đợi thêm một lúc và thử lại.
Lỗi thường gặp khi cấu hình và cách tránh
Lỗi phổ biến nhất là tồn tại hai bản ghi SPF cùng lúc. Máy nhận coi đó là lỗi cú pháp và xác thực thất bại. Cách xử lý là gộp mọi cơ chế vào một bản ghi duy nhất.
Lỗi thứ hai là quên bật DKIM. Một số dịch vụ vẫn cho phép gửi khi chưa có DKIM, nhưng nhiều nhà cung cấp, MONA Mail là một ví dụ, yêu cầu bắt buộc. Kết quả là thư đi ra khỏi hệ thống nhưng bị chặn ở đầu nhận, và bạn khó biết nguyên nhân nếu không kiểm tra.
Lỗi thứ ba là chuyển DMARC sang p=reject quá sớm. Khi đó mọi thư không vượt qua xác thực đều bị loại bỏ, kể cả thư hợp lệ từ một dịch vụ bạn quên khai báo. Hãy theo dõi báo cáo đủ lâu trước khi siết chặt chính sách.
Khi nào nên dùng API có tài liệu và SDK đầy đủ
Nếu cần tích hợp nhanh, đừng cố đọc mọi thứ từ đầu. Hãy bắt đầu với tài liệu API và SDK của nhà cung cấp. Với MONA Mail, bạn có thể xem tại tài liệu API và SDK của MONA Mail, nơi có ví dụ gửi thư cho nhiều ngôn ngữ lập trình khác nhau.
Việc so sánh mức độ đầy đủ của tài liệu giữa các nhà cung cấp rất đáng làm. Một trang tài liệu rõ ràng, có kèm ví dụ về lỗi và cách xử lý, sẽ giúp bạn tiết kiệm nhiều buổi tối ngồi đoán mò. Nếu bạn đang cân nhắc tự động hóa nhiều đầu việc kỹ thuật, những tác vụ kỹ thuật nên giao cho máy trước tiên là bài đọc giúp bạn hình dung nên tự động hóa phần nào của quy trình gửi thư.
Với dự án nhỏ, một SDK đơn giản là đủ. Với hệ thống lớn có nhiều luồng thư khác nhau, hãy ưu tiên dịch vụ có khả năng theo dõi và cảnh báo rõ ràng. Đó là thứ sẽ cứu bạn vào lúc nửa đêm khi có sự cố.
Nền tảng kiến thức trước khi cấu hình
Nếu bạn mới làm quen với các khái niệm như DNS, máy chủ hay API, nên đọc qua phần kiến thức nền trước. Bên mình từng tổng hợp kiến thức nền tảng về lập trình web và mobile cho người mới, và phần này giúp bạn đọc các bước cấu hình bên trên dễ dàng hơn nhiều.
Câu hỏi thường gặp
Có cần cấu hình cả SPF lẫn DKIM không?
Chúng tôi khuyên nên làm cả hai. SPF và DKIM kiểm tra hai khía cạnh khác nhau, và DMARC hoạt động hiệu quả nhất khi có ít nhất một trong hai đạt yêu cầu. Tốt nhất là bật đủ cả ba cơ chế ngay từ đầu.
DMARC p=none có đủ để bảo vệ tên miền không?
Chưa hẳn. p=none chỉ giúp bạn theo dõi, chưa ngăn được kẻ giả mạo. Đây là bước khởi đầu an toàn, còn bảo vệ thực sự chỉ đến khi bạn nâng lên quarantine hoặc reject.
Lệnh dig có kiểm tra được DKIM không?
Có, miễn là bạn biết đúng selector. Dig chỉ xác nhận bản ghi tồn tại và nội dung đúng, nhưng không kiểm tra chữ ký của một thư cụ thể. Muốn kiểm tra chữ ký, bạn cần gửi thử và xem header của thư nhận được.
Bao lâu thì bản ghi DNS có hiệu lực?
Thường từ vài phút đến vài giờ, tùy TTL và nhà cung cấp DNS. Trong trường hợp hiếm, có thể mất đến hai ngày. Đừng sửa liên tục, hãy đợi rồi kiểm tra lại bằng dig.
Gửi email giao dịch có cần IP riêng không?
Đa số người mới không bắt buộc. IP chung của nhà cung cấp, nếu được quản lý tốt, vẫn cho kết quả ổn định. IP riêng chỉ đáng cân nhắc khi lượng thư đủ lớn và bạn muốn kiểm soát hoàn toàn uy tín gửi thư.
Lời khuyên cuối cùng của đội ngũ bên mình: đừng đợi khách hàng phàn nàn thư không tới mới bắt tay làm. Hãy dành một buổi chiều để cấu hình SPF, DKIM, DMARC và kiểm tra bằng dig ngay từ đầu. Bạn sẽ tránh được cả tuần truy tìm lỗi về sau.
