Tự dựng Postfix hay thuê API gửi email giao dịch: vì sao câu hỏi này làm đội dev mất ngủ?
Có một đêm, đội ngũ bên mình nhận cuộc gọi lúc gần hai giờ sáng. Khách hàng báo không nhận được mã OTP đăng nhập và đã chờ hơn chục phút. Chúng tôi mở log ra xem. Mọi thứ trông vẫn bình thường. Thư thì chưa bao giờ tới hộp thư đích.
Chính buổi đêm ấy khiến chúng tôi ngồi lại và nhìn nghiêm túc cách mình gửi email giao dịch. Loại thư này là thư hệ thống tự động, gửi ngay khi người dùng vừa làm một việc cụ thể. Có thể là mã xác thực, hóa đơn hoặc xác nhận đơn hàng. Khác với email marketing, thư giao dịch cần tới nhanh và tới đúng hộp thư. Chậm vài phút cũng đủ khiến người dùng bỏ đi.
Trước khi chọn tự dựng hay thuê ngoài, bạn nên tự hỏi đội mình có đủ người để vận hành hạ tầng gửi thư không. Câu trả lời phụ thuộc vào số người có kinh nghiệm, lượng thư mỗi tháng và mức rủi ro doanh nghiệp chấp nhận được.
Tự dựng Postfix: lợi thế và phần việc ẩn phía sau
Postfix là máy chủ SMTP mã nguồn mở. Nó nhận thư từ hệ thống của bạn rồi chuyển sang máy chủ của người nhận. Lợi thế lớn nhất là bạn nắm toàn quyền kiểm soát, từ cấu hình đến dữ liệu. Ở quy mô nhỏ, chi phí hạ tầng khá thấp, chỉ cần một máy chủ vừa phải.
Tuy vậy, phần việc phía sau thường bị đánh giá thấp. Bạn phải cấu hình TLS, cập nhật bản vá bảo mật, theo dõi hàng đợi thư và xử lý khi IP bị đưa vào danh sách chặn. Chúng tôi từng gặp một máy chủ bị khóa chỉ vì một lỗ hổng relay cũ chưa được đóng. Phải mất gần một ngày mới gỡ xong. Trong lúc đó, người dùng liên tục hỏi về thư xác thực.
Điều khó nói nhất là khi mọi thứ chạy ổn, công sức bỏ ra gần như vô hình. Không ai khen một email tới đúng giờ. Nhưng chỉ cần một lần hỏng, cả đội sẽ nhớ rất lâu.
Uy tín IP: vấn đề không nằm ở đoạn code
Nhiều người nghĩ viết code đúng là đủ. Thực tế, các hộp thư lớn như Gmail hay Outlook đánh giá người gửi chủ yếu qua địa chỉ IP. Một IP mới, hoặc một IP dùng chung với người từng gửi spam, rất dễ bị nghi ngờ ngay từ lần gửi đầu tiên.
Muốn IP có uy tín, bạn cần làm nóng nó dần. Tăng khối lượng theo từng tuần, bắt đầu từ con số nhỏ và ưu tiên người nhận thật, những người có tương tác tốt với thư. Quá trình này thường kéo dài bốn đến sáu tuần. Trong thời gian đó, đừng đẩy đi khối lượng lớn chỉ vì muốn xong sớm.
Nhà cung cấp API đã có sẵn lịch sử gửi tốt, nên bạn được hưởng uy tín đó ngay. Đổi lại, bạn phải chia sẻ IP với người khác. Nếu một khách hàng của nhà cung cấp gửi spam, IP chung có thể bị ảnh hưởng theo. Vì vậy, chọn đơn vị có chính sách kiểm soát người gửi chặt chẽ là việc đáng làm.
DKIM, SPF và DMARC: vì sao phải cấu hình đúng từ đầu
Ba bản ghi DNS này giống như giấy tờ chứng minh thư thật sự đến từ bạn. SPF khai báo máy chủ nào được phép gửi thay tên miền của bạn. DKIM gắn chữ ký số vào từng thư. DMARC cho biết hộp thư nhận nên làm gì khi thư không qua các kiểm tra.
Lỗi chúng tôi gặp nhiều nhất là quên xoay khóa DKIM, hoặc đặt sai tên selector ngay từ đầu. Một lỗi khác khá phổ biến là đổi nhà cung cấp nhưng quên cập nhật DNS. Thư bị từ chối âm thầm và không ai hay biết. Trước khi bật gửi thật, hãy kiểm tra từng bản ghi bằng công cụ kiểm tra DNS.
Một số dịch vụ hiện nay yêu cầu DKIM ngay từ đầu. Theo chúng tôi, đây là điều tốt, vì nó buộc bạn làm đúng ngay ngày đầu thay vì vá lỗi khi sự cố đã xảy ra.
Bounce và hàng đợi: nơi thư thường mất âm thầm
Bounce là thư bị trả lại vì không gửi được. Hard bounce là lỗi vĩnh viễn, ví dụ địa chỉ không tồn tại. Soft bounce là lỗi tạm thời, chẳng hạn hộp thư đang đầy. Complaint xảy ra khi người nhận bấm báo thư rác.
Nếu bạn tiếp tục gửi cho địa chỉ đã hard bounce, uy tín người gửi sẽ giảm rất nhanh. Cách xử lý hợp lý là tự động gỡ địa chỉ lỗi ngay sau lần đầu bị trả về, đồng thời theo dõi sát tỷ lệ khiếu nại. Đừng đợi đến khi có con số xấu rồi mới hành động.
Bạn cũng cần webhook hoặc log chi tiết để biết trạng thái từng thư. Nếu không có, bạn chỉ biết thư đã mất khi khách hàng gọi đến phàn nàn, lúc đó thì đã muộn.
Ai sẽ trực đêm khi email ngừng gửi?
Đây là chi phí ít người tính tới khi so sánh. Nếu tự vận hành, bạn phải có ít nhất một người hiểu hệ thống và sẵn sàng bị gọi dậy giữa đêm. Trong một đội nhỏ, người đó thường đang gánh rất nhiều việc khác, nên sự cố nửa đêm dễ trở thành gánh nặng kéo dài.
Nhà cung cấp API thường có cam kết thời gian phản hồi sự cố. Hãy đọc kỹ điều khoản, đặc biệt phần đền bù. Cam kết uptime 99,9% nghe có vẻ ổn, nhưng nên hỏi rõ họ đền bù thế nào khi vi phạm. Nhiều nhà cung cấp hoàn tiền cho hosting nhưng không nhất thiết áp dụng cho email, nên hãy xem đúng sản phẩm bạn định dùng.
Đầu tư on-call nội bộ chỉ thật sự có ý nghĩa khi đội đã có người am hiểu hạ tầng và lượng thư đủ lớn. Nếu bạn chỉ có một hai lập trình viên, giao phần này cho bên thứ ba thường giúp đội đỡ mệt hơn nhiều.
So sánh các lựa chọn phổ biến
Trên thị trường có hai nhóm chính. Nhóm thứ nhất là tự vận hành SMTP, tiêu biểu là Postfix và các máy chủ mail tự host khác. Nhóm thứ hai là API gửi thư giao dịch, như Resend, SendGrid, Amazon SES và MONA Mail.
Khi đặt cạnh nhau, chúng tôi thường xét bốn tiêu chí: chi phí, độ dễ tích hợp, khả năng quản lý bounce và hỗ trợ tiếng Việt. Tự host thường thắng về chi phí khi lượng thư còn nhỏ, nhưng thua về thời gian và công sức. API thắng về tích hợp và quản lý bounce, còn chi phí tăng theo khối lượng gửi.
Về giá và hạn mức, chúng tôi chỉ tham chiếu theo thông tin tại thời điểm viết bài. Các con số này thay đổi thường xuyên, nên hãy xem bảng giá chính thức của từng nhà cung cấp trước khi quyết định. Chẳng hạn MONA Mail hiện có gói miễn phí cho 3.000 email mỗi tháng cùng các gói trả phí. Dù vậy, đó chỉ là một lựa chọn trong nhiều lựa chọn khác. Nếu muốn hình dung công việc tích hợp thực tế, bạn có thể xem tài liệu API và SDK của MONA Mail tại monamail.vn/docs để đối chiếu.
Đừng bỏ qua điểm yếu của việc thuê API
Thuê API có những nhược điểm rõ ràng. Bạn sẽ phụ thuộc vào nhà cung cấp. Nếu họ tăng giá hoặc ngừng dịch vụ, việc chuyển đi không đơn giản, vì mọi thứ đã gắn chặt vào mã nguồn và cấu hình DNS của bạn.
Chi phí cũng tăng theo khối lượng. Với đội đang tăng trưởng nhanh, hóa đơn có thể lớn hơn dự đoán nếu không theo dõi thường xuyên. Hãy đặt cảnh báo ngân sách từ đầu để tránh bất ngờ cuối tháng.
Kiểm tra kỹ cam kết uptime và thời gian phản hồi sự cố trước khi ký hợp đồng. Đừng dừng lại ở con số phần trăm đẹp mắt trên trang giới thiệu. Hãy hỏi thêm về quy trình xử lý thực tế khi có sự cố.
Chọn theo quy mô và năng lực đội ngũ
Nếu bạn gửi dưới vài nghìn email mỗi tháng và đội chưa có chuyên gia hạ tầng, thuê API thường an toàn hơn. Đội có thể tập trung vào sản phẩm, còn phần thư giao cho người chuyên lo.
Khi khối lượng lớn, hoặc doanh nghiệp có yêu cầu kiểm soát dữ liệu nghiêm ngặt, tự vận hành mới đáng cân nhắc nghiêm túc. Lúc đó đội thường đã có đủ người và đủ lý do để gánh rủi ro này.
Nếu cần chuyển từ tự dựng sang API, chúng tôi khuyên chạy song song hai hệ thống trong vài tuần. Gửi một phần thư qua API, theo dõi tỷ lệ tới nơi, rồi tăng dần tỷ trọng. Cách này giúp người dùng không nhận ra thay đổi, và bạn có thời gian sửa lỗi trước khi chuyển hoàn toàn.
Nếu đội còn nhỏ và đang cân nhắc thứ tự ưu tiên hạ tầng, bạn có thể tham khảo thêm cách chuyển đổi số cho doanh nghiệp nhỏ, nên bắt đầu từ website hay phần mềm. Còn nếu đang tìm nền tảng phù hợp cho đội mới, hướng dẫn lựa chọn dịch vụ công nghệ cho doanh nghiệp mới là điểm khởi đầu hữu ích.
Câu hỏi thường gặp
Postfix tự dựng có rẻ hơn thuê API không?
Ở quy mô nhỏ, chi phí máy chủ thấp hơn là điều có thật. Nhưng nếu tính cả thời gian lập trình viên bỏ ra để cấu hình và xử lý sự cố, tổng chi phí có thể cao hơn nhiều. Hãy tính đủ công sức trước khi kết luận.
DKIM có bắt buộc không, và cài đặt có khó không?
Phần lớn hộp thư lớn hiện yêu cầu DKIM để tin cậy người gửi. Cài đặt không quá khó nếu bạn làm theo hướng dẫn của nhà cung cấp và kiểm tra lại bản ghi DNS sau khi thêm.
Hard bounce và soft bounce khác nhau thế nào?
Hard bounce là lỗi vĩnh viễn, như địa chỉ không tồn tại, nên cần gỡ địa chỉ đó khỏi danh sách. Soft bounce là lỗi tạm thời, như hộp thư đầy, và hệ thống thường tự thử gửi lại sau.
Nếu email giao dịch bị chậm, nên kiểm tra ở đâu trước?
Hãy kiểm tra hàng đợi và log trạng thái từng thư để xem thư đang nằm ở đâu. Sau đó kiểm tra bản ghi DNS và tỷ lệ bounce. Phần lớn sự cố nằm ở một trong ba chỗ này.
