Cuối tuần trước, một khách hàng của chúng tôi gọi điện trong tình trạng khá căng. Ứng dụng vừa ra mắt được hai ngày, người dùng đăng ký xong thì chờ mãi không thấy mã xác thực đâu. Đội hỗ trợ kiểm tra log thì thấy hệ thống vẫn gửi thư đi bình thường, chỉ là toàn bộ đều nằm trong thư mục spam. Chúng tôi gặp tình huống này khá thường xuyên. Vì vậy hôm nay chúng tôi muốn đi qua cách cấu hình SPF, DKIM và DMARC cho tên miền gửi email giao dịch, cùng cách kiểm tra từng bản ghi bằng lệnh dig, để bạn tránh rơi vào hoàn cảnh tương tự.
Vì sao email giao dịch cần xác thực ngay từ đầu
Email giao dịch là loại thư hệ thống tự động gửi đi khi người dùng làm một việc cụ thể, như xác thực tài khoản, nhận hóa đơn hay đặt lại mật khẩu. Nghe thì đơn giản, nhưng các nhà cung cấp hộp thư lớn như Gmail hay Outlook đánh giá rất gắt với thư đến từ máy chủ lạ.
Khi thư không đi kèm chứng nhận xác thực, phía người nhận không có cách nào biết nó thật sự do bạn gửi. Thiếu xác thực nghĩa là thư dễ bị gắn cờ giả mạo, và nhiều khi bị đẩy thẳng vào spam. Ba bản ghi SPF, DKIM và DMARC chính là cách để bạn chứng minh danh tính người gửi với máy chủ nhận.
Ba bản ghi DNS bạn cần hiểu rõ
Ba cái tên này nghe giống thủ tục hành chính, nhưng mỗi cái trả lời một câu hỏi khác nhau mà máy chủ nhận đặt ra.
- SPF là bản ghi TXT liệt kê các máy chủ được phép gửi thư thay mặt tên miền của bạn.
- DKIM là chữ ký số gắn vào mỗi thư. Máy chủ nhận dùng khóa công khai đặt trong DNS để kiểm tra nội dung có bị sửa dọc đường hay không.
- DMARC là chính sách cho biết người nhận cần xử lý thế nào khi SPF hoặc DKIM không khớp, đồng thời gửi báo cáo ngược về cho bạn.
Ba thứ này bổ trợ cho nhau chứ không thay thế nhau. Chỉ có SPF thì thư giả mạo qua chuyển tiếp vẫn có thể lọt. Chỉ có DKIM thì bạn không biết ai đang mạo danh tên miền của mình. Với dự án nghiêm túc, đội ngũ chúng tôi luôn khuyên làm đủ cả ba.
Thêm bản ghi vào tên miền thế nào cho đúng?
Bạn đăng nhập trang quản lý DNS của nhà cung cấp tên miền, rồi tạo các bản ghi TXT với đúng tên host và nội dung mà dịch vụ email đã cấp. Đừng tự chế nội dung. Lệch một ký tự là cả chuỗi coi như vô dụng.
Với DKIM, tên host thường có dạng tên selector đi kèm ._domainkey. Khi dán chuỗi khóa dài, hãy để ý không để lại khoảng trắng hay dấu xuống dòng thừa ở đầu hoặc cuối. Đây là chỗ chúng tôi gặp nhiều lỗi nhất, và có lần chủ dự án loay hoay cả buổi mới phát hiện chỉ vì một dấu cách vô hình.
Sau khi lưu, DNS cần thời gian để lan truyền, thường từ vài phút đến vài giờ. Chưa thấy thay đổi thì đừng vội sửa lại, vì sửa liên tục chỉ làm mọi thứ rối thêm và khó biết bản nào đang có hiệu lực.
Kiểm tra từng bản ghi bằng lệnh dig
Khi đã chờ đủ thời gian, bạn mở terminal và kiểm tra từng bản ghi. Lệnh đầu tiên là:
dig TXT yourdomain.com +short
Lệnh này trả về các bản ghi TXT của tên miền. Bạn tìm dòng bắt đầu bằng v=spf1 để xác nhận SPF. Với DKIM, chạy dig TXT selector._domainkey.yourdomain.com +short và thay selector bằng tên mà dịch vụ đã cấp. Cuối cùng, kiểm tra DMARC bằng dig TXT _dmarc.yourdomain.com +short.
Nếu kết quả trống hoặc khác với nội dung dịch vụ đưa ra, đừng hoang mang. Hãy soát lại chính tả, dấu nháy và tên host. Lệnh dig chỉ cho bạn thấy DNS đang trả về cái gì, nên nó là công cụ đối chiếu rất đáng tin. Đó cũng là cách chúng tôi thường làm mỗi khi hỗ trợ khách qua điện thoại.
Những lỗi hay gặp 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ỗi tên miền chỉ được có một bản ghi SPF. Thêm nhiều bản ghi thì máy chủ nhận có thể coi tất cả là lỗi, và thư vẫn không qua được kiểm tra. Nếu cần thêm máy chủ gửi mới, hãy gộp vào cùng một bản ghi.
Lỗi thứ hai là copy thừa khoảng trắng khi dán chuỗi DKIM. Chuỗi này rất dài và dễ lệch vài ký tự, nên sau khi dán xong, hãy chạy dig để xác nhận lại từng ký tự.
Lỗi thứ ba là đặt DMARC ở chế độ từ chối ngay từ đầu. Chúng tôi thường khuyên bắt đầu bằng chính sách chỉ quan sát, nhận báo cáo trong vài tuần để xem ai đang gửi thư dưới tên bạn, rồi mới siết dần. Cách làm này giúp bạn không vô tình chặn nhầm chính những thư thật của mình.
Chọn dịch vụ gửi email giao dịch phù hợp
Khi làm dự án mới, bạn nên chọn dịch vụ có tài liệu cấu hình dễ đọc, đừng chỉ nhìn tính năng trên trang giới thiệu. Một điểm chúng tôi hay nhắc khách là webhook. Webhook giúp hệ thống của bạn biết ngay khi một địa chỉ nhận không tồn tại, để ngừng gửi vào đó. Nếu cứ gửi tiếp vào địa chỉ chết, tỉ lệ bounce tăng lên, và uy tín tên miền cũng đi xuống theo.
Có một điều chúng tôi muốn nhấn mạnh: email giao dịch và email marketing nên đi qua hai luồng riêng. Thư xác thực thì không được phép thất bại, còn bản tin khuyến mãi có thể gửi chậm hơn và chọn lúc. Tách hai luồng giúp một chiến dịch quảng cáo không kéo uy tín của luồng giao dịch xuống theo.
Nếu bạn là dev Việt đang tìm lựa chọn, MONA Mail là một cái tên đáng cân nhắc. Gói miễn phí hỗ trợ 3.000 email mỗi tháng (tính đến tháng 11/2026) và yêu cầu cấu hình DKIM ngay từ đầu, nên bạn khó bỏ qua bước xác thực. Điểm chưa mạnh là tài liệu tiếng Anh của các đối thủ lớn thường phong phú hơn, nên nếu gặp lỗi lạ, bạn có thể mất thêm thời gian tìm lời giải. Trước khi tích hợp, bạn có thể xem tài liệu API và SDK tại MONA Mail để đối chiếu từng tham số.
Khi đã nghĩ tới chuyện xây hệ thống thông báo cho ứng dụng, bạn cũng nên đọc bài viết về rate limiting để hiểu vì sao cần giới hạn số lần gửi yêu cầu, tránh việc một lỗi nhỏ làm hệ thống gửi thư bị quá tải.
Chi phí khi quy mô gửi email tăng lên
Lúc mới làm, chi phí gửi email có vẻ là chuyện nhỏ. Nhưng khi người dùng tăng từ vài nghìn lên vài trăm nghìn mỗi tháng, khác biệt giữa các gói bắt đầu lộ rõ.
Cách ước lượng đơn giản là đếm số người đăng ký mỗi tháng, nhân với số email giao dịch mà mỗi người nhận trong vòng đời tài khoản, rồi cộng thêm thư đặt lại mật khẩu và hóa đơn. Lấy con số đó làm nền, sau đó chừa thêm khoảng 20 đến 30 phần trăm để dự phòng. Đừng mua gói quá lớn chỉ vì sợ thiếu, vì phần lớn dự án tăng trưởng chậm hơn kỳ vọng ban đầu nhiều.
Quy trình triển khai cho dự án mới
Đội ngũ chúng tôi thường đi theo ba bước. Bước đầu là chọn một tên miền gửi riêng, ví dụ mail.yourdomain.com, tách khỏi tên miền website chính. Nếu có sự cố về uy tín gửi thư, website chính sẽ không bị kéo theo.
Bước thứ hai là cấu hình ba bản ghi, dùng dig để kiểm tra, rồi gửi thử trên môi trường staging. Đừng đưa lên môi trường thật khi chưa nhìn thấy thư về hộp thư thật, cả Gmail lẫn Outlook. Và đừng quên mở thư mục spam để xem.
Bước cuối là thiết lập webhook để theo dõi bounce và khiếu nại, sau đó định kỳ làm sạch danh sách. Địa chỉ đã bounce nhiều lần nên được loại khỏi danh sách gửi, không nên thử lại mãi.
Câu hỏi thường gặp
SPF và DKIM khác nhau thế nào?
SPF cho biết máy chủ nào được phép gửi thư cho tên miền của bạn. DKIM gắn chữ ký số vào từng thư để người nhận xác minh thư không bị sửa giữa đường. Hai cái này bổ sung cho nhau, không cái nào thay thế được cái nào.
Vì sao thư giao dịch vẫn vào spam dù đã cấu hình đủ?
Thường do nội dung có từ ngữ giống quảng cáo, tỉ lệ bounce cao, hoặc uy tín của IP còn mới. Hãy kiểm tra webhook, làm sạch danh sách và tránh gửi cùng lúc quá nhiều thư không liên quan đến người dùng.
Có cần DMARC nếu chỉ gửi vài trăm email mỗi tháng không?
Nên có. Khi đã có SPF và DKIM, DMARC không tốn nhiều công sức, và nó giúp bạn phát hiện ai đó đang mạo danh tên miền của mình.
Làm sao kiểm tra bản ghi DNS đã đúng bằng lệnh dig?
Chạy dig với loại TXT và tên miền tương ứng, rồi so kết quả với nội dung dịch vụ cung cấp. Nếu chưa thấy thay đổi, hãy chờ thêm thời gian DNS lan truyền rồi thử lại.
Nên chọn gói miễn phí hay trả phí ngay từ đầu?
Nếu dự án còn thử nghiệm, gói miễn phí đủ để làm quen và kiểm tra luồng gửi. Khi người dùng thật bắt đầu tăng, hãy chuyển sang gói trả phí để có hạn mức và hỗ trợ ổn định hơn.
Tham khảo thêm: khi nào nên đầu tư máy chủ riêng thay vì thuê cloud nếu bạn đang cân nhắc hạ tầng gửi thư lâu dài cho doanh nghiệp.