Chúng tôi gặp tình huống này khá thường xuyên. Khách hàng nhắn rằng họ không nhận được mã OTP, hoặc hóa đơn bỗng dưng mất tích đâu đó. Mở thư mục spam ra thì thư nằm im ở đó. Nguyên nhân thường đơn giản: máy chủ nhận không tin người gửi. Bài này ghi lại cách đội ngũ bên mình xử lý vấn đề từ đầu đến cuối, để bạn làm theo được từng bước.
Vì sao email giao dịch hay rơi vào thư mục spam?
Đây là phần nên đọc trước tiên, vì nó giải thích nguyên nhân gốc. Mỗi khi hệ thống gửi một thư, máy chủ nhận sẽ tự hỏi: người gửi này có thật sự được phép dùng tên miền đó không? Nếu không chứng minh được, thư bị đẩy sang spam, hoặc tệ hơn là bị chặn hẳn.
Có một dự án chúng tôi từng mất gần một tuần chỉ để truy lỗi. Phía shop khẳng định đã gửi OTP, khách thì không thấy đâu. Cuối cùng nguyên nhân nằm ở việc thiếu xác thực người gửi, hoàn toàn không phải do nội dung thư. Sau khi bổ sung cấu hình, tỷ lệ thư vào hộp thư đến tăng rõ rệt chỉ trong vài ngày.
Gmail và Outlook hiện siết xác thực người gửi khá chặt. Một thư thiếu chữ ký rõ ràng rất dễ bị đánh dấu đáng ngờ. Điều này áp dụng cho cả shop nhỏ, không riêng doanh nghiệp lớn.
Nên tách bạch hai loại thư. Email giao dịch là thư hệ thống gửi tự động như xác nhận đơn, mã OTP, hóa đơn. Email marketing là thư quảng cáo và khuyến mãi. Hai loại này nên dùng tên miền gửi riêng, để nếu một bên bị đánh dấu spam thì bên kia không bị kéo theo.
Ba lớp xác thực SPF, DKIM, DMARC hoạt động ra sao?
Ba cái tên nghe có vẻ rối, nhưng mỗi cái trả lời một câu hỏi khác nhau. Chúng tôi hay ví chúng như ba lớp giấy tờ khi gửi hàng đi xa: một giấy ủy quyền, một con niêm phong, và một quy định xử lý khi giấy tờ có vấn đề.
SPF là danh sách các máy chủ được phép gửi thư thay cho tên miền của bạn. Khi thư đến từ một máy không nằm trong danh sách, máy nhận lập tức nghi ngờ.
DKIM là chữ ký số gắn vào từng email, chứng minh nội dung không bị sửa trên đường đi. Nhà cung cấp dịch vụ cấp cho bạn một khóa, bạn đặt khóa đó lên DNS để máy nhận đối chiếu.
DMARC là chính sách quyết định phải làm gì khi SPF hoặc DKIM thất bại: cho qua, đưa vào spam, hay chặn hẳn. Đây là lớp đứng trên để hướng dẫn hai lớp kia, đồng thời cho bạn báo cáo về những nguồn nào đang gửi thư thay tên miền của mình.
Cần chuẩn bị gì trước khi sửa DNS?
Đừng vội mở trang quản lý tên miền. Vài bước chuẩn bị sẽ tiết kiệm nhiều thời gian về sau.
- Xác định nhà cung cấp gửi thư bạn đang dùng, rồi lấy đúng các bản ghi họ yêu cầu, không tự suy đoán.
- Sao lưu toàn bộ bản ghi DNS hiện tại. Đội ngũ bên mình từng làm mất bản ghi của một dịch vụ khác chỉ vì sửa quá vội.
- Một tên miền chỉ nên có một bản ghi SPF. Nếu có hai, máy nhận coi là lỗi và có thể bỏ qua toàn bộ.
Thêm từng bản ghi lên DNS và kiểm tra bằng lệnh dig
Lệnh dig hỏi trực tiếp hệ thống DNS xem bản ghi đã cập nhật hay chưa. Trên Linux và macOS bạn không cần cài thêm gì. Trên Windows, có thể dùng bản dig đi kèm bộ BIND hoặc chạy qua WSL.
Bước đầu tiên là SPF. Thêm một bản ghi TXT vào tên miền gốc, nội dung bắt đầu bằng v=spf1. Sau đó chạy lệnh dig TXT tenmien.com và đọc kết quả để xác nhận chuỗi hiển thị đúng.
Tiếp theo là DKIM. Bản ghi có tên dạng selector._domainkey.tenmien.com, trong đó selector do nhà cung cấp đặt. Kiểm tra bằng lệnh dig TXT selector._domainkey.tenmien.com. Khi dán khóa, để ý không thừa khoảng trắng và không mất ký tự cuối. Khóa bị cắt cụt là lỗi chúng tôi gặp rất thường xuyên.
Cuối cùng là DMARC, nên bắt đầu với p=none. Chế độ này chỉ theo dõi, không chặn thư nào. Bạn cần vài tuần báo cáo để biết nguồn nào đang gửi thay tên miền mình trước khi siết chính sách. Kiểm tra bằng lệnh dig TXT _dmarc.tenmien.com.
Đọc kết quả kiểm tra và xử lý lỗi thường gặp
Lỗi phổ biến nhất là tồn tại nhiều bản ghi SPF cùng lúc. Khi đó SPF fail toàn bộ, dù từng bản ghi riêng lẻ đều đúng. Cách khắc phục là gộp các mục include vào đúng một bản ghi duy nhất.
Lỗi thứ hai là DKIM sai selector, hoặc khóa bị cắt khi dán. Nếu lệnh dig trả về rỗng hoặc chuỗi đứt quãng, đó là dấu hiệu rõ để kiểm tra lại.
Về thời gian, DNS cần một khoảng để lan truyền, thường vài phút đến vài giờ, nhưng cũng có trường hợp kéo dài cả ngày. Đừng sửa liên tục trong lúc chờ, vì mỗi lần thay đổi lại làm kéo dài thêm. Đội ngũ bên mình thường đợi tối thiểu hai giờ rồi mới kiểm tra lại.
Chọn dịch vụ gửi email giao dịch: nhìn từ thực tế
Thị trường hiện có khá nhiều lựa chọn như Resend, SendGrid, Amazon SES và MONA Mail. Chúng tôi không khẳng định ai tốt nhất tuyệt đối, vì lựa chọn còn phụ thuộc quy mô và kỹ năng của đội bạn.
Resend dễ dùng với lập trình viên và tài liệu khá rõ, nhưng gói miễn phí không quá rộng. SendGrid có lịch sử lâu năm và báo cáo chi tiết, đổi lại giao diện đôi khi khiến người mới rối. Amazon SES giá rất rẻ khi khối lượng lớn, nhưng cấu hình và duyệt tài khoản khá phiền.
Với MONA Mail, gói miễn phí cho 3.000 email mỗi tháng, các gói trả phí có mức 99k, 299k và 799k. Dịch vụ này bắt buộc cấu hình DKIM, tức là chưa hoàn tất xác thực thì chưa cho gửi. Điều đó tốt cho bảo mật, nhưng bạn phải làm xong bước DNS trước khi gửi được thư đầu tiên. Số liệu này cần đối chiếu lại bảng giá tại trang chính thức. Nếu muốn thao tác nhanh, bạn có thể tham khảo tài liệu API và SDK của MONA Mail.
Tiêu chí chúng tôi dùng khi chọn gồm ba điểm: giá theo số thư thực tế, mức độ dễ cấu hình DNS, và báo cáo gửi đủ chi tiết để đọc được tỷ lệ bounce. Đừng chọn chỉ vì quảng cáo. Hãy thử gửi vài trăm thư trước khi quyết định.
Nếu bạn quan tâm đến cách tổ chức hệ thống vận hành nội bộ một cách bài bản, có thể đọc thêm cách tự động hóa quản trị nội bộ bằng AI agent, nơi bên mình chia sẻ thêm về việc giảm phần mềm rời rạc trong vận hành.
Mẹo giữ tỷ lệ vào hộp thư đến ổn định
Dùng một tên miền gửi riêng cho email giao dịch, tách khỏi email cá nhân của nhân viên. Đây là việc đầu tiên đội ngũ bên mình làm cho mọi khách hàng, vì nó giúp cô lập rủi ro.
Sau mỗi đợt đổi cấu hình, theo dõi tỷ lệ bounce và số khiếu nại spam. Khi hai chỉ số này tăng, đó là tín hiệu sớm để dừng lại và kiểm tra.
Đừng bật DMARC ở mức nghiêm ngay từ đầu. Nâng dần từ none sang quarantine rồi mới đến reject, mỗi bước cách nhau vài tuần để có đủ dữ liệu đánh giá.
Những sai lầm thường gặp khi tự cấu hình
Sai lầm đầu tiên là gộp quá nhiều include vào SPF, khiến số lần tra cứu vượt giới hạn 10. Máy nhận báo lỗi dù cú pháp không sai chỗ nào.
Sai lầm thứ hai là bật DMARC ở chế độ reject khi chưa nắm đủ các nguồn gửi. Hậu quả là thư hợp lệ của một dịch vụ nào đó bị chặn, và bạn mất nhiều thời gian mới tìm ra nguyên nhân.
Sai lầm thứ ba hay bị bỏ quên: không cấu hình DKIM cho các dịch vụ thứ ba đang gửi thay tên miền, ví dụ phần mềm CRM hay công cụ marketing. Mỗi dịch vụ cần một khóa riêng.
Chi phí và thời gian triển khai cần tính trước
Phần lớn chi phí không nằm ở tiền dịch vụ mà ở công sức đồng bộ DNS và theo dõi báo cáo. Bên mình thường ước tính một đến hai buổi làm việc cho phần cấu hình, cộng thêm vài tuần theo dõi DMARC. Tính từ lúc bắt đầu đến khi báo cáo ổn định, một tên miền gửi thông thường mất khoảng một tháng.
Câu hỏi thường gặp
SPF và DKIM khác nhau ở điểm nào?
SPF kiểm tra máy gửi có được phép hay không. DKIM kiểm tra nội dung có bị sửa đổi hay không. Hai cơ chế bổ sung cho nhau, nên nên triển khai cả hai.
Có thể dùng nhiều dịch vụ gửi email trên cùng một tên miền không?
Được, nhưng mỗi dịch vụ cần DKIM riêng, còn SPF phải gộp vào một bản ghi duy nhất.
Lệnh dig dùng để kiểm tra điều gì sau khi thêm bản ghi?
Dig hỏi trực tiếp DNS xem bản ghi đã hiển thị chưa và nội dung có đúng không. Đây là cách nhanh nhất để biết cấu hình đã có hiệu lực.
Đổi nhà cung cấp email thì cần làm lại những gì?
Cập nhật SPF để thêm máy chủ mới, thêm DKIM của nhà cung cấp mới, và có thể bỏ bản ghi cũ sau khi chắc chắn không còn thư nào đi qua đó.
Bao lâu thì thay đổi DNS có hiệu lực?
Thường từ vài phút đến vài giờ, đôi khi lâu hơn. Đợi ít nhất hai giờ rồi kiểm tra lại là hợp lý.
Nếu bạn đang loay hoay với thư giao dịch, hãy bắt đầu bằng việc kiểm tra DKIM và SPF bằng lệnh dig như đã hướng dẫn. Phần lớn lỗi nằm ở chỗ đó, chứ không nằm ở nội dung thư. Bạn cũng có thể xem thêm shop MONA Mail để tham khảo các gói dịch vụ hiện có.
