Chúng tôi từng gặp tình huống này không ít lần. Đội kỹ thuật vừa hoàn thành tính năng quên mật khẩu, bấm thử thì mã OTP biến mất khỏi hộp thư đến. Mở thư mục spam mới thấy nó nằm đó. Lúc này người làm code thường lục lại từng dòng logic mà vẫn không tìm ra lỗi. Thực ra nguyên nhân nằm ở tầng hạ tầng gửi thư. Bài viết này được chúng tôi chia sẻ để bạn bớt những buổi tối debug vô ích, nhất là khi bạn cần cấu hình SPF, DKIM, DMARC cho tên miền gửi email giao dịch và kiểm tra lại bằng lệnh dig.
Vì sao email giao dịch bị vào spam dù code đã đúng?
Email giao dịch là thư hệ thống tự động gửi khi có một hành động cụ thể, như mã xác nhận, thông báo đơn hàng, hóa đơn hoặc liên kết đặt lại mật khẩu. Người dùng đang chờ những thư này. Các nhà cung cấp hộp thư lớn như Gmail hay Outlook xử lý chúng khác hẳn với thư quảng cáo.
Máy chủ nhận không tin bạn chỉ vì tên người gửi nghe quen thuộc. Nó cần kiểm chứng. Code quyết định nội dung và thời điểm gửi, nhưng việc chứng minh thư thật sự đến từ tên miền của bạn lại phụ thuộc vào bản ghi DNS và cấu hình máy chủ gửi. Nếu phần này thiếu hoặc sai, dù nội dung hoàn hảo, thư vẫn có thể bị gắn cờ nghi ngờ.
Vì vậy, người làm web nên nắm phần hạ tầng này ngay từ đầu. Dành chút thời gian đọc kỹ sẽ giúp bạn tránh được nhiều đêm loay hoay không cần thiết.
Email giao dịch khác email marketing ở điểm nào?
Email giao dịch được kích hoạt bởi hành động của một người dùng cụ thể, ví dụ vừa đăng ký, vừa đặt hàng hay vừa bấm quên mật khẩu. Email marketing thì được gửi hàng loạt theo chiến dịch và không gắn với hành động nào tại thời điểm gửi.
Khác biệt lớn nhất nằm ở độ gấp. Mã OTP chỉ có hiệu lực vài phút. Nếu thư đến sau mười phút, người dùng gần như đã bỏ đi. Thư giao dịch vì thế cần tốc độ và độ tin cậy cao hơn hẳn thư quảng cáo. Khi đánh giá một dịch vụ, bạn nên hỏi ba điều: thư có đến nhanh không, tỷ lệ vào hộp thư chính có cao không, và khi có sự cố thì có công cụ truy vết để tra lại không.
Các nhóm dịch vụ gửi email phổ biến hiện nay
Thị trường hiện có bốn nhóm khá rõ ràng, mỗi nhóm hợp một kiểu dự án khác nhau. Nhóm API gửi email chuyên dụng như Resend, SendGrid hay Amazon SES là lựa chọn quen thuộc của nhiều ứng dụng web. Nhóm tích hợp sẵn trong nền tảng triển khai như Vercel, Railway hay Render tiện nếu bạn đã đưa ứng dụng lên đó.
Nhóm backend-as-a-service có sẵn dịch vụ email, như Supabase hay Firebase, hợp lý khi bạn đã dùng cả bộ công cụ của họ. Còn dịch vụ trong nước như MONA Mail tập trung vào email giao dịch cho thị trường Việt Nam, có hỗ trợ tiếng Việt và múi giờ thuận tiện hơn cho đội ngũ trong nước.
Không có nhóm nào tốt nhất cho mọi trường hợp. Hãy nhìn vào nhu cầu của dự án trước khi nhìn vào bảng so sánh.
Giá, hạn mức và cách tính phí cần xem kỹ
Với các đối thủ quốc tế, bạn nên tự đối chiếu bảng giá chính thức, vì chính sách thay đổi theo thời gian. Chúng tôi không muốn bạn đọc một con số đã lỗi thời trong bài viết này.
Riêng MONA Mail, tính đến tháng 11/2026, gói miễn phí cho phép gửi 3.000 email mỗi tháng. Các gói trả phí có mức giá 99.000đ, 299.000đ và 799.000đ. Với một ứng dụng nhỏ mới ra mắt, bạn có thể vận hành gần như miễn phí trong giai đoạn đầu.
Đừng chỉ nhìn vào số tiền. Hãy đọc kỹ giới hạn gửi theo ngày, dung lượng đính kèm tối đa và thời gian lưu log. Một gói rẻ nhưng chỉ giữ log bảy ngày sẽ khiến bạn lúng túng khi khách hàng hỏi về một email gửi từ tuần trước.
Những điểm hạn chế bạn nên biết trước
Không lựa chọn nào hoàn hảo. Các dịch vụ quốc tế thường có giao diện tiếng Anh, hỗ trợ theo múi giờ khác và yêu cầu thẻ thanh toán quốc tế. Người chưa quen những điều này sẽ mất kha khá thời gian làm quen.
Dịch vụ nội địa thì hệ sinh thái nhỏ hơn và số bài hướng dẫn từ cộng đồng ít hơn. Khi gặp lỗi lạ, bạn có thể phải tự đọc tài liệu kỹ hơn, đôi khi phải liên hệ hỗ trợ trực tiếp. Trước khi bắt đầu, bạn nên xem qua tài liệu API và SDK của MONA Mail để đối chiếu cách cấu hình.
Ngoài ra, hãy để ý các chi phí ẩn. Khi vượt hạn mức thì tính phí thế nào? Thêm tên miền gửi có mất phí không? Hai khoản này thường bị bỏ qua ở giai đoạn đầu và hay gây bất ngờ về sau.
Cấu hình SPF, DKIM, DMARC: ba bản ghi không thể bỏ qua
Ba bản ghi này nghe như thuật ngữ khó, nhưng ý nghĩa khá đơn giản. Hãy hình dung tên miền của bạn như một công ty có con dấu, và có quy định rõ ai được phép dùng con dấu đó.
SPF là danh sách các máy chủ được phép gửi thư thay mặt tên miền của bạn, tức là những ai được mang danh công ty đi gửi thư. DKIM là chữ ký số gắn vào mỗi thư. Người nhận dùng khóa công khai đặt trong DNS để xác minh thư không bị sửa đổi trên đường đi. DMARC là quy định cho người nhận biết phải làm gì khi SPF hoặc DKIM thất bại: cho qua, đưa vào thư rác hay từ chối hẳn.
Hiện nay nhiều nhà cung cấp bắt buộc DKIM, và MONA Mail cũng yêu cầu cấu hình này trước khi cho phép gửi thư từ tên miền của bạn. Nếu bỏ qua, thư rất dễ rơi vào thư rác. Với DMARC, chúng tôi khuyên bắt đầu ở chế độ chỉ theo dõi rồi mới siết dần, để tránh chặn nhầm những thư hợp lệ.
Kiểm tra cấu hình bằng lệnh dig
Đừng dựa vào cảm giác rằng mình đã cấu hình đúng. Hãy kiểm tra bằng lệnh. Lệnh dig có sẵn trên Linux và macOS. Trên Windows, bạn có thể dùng WSL hoặc một công cụ tương đương.
Để xem bản ghi SPF, chạy dig TXT ten-mien-cua-ban.vn +short rồi tìm dòng bắt đầu bằng v=spf1. Nếu không thấy dòng này, nghĩa là bạn chưa cấu hình SPF.
Với DKIM, bạn cần selector do nhà cung cấp cấp. Chạy dig TXT selector._domainkey.ten-mien-cua-ban.vn +short. Kết quả phải chứa khóa công khai bắt đầu bằng v=DKIM1. Nếu trả về rỗng, khả năng cao selector đang nhập sai.
Với DMARC, chạy dig TXT _dmarc.ten-mien-cua-ban.vn +short. Bạn sẽ thấy v=DMARC1 cùng chính sách p=. Người mới nên bắt đầu với p=none để quan sát báo cáo trước.
Qua quá trình hỗ trợ khách hàng, đội ngũ chúng tôi thấy ba lỗi xuất hiện nhiều nhất. Lỗi đầu tiên là có hai bản ghi SPF cùng lúc, và người nhận sẽ coi đó là cấu hình sai. Lỗi thứ hai là nhập sai selector nên không tìm thấy khóa. Lỗi thứ ba là vừa sửa DNS xong đã kiểm tra ngay, trong khi bản ghi cũ vẫn còn hiệu lực do TTL. Hãy chờ vài phút đến vài giờ rồi kiểm tra lại.
Chọn dịch vụ theo nhu cầu thực tế
Dự án nhỏ với ít email nên ưu tiên gói miễn phí và tích hợp dễ dàng. Đừng vội trả tiền cho những tính năng chưa cần đến.
Ứng dụng có lượng gửi lớn cần quan tâm đến độ ổn định và công cụ theo dõi tỷ lệ mở, tỷ lệ bị đánh dấu spam. Một sự cố nhỏ ở quy mô đó có thể khiến hàng nghìn người dùng không nhận được mã xác nhận trong cùng một buổi sáng.
Nên dùng API hay SMTP khi tích hợp?
SMTP là giao thức gửi thư lâu đời và hầu như ứng dụng nào cũng hỗ trợ. Với hệ thống cũ, SMTP vẫn là đường đi dễ nhất vì ít phải sửa code. Nhược điểm là thông báo lỗi thường mơ hồ và việc kiểm thử khá rườm rà.
API gọn hơn. Cấu hình đơn giản, lỗi trả về rõ ràng, và bạn có thể viết test tự động dễ dàng. Với dự án mới, chúng tôi thường khuyên dùng API. Khi cần hiểu thêm về cách hệ thống kết nối dữ liệu, bạn có thể tham khảo bài công nghệ xe để thấy rõ hơn tư duy đồng bộ dữ liệu giữa các hệ thống.
Câu hỏi thường gặp
Có cần cấu hình cả SPF, DKIM lẫn DMARC không?
Nên có đủ cả ba. SPF và DKIM là nền tảng, còn DMARC là lớp bảo vệ và cung cấp báo cáo. Nếu chỉ làm một phần, thư vẫn có thể bị nghi ngờ, đặc biệt khi có kẻ giả mạo tên miền của bạn.
Email vào thư rác sau khi đổi nhà cung cấp thì xử lý thế nào?
Trước tiên, kiểm tra SPF đã có máy chủ mới chưa và DKIM đã đúng selector chưa. Sau đó theo dõi báo cáo DMARC vài ngày để xem thư nào thất bại. Đừng vội quay lại nhà cung cấp cũ khi chưa tìm ra nguyên nhân.
Bản ghi DNS mất bao lâu để có hiệu lực?
Thường từ vài phút đến vài giờ, tùy TTL. Có trường hợp lâu hơn. Nếu sau một ngày vẫn chưa thấy thay đổi, hãy kiểm tra lại tên bản ghi và cấu hình tại nhà cung cấp DNS.
Gói miễn phí có đủ cho ứng dụng nhỏ không?
Với MONA Mail, gói miễn phí 3.000 email mỗi tháng đủ cho nhiều ứng dụng mới ra mắt. Hãy ước lượng số thư giao dịch thực tế của bạn trước khi quyết định.
Làm sao biết cấu hình đã đúng?
Dùng lệnh dig như hướng dẫn ở trên để kiểm tra từng bản ghi. Sau đó gửi thử vài thư đến các hộp thư phổ biến và xem thư nằm ở đâu. Nếu thư vào hộp thư chính và các thông tin xác thực đều hợp lệ, bạn đã đi đúng hướng.
Nếu chỉ làm một việc hôm nay, chúng tôi khuyên bạn kiểm tra ba bản ghi DNS của tên miền đang dùng bằng lệnh dig. Việc này mất khoảng mười phút, nhưng có thể giúp bạn tránh một tuần lo lắng vì khách hàng không nhận được mã xác nhận.