Vì sao email giao dịch của app hay bị lỗi không tới nơi
Chúng tôi đã gặp tình huống này không ít lần. Khách vừa đặt đơn xong, chờ mãi mà không thấy email xác nhận. Người khác thì không nhận được mã OTP để đổi mật khẩu. Mở log ra kiểm tra, thư thường nằm trong spam, hoặc tệ hơn là chưa từng được gửi đi.
Lỗi này phổ biến ở các app Việt quy mô nhỏ. Đội ngũ thường dồn thời gian cho giao diện và tính năng, còn đường đi của email thì bị bỏ quên. Trong khi đó, email giao dịch lại là thứ người dùng cần đúng lúc nhất. Một sai sót nhỏ ở đây có thể khiến họ rời đi rất nhanh. Bạn thử hình dung: vừa thanh toán xong mà không thấy hóa đơn, bạn có yên tâm không?
Cần phân biệt rõ email giao dịch với email marketing. Email marketing gửi cho hàng nghìn người cùng lúc và chờ họ mở, bấm. Còn email giao dịch như mã OTP, hóa đơn hay thông báo trạng thái đơn phải đến trong vài giây và nằm chắc trong hộp thư chính. Hai luồng này nên tách riêng ngay từ đầu.
Khâu hay vướng nhất là xác thực domain. Bộ ba bản ghi SPF, DKIM và DMARC nghe khô khan, nhưng đây là cách để máy chủ của Gmail hay Outlook tin rằng bạn đúng là chủ domain đang gửi thư. Thiếu một trong số này, thư có thể bị đẩy vào spam mà không có bất kỳ cảnh báo nào. Bạn có thể tham khảo thêm cách thiết lập nền tảng công nghệ cho startup để hiểu vì sao hạ tầng kỹ thuật cần được chuẩn bị bài bản ngay từ đầu.
Email giao dịch gồm những loại nào
Nói ngắn gọn, email giao dịch là thư do hệ thống tự động gửi khi người dùng vừa làm một việc cụ thể, như đăng ký, thanh toán hoặc bấm quên mật khẩu.
Phổ biến nhất có ba nhóm. Nhóm đầu là mã OTP và link xác nhận đăng nhập. Nhóm thứ hai là hóa đơn và biên lai thanh toán. Nhóm cuối là thông báo trạng thái đơn hàng, từ đã xác nhận, đang giao cho đến đã giao.
Mỗi nhóm có yêu cầu khác nhau. OTP cần nhanh nhất, chậm vài chục giây là người dùng đã bỏ đi. Hóa đơn thì cần đúng nội dung và lưu được lịch sử, nên nên chọn dịch vụ có log theo dõi. Khi khách hỏi “sao tôi không nhận được”, bạn tra được thư đã đi đâu chỉ trong vài phút.
Chúng tôi khuyên không dùng chung một hệ thống cho cả chiến dịch quảng cáo lẫn email giao dịch. Khi chiến dịch bị đánh dấu spam, uy tín domain đi xuống, và mã OTP cũng chịu ảnh hưởng theo. Tách hai luồng ra sớm sẽ tránh được nhiều phiền phức về sau.
Chọn dịch vụ gửi email API theo tiêu chí nào
Đừng chỉ nhìn giá khi chọn. Khi đánh giá cho khách, chúng tôi thường xem bốn điểm theo đúng thứ tự dưới đây.
Điểm đầu tiên là cấu hình domain có rõ ràng không. Dịch vụ tốt sẽ chỉ rõ bạn cần thêm bản ghi DNS nào, và nhiều nơi bắt buộc DKIM để thư không bị giả mạo. Nếu bước này rối rắm, bạn có thể mất cả buổi chiều chỉ để email đầu tiên đi được. Chúng tôi từng có một dự án mất gần hai ngày chỉ vì DNS lan truyền chậm, mà không ai biết phải kiểm tra ở đâu.
Điểm thứ hai là hạn mức miễn phí và cách tính phí. Có nơi tính theo số email, có nơi theo số domain hoặc theo gói tháng. Hãy ước lượng số thư mỗi tháng trước khi chọn để tránh bất ngờ khi hóa đơn về.
Điểm thứ ba là tài liệu API và SDK. Nếu backend của bạn dùng Node hay Python, một SDK rõ ràng sẽ tiết kiệm rất nhiều giờ debug.
Điểm cuối là thanh toán. Với doanh nghiệp Việt, việc trả bằng VND và có hóa đơn đúng tên công ty đôi khi còn quan trọng hơn con số trên bảng giá.
Resend, SendGrid và Amazon SES khác nhau ở đâu
Ba cái tên này được nhắc đến nhiều nhất, và mỗi cái có một tính cách khá rõ. Resend thiên về trải nghiệm developer, cài đặt nhanh và API dễ đọc, khá hợp với sản phẩm mới hoặc dự án nhỏ. Bạn nên đối chiếu bảng giá chính thức ở thời điểm đăng ký, vì chính sách có thể thay đổi.
SendGrid đã có mặt lâu năm, hệ sinh thái rộng, từ template đến phân tích chi tiết đều có đủ. Đổi lại, bảng điều khiển nhiều mục, người mới lúc đầu có thể thấy rối.
Amazon SES thường rẻ hơn khi lượng gửi lớn. Nhưng cấu hình khá kỹ thuật. Bạn phải tự xử lý sandbox, hạn mức gửi và bounce. Với đội nhỏ chưa quen hạ tầng AWS, đây có thể là một gánh nặng không nhỏ.
Lưu ý là con số giá thay đổi liên tục. Hãy xem trang chính thức của từng nhà cung cấp trước khi quyết định.
Triển khai email giao dịch với MONA Mail trong thực tế
Để dễ hình dung, đây là quy trình chúng tôi thường làm khi dựng email giao dịch cho một app nhỏ bằng MONA Mail.
Bước 1: thêm domain gửi trong bảng điều khiển rồi cấu hình các bản ghi DNS được cung cấp. DKIM là bắt buộc, đừng bỏ qua. Sau khi thêm, chờ DNS lan truyền và kiểm tra lại trạng thái xác thực.
Bước 2: lấy API key và gọi endpoint gửi thư từ backend. Đặt key trong biến môi trường, tuyệt đối không đưa thẳng vào mã nguồn phía client.
Bước 3: theo dõi trạng thái gửi và xử lý các thư bị trả về. Ghi log cho từng email giao dịch để khi có khiếu nại, bạn tra cứu nhanh.
Về gói dịch vụ, MONA Mail có gói miễn phí 3.000 email mỗi tháng. Các gói trả phí là 99.000đ, 299.000đ và 799.000đ, tính đến tháng 11/2026. Với app mới chạy, gói miễn phí thường đủ cho giai đoạn thử nghiệm và vận hành ban đầu.
Nếu bạn đang dùng Resend và muốn chuyển sang, có thể xem trang so sánh chi tiết và hướng dẫn chuyển từ Resend để nắm các bước cụ thể. Khi lên kế hoạch vận hành sản phẩm lâu dài, bạn cũng có thể đọc thêm quy trình thành lập công ty cho dev team để chuẩn bị mặt pháp lý song song với kỹ thuật.
Chi phí thực tế cho một app Việt quy mô nhỏ
Cách đơn giản nhất để ước lượng là đếm số sự kiện gửi thư phát sinh từ một người dùng điển hình. Một lượt đăng ký có thể tạo ra thư chào mừng và mã xác nhận. Một đơn hàng có thể sinh ra xác nhận, hóa đơn và thông báo giao hàng. Nhân con số đó với số người dùng hoạt động mỗi tháng, bạn sẽ có một con số khá sát.
Chúng tôi thường tách riêng chi phí email khỏi hạ tầng khác như server hay database. Nhiều người gộp hết thành một khoản, nên không biết phần nào thực sự tăng khi app lớn lên. Tách ra giúp bạn nhìn rõ hơn và ra quyết định tốt hơn.
Trước khi chọn gói, hãy tính thử với số người dùng hiện tại và kỳ vọng sau sáu tháng. Nếu con số sớm vượt hạn mức miễn phí, hãy xem trước gói tiếp theo có hợp lý không, thay vì đợi đến lúc bị giới hạn rồi mới đổi gấp.
Những điểm MONA Mail còn hạn chế
Chúng tôi muốn nói thẳng: MONA Mail không phải lựa chọn phù hợp cho mọi trường hợp. Hệ sinh thái và cộng đồng của MONA Mail vẫn nhỏ hơn đáng kể so với SendGrid hay Amazon SES. Nếu bạn cần tìm lời giải cho một lỗi lạ trên mạng, số bài viết tham khảo có thể ít hơn nhiều.
Một số tính năng nâng cao cũng nên kiểm tra kỹ trước khi đưa vào môi trường thật. Đừng mặc định mọi thứ hoạt động đúng như mong muốn. Hãy đọc tài liệu và thử từng tính năng quan trọng với chính app của bạn.
Vì vậy, chúng tôi khuyên nên thử gửi trên môi trường staging trước khi chuyển hẳn. Gửi thử vài trăm thư thật, kiểm tra hộp Gmail và Outlook xem có vào spam không, rồi mới chuyển luồng chính.
Sai lầm thường gặp khi đổi nhà cung cấp email
Sai lầm phổ biến nhất là quên cấu hình SPF và DKIM cho domain. Thư vẫn gửi đi nhưng rơi vào spam, và bạn mất vài ngày mới nhận ra nguyên nhân.
Sai lầm thứ hai là chuyển đột ngột mà không giữ dịch vụ cũ chạy song song. Khi có lỗi, bạn không còn đường lui. Cách an toàn hơn là chuyển dần từng loại thư, rồi theo dõi tỉ lệ đến hộp thư.
Sai lầm thứ ba là không thử template trên nhiều ứng dụng mail. Một thư trông đẹp trên Gmail có thể vỡ bố cục trên Outlook. Dành chút thời gian kiểm tra trước sẽ tránh được những phản hồi khó chịu từ khách.
Câu hỏi thường gặp
Có nên dùng nhiều nhà cung cấp email cùng lúc không?
Được, và nhiều đội ngũ làm vậy để dự phòng, ví dụ một dịch vụ cho OTP và một dịch vụ khác cho hóa đơn. Tuy nhiên, bạn phải quản lý domain và DNS cho từng bên, nên chỉ nên làm khi đội đã đủ sức theo dõi.
Email OTP có cần dịch vụ riêng khỏi email marketing không?
Chúng tôi khuyên nên tách. Email OTP cần tốc độ và độ tin cậy cao nhất. Nếu chung hệ thống với chiến dịch marketing, uy tín domain bị ảnh hưởng sẽ kéo theo cả mã xác nhận.
Làm sao biết email giao dịch đã vào hộp thư chưa?
Trước hết, xem log trạng thái gửi trong bảng điều khiển để biết thư đã được chấp nhận hay bị trả về. Nhưng trạng thái “đã gửi” chưa chắc là đã vào hộp thư chính. Hãy gửi thử tới vài tài khoản thật ở các nhà cung cấp khác nhau và kiểm tra thư mục spam định kỳ.
Giá các dịch vụ được tính đến tháng 11/2026, có thay đổi sau này không?
Có, và đó là lý do chúng tôi luôn ghi rõ mốc thời gian. Giá và hạn mức có thể đổi theo chính sách từng nhà cung cấp, nên trước khi quyết định, hãy đối chiếu lại với trang giá chính thức.