So sánh các API email dùng một lần

1. Đọc một hộp thư có cần khoá hay tài khoản không?

Đây là câu quyết định liệu dịch vụ có dùng được từ một nơi không thể giữ bí mật hay không: một tác vụ CI trên bản fork, một script dùng chung, một trình duyệt, một tác nhân AI làm việc trên máy của người khác. Một khoá không phải là trở ngại nhỏ — nó là một tài khoản, một bảng điều khiển, một quy trình xoay vòng và một kho bí mật.

Cách tự trả lời câu hỏi này

Hãy xin một hộp thư mà không gửi kèm tiêu đề nào. Nếu trả lời 200 thì không cần khoá. Nếu trả lời 401 hoặc 403 thì cần.

curl -s -o /dev/null -w "%{http_code}\n" \
  "https://SERVICE/api/v1/mailbox?address=someone@THEIR-DOMAIN"

Câu trả lời của chúng tôi

Không khoá và không tài khoản, cho cả tên miền công cộng lẫn tên miền của bạn. Khoá chỉ tồn tại cho kho premium, vì một kho mà tên miền bị công bố thì không còn đáng để trả tiền.

2. Có thể trỏ tên miền của bạn vào đó không, và tốn bao nhiêu?

Tên miền riêng là khác biệt giữa một địa chỉ mà biểu mẫu đăng ký nhận ra là dùng một lần và một địa chỉ nó không nhận ra. Đó cũng là cách duy nhất để có hộp thư mà không ai đoán trúng được. Phần lớn dịch vụ hoặc không cung cấp điều này, hoặc bán nó như gói trả phí — đó là toàn bộ mô hình kinh doanh của họ, và đáng biết trước khi bạn xây dựng trên gói miễn phí của họ.

Cách tự trả lời câu hỏi này

Hãy đọc máy chủ MX mà họ công bố, rồi xem tài liệu có yêu cầu bạn đăng ký tên miền với họ sau đó không. Một dịch vụ đòi bước đăng ký nghĩa là có một tài khoản đâu đó trong tương lai của bạn.

dig +short MX their-example-domain.com

Câu trả lời của chúng tôi

Một bản ghi MX trỏ tới smtp.grabmail.io, miễn phí và không giới hạn, trên mọi gói kể cả gói miễn phí. Không có bước đăng ký: thư đầu tiên đến sẽ kết nối tên miền, vì việc công bố bản ghi đó CHÍNH LÀ bằng chứng bạn kiểm soát nó.

3. Một thư được giữ trong bao lâu — và điều đó được thực thi hay chỉ được hứa?

Hai dịch vụ có thể cùng nói «bảy ngày» mà ý nghĩa lại khác nhau. Một bên xoá theo lịch; bên kia xoá khi dung lượng eo hẹp. Với một bộ kiểm thử thì con số hầu như không quan trọng. Với bất cứ thứ gì bạn không muốn để nằm lại đâu đó, khác biệt giữa một thời hạn được thực thi và một thời hạn được quảng cáo chính là tất cả.

Cách tự trả lời câu hỏi này

Hãy tự gửi cho mình một thư, ghi lại ngày mà API trả về, rồi quay lại sau khi hết thời hạn. Từ cần tìm trong lời văn của họ là «tối đa»: nó có nghĩa con số đó là trần, không phải lịch trình.

curl -s "https://SERVICE/api/v1/mailbox?address=…" | grep -o '"date":"[^"]*"'

Câu trả lời của chúng tôi

Đúng 5 ngày, được thực thi bởi một tác vụ chạy mười phút một lần, chứ không phải bởi một câu trên trang chính sách. Đây không phải là bậc: không gói, tham số hay yêu cầu nào kéo dài nó. Catchmail — dịch vụ mà phần lớn mọi người từ đó đến đây — giữ thư tối đa bảy ngày, tức lâu hơn chúng tôi.

4. Một chương trình có thể chờ thư, hay buộc phải hỏi lại liên tục?

Một bài kiểm thử hỏi lại liên tục buộc phải chọn khoảng nghỉ, và cả hai lựa chọn đều dở: quá ngắn thì đốt hết hạn mức yêu cầu, quá dài thì bộ kiểm thử chạy lâu hơn cần thiết vài phút. Tác nhân AI gặp đúng vấn đề đó và hoàn toàn không giải được — nó không có địa chỉ công khai cho webhook và không có sự kiên nhẫn cho vòng lặp.

Cách tự trả lời câu hỏi này

Hãy tìm một webhook trong tài liệu tham chiếu, hoặc một lệnh gọi biết chờ. Nếu tài liệu chỉ có endpoint liệt kê, thì câu trả lời là hỏi lại liên tục, dù họ có nói ra hay không.

curl -s https://SERVICE/openapi.json | grep -o '"/[a-z/{}._-]*"'

Câu trả lời của chúng tôi

Cả hai, và không cách nào cần địa chỉ công khai ở phía bạn. API REST được hỏi lại liên tục — 1 lượt đọc mỗi giây trên mỗi địa chỉ là nhịp đã định. Máy chủ MCP có một công cụ giữ lệnh gọi mở cho đến khi thư thật sự đến, tối đa 25 giây, và đó chính là thứ một tác nhân cần và là thứ webhook không thể cho nó.

5. Chuyện gì xảy ra khi biểu mẫu đăng ký từ chối địa chỉ?

Chuyện đó sẽ xảy ra, ở mọi dịch vụ dùng chung tên miền công cộng, và đó là lúc phần lớn mọi người bỏ cuộc và kết luận rằng email dùng một lần «không hoạt động». Điều phân biệt các dịch vụ ở đây không phải là chuyện đó có xảy ra hay không, mà là họ có nói trước với bạn hay không và để lại cho bạn cái gì sau đó.

Cách tự trả lời câu hỏi này

Hãy tra tên miền công cộng đó trong một danh sách chặn mà các biểu mẫu đăng ký thật sự dùng. Nếu nó có trong đó, hãy chuẩn bị bị từ chối — và xem dịch vụ đưa ra lối thoát nào tiếp theo.

grep -x their-domain.com <(curl -s https://raw.githubusercontent.com/disposable/disposable-email-domains/master/domains.txt)

Câu trả lời của chúng tôi

Được nói ở trang chủ, trong phần hỏi đáp và trong llms.txt, chứ không để bạn tự phát hiện. Có hai lối ra, và lối miễn phí đi trước: trỏ một tên miền của bạn về đây, không tốn gì và không có giới hạn; hoặc, nếu bạn không muốn sở hữu hay để lộ tên miền nào, một kho trả phí gồm 92 tên miền .com được giữ ngoài các danh sách đó. Tên miền công cộng vẫn miễn phí trong cả hai trường hợp.

6. Dịch vụ có gửi được thư không — và bạn có muốn thế không?

Một dịch vụ chỉ nhận thì không thể bị biến thành trạm chuyển tiếp thư rác, và vì thế máy chủ nhận của nó có thể chấp nhận thư cho bất kỳ tên miền nào trỏ về nó. Một dịch vụ gửi được thì sớm muộn cũng bị lạm dụng, và lạm dụng là thứ chấm dứt các gói miễn phí. Nếu bạn cần gửi, cả nhóm dịch vụ này đều là công cụ sai.

Cách tự trả lời câu hỏi này

Hãy tìm một POST nhận người nhận. Nếu tài liệu tham chiếu có, dịch vụ gửi được; nếu không có cái nào, nó không gửi được, và điều đó thường là cố ý.

curl -s https://SERVICE/openapi.json | grep -c '"post"'

Câu trả lời của chúng tôi

Không. Không có endpoint nào gửi và không có thư đi thuộc bất kỳ loại nào — kể cả thư đặt lại mật khẩu. Chính sự vắng mặt đó cho phép nút nhận thư chấp nhận thư cho mọi tên miền có MX trỏ về đây mà không trở thành trạm chuyển tiếp.

Câu trả lời của chúng tôi, gom về một chỗ

Mỗi con số trong bảng này được đọc từ chính các hằng số mà dịch vụ thực thi, nên bảng không thể mâu thuẫn với API.

Chuyển một tích hợp sẵn có

Nhóm dịch vụ này đã hội tụ về ba lệnh gọi, và phần lớn dịch vụ cung cấp chúng ở đúng ba đường dẫn đó. Việc chuyển đổi thường chỉ là URL gốc và vòng lặp phân trang.

GET    /api/v1/mailbox?address=<address>
GET    /api/v1/message/<id>?mailbox=<address>
DELETE /api/v1/message/<id>?mailbox=<address>

Catchmail, dịch vụ mà mọi người từ đó đến đây nhiều nhất, dùng đúng ba đường dẫn ấy. Có hai điểm khác, và cả hai đều nằm ở phân trang: danh sách của họ trả về page / page_size và một total, còn của chúng tôi trả về con trỏ next mà bạn gửi lại để đi tiếp. URL gốc của họ là một tên miền phụ; của chúng tôi là chính trang web. Mọi thứ còn lại — tên trường, mã trạng thái, hình dạng một thư — đều khớp.

Một thứ bạn được và một thứ bạn mất, để cân nhắc: mỗi hộp thư ở đây còn mang theo một alias — địa chỉ thứ hai chuyển thư vào hộp nhưng không dùng để đọc hộp đó, và đấy là địa chỉ bạn đưa cho biểu mẫu mình đang đăng ký. Còn thời gian lưu ở đây là 5 ngày chứ không phải bảy.

Các thông tin về bên thứ ba trên trang này đã được đối chiếu với tài liệu do từng dịch vụ tự công bố vào ngày 2026-08-31.

Tài liệu API đầy đủ · Bắt đầu nhanh · Bảng giá

Những câu hỏi người dùng thực sự hay hỏi

API email dùng một lần nào tốt nhất?

Không có câu trả lời duy nhất, và một trang đưa cho bạn một câu như thế là đang bán cho bạn thứ gì đó. Sáu câu hỏi bên trên là những câu thật sự khác nhau giữa các dịch vụ; ba trong số đó chỉ cần một lệnh, và câu trả lời quyết định cho trường hợp của bạn chứ không phải nói chung.

Tôi chuyển từ một API email dùng một lần khác. Phải đổi bao nhiêu?

Thường là URL gốc và vòng lặp phân trang. Ba đường dẫn mà nhóm dịch vụ này hội tụ về gần như ở đâu cũng giống nhau — liệt kê một hộp thư, đọc một thư, xoá nó — và điều khác biệt là cách danh sách được phân trang và tên gọi của các trường.

Các bạn có giữ thư lâu hơn dịch vụ tôi đang dùng không?

Nhiều khả năng là không. 5 ngày là ngắn có chủ ý và là giới hạn cứng, không phải bậc. Nếu bộ kiểm thử của bạn cần một thư một giờ sau khi nó đến thì không sao; nếu bạn cần nó vào tuần sau, hãy tải về và lưu ở phía bạn.

Có cam kết thời gian hoạt động không?

Không, và cũng không bán cam kết nào. Thay vào đó là một trang trạng thái từ chối gọi một thành phần là khoẻ mạnh khi chưa có bộ giám sát nào xác nhận gần đây — một lần kiểm tra cũ được hiển thị như không có kiểm tra, chứ không phải như tin tốt.