Mail.tm already gives developers a strong free API: REST with an OpenAPI definition, server-sent events (SSE), HTML and raw message source, attachments, and a published 8 queries-per-second limit. Relay does not replace those strengths. Its narrower distinction is an official MCP server, scoped revocable keys, and bring-your-own-domain support.
For an AI agent or test platform, the decision should turn on integration and control rather than a universal feature ranking. Mail.tm can be the better API mailbox; Relay can be the better managed agent surface. This review of official documentation was completed October 28, 2026.
The useful comparison is narrower than a feature count
Relay exposes list_domains, list_inboxes, create_inbox, list_messages, and read_message through its remote MCP endpoint at /api/mcp. That allows a compatible agent to discover and invoke mailbox operations without a custom tool wrapper. Its REST API under /api/v1 remains available for conventional services. The Relay MCP documentation explains the agent-facing model.
Mail.tm instead documents account creation, password-based token acquisition, message operations, attachments, and real-time listening through REST and SSE. No official MCP integration was found in the reviewed sources. An agent can still use Mail.tm through generated or hand-written tools, but the developer owns that adaptation layer. In return, Mail.tm supplies capabilities Relay does not currently match, especially SSE and raw source.
Detailed feature comparison
| Capability | Relay | Mail.tm | What the documentation supports |
|---|---|---|---|
| Official MCP server | Yes, remote /api/mcp |
Not documented | Relay has the native MCP distinction |
| HTTP API | REST /api/v1 |
Free REST API at api.mail.tm with OpenAPI v3 |
Both have documented HTTP automation |
| API authentication | Scoped, revocable Bearer keys | Bearer token obtained using generated address and password; no separate API key | Relay documents scoped key administration |
| Inbox lifecycle | No fixed inbox expiry | Mailbox remains until deleted; messages stored for seven days | Both can retain an address, with different message-retention claims |
| Bring your own domain | NS or MX; public or private domain options | User BYOD not documented; API lists service domains | Relay supports customer-controlled DNS |
| Attachment API | Yes | Yes, with attachment metadata and download documentation | Both support programmatic attachment workflows |
| HTML and raw source | Sanitized HTML message reading | HTML field plus GET /sources/{id} raw source |
Mail.tm is stronger for original-source inspection |
| Real-time events | No SSE or webhooks | SSE for new-message listening; webhooks not documented | Mail.tm has a concrete event-stream advantage |
| Sending and reply | Neither currently provided | Official FAQ explicitly says sending is not provided | Both reviewed services are inbound-oriented |
| Price and published limit | No numerical comparison invented here | Free, no paid API tiers; 8 QPS per IP | Mail.tm publishes unusually clear access terms |
A “yes” for token access does not mean identical authorization. Mail.tm documents bearer tokens derived from mailbox credentials; Relay specifically documents scoped, revocable API keys. Likewise, a persistent mailbox is not seven-day message retention: address lifetime and message lifetime must be evaluated separately.
REST, OpenAPI, SSE, and MCP lead to different agents
A Mail.tm integration begins by creating an account through the API and requesting a bearer token with the address and generated password. The OpenAPI document makes the service approachable for client generation, while SSE lets a worker react when mail arrives instead of maintaining only a polling loop. Message resources expose HTML and attachment metadata, and /sources/{id} retrieves the original source for lower-level analysis. Its documented API model is substantial, not a secondary afterthought.
Relay's MCP path moves the integration boundary upward. Instead of teaching an agent each HTTP schema, a developer connects the client to MCP and exposes the named inbox and message tools. Scoped keys make it easier to align a credential with a specific integration and revoke it later. Account ownership and guest inbox passwords provide explicit access models. For services that do not use MCP, the Relay REST API supplies the conventional route.
The trade-off is important: Relay has no official SDKs, webhooks, or SSE. Mail.tm has no official SDKs found in the reviewed sources, but its OpenAPI and SSE support are real advantages. Relay also lacks dedicated OTP extraction and raw-source retrieval is not claimed here. An MCP client may reason about a message to find a code, but that is not a specialized OTP API.
Domain ownership and lifecycle are separate decisions
Relay supports connecting a domain through nameserver delegation or MX routing. Public domains become available for shared use after verification, while private domains belong to the connecting user. That distinction lets a team choose between intentional shared availability and a controlled testing namespace. Review the domain options before changing production DNS.
Mail.tm's API exposes domains operated by the service, and its FAQ says those domains are renewed. A user-controlled custom-domain or BYOD capability was not found in the reviewed official sources. That is not proof no such option could ever exist; it means Relay has the clearer current documentation for organizations that require their own namespace.
Mail.tm says a mailbox remains until the user deletes it, while messages are stored for seven days only. Relay has no fixed inbox expiry, which supports a stable test identity, but this article does not convert that fact into an unsupported promise of indefinite message storage. In both systems, plan retention at the address and message levels independently.
Privacy, access, and acceptable use
Mail.tm creates a mailbox password and uses it to obtain the API token. Its FAQ says password reset is unavailable, so losing the credential can mean losing practical access. Its privacy policy says no IP address is stored, mailbox access is limited to the user for its lifetime, and temporarily stored email and data are permanently deleted. The policy also describes cookies and third-party advertising through Freestar, so “no personal details required” should not be read as “no data processing.”
Relay's scoped keys, guest passwords, and account ownership give developers more explicit administrative controls to map onto their own environments. Sanitized HTML is useful when rendering external content, though it does not make links or attachments trustworthy. Neither service should receive production secrets merely because an inbox is access-controlled.
Mail.tm's API policy also prohibits illegal activity, paid products that merely wrap the API, and mirroring or proxying it under another domain. Visible attribution and a link back to Mail.tm are required. Those conditions matter for developer products, not just individual test scripts.
Free access and concrete limits
Mail.tm says every user receives full access and can create unlimited new disposable addresses at no cost. Its API documentation separately says “completely free,” with no API key, signup barrier, or paid tiers. The documented request ceiling is 8 QPS per IP address. This is a published rate limit, not a promise of deliverability, availability, or unlimited total message volume.
No numerical Relay quota or price is inferred from Mail.tm's material. Teams comparing operational cost should inspect their current Relay account and implementation needs rather than treating “free” as the only cost: MCP adaptation, event handling, DNS administration, and credential management all affect engineering effort.
Verdict by developer workflow
Relay is better for MCP-native, domain-controlled testing
Choose Relay when an MCP-compatible agent should manage inboxes directly, when scoped and revocable keys are a requirement, or when test identities must use your own public or private domain. Its attachment API and stable inbox lifecycle fit controlled QA fixtures. The documentation is the best place to validate the required ownership model before implementation.
Mail.tm is better for free REST, event streams, and raw source
Choose Mail.tm when budget-free OpenAPI access, SSE, raw MIME source, and a known 8 QPS ceiling matter more than native MCP or BYOD. It is particularly coherent for a lightweight worker that creates a mailbox, listens for a message, and inspects the original source. It is also the clearer choice when a free API with no paid tiers is a hard constraint.
Relay's missing send/reply means neither service wins an outbound-conversation test. Mail.tm explicitly does not provide sending, and no reply capability should be assumed. The verdict is deliberately split: Relay for controlled MCP and domains; Mail.tm for open REST, SSE, and source-level work.
Frequently asked questions
Is Relay's API more capable than Mail.tm's API overall?
No such blanket conclusion is supported. Mail.tm documents OpenAPI, SSE, raw source, HTML, attachments, and 8 QPS free access. Relay's documented advantages are narrower: official MCP tools, scoped revocable keys, BYOD, and its inbox lifecycle model.
Does Mail.tm keep mail forever if the mailbox persists?
No. Mail.tm distinguishes mailbox lifetime from message retention. The mailbox can remain until deleted, but the FAQ says incoming messages are stored for seven days only.
Can an AI agent use Mail.tm without an official MCP server?
Yes, through custom tools or generated API clients. OpenAPI can simplify that work. Relay reduces the adaptation required for MCP-compatible clients, but it does not make Mail.tm unusable by agents.
Sources and review notes
Reviewed October 28, 2026, against Mail.tm's official site, FAQ, API documentation, authentication guide, message reference, and privacy policy. No speed test, deliverability claim, uptime score, or invented usage data is included. Undocumented means not established by these sources, not proven unavailable.
- Mail.tm home — free access, disposable addresses, mailbox lifetime, and API availability.
- Mail.tm FAQ — seven-day message retention, registration, passwords, and no sending.
- Mail.tm API documentation — OpenAPI, SSE, free access, 8 QPS, attribution, and API restrictions.
- Mail.tm authentication — account credentials and bearer-token flow.
- Mail.tm message API — HTML, attachments, and raw-source retrieval.
- Mail.tm privacy policy — IP handling, deletion, cookies, and advertising.