Cách một web app gửi email THẬT năm 2026 — mà không tự chạy mail server: một lời gọi API, mạng của provider, và ba record DNS giúp email không rơi vào spam.
← / → để chuyển slide · chuyển EN/VI bên dưới
Mọi sản phẩm thật đều gửi email. Nếu nó dừng, người dùng tự khóa mình ra ngoài, mất hóa đơn, và âm thầm mất niềm tin vào sản phẩm.
Nếu người dùng không nhận được email đặt lại mật khẩu, họ không đăng nhập lại được. Không email = không login, không hỗ trợ, không hoàn tiền.
Đặt hàng, thanh toán, tạo tài khoản — mỗi sự kiện sinh ra một email. Đó là hồ sơ giấy của sản phẩm bạn.
Nhắc nhở, cập nhật đơn hàng, lời nhắc — nhiều app sống hay chết dựa vào việc email tới inbox nhanh và chắc chắn thế nào.
Push cần cài app, SMS tốn tiền theo tin nhắn. Email gần như miễn phí, ai cũng có, và dựa trên hạ tầng 40+ năm.
Code của bạn không bao giờ nói chuyện với mạng email của internet. Nó chỉ gọi HTTPS một lần — provider lo phần còn lại.
Kích hoạt email từ hành động người dùng: bấm đặt lại, đã thanh toán. Nó tạo From/To/tiêu đề/nội dung — không hơn.
Cánh cửa: một POST HTTPS có xác thực. Bạn nhận lại ID thông điệp và 202 'đã vào hàng chờ'. Đó là toàn bộ hợp đồng.
Server gửi có IP sạch và nhiều năm uy tín. Họ ký thông điệp (DKIM) và chuyển phát qua SMTP.
Server người nhận kiểm tra SPF/DKIM/DMARC so với DNS của DOMAIN BẠN, rồi phân loại: inbox hay spam.
không mail server trên VPS · không code SMTP trong app · không cần tự xây uy tín IP
Bạn không tự chạy mail server. Bạn thuê một dịch vụ chuyển phát — và việc duy nhất của bạn là trao đúng phong bì với đúng địa chỉ.
Tự gửi email về kỹ thuật là được, về thực tế là đau. Phần này giải thích vì sao mọi app nghiêm túc đều trả tiền cho người khác làm việc này.
Hầu hết email của app là transactional. Marketing email là một ngành riêng với quy tắc riêng — cần biết ranh giới.
Đặt lại mật khẩu, hóa đơn, 'đơn đã gửi'. Một thông điệp, một người nhận, được kích hoạt bởi một sự kiện. Cấp bách, lượng thấp, phải tới nơi.
Newsletter, khuyến mãi, bản tin. Bắt buộc opt-in, giới hạn gửi chặt, link hủy đăng ký. Thường là dịch vụ riêng và domain gửi riêng.
Provider định giá và hạn mức theo loại. Nhồi newsletter qua tài khoản transactional sẽ bị hạ băng thông — hoặc email app bị gắn nhãn sai.
Mọi thứ bên dưới: cách web app gửi email transactional vào inbox, chứ không phải thư mục spam.
Rất hấp dẫn: bớt một dịch vụ, bớt một hóa đơn. Thực tế, một server mới là kẻ gửi email tệ nhất có thể.
Hầu hết provider VPS/cloud chặn port 25 ra ngoài (port gửi mail) ở cấp mạng — để bạn không biến thành xưởng spam qua một đêm.
Provider inbox theo dõi uy tín IP. IP mới tinh, chưa có lịch sử, trông y hệt IP của bot spam. 'Làm ấm' mất vài tuần tăng lượng cẩn thận.
Thư im lặng vào spam, bị trả lại, hoặc biến mất. Không có dashboard và webhook, bạn chỉ biết khi người dùng phàn nàn — nhiều ngày sau.
Xây uy tín IP gửi là dự án vài tháng: tăng lượng từ từ, giám sát, quản lý khiếu nại. Đó là nghề của người khác.
Từ một VPS mới điển hình, port mail đơn giản là không tồn tại — trong khi cánh cửa API mở toang.
Bạn không trả tiền cho 'việc gửi'. Bạn trả tiền cho uy tín, một mạng lưới, và vòng phản hồi đã mất nhiều năm để xây.
Server gửi của họ có nhiều năm hành xử tốt. Provider inbox cho phép lưu lượng của họ đi qua — đó chính là sản phẩm.
Mỗi thông điệp được mạng của họ ký bằng khóa DKIM của domain bạn. Bạn công bố một record DNS; họ ký mãi mãi.
Bounce, click, khiếu nại, trạng thái chuyển phát quay về app dưới dạng webhook. Code của bạn phản ứng: ngừng gửi tới các địa chỉ chết.
Cùng một lời gọi HTTPS chạy với Python, Node, Go hay serverless. Hệ thống mail không còn là một phần codebase của bạn.
Tất cả đều làm cùng một việc. Chọn theo gói miễn phí, trải nghiệm dev, và độ hợp với stack của bạn.
| Provider | Nổi bật vì | Phù hợp |
|---|---|---|
| SendGrid | Cựu binh — hệ sinh thái lớn + gói miễn phí | dự án lớn, nhiều tích hợp |
| Resend | API thân dev, DX rất sạch | web app hiện đại, setup nhanh |
| Postmark | cực đoan về deliverability, rất nghiêm | email mà việc tới nơi là sống còn |
| Amazon SES | giá cực thấp khi lên scale | khối lượng lớn, nhạy cảm chi phí |
| Mailgun | API linh hoạt, quản domain & theo dõi | app cần kiểm soát chi tiết |
Việc của bạn là một HTTP call và ba record DNS. Phần khó nhất của email — uy tín, chuyển phát, xác thực — là nghề toàn thời gian của người khác.
Theo một email đặt lại mật khẩu từ code của bạn tới inbox người nhận. Mọi mảnh ghép bạn cần đều nằm trên bản đồ này.
Cùng bốn trạm như bức tranh lớn — nhưng giờ mỗi chặng được gắn nhãn thứ thực sự đi trên đường truyền.
Gửi From/To/tiêu đề/nội dung cùng API key. Không có giao thức mail trong code của bạn.
Xác thực, xếp hàng thông điệp, trả về 202 + ID. Request của bạn xong — chuyển phát chạy ở nền.
Tra MX record của người nhận, nối tới mail server của họ, trao thông điệp. Tự thử lại, đổi đường khi hỏng.
Chạy kiểm tra SPF/DKIM/DMARC so với DNS domain bạn, chấm điểm thông điệp, phân loại: inbox, spam — hoặc trả bounce.
bạn sở hữu chặng 1 (và các record DNS) · provider sở hữu chặng 2–3 · thế giới người nhận sở hữu chặng 4
Không client SMTP, không mail server, không port 25. Một request HTTPS với body JSON — là hết.
import httpx
# the entire 'email feature' of your app
r = httpx.post(
"https://api.resend.com/emails",
headers={"Authorization": "Bearer re_..."},
json={
"from": "Acme App <noreply@shop.example.com>",
"to": ["alice@example.com"],
"subject": "Your password reset link",
"html": "<p>Click <a href='/reset?token=...'>here</a> to reset.</p>",
},
)
print(r.status_code) # 202 — queued for deliveryDocs của provider cho bạn snippet theo ngôn ngữ. Có AI, đây là việc 5 phút — kỹ năng là hiểu phản hồi có nghĩa gì.
Diễn ra sau 202 của bạn — phía provider của hợp đồng.
API kiểm tra key, domain gửi và nội dung, rồi đưa thông điệp vào hàng chờ. Bạn đã cầm ID thông điệp.
Mạng ký bằng khóa riêng DKIM của domain bạn. Nửa công khai nằm trong DNS của bạn — người nhận dùng nó ngay sau đó.
Tra MX DNS tìm mail server của người nhận (chẳng hạn của Google). Provider nối qua SMTP port 25 và trao thông điệp.
Server người nhận kiểm tra SPF, DKIM, DMARC so với record domain bạn, rồi chạy bộ lọc spam. Cấu hình DNS của bạn bị thử ở đây.
Inbox: chuyển phát xong, webhook chạy. Spam: tới nhưng vô dụng. Bounce: địa chỉ không tồn tại, app được báo ngừng gửi tới đó.
Phần lớn sự nhầm lẫn về email là trộn hai vế này. Bạn sống ở bên trái; bên phải là nơi record DNS của bạn được đọc.
SMTP là giao thức đưa mail giữa các server — nhưng bạn không bao giờ chạm tới. App gọi API; server của provider lo SMTP, thử lại, và uy tín IP.
Nếu nghe 'SMTP', hãy nghĩ: đường ống nội bộ của provider.
Server người nhận là người giữ cổng: tra record SPF/DKIM/DMARC của bạn, xác minh thông điệp, rồi quyết inbox, spam, hay từ chối.
Đây là nơi deliverability sống — toàn bộ phần kế tiếp.
Mọi email thật đều mang một khối header — hộ chiếu của thông điệp, và nơi xác thực xuất hiện.
Provider theo dõi mọi thông điệp sau khi bạn gửi. Bạn đăng ký nhận kết quả — và app có thể hành động dựa trên đó.
Hard bounce = địa chỉ không tồn tại (ngừng gửi, đánh dấu). Soft = đầy hay bận (thử lại sau). App tốt sẽ cập nhật danh sách người dùng từ đây.
Người nhận bấm 'báo spam'. Vài cái là bình thường; một đợt tăng nghĩa là nội dung hay danh sách của bạn sai — và deliverability sắp chịu thiệt.
Một POST HTTPS về APP CỦA BẠN khi thông điệp được chuyển phát, bounce, hay bị khiếu nại. 'Gửi' thành tính năng đáng tin, chứ không phải bắn rồi quên.
Danh sách chặn (không bao giờ gửi tới các địa chỉ bounce đã biết) và danh sách sạch giữ domain trẻ khỏi rắc rối. Phần lớn provider lo phần cơ bản cho bạn.
Inbox đa nghi vì ai cũng giả được header From:. Ba record DNS là điều kiện tiên quyết — và đúng là phần DNS bạn đã biết.
Giao thức mail không có danh tính tích hợp. Header From: là một lời tuyên bố, không phải sự thật — và internet đầy những lời tuyên bố sai.
Ai cũng viết được bất kỳ địa chỉ nào vào From:. Không có kiểm tra, tin lừa từ 'support@example.com' gửi bởi server của người lạ trông giống hệt thư thật về cấu trúc.
Không có cơ quan trung tâm nào xác minh người gửi. Mỗi provider inbox (Google, Microsoft, Apple…) tự chạy cổng kiểm soát — và chia sẻ dữ liệu mối đe dọa để giữ spam ra ngoài.
Vì không ai xác minh bạn, CHÍNH BẠN công bố quy tắc xác minh trong DNS của domain. Server người nhận đọc chúng trước khi quyết thư của bạn đi đâu.
Domain không có SPF hay DKIM tự nó là lá cờ đỏ. Với sản phẩm mới, mail không xác thực có thể không bao giờ tới inbox chính — kể cả email đặt lại mật khẩu đầu tiên.
Học theo thứ tự này: ai được PHÉP (SPF), ai THẬT SỰ KÝ (DKIM), và phải LÀM GÌ khi câu chuyện không khớp (DMARC).
Một record TXT trên domain: 'chỉ những server này được phép gửi mail nhân danh domain tôi.' Người nhận đối chiếu server gửi với danh sách.
Mỗi thông điệp được ký bằng khóa riêng; khóa công nằm trong DNS của bạn. Nếu người nhận xác minh được chữ ký, thông điệp nguyên vẹn và thật sự của bạn.
Một record chính sách: 'nếu thông điệp trượt SPF hoặc DKIM, từ chối / cách ly / bỏ qua.' Nó cũng chỉ nơi người nhận gửi báo cáo về ai đã dùng domain của bạn.
Một record TXT trên domain của bạn. Đó là danh sách khách, và token cuối là quy tắc cho tất cả người còn lại.
# registrar panel -> your domain -> add TXT record
name: @
value: v=spf1 include:resend.net ~all
# read it left to right:
# v=spf1 -> this is an SPF record, version 1
# include:resend.net -> the provider's servers are allowed
# ~all -> everyone else: soft-fail (flag, don't reject)Dashboard của provider đưa bạn giá trị include chính xác để dán. '-all' là biến thể chặt hơn: từ chối cứng mọi người không có trong danh sách.
Khi thông điệp của bạn tới server người nhận, nó chạy chuỗi này — mỗi bước đều đọc DNS của DOMAIN BẠN.
Mail server người nhận nhận thư từ IP của provider — và bắt đầu kiểm tra các tuyên bố bên trong.
Tra DNS domain bạn: server gửi này có trong danh sách khách không? Pass hay fail, được ghi lại.
Tra record selector của bạn trong DNS, rồi xác minh chữ ký. Thông điệp này thật sự do khóa của bạn ký, chưa bị sửa?
Kiểm tra pass và domain From: khớp — inbox. Trượt — chính sách DMARC của bạn bảo từ chối, cách ly, hay bỏ qua.
hai trong bốn bước là tra DNS trên DOMAIN CỦA BẠN — bạn đã biết cách làm phần đó rồi
Bỏ qua chi tiết tạo khóa; đây là cấu trúc quan trọng.
Provider tạo cặp khóa DKIM cho domain bạn và đưa bạn một record TXT để công bố (chẳng hạn dưới mail._domainkey.yourdomain.com). Đó là việc duy nhất của bạn.
Mỗi thông điệp rời mạng của họ mang header DKIM-Signature: bản băm của thông điệp, ký bằng khóa riêng của bạn. Bạn không bao giờ chạm vào khóa.
Người nhận đọc header chữ ký, lấy khóa công từ DNS của bạn, và kiểm tra: cùng thông điệp, cùng người gửi. Sửa bất cứ thứ gì là vỡ.
SPF chỉ kiểm tra server NÀO đã gửi. Nếu server đó bị chiếm hay bị lạm dụng, SPF vẫn pass. DKIM gắn chữ ký với NỘI DUNG — một ổ khóa khác.
DMARC thêm hai thứ: điều xảy ra khi thất bại, và ai báo cho bạn khi ai đó dùng sai domain của bạn.
Một record TXT tại _dmarc.yourdomain.com: v=DMARC1; p=none → p=quarantine → p=reject. Bạn bắt đầu ở none và siết dần khi SPF+DKIM ổn định.
DMARC chỉ tính pass nếu domain trong From: khớp domain được xác thực bởi SPF hoặc DKIM. 'Gửi qua đối tác, mang thương hiệu của tôi' chính là thứ nó kiểm soát.
Chỉ rua= vào một hộp thư và provider inbox sẽ gửi bạn tóm tắt hằng ngày về ai đã gửi mang domain của bạn — kể cả kẻ tấn công mà bạn chưa từng cấp phép.
Các tập đoàn lớn chạy p=reject: bất kỳ thứ nào không xác thực mạo danh domain của họ sẽ bị xóa ngay tại cổng. Đó là lời tuyên bố chống phishing mạnh nhất một domain có thể làm.
Ba record, ba câu hỏi, ba đáp án — tất cả trong panel DNS của chính bạn.
| Record | Nằm ở | Trả lời | Ẩn dụ |
|---|---|---|---|
| SPF | @ (the domain) | Server nào được phép gửi mang tên tôi? | danh sách khách |
| DKIM | selector._domainkey | Tôi có thật sự ký thông điệp này không? | con dấu sáp |
| DMARC | _dmarc | Làm gì khi câu chuyện không khớp? | quy tắc của nhà |
Ba lần tra, ba đáp án. Nếu cả ba đều trả về, domain của bạn được phép gửi mail mà inbox chấp nhận.
Từ con số 0 tới 'app của tôi gửi email thật': năm bước, một panel DNS, và vài thói quen giữ mối quan hệ hộp thư khỏe mạnh.
Cả bài học, nén lại thành những gì bạn thực sự bấm và dán.
Domain bạn điều khiển (đã mua cho site — nó kiêm cả danh tính mail). Bạn sẽ thêm record vào panel DNS của nó.
Chọn một cái (bảng ở Phần 1), xác minh domain với họ, và lấy API key. Dashboard lúc này hiện đúng các record DNS cần thêm.
SPF (include provider), DKIM (dán TXT của họ), DMARC (bắt đầu p=none). Lưu, rồi chờ DNS ổn định — vài phút tới một ngày.
Gọi API một lần tới một inbox thật do bạn kiểm soát. Xem nó tới inbox chính — không phải spam — và provider đánh dấu đã chuyển phát.
Chỉ webhook của provider về app của bạn, để bounce và khiếu nại tự cập nhật danh sách người dùng. Giờ email là một tính năng, không phải cầu may.
Mọi thứ dashboard provider yêu cầu thêm, trong một khung nhìn. Giá trị chỉ mang tính minh họa — của bạn sẽ là chuỗi khác.
# your domain's DNS panel — the shippable-email set
name type value
@ TXT v=spf1 include:resend.net ~all
mail._domainkey TXT v=DKIM1; k=rsa; p=MIIBIjANBgkq...QIDAQAB
_dmarc TXT v=DMARC1; p=none; rua=mailto:dmarc@example.comSPF nói ai được gửi. DKIM nói cách xác minh chữ ký. DMARC nói làm gì khi thất bại. Thêm cả ba ngay ngày đầu.
Những lựa chọn nhỏ lúc gửi quyết định domain của bạn có giữ được tiếng tốt không.
Gửi từ 'Acme App <noreply@…>' với Reply-To trỏ vào hộp thư hỗ trợ thật. Địa chỉ noreply mà vẫn nhận reply làm phiền người dùng; Reply-To sửa được.
Khi phát triển, thêm địa chỉ của bạn vào BCC để xem chính xác thứ người dùng nhận — tiêu đề, nội dung, link, tất cả.
Sự kiện ít cấp bách (người theo dõi mới, 3 lượt nhắc) gộp thành một bản tin hằng ngày. Ít email hơn, lớn hơn, nhẹ hơn với inbox — và với deliverability.
Giữ marketing ở subdomain riêng (chẳng hạn mail.example.com) để một đợt quảng cáo tệ không kéo tụt uy tín email transactional của bạn theo.
Gmail rất hợp để ĐỌC mail. Nó là công cụ sai để GỬI mail sản phẩm ở quy mô lớn.
| Provider transactional | Gmail / Outlook | |
|---|---|---|
| Dành cho | do app kích hoạt, một-đối-một, cấp bách | con người, hội thoại, lượng thấp |
| Gửi | API + khối lượng gần như không giới hạn trong fair use | thủ công, giới hạn ~500/ngày, không có API |
| Uy tín & xác thực | IP được quản lý, công cụ SPF/DKIM/DMARC, tỷ lệ vào inbox | trách nhiệm của bạn, không có công cụ |
| Phản hồi | bounce, click, khiếu nại qua webhook | không ai báo cho bạn bất cứ điều gì |
Toàn bộ hệ thống hiện đại, nhìn từ góc của bạn: bạn công bố niềm tin trong DNS, bạn viết thông điệp trong code, provider lo phần còn lại.
SPF + DKIM + DMARC trong DNS của nó: các quy tắc công khai để inbox tin thư mang tên bạn.
Một lời gọi xác thực từ app của bạn. Chuyển phát, ký, thử lại và uy tín IP là công việc được trả tiền của provider.
Đã chuyển phát, bounce, bị khiếu nại — kết quả quay về app của bạn, giúp danh sách người dùng luôn chính xác.
đặt lại mật khẩu, hóa đơn và thông báo giờ ship cùng app — giống mọi sản phẩm bạn đang dùng
Cài ba record, làm một lời gọi API — và app của bạn gửi email thật mà thực sự đến nơi, cùng vòng phản hồi giúp nó luôn chính xác.
Thêm SPF, DKIM, DMARC vào domain, gọi provider một lần, nối webhook — rồi đi xây tính năng gửi thư.