Cách gửi email từ app (và vào được hộp thư đến)

Để gửi email từ app một cách đáng tin cậy, hãy dùng nhà cung cấp dịch vụ gửi email thay vì hộp thư cá nhân, gửi từ địa chỉ thuộc tên miền của bạn, và thêm các bản ghi DNS mà nhà cung cấp đưa ra để SPF, DKIM và DMARC đều đạt. Hãy tách email giao dịch — đặt lại mật khẩu, biên lai, xác nhận — khỏi email marketing, chỉ gửi mỗi loại đến những người đang mong đợi nó, và xử lý email bị trả về cùng yêu cầu hủy đăng ký. Hãy làm đúng phần xác thực trước; đây là lý do phổ biến nhất khiến email của app bị đưa vào thư rác.

Email giao dịch và email marketing

Hai loại email này trông giống nhau trong mã nguồn, nhưng các nhà cung cấp hộp thư và pháp luật đối xử với chúng rất khác nhau.

Hãy tách hai loại này ra. Nếu một chiến dịch marketing bị khiếu nại thư rác, bạn không muốn email đặt lại mật khẩu từ cùng luồng cũng bị ảnh hưởng. Cách phổ biến là dùng các tên miền phụ riêng — ví dụ mail.example.com cho email tài khoản và news.example.com cho bản tin — và một số nhà cung cấp tách hai loại này ngay bên trong hệ thống. Chẳng hạn, Postmark mô tả các "luồng tin nhắn" giao dịch và phát sóng của mình chạy trên hạ tầng gửi riêng biệt, tính đến tháng 9/2026.

Chọn nhà cung cấp

App của bạn không nên tự gửi email từ máy chủ của chính nó. Các nhà cung cấp dịch vụ gửi email lo phần hạ tầng, uy tín địa chỉ IP, gửi lại và xử lý email bị trả về. Các lựa chọn nổi tiếng gồm Postmark, Resend, SendGrid, Amazon SES và Mailgun; mỗi bên đều có API HTTP và truy cập SMTP. Giá và gói dịch vụ thay đổi thường xuyên, nên hãy so sánh trên trang chính thức của từng bên.

Những điều cần so sánh:

• Trọng tâm. Một số nhà cung cấp tập trung vào email giao dịch; số khác kết hợp cả giao dịch lẫn marketing.
• Trải nghiệm lập trình. API rõ ràng, thư viện chính thức cho ngôn ngữ của bạn, nhật ký hữu ích cho biết mỗi thư đã được gửi, bị trả về hay bị đánh dấu thư rác.
• Webhook cho email bị trả về, khiếu nại và email đã gửi thành công, để app của bạn có thể phản ứng.
• Mẫu thư — được lưu trên nhà cung cấp, hoặc nằm trong mã nguồn của bạn. Giữ mẫu trong mã giúp chúng có phiên bản và dễ kiểm thử.
• Vùng lưu trữ và xử lý dữ liệu, nếu bạn có yêu cầu về nơi dữ liệu được xử lý.
• Chi phí ở khối lượng của bạn, bao gồm điều gì xảy ra khi vượt gói miễn phí.

Với bản tin gửi đến một danh sách, một công cụ bản tin hoặc email marketing chuyên dụng thường phù hợp hơn là tự xây tính năng chiến dịch trong app.

Thiết lập tên miền gửi

Hãy gửi từ tên miền của riêng bạn — hello@example.com, không phải địa chỉ Gmail hay Outlook. Thư gửi từ hộp thư miễn phí qua dịch vụ bên thứ ba sẽ thất bại ở các kiểm tra xác thực và rất dễ bị lọc.

Hãy cân nhắc dùng một tên miền phụ chỉ dành cho việc gửi. Ví dụ, Resend khuyến nghị gửi từ các tên miền phụ như updates.example.com để tách uy tín gửi thư (tính đến tháng 9/2026). Cách này cũng giữ các bản ghi DNS của email tách biệt với trang chính của bạn.

Nhà cung cấp sẽ đưa cho bạn các bản ghi DNS cần thêm vào nơi quản lý DNS của tên miền. Nếu DNS còn mới với bạn, cách hoạt động của tên miền và DNS sẽ giải thích các bản ghi trước.

SPF

SPF (Sender Policy Framework) là một bản ghi TXT liệt kê những máy chủ nào được phép gửi email thay mặt tên miền của bạn. Máy nhận sẽ kiểm tra xem máy chủ gửi có nằm trong danh sách hay không.

• Một tên miền chỉ nên có một bản ghi SPF. Nếu thêm nhà cung cấp mới, hãy gộp vào bản ghi hiện có thay vì thêm bản ghi thứ hai.
• SPF cho phép tối đa 10 lượt tra cứu DNS khi được đánh giá; chuỗi dài các mục include: có thể vượt giới hạn này và gây lỗi.
• Nhiều nhà cung cấp đặt SPF trên một tên miền phụ dùng để trả về (return-path) mà họ yêu cầu bạn tạo, nên bạn có thể không cần sửa bản ghi SPF chính.

DKIM

DKIM (DomainKeys Identified Mail) thêm một chữ ký mật mã vào mỗi thư. Nhà cung cấp ký bằng khóa riêng; bạn công bố khóa công khai tương ứng dưới dạng bản ghi DNS (TXT hoặc CNAME, tùy nhà cung cấp). Máy nhận kiểm tra chữ ký để xác nhận thư đến từ người gửi được ủy quyền và không bị thay đổi trên đường đi.

Bước "xác minh tên miền" của nhà cung cấp chủ yếu là về DKIM. Đừng bỏ qua.

DMARC

DMARC kết nối hai cơ chế kia lại với nhau. Đó là một bản ghi TXT đặt tại _dmarc.yourdomain.com, cho máy nhận biết:

• Sự khớp (alignment): tên miền trong địa chỉ From hiển thị phải khớp với tên miền đã vượt qua SPF hoặc DKIM.
• Chính sách: cần làm gì với thư không đạt — p=none (chỉ báo cáo), p=quarantine (coi là đáng ngờ, thường vào thư rác) hoặc p=reject.
• Báo cáo: gửi báo cáo tổng hợp (rua=) đến đâu, để bạn thấy ai đang gửi thư thay mặt tên miền của mình.

Cách hợp lý là bắt đầu với p=none kèm địa chỉ nhận báo cáo, xác nhận thư hợp lệ của bạn đều đạt, rồi chuyển sang quarantine và cuối cùng là reject. Chính sách nghiêm ngặt cũng khiến người khác khó giả mạo tên miền của bạn hơn nhiều.

Gmail yêu cầu những gì

Tính đến tháng 9/2026, hướng dẫn dành cho người gửi của Google nêu:

• Mọi người gửi đến tài khoản Gmail cá nhân cần có SPF hoặc DKIM, DNS xuôi và ngược hợp lệ cho máy chủ gửi, TLS, và tỷ lệ thư rác trong Postmaster Tools dưới 0,3%.
• Người gửi hàng loạt (hơn 5.000 thư mỗi ngày đến Gmail) cần có cả SPF lẫn DKIM, một bản ghi DMARC (cho phép chính sách p=none), sự khớp tên miền From, và tính năng hủy đăng ký một lần nhấn cùng liên kết hủy đăng ký hiển thị rõ trên thư marketing và thư đăng ký.

Nhà cung cấp của bạn lo các phần phía máy chủ. Các bản ghi DNS và việc xử lý hủy đăng ký là phần của bạn. Ngay cả khi bạn chưa đến 5.000 thư mỗi ngày, đáp ứng các quy tắc dành cho người gửi hàng loạt là cách đơn giản nhất để an toàn.

Đưa việc gửi email vào app

Khi tên miền đã được xác minh:

1. Lưu API key như một bí mật phía máy chủ — tuyệt đối không đặt trong mã phía giao diện. Xem biến môi trường và bí mật là gì.
2. Gửi từ máy chủ, sau khi hành động kích hoạt email đã thành công.
3. Đừng bắt người dùng chờ email. Với bất cứ app nào vượt quá mức đơn giản nhất, hãy xếp thư vào hàng đợi và thử lại khi gặp lỗi tạm thời, để phản hồi chậm từ nhà cung cấp không làm chậm quá trình đăng ký.
4. Ghi nhật ký kết quả — mã tin nhắn và trạng thái từ nhà cung cấp — mà không ghi key hay toàn bộ nội dung thư có dữ liệu cá nhân.
5. Xử lý webhook cho email bị trả về và khiếu nại: ngừng gửi đến những địa chỉ bị trả về vĩnh viễn hoặc đánh dấu bạn là thư rác.

Một prompt bao gồm các phần cơ bản:

Gửi email giao dịch bằng [PROVIDER] với bí mật phía máy chủ [ENV_NAME], từ "Acme hello@mail.acme.com". Gửi email chào mừng sau khi đăng ký và email xác nhận đặt chỗ sau khi lịch hẹn được lưu. Giữ mẫu thư trong mã, kèm phiên bản văn bản thuần bên cạnh HTML. Xếp thư vào hàng đợi và thử lại lỗi tạm thời tối đa ba lần. Ghi nhật ký lỗi kèm thông báo từ nhà cung cấp nhưng không bao giờ ghi API key. Thêm một endpoint webhook đánh dấu các địa chỉ không nhận được thư khi bị trả về vĩnh viễn hoặc có khiếu nại, và bỏ qua các địa chỉ đó sau này.

Email tài khoản — liên kết xác minh, liên kết đăng nhập và đặt lại mật khẩu — là một phần của đăng nhập. Cách thêm đăng nhập vào app giải thích các luồng này khớp với nhau thế nào; hãy làm các liên kết này dùng một lần và có thời hạn ngắn.

Thói quen để email vào được hộp thư đến

Xác thực giúp thư được xem xét. Hành vi giúp thư nằm lại trong hộp thư đến.

• Chỉ gửi điều người ta mong đợi. Đăng ký đã xác nhận, đồng ý rõ ràng cho marketing, không mua danh sách.
• Làm cho việc hủy đăng ký dễ dàng với mọi thứ không hoàn toàn là giao dịch, và tôn trọng yêu cầu ngay lập tức.
• Làm nóng tên miền mới. Một tên miền mới gửi hàng nghìn thư ngay ngày đầu trông đáng ngờ. Hãy bắt đầu với thư giao dịch và tăng khối lượng dần.
• Giữ danh sách sạch. Xóa ngay các email bị trả về vĩnh viễn và cân nhắc xóa những người lâu không mở thư nào.
• Viết như một con người. Tiêu đề rõ ràng, tên người gửi dễ nhận ra, một phần văn bản thuần, ít hình ảnh và liên kết dẫn về tên miền của bạn. Tránh dịch vụ rút gọn liên kết.
• Theo dõi. Đăng ký tên miền của bạn trong Google Postmaster Tools và thỉnh thoảng đọc báo cáo DMARC.
• Dùng địa chỉ trả lời thật có người đọc. Các phản hồi là tín hiệu tốt và là nguồn góp ý hữu ích.

Kiểm thử mà không làm phiền ai

• Dùng chế độ thử nghiệm hoặc sandbox của nhà cung cấp nếu có, hoặc gửi đến các địa chỉ bạn sở hữu.
• Khi phát triển, gửi đến một hộp thư thử nghiệm nhận tất cả thay vì người dùng thật; một cơ sở dữ liệu chứa đầy địa chỉ trông như thật rất dễ khiến bạn gửi thư nhầm cho người lạ.
• Kiểm tra từng mẫu thư trên vài trình khách — Gmail trên web, ứng dụng thư trên điện thoại, Outlook — và cả chế độ tối.
• Xem phần tiêu đề (header) của một email thử: chúng cho biết SPF, DKIM và DMARC có đạt hay không.

Những điều pháp lý cơ bản

Quy định khác nhau theo quốc gia. Nói chung, email marketing cần sự đồng ý ở nhiều nơi, phải nêu rõ người gửi, và phải có cách hủy đăng ký hoạt động được; email giao dịch được đối xử khác nhưng không nên lợi dụng để lồng quảng cáo vào. Nếu bạn thu thập địa chỉ từ trang danh sách chờ, hãy nói rõ bạn sẽ gửi gì và lưu trữ gì, và khi nào, như thế nào mỗi người đã đăng ký. Khi còn nghi ngờ, hãy kiểm tra quy định ở nơi người dùng của bạn đang sinh sống.

Danh sách kiểm tra email

• Đã chọn nhà cung cấp gửi email; API key được lưu như bí mật phía máy chủ
• Gửi từ tên miền hoặc tên miền phụ của bạn, không dùng hộp thư miễn phí
• Đã thêm và đạt các bản ghi SPF, DKIM và DMARC
• Đã tách thư giao dịch và thư marketing
• Thư được xếp hàng đợi và thử lại; kết quả được ghi nhật ký
• Đã xử lý webhook cho email bị trả về và khiếu nại
• Có cách hủy đăng ký trên thư không phải giao dịch, và được tôn trọng ngay lập tức
• Đã kiểm thử mẫu thư trên nhiều trình khách; thư thử không bao giờ đến người dùng thật

Gửi email từ app Mythex

Mythex không có dịch vụ gửi email tích hợp sẵn cho các app bạn xây dựng, nên bạn cần tự đưa nhà cung cấp như Resend, SendGrid hoặc Postmark. Lưu API key của họ như một bí mật của dự án — agent có thể yêu cầu bạn nhập qua thẻ bí mật trong chat — rồi mô tả các email bạn cần bằng lời thường. Tài liệu có một prompt mẫu trong gửi email từ app của bạn. Nếu bạn đã mua tên miền qua Mythex với gói Pro, bạn có thể thêm các bản ghi TXT và CNAME của nhà cung cấp trong phần cài đặt DNS của tên miền; xem tên miền tùy chỉnh.

Câu hỏi thường gặp