Chúng tôi từng gặp không ít trường hợp khách hàng nhắn tin hỏi: email xác nhận đơn hàng không thấy đâu, còn mã OTP thì nằm im trong thư mục spam. Ai cũng sốt ruột. Khi rà lại từng khâu, phần lớn lỗi không nằm ở nội dung thư mà ở chỗ tên miền gửi chưa được khai báo đúng với hệ thống nhận. Bài này đi qua cách cấu hình SPF, DKIM và DMARC cho tên miền gửi email giao dịch, rồi kiểm tra từng bản ghi bằng lệnh dig, đúng theo quy trình đội ngũ bên mình vẫn dùng khi bàn giao cho khách.
Vì sao email giao dịch không chỉ cần gửi đi
Email giao dịch là những thư hệ thống tự động gửi đi: xác nhận đơn, mã OTP, nhắc lịch hẹn, hóa đơn. Người nhận đang chờ đúng những email này. Nếu một mã OTP bị đẩy vào spam, khách không đăng nhập được, và phần lớn họ sẽ không kiên nhẫn đi tìm.
Gmail hay Outlook không tin ngay một thư chỉ vì nó tự nhận mình đến từ tên miền của bạn. Hệ thống nhận cần một cách để kiểm chứng. Ba cơ chế SPF, DKIM và DMARC ra đời để làm việc đó. Chúng bổ sung cho nhau chứ không thay thế nhau.
Thư có thể được gửi đi bằng hai cách. Cách thứ nhất là tự dựng máy chủ SMTP và quản lý toàn bộ đường gửi. Cách thứ hai là gọi API của một nhà cung cấp, một lệnh là thư được chuyển đi. Mỗi cách có ưu nhược điểm riêng. Việc chọn cách nào thường phụ thuộc vào quy mô gửi và nguồn lực kỹ thuật bạn đang có.
Ba cơ chế xác thực nhìn từ phía người vận hành
Nói ngắn gọn: SPF trả lời câu hỏi máy chủ nào được phép nhân danh tên miền của bạn để gửi thư. DKIM chứng minh nội dung không bị ai sửa trên đường đi. DMARC đứng trên cả hai và quyết định nên xử lý thế nào với thư không vượt qua kiểm tra.
Người mới thường nghĩ chỉ cần có SPF là yên tâm. Thực tế SPF có giới hạn riêng, đặc biệt khi thư được chuyển tiếp qua trung gian. Vì vậy DKIM và DMARC là những lớp cần thiết, không phải phần thêm cho đủ bộ.
Cấu hình SPF
SPF là một bản ghi TXT trong DNS, liệt kê các máy chủ hoặc dải IP được phép gửi thư thay mặt tên miền của bạn. Có thể hình dung nó như một bản khai công khai: những địa chỉ này đã được ủy quyền gửi thư.
Lỗi chúng tôi gặp nhiều nhất là tạo hai bản ghi SPF cho cùng một tên miền. Nhiều hệ thống nhận sẽ coi cả hai đều không hợp lệ, và thư bị đánh giá thấp mà bạn khó hiểu vì sao. Khi thêm nhà cung cấp mới, hãy gộp mọi cơ chế vào một bản ghi duy nhất. Lưu ý thêm rằng mỗi lệnh include là một lượt tra cứu DNS, nên gửi qua quá nhiều dịch vụ có thể vượt giới hạn và khiến SPF lỗi.
- Chỉ giữ một bản ghi v=spf1 cho mỗi tên miền.
- Kết thúc bằng ~all hoặc -all tùy mức độ nghiêm ngặt bạn muốn.
- Khai báo đủ include cho mọi nhà cung cấp đang gửi thư thay bạn.
Cấu hình DKIM
DKIM là chữ ký số gắn vào từng email. Máy chủ nhận dùng khóa công khai đặt trong DNS để kiểm tra chữ ký. Nếu khớp, thư được xác nhận là không bị chỉnh sửa giữa đường.
Nhiều nhà cung cấp hiện nay coi DKIM là điều kiện bắt buộc. Khi dùng MONA Mail chẳng hạn, bạn cần thêm khóa DKIM do hệ thống cấp trước khi gửi thư thật. Bỏ qua bước này, thư vẫn đi được nhưng dễ bị hộp thư đích nghi ngờ. Đây là lỗi khá thường gặp khi chúng tôi hỗ trợ đội ngũ mới chuyển sang, và thường chỉ được phát hiện khi có khách phàn nàn.
Cấu hình DMARC và lộ trình siết dần
DMARC là bản ghi chính sách đặt tại _dmarc.tenmien. Nó cho biết thư không vượt qua SPF hoặc DKIM thì nên được cho qua, đưa vào spam, hay bị từ chối. Giá trị lớn nhất của DMARC là báo cáo gửi về địa chỉ bạn chỉ định, cho thấy ai đang gửi thư nhân danh tên miền của bạn, kể cả những kẻ mạo danh mà bạn chưa từng biết.
Với người mới, chúng tôi khuyên bắt đầu bằng p=none. Chính sách này chỉ theo dõi và không ảnh hưởng đến thư đang gửi. Sau vài tuần đọc báo cáo và xác nhận mọi nguồn gửi hợp lệ đã được xác thực, mới nên chuyển sang p=quarantine rồi p=reject. Siết ngay từ đầu rất dễ chặn luôn những thư hợp lệ mà bạn chưa kịp nhận ra.
Kiểm tra bản ghi bằng lệnh dig
Sau khi thêm bản ghi, đừng đoán rằng nó đã có hiệu lực. Lệnh dig trên Linux hoặc macOS cho phép hỏi trực tiếp DNS, và đây là cách nhanh nhất để xác nhận.
Để xem SPF, chạy dig TXT tenmien.vn +short rồi tìm dòng bắt đầu bằng v=spf1. Để kiểm tra DMARC, chạy dig TXT _dmarc.tenmien.vn +short. Kết quả có chuỗi v=DMARC1 nghĩa là bản ghi đã được công bố.
DKIM hơi khác vì khóa nằm dưới một selector do nhà cung cấp đặt, ví dụ dig TXT selector1._domainkey.tenmien.vn +short. Tên selector phải khớp với hướng dẫn của nhà cung cấp. Lỗi thường gặp là dùng sai selector nên lệnh trả về rỗng, dù khóa bạn nhập vào DNS hoàn toàn chính xác.
Ba lỗi chúng tôi thấy nhiều nhất là: hai bản ghi SPF trùng nhau, thiếu hoặc thừa dấu ngoặc kép và khoảng trắng trong chuỗi, và quên rằng DNS có TTL nên kết quả vẫn trả về bản cũ trong một khoảng thời gian. Hãy đợi rồi kiểm tra lại, đừng vội kết luận.
Tích hợp API vào ứng dụng thực tế
Giả sử bạn cần gửi email xác nhận ngay khi khách thanh toán xong. Bạn gọi SDK của nhà cung cấp, truyền địa chỉ người nhận, tiêu đề và nội dung. Phần gọi hàm không khó. Phần xử lý lỗi mới quyết định chất lượng vận hành.
Khi API timeout hoặc trả lỗi tạm thời, hãy thử lại với số lần giới hạn và giãn khoảng cách giữa các lần để tránh dồn tải. Đồng thời, đăng ký webhook để nhận sự kiện bounce và complaint. Nhờ vậy địa chỉ hỏng được gỡ khỏi danh sách trước khi làm giảm uy tín gửi của bạn. Tài liệu chi tiết và SDK chính thức của MONA Mail nằm tại tài liệu API và SDK của MONA Mail, bạn nên đọc kỹ phần webhook trước khi đưa vào sản xuất.
So sánh các hướng đi phổ biến
Thị trường hiện có nhiều lựa chọn. Resend được nhiều lập trình viên ưa dùng nhờ API gọn và tài liệu dễ đọc, nhưng hệ sinh thái còn non so với các đơn vị lâu năm. SendGrid có nhiều tính năng dành cho doanh nghiệp lớn, đổi lại giao diện và gói giá đôi khi khiến người mới khó nắm bắt. Tài khoản mới đôi khi còn bị giới hạn số lượng gửi.
Amazon SES có chi phí hấp dẫn khi khối lượng lớn và chạy ổn định trên hạ tầng AWS. Đổi lại, bạn tự làm nhiều việc hơn: quản lý quyền IAM, theo dõi chất lượng gửi và đưa tài khoản ra khỏi chế độ sandbox. MONA Mail là lựa chọn trong nước, có gói miễn phí 3.000 email mỗi tháng và các gói trả phí 99.000đ, 299.000đ, 799.000đ (tính đến tháng 11/2026), phù hợp với đội ngũ cần hỗ trợ tiếng Việt và thanh toán nội địa. Giá và hạn mức có thể thay đổi, nên hãy đối chiếu bảng giá chính thức trước khi quyết định.
Ba sai lầm thường gặp khi chuyển sang API gửi email mới
Sai lầm đầu tiên là quên cấu hình DKIM. Thư vẫn đi được, nhưng không được ký nên dễ bị đánh giá thấp. Người dùng thấy email rơi vào spam mà không hiểu lý do, và đội ngũ kỹ thuật thường mất vài ngày để tìm ra nguyên nhân.
Sai lầm thứ hai là dùng chung một tên miền cho cả email giao dịch lẫn email marketing. Khi người nhận bấm báo spam với thư quảng cáo, uy tín tên miền đi xuống và email xác nhận đơn cũng bị kéo theo. Chúng tôi khuyên tách subdomain hoặc tài khoản gửi riêng để cô lập rủi ro.
Sai lầm thứ ba là đổi nhà cung cấp rồi thôi, không theo dõi tỷ lệ bounce. Hãy xem chỉ số này trong vài tuần đầu. Nếu tăng bất thường, có thể bản ghi DNS chưa đúng, hoặc danh sách người nhận cũ đang chứa nhiều địa chỉ không còn tồn tại.
Câu hỏi thường gặp
SPF và DKIM khác nhau thế nào?
SPF xác định máy chủ nào được phép gửi thư cho tên miền. DKIM là chữ ký số gắn vào từng email để chứng minh nội dung không bị sửa. Hai cơ chế này bổ sung cho nhau, không thay thế nhau.
Có cần DMARC nếu chỉ gửi vài trăm email mỗi tháng không?
Nên có. DMARC không tốn nhiều công sức thiết lập, còn báo cáo giúp phát hiện sớm kẻ mạo danh tên miền của bạn. Với khối lượng nhỏ, bắt đầu bằng p=none là đủ an toàn.
Gói miễn phí có đủ cho ứng dụng nhỏ không?
Với ứng dụng nhỏ, gói miễn phí thường đủ để bắt đầu. Khi lượng thư tăng, hãy theo dõi số liệu thực tế rồi mới nâng gói, thay vì đoán trước.
Đổi nhà cung cấp email có làm mất uy tín gửi không?
Có thể ảnh hưởng trong giai đoạn đầu, vì hệ thống nhận chưa quen với đường gửi mới. Nên tăng khối lượng dần và theo dõi tỷ lệ bounce, thay vì chuyển toàn bộ trong một ngày.
Nếu chỉ làm một việc ngay hôm nay, chúng tôi khuyên bạn kiểm tra bản ghi SPF và DMARC của tên miền bằng lệnh dig, rồi mới bàn đến chuyện chọn nhà cung cấp. Cấu hình đúng từ đầu sẽ tiết kiệm rất nhiều thời gian gỡ rối về sau.
