Làm đồ án cuối khoá bao giờ cũng nhiều chuyện dở khóc dở cười. Đợt vừa rồi, mình nhận làm một website đăng ký lớp học kỹ năng cho trung tâm của người quen. Do thời gian nộp bài khá gấp, mình tận dụng luôn Claude Code để phụ gõ những đoạn mã cơ bản. Phần lớn giao diện, biểu mẫu điền thông tin và logic kiểm tra lỗi được AI hoàn thiện rất nhanh. Mình cứ nghĩ phần gửi email từ website để đẩy mã OTP và mail xác nhận lịch là dễ nhất. Nhắm mắt cũng xong. Sai bét.
Kết quả loay hoay mất 4 ngày, sửa code liên tục chỉ vì mail hệ thống toàn chui vào Spam hoặc không đi. Mình ghi lại cho bạn nào sắp làm dự án dính tới mail.
Gửi email từ website khác gì bấm gửi trong Gmail
Ban đầu mình nghĩ kiểu người dùng: máy chủ gửi mail cũng như mình mở Gmail gõ địa chỉ rồi bấm gửi. Bên dưới khác hẳn, và cái khác đó là thứ làm mình mất mấy ngày mà không hiểu vì sao thư cứ biến mất.
Khi tự gửi thư bằng giao diện trang web, máy chủ biết rõ bạn là ai, bạn đang dùng trình duyệt gì. Các bộ lọc có hàng tá lớp bảo vệ để xác minh bạn là con người thật. Còn khi bạn yêu cầu máy chủ tự động gửi email từ website, mọi thứ diễn ra ngầm qua các giao thức kỹ thuật như SMTP hoặc API. Bạn đang ủy quyền cho đoạn mã tự động hóa giao tiếp, và các nền tảng nhận thư luôn duy trì thái độ rất cảnh giác với máy móc vì sợ thư rác.
Để các hệ thống nhận thư lớn tin tưởng, dự án của bạn cần những cơ chế xác thực danh tính riêng biệt. Mình hay ví von việc này giống hệt chuyện bạn cử một nhân viên đi giao công văn tận tay đối tác. Nhân viên đó bắt buộc phải mang theo giấy giới thiệu có đóng dấu mộc đỏ của giám đốc công ty. Trong thế giới mạng, con dấu mộc đỏ đó chính là các bản ghi bảo mật SPF và DKIM. Người nhận thư sẽ tự động soi con dấu này. Nếu họ tra dữ liệu thấy dấu giả, hoặc nhân viên đi tay không, thư của bạn lập tức bị quăng vào thùng rác.
Việc thiết lập SMTP hay API bản chất là quá trình bạn khai báo danh tính của máy chủ với thế giới mạng. Mỗi lá thư sinh ra từ hệ thống phải mang theo chữ ký số. Người dùng bình thường không bao giờ thấy những con số này, nhưng thuật toán chống thư rác thì soi rất kỹ. Code sinh OTP mất 15 phút. Cấu hình để thư qua được vòng bảo vệ đó mất 4 ngày.
5 lỗi mình dính khi gửi email từ website
Lỗi thứ nhất, mình xài luôn tài khoản Gmail cá nhân làm SMTP cho website, nghĩ đơn giản là mình gửi được thì máy chủ cũng gửi được, có gì mà phải đăng ký dịch vụ riêng cho mất công. Lấy thông tin đăng nhập quăng thẳng vào đoạn mã kết nối. Lúc thử nghiệm trên máy ở nhà, thấy hệ thống báo về điện thoại ngon lành. Mình gửi liên kết cho nhóm dùng thử tốc độ. Lượng người truy cập nhào vô thao tác cùng lúc, hệ thống vọt lên gửi 60 mail trong một buổi sáng. Google khoá tài khoản ngay. Sáng gửi, trưa khoá. Họ gửi cảnh báo có hoạt động bất thường, nghi ngờ tài khoản bị xâm nhập và chặn toàn quyền truy cập từ các ứng dụng kém an toàn. Mình hoảng, tưởng mất hộp thư chính, phải làm đủ bước khôi phục mới lấy lại.
Lỗi thứ hai, mình lách bằng cách tạo mật khẩu ứng dụng riêng cho Gmail. Thư tự động đẩy đi được, mã Node.js không báo lỗi, tài khoản an toàn. Trớ trêu thay, toàn bộ thư rớt thẳng vào mục Spam của người nhận. Mình mò mẫm trên các diễn đàn mới biết tên miền của trung tâm chưa cài đặt các bản ghi SPF và DKIM. Bên nhận coi đó là mail mạo danh, nên thư gửi đi được nhưng vào tới cửa hộp thư người nhận là bị đẩy thẳng sang Spam mà mình không nhận được bất kỳ thông báo lỗi nào ở phía gửi.
Lỗi thứ ba, cái này suýt làm mình ôm hận. Mình để nguyên chuỗi mật khẩu ứng dụng đó trong tệp cấu hình dự án rồi đẩy tuốt lên kho chứa GitHub. Mình vô ý quên bẵng việc đưa tệp biến môi trường vào danh sách từ chối, thế là mã bí mật phơi mặt cho thiên hạ xem. Hôm sau một ông bạn kéo mã về, tá hỏa gọi điện bắt mình gỡ xuống gấp. Mình tìm hiểu thêm thì đọc được báo cáo của vibe-eval, khóa API lộ trong mã nguồn công khai bị hacker quét được và khai thác chỉ sau 11 phút. Mình xoá khoá và thu hồi mật khẩu ngay trong đêm, rồi ngồi đọc lại toàn bộ cách dùng biến môi trường mà trước đó cứ tưởng là chuyện màu mè của dân đi làm.
Lỗi thứ tư, mình bỏ Gmail, đăng ký Resend của nước ngoài cho đúng bài. Bên này mượt, tài liệu dễ hiểu, trang MONA Mail so với Resend cũng ghi nhận thẳng điểm đó. Kẹt ở chỗ khác: thầy hướng dẫn đòi hoá đơn có mã số thuế Việt Nam cho kế toán trung tâm. Dịch vụ nước ngoài tính tiền đô, giấy tờ chỉ là biên lai chung, kế toán lắc đầu.
Lỗi thứ năm, khách đăng ký thử than OTP về chậm. Việc này xuất phát từ việc máy chủ gửi mail của dịch vụ ngoại đặt tận bên Mỹ. Những lúc băng thông cáp quang quốc tế nghẽn, thư phải xếp hàng chờ trên máy chủ của họ. Có hôm mình canh đồng hồ, thư trễ 3 phút. Khách thoát. Mất lead. Một luồng làm kỹ từ đầu hỏng chỉ vì 3 phút chờ.
Đổi sang MONA Mail: 4 bước mình làm
Ăn đủ 5 vố, mình tìm dịch vụ có máy chủ ở Việt Nam và có hoá đơn cho kế toán. Chọn MONA Mail vì miễn phí 3.000 mail mỗi tháng, có hoá đơn VAT; trung tâm nhỏ xài không hết, đông hơn thì gói từ 99.000đ/tháng. Cấu hình lại phần gửi mail từ website theo 4 bước.
Bước một, mình tạo tài khoản MONA Pass. Đây là tài khoản định danh dùng chung cho bộ công cụ của họ nên thủ tục khá nhanh gọn. Mình quét VietQR nạp 50.000đ vào ví cho có, gói miễn phí nên chưa bị trừ đồng nào.
Bước hai, mình làm thủ tục thêm tên miền của trung tâm và trỏ cấu hình DNS. Nhập tên miền vào hệ thống, trang web kết xuất ra loạt bản ghi DNS cần thiết. Mình sao chép từng dòng, mở giao diện quản trị bên Namecheap ra rồi dán các thông số đó vào đúng ô. Chờ tầm một tiếng cho mạng lưới đồng bộ, hệ thống báo xác thực thành công. Tên miền trang web giờ trang bị đủ con dấu SPF và DKIM hợp lệ. Các máy chủ email lớn khi nhận thư từ hệ thống sẽ tự động truy vấn lại, thấy chữ ký số khớp là cho qua dễ dàng.
Bước ba, mình vào mục quản lý bảo mật khởi tạo khóa API mới phục vụ kết nối. Nhớ lại vụ kho chứa GitHub đợt trước, lần này tạo khóa xong là mình dán ngay vào biến môi trường trên máy tính. Mã nguồn đẩy lên mạng hoàn toàn sạch sẽ, không lưu trữ mật khẩu nhạy cảm nào. Nguyên tắc sống còn là luôn tách biệt phần logic và phần lưu trữ thông tin xác thực.
Bước bốn, mình nhường cho AI tự viết code gửi email từ website. Thay vì mở tài liệu đọc từng hàm, mình cung cấp luôn đường link monamail.vn/llms.txt cho Claude Code phân tích. Nó tự nhận diện thư viện, chạy lệnh cài đặt gói monacloud-mcp từ kho lưu trữ npm. Sau đó nó gọi thẳng công cụ mail_send, tự động nhúng vào tệp xử lý luồng đăng ký của dự án. Mình ngồi xem, không gõ dòng kết nối nào. Giờ ai điền form là OTP tới trong vài giây. Vào Inbox.
Hai chỗ chưa ưng
Đồ án chạy được rồi, nhưng có hai chỗ mình chưa ưng, bạn nên biết trước.
Thứ nhất, hệ thống gửi thư này vẫn đang trong giai đoạn beta. Lúc mình vừa cấu hình DNS xong và chạy thử luồng gửi, lá mail xác nhận lịch học đầu tiên chui thẳng vào tab Quảng cáo của Gmail. Mình phải tự mở hòm thư, bấm chọn và di chuyển thủ công nó sang hộp thư chính. Tên miền mới gửi mail cần vài ngày “làm ấm”, tức là gửi đều để Gmail quen nguồn, rồi mới vào Inbox ổn.
Thứ hai, toàn bộ công cụ này hoàn toàn vắng bóng giao diện kéo thả trực quan để thiết kế mẫu thư. Rất nhiều nền tảng ngoài kia cho bạn kéo khối văn bản, xếp hình ảnh bằng chuột. Ở đây, mình phải tự gõ code HTML thô cho từng lá mail xác nhận hoặc nhờ AI sinh mã theo ý rồi dán vào. Dân code thì quen, nhưng bạn nào đang quen công cụ kéo thả kiểu soạn mail marketing mà đụng vào chắc sẽ thấy cực và bỏ.
Gỡ xong luồng gửi email từ website cho đồ án, mình học được nhiều hơn cả phần code chính, nhất là vụ khoá API, không có ông bạn nhắc thì giờ chắc đang khổ. Cuối tuần rảnh mình định thử nối database đám mây xem phản hồi nhanh thêm được bao nhiêu.
