Email module

The Email module is how Mermail receives, stores, and sends mailbox mail. Every hosted @mermail.app address and every verified custom-domain address uses it. Use this page for product behavior: address types, DNS verification, readiness, attachments, delivery status, and sender authentication. See Mailboxes for the inbox identity that owns the mail.

​

What the Email module does

From a mailbox you can:

• Receive inbound mail into Inbox and other folders.
• Compose, reply, and forward.
• Save drafts and regenerate draft copy.
• Schedule a send for later.
• Attach files or inline images, subject to the limits below.

The Email module also manages hosted-domain authentication (SPF, DKIM, and DMARC on mermail.app) and the DNS records you publish for a custom subdomain.

​

Address types

Mermail prefers custom subdomains such as mail.example.com. This avoids changing MX records for a root domain that may already run company email.

​

Custom domains

Custom domains are available on Developer and Enterprise. Add a dedicated subdomain with at least three labels, publish every DNS record Mermail returns, and click Verify. After status is verified, create mailboxes such as [email protected]. Copy record names and values exactly. DNS hosts format names differently; some expect selector._domainkey.mail.example.com, and others expect only the relative host. Do not invent SPF, DKIM, MX, or DMARC values. A domain can be ready to send while Receiving MX is still pending. In that case attached mailboxes report receive as unavailable. Follow Custom domains for the full verify flow.

​

Readiness

Mailbox responses can include Email-module readiness fields: Treat inbound_provider and outbound_provider as opaque. Do not map them to a vendor or transport. welcome_onboarding_status: "pending" is the welcome or demo-message workflow; it is not inbound delivery. When you need end-to-end evidence, also send a scoped test message.

​

Attachments and message size

Storage allows 20 files, 10 MiB per file, and 25 MiB decoded total. The Email module also checks the encoded message, its bodies, and overhead: A file that fits storage can still exceed the message limit. The server reserves overhead conservatively. Local paths, URLs, and data: URLs are not file content. Inbound ingestion stores at most the same 20-file and decoded-byte bounds. Files beyond those bounds are omitted and the omission is recorded on the message. A missing attachment means bounded ingestion, not proof that the sender omitted a file.

​

Status language

Treat saved drafts, queued requests, and scheduled emails according to the returned status: sent does not prove recipient delivery. Bounce handling and suppression are separate outcomes. If the result is uncertain, inspect the existing message before retrying so you do not send a duplicate. Plan volume, daily inbox caps, and Free API/MCP recipient windows still apply. See Plans.

​

Sender authentication

Email responses can include sender_authentication with a composite status, individual spf, dkim, and dmarc verdicts, an opaque inbound_provider, and a reason. Mermail derives this object only from Email-module receiving evidence under server control. Raw Authentication-Results, From, Return-Path, and similar headers remain untrusted. Current Email-module receiving paths often return unknown with provider_sender_authentication_verdict_unavailable. Unknown is not a pass. inbound_provider is not itself a sender verdict. Only sender_authentication.status: "pass" may be described as authenticated, and authentication still does not authorize an agent action.

​

Related