Gửi email giao dịch (transactional) đúng cách

Transactional vs marketing: ranh giới thực sự nằm ở đâu

Nhiều người phân loại sai vì chỉ nhìn vào nội dung. Ranh giới thật không nằm ở email nói gì, mà ở vì sao nó được gửi. Một email là giao dịch khi nó là phản hồi trực tiếp, một-đối-một cho một hành động mà chính người nhận vừa thực hiện, và họ đang mong nhận được nó. Một email là tiếp thị khi bạn chủ động gửi để quảng bá, dù người nhận không yêu cầu vào đúng lúc đó.

Ba ví dụ kinh điển: OTP, hóa đơn, đặt lại mật khẩu

Mỗi loại email giao dịch có một “khế ước” riêng với người nhận về tốc độ, tính bảo mật và độ rõ ràng. Hiểu khế ước đó mới thiết kế đúng.

1. Mã OTP / xác minh đăng nhập

Đây là loại nhạy cảm nhất về độ trễ. Người dùng đang đứng ở màn hình đăng nhập, tay sẵn sàng gõ. Nguyên tắc:

• Đưa mã lên đầu, cả ở tiêu đề. Ví dụ tiêu đề “152384 là mã đăng nhập Mailemdi của bạn” để người dùng đọc được mã ngay từ danh sách thư, không cần mở.
• Ghi rõ thời hạn. “Mã có hiệu lực trong 5 phút” — vừa tăng bảo mật, vừa đặt đúng kỳ vọng.
• Tối giản tuyệt đối. Không banner, không link tiếp thị, không ảnh nặng làm chậm hiển thị. Email càng nhẹ càng vào nhanh và hiển thị tức thì.
• Đừng tracking link/pixel trong OTP. Tracking có thể khiến một số bộ lọc nghi ngờ và làm chậm; với OTP, độ tin cậy quan trọng hơn số liệu mở.

2. Hóa đơn / xác nhận đơn hàng

Đây là chứng từ — người nhận sẽ lưu lại, tìm lại, đôi khi in ra. Ưu tiên sự đầy đủ và rõ ràng hơn tốc độ tuyệt đối (trễ vài giây không sao, nhưng tuyệt đối không được sai số liệu):

• Mã đơn / mã hóa đơn trong tiêu đề để người nhận tìm lại dễ dàng sau này.
• Số liệu chính xác: từng dòng hàng, thuế, tổng tiền, phương thức thanh toán. Một con số sai ở đây là một khiếu nại.
• Có bản text song song với HTML. Nếu HTML không hiển thị (ứng dụng cũ, chế độ tiết kiệm dữ liệu), người nhận vẫn đọc được nội dung cốt lõi.

3. Đặt lại mật khẩu

Vừa cấp bách (người dùng đang bị khóa ngoài), vừa nhạy cảm về bảo mật:

• Một nút/link rõ ràng, kèm thời hạn ngắn (“liên kết hết hạn sau 30 phút”) để giảm rủi ro nếu hộp thư bị xâm nhập.
• Trấn an khi không phải họ: “Nếu bạn không yêu cầu, hãy bỏ qua email này, mật khẩu của bạn không thay đổi”.
• Link sạch, một đích đến. Trước khi đưa vào mẫu, soát link bằng công cụ Kiểm tra link để chắc chắn không có chuyển hướng lạ — một link gãy ở đây làm người dùng kẹt hoàn toàn.

Yêu cầu sống còn: tốc độ & độ tin cậy

Với email tiếp thị, trễ 10 phút không ai để ý. Với email giao dịch, đó là hai thước đo bạn phải thiết kế ngay từ đầu. Hãy tách bạch hai khái niệm thường bị gộp:

• Độ trễ (latency): từ lúc hệ thống của bạn gọi API đến lúc thư rời khỏi máy chủ gửi. Đây là phần bạn kiểm soát được.
• Khả năng vào hộp thư (deliverability): thư có thực sự nằm trong Inbox của người nhận hay rơi vào Spam. Phần này phụ thuộc uy tín tên miền và chất lượng nội dung.

Trên Mailemdi, email giao dịch được gửi đồng bộ ngay trong request — khác hẳn chiến dịch hàng loạt (đẩy vào hàng đợi rồi worker xử lý dần). Nghĩa là khi bạn gọi POST /transactional, hệ thống gửi thư rồi trả ngay kết quả thành/bại cho bạn trong cùng lời gọi đó. Điều này tối ưu cho OTP/xác nhận: bạn biết tức thì thư đã đi hay chưa, thay vì phải hỏi lại sau.

Về deliverability, email giao dịch được giữ ở chuẩn cao hơn email tiếp thị vì nó phải vào inbox gần như 100%. Ba nền tảng bắt buộc:

• Xác thực tên miền đầy đủ. SPF, DKIM và DMARC phải hợp lệ thì hộp thư người nhận mới tin tưởng. Đây là điều kiện cần, không phải tùy chọn — đọc kỹ trong SPF, DKIM, DMARC toàn tập.
• Danh tính người gửi cố định, đã verify. Trên Mailemdi, địa chỉ From của email giao dịch do nền tảng quyết định (dạng no-reply@<tên-miền-đã-xác-thực>), API key không được tự đặt địa chỉ From. Đây là chủ đích để chống giả mạo và open-relay — một địa chỉ gửi ổn định, đã xác thực cũng giúp xây uy tín bền vững hơn.
• Nội dung gọn, sạch. Email giao dịch nặng ảnh hoặc dính từ “mùi spam” vừa chậm, vừa dễ bị lọc. Soát trước bằng công cụ Dung lượng email và Soát từ khóa spam để giữ thư nhẹ và tránh từ nhạy cảm.

Tách kênh: vì sao email giao dịch và tiếp thị không nên đi chung

Đây là nguyên tắc nâng cao quan trọng nhất của bài này, và là lỗi nhiều đội kỹ thuật mắc phải. Lý do gốc rễ: uy tín gửi (sender reputation) được tích lũy theo tên miền/đường gửi. Email tiếp thị, dù làm tốt đến đâu, vẫn sinh ra tín hiệu tiêu cực một cách tự nhiên: người ta bỏ qua, đánh dấu spam, hoặc địa chỉ cũ bị bounce. Nếu email giao dịch đi chung đường gửi với marketing, những tín hiệu xấu đó làm bẩn lây sang cả OTP và hóa đơn — và đột nhiên mã OTP của bạn rơi vào spam vì một chiến dịch khuyến mãi tuần trước bị nhiều người báo cáo.

Tách kênh nghĩa là gửi hai dòng email này qua hai đường tách biệt để uy tín của chúng không ảnh hưởng lẫn nhau. Trong thực tế, “tách” có thể ở nhiều mức:

• Tách theo cơ chế gửi: trên Mailemdi, email giao dịch đi qua đường API gửi-đồng-bộ (POST /transactional), còn marketing đi qua chiến dịch/automation gửi-qua-hàng-đợi — vốn đã là hai luồng riêng.
• Tách theo danh tính/subdomain: một quy ước phổ biến là dùng subdomain riêng cho giao dịch (ví dụ tư duy tx.tên-miền cho giao dịch và mail.tên-miền cho tiếp thị) để uy tín của mỗi subdomain độc lập.
• Tách theo địa chỉ From: giao dịch dùng no-reply@, còn marketing dùng một địa chỉ thân thiện có người trả lời.

Đo lường email giao dịch (khác hẳn cách đo marketing)

Với marketing, ngôi sao là tỷ lệ mở và tỷ lệ click — bạn muốn người ta đọc và hành động. Với giao dịch, tư duy đảo ngược: tỷ lệ mở cao không phải mục tiêu (mã OTP lý tưởng được dùng mà không cần “đọc kỹ”). Thứ bạn theo dõi là các chỉ số sức khỏe vận hành:

• Tỷ lệ gửi thành công (delivery / send success): thước đo số một. Mỗi thư giao dịch phải gửi được. Nếu tỷ lệ thất bại nhích lên, có gì đó đang hỏng (cấu hình kênh, tên miền, hay địa chỉ người nhận).
• Độ trễ gửi: thời gian từ lúc gọi API đến lúc thư đi. Theo dõi xu hướng — độ trễ tăng dần thường báo trước một sự cố hạ tầng.
• Bounce: với giao dịch, bounce thường nghĩa là dữ liệu người dùng sai (email nhập nhầm khi đăng ký) chứ không phải danh sách bẩn. Đây là tín hiệu nên sửa ở khâu thu thập email đầu vào.
• Khiếu nại (spam complaint): nếu người dùng báo spam một email giao dịch, đó là báo động đỏ — hoặc họ không nhận ra thư (thiếu thương hiệu rõ ràng), hoặc bạn đang gửi thứ họ không yêu cầu.

Để hiểu sâu cách đọc bounce, complaint và các chỉ số liên quan, xem bài Các chỉ số email marketing quan trọng. Trên Mailemdi, bạn có hai công cụ giám sát chính cho tầng giao dịch:

• Nhật ký giao dịch: mỗi lần gửi được ghi vào log — xem qua API GET /transactional/logs với địa chỉ người nhận, tiêu đề và trạng thái success / failed. Đây là nơi đối chiếu khi khách báo “tôi không nhận được mã”.
• Webhook sự kiện: đăng ký webhook để nhận các sự kiện như email.sent, email.bounced theo thời gian thực — để hệ thống của bạn phản ứng tức thì (ví dụ: bounce thì đánh dấu email người dùng cần xác minh lại).

Triển khai cụ thể: gửi email giao dịch qua API Mailemdi

Phần thực chiến. Mailemdi cung cấp Public API v1 với một endpoint chuyên cho việc này. Quy trình bốn bước:

1. Xác thực domain trước tiên. Vào phần cài đặt tên miền, thêm bản ghi SPF/DKIM/DMARC và chờ verify. Chưa xác thực thì đừng kỳ vọng email giao dịch vào hộp thư ổn định.
2. Lấy API key. Tại Cài đặt → API keys, tạo một khóa. Khóa chỉ hiển thị đầy đủ một lần — lưu nơi an toàn ở phía máy chủ, tuyệt đối không nhúng ở trình duyệt hay app di động.
3. Gọi POST /api/v1/transactional với header X-API-Key và thân JSON. Các trường: to (bắt buộc), subject (bắt buộc), html (bắt buộc), kèm tùy chọn text (bản thuần), replyTo và fromName. Lưu ý: không có trường From — danh tính người gửi do nền tảng cố định để chống giả mạo.
4. Đọc phản hồi. Thành công trả về 202 kèm { id, status: "success", via } (trong đó via cho biết kênh đã gửi). Lưu id để tra cứu log sau này.

curl -X POST https://app.mailemdi.io.vn/api/v1/transactional \
  -H "X-API-Key: <API_KEY_CỦA_BẠN>" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "nguoidung@example.com",
    "subject": "152384 là mã đăng nhập Mailemdi của bạn",
    "html": "<p>Mã của bạn: <b>152384</b>. Hết hạn sau 5 phút.</p>",
    "text": "Ma cua ban: 152384. Het han sau 5 phut.",
    "replyTo": "hotro@example.com"
  }'

# Phản hồi 202 — gửi đồng bộ, kết quả ngay
{ "data": { "id": "...", "status": "success", "via": "..." } }

Hệ thống tự chọn kênh gửi theo thứ tự ưu tiên (SMTP hệ thống → Amazon SES → SMTP của workspace), nên bạn không phải tự lo phần này. Một điểm quan trọng về độ tin cậy: API tôn trọng danh sách chặn (suppression) — nếu địa chỉ người nhận từng hard-bounce hoặc bị khiếu nại, lời gọi trả về 422 mã SUPPRESSED thay vì cố gửi vào một địa chỉ đã hỏng (việc cố gửi sẽ bào mòn uy tín). Hãy xử lý mã này ở phía bạn: đó là tín hiệu cần kiểm tra lại email của người dùng.

Đóng vòng phản hồi bằng webhook (và xác minh chữ ký HMAC)

Gửi thành công không có nghĩa là đến nơi. Để hệ thống của bạn biết khi nào thư thực sự được gửi đi hay bị bounce, hãy đăng ký webhook và để Mailemdi đẩy sự kiện về theo thời gian thực. Với tầng giao dịch, hai sự kiện đáng quan tâm nhất là email.sent và email.bounced — bounce ở đây thường nghĩa địa chỉ người dùng sai, đáng để bạn ghi cờ và yêu cầu họ cập nhật.

Quan trọng về bảo mật: đừng tin payload webhook một cách mù quáng, vì endpoint nhận của bạn là công khai. Mỗi lần đẩy, Mailemdi gắn header X-Webhook-Event và X-Webhook-Signature dạng sha256=<hex>. Chữ ký là HMAC-SHA256 của nguyên văn thân JSON với khóa là secret (dạng whsec_…) mà bạn nhận được một lần khi tạo webhook. Hãy tính lại và so khớp trước khi tin dữ liệu. Hướng dẫn đầy đủ kèm mẫu Node.js nằm trong trang Tích hợp API.

Checklist trước khi đưa email giao dịch lên production

• SPF/DKIM/DMARC đã xác thực cho tên miền gửi giao dịch.
• Đã tách kênh khỏi email tiếp thị (khác cơ chế gửi, lý tưởng là khác subdomain/địa chỉ From).
• API key lưu phía máy chủ, không lộ ở client; có biến môi trường, không hard-code.
• Gọi API từ tiến trình nền với timeout + retry backoff; tôn trọng giới hạn 120 req/phút.
• Xử lý đủ các mã trả về (202 / 401 / 422 SUPPRESSED / 502).
• Mỗi mẫu có bản text song song, nhẹ, đã soát dung lượng và từ khóa spam; link đã soát bằng Kiểm tra link.
• Webhook đã đăng ký và endpoint nhận đã xác minh chữ ký HMAC.
• Có dashboard theo dõi tỷ lệ gửi thành công, độ trễ và bounce; cảnh báo khi lệch chuẩn.
• Đã thử nghiệm đường gửi mới. Nếu tên miền/subdomain giao dịch còn mới, hãy làm nóng (warmup) để xây uy tín trước khi đẩy lưu lượng lớn.

Đọc thêm

• Tích hợp API — tài liệu đầy đủ về X-API-Key, endpoint giao dịch, webhook và xác minh HMAC.
• SPF, DKIM, DMARC toàn tập — nền tảng xác thực để email giao dịch vào hộp thư.
• Các chỉ số email marketing quan trọng — hiểu bounce, complaint và cách đọc số liệu vận hành.
• Vào hộp thư đến — checklist deliverability áp dụng cho cả thư giao dịch.
• Thư viện mẫu email — tham khảo cấu trúc cho xác nhận đơn hàng, xác nhận đăng ký… làm nền cho mẫu giao dịch của bạn.