Agent Emailing: email providers

Required

What a provider must support

1. Send an attachment unchanged

The sender chooses the attachment's media type and filename, and the bytes arrive unchanged after decoding.

Section 11.2
2. Deliver an attachment unchanged

The receiving side can get the attachment's exact bytes, from the raw message or as an attachment download.

Section 11.2
3. Sign with DKIM aligned to the sender's domain

Every message is DKIM-signed with the signing domain aligned to the From domain. A domain the provider manages is enough.

Sections 6.4 and 11.2

Recommended

What a provider should support

Push delivery of inbound mail: a webhook, a websocket, server-sent events, or IMAP IDLE. Polling works, but it adds delay.
At-least-once delivery with a stable event identifier, so a receiver can tell a retry from a new email.
Inbound authentication results: SPF, each DKIM signature with its domain and result, and DMARC with alignment. Bridged mode needs these.
Threading fields on sending, or a reply operation that sets them, so people see one thread.
Custom headers, at least Auto-Submitted, then the optional hint headers.
A custom sending domain, so an organization can send from its own domain.
Delivery status reporting for bounces and deferrals.
Keeping inbound mail for at least seven days, the mailbox window.
Leaving the text part unchanged, with no added footer or banner. Software that checks the human part warns when the text was changed.

Kinds of provider

Which kinds of provider meet it

This table describes kinds of provider, not products. The names in the last column are examples for reference, linked to their own documentation. They are not recommendations.

usually
varies
rarely

Kind	Required items	Push delivery	Authentication results	Custom headers	Examples
Inbox services built for agentsAn inbox per agent, created through an interface.	usually	usually webhooks, websockets or server-sent events	varies	varies from any header to a short list	AgentMail, Primitive, Nylas Agent Accounts, Mailtrap, Hostinger Agentic Mail, Robotomail
Sending services that also receiveBuilt for application mail, with an inbound feature.	usually	usually webhooks	varies	usually	Resend, Mailgun, Postmark, SendGrid
Cloud mail infrastructureRaw sending and receiving that you assemble yourself.	usually	usually notifications to your code	usually	usually, though some set their own Message-ID	Amazon SES
Mail routed to code at the network edgeInbound mail runs a function you write.	usually	usually the function runs for each message	varies	varies	Cloudflare Email Service
A person's own mailbox, through an interfaceThe agent uses a mailbox a person already has.	usually	usually	varies	usually	Gmail API, with low daily sending limits (500 a day for a personal account, 2,000 for a work account) and agent mail mixed into a person's own
A mail server you runYour own SMTP and IMAP servers.	usually	usually IMAP IDLE	usually	usually	Any standard mail server. You keep its reputation and deliverability yourself.

From their documentation

What some providers document today

Each entry below says what the provider's public documentation said on 29 October 2026, with a link to it. Providers change, so check their documentation before relying on an entry. Every provider listed here documents the first two required items. Check how each one signs mail from your domain with DKIM in its own documentation. The list is in alphabetical order.

Provider	Attachments	Exact bytes on receipt	Push delivery	Custom headers	Notes
AgentMail	Chosen content type; 6 MB per request inline, 10 MB per message over SMTP	The raw message by download link	Signed webhooks, websockets, IMAP IDLE	A `headers` map on sending	Inbound messages carry SPF, DKIM and DMARC results. Custom domains on paid plans.
Amazon SES	You build the raw message	The raw message, stored to S3	Notifications to your code	Yes, in the raw message	Sets its own Message-ID and Date (documentation), which section 3.6 allows for.
Cloudflare Email Service	Raw message on reply, or SMTP	The raw message in a Worker	A Worker runs for each message	In a raw reply; forwarding adds only `X-` headers	Outbound messages up to 5 MiB, inbound up to 25 MiB (limits).
Mailgun	Yes	The raw message, posted by a route	Routes post to your URL	Parameters that start with `h:`	Sends from your own domain.
Nylas Agent Accounts	Yes, or a raw message	The raw message on request	Webhooks	`custom_headers` on sending	A hosted inbox per agent, on a Nylas domain or your own (product page).
Primitive	Chosen content type; up to 100 files and 30 MiB	The raw message, with a SHA-256 for it and for each attachment	Signed webhooks, hosted functions	Only `Auto-Submitted`, `X-Auto-Response-Suppress` and `Precedence`	Detailed SPF, DKIM and DMARC results. New agent accounts start able to reply only. Custom domains.
Resend	Yes, up to 40 MB per email	The raw message by download link	Webhooks, with the content fetched afterwards	A `headers` object on sending	Sends from your own domain.

Not yet checked against their documentation: Hostinger Agentic Mail, Mailtrap, Postmark, Robotomail, SendGrid, and smaller inbox services.

For builders

One adapter per provider

A bridge, or an agent's runtime, that should work with any provider puts a small adapter in front of each one. The adapter turns the provider's interface into four operations: say what the provider supports, send one email, receive inbound mail, and report a sent email's delivery status. It never changes the bytes of the envelope or of a file.

The full interface is in section 11.4 of the specification.

Test a provider

The conformance fixtures

The fixtures are email files with really signed envelopes, and a list of cases that says what each one must produce. The keys are published test keys and control nothing.

cases.json: the nineteen cases, the test keys, and the canonical form of the four envelopes of the thread. cards.json: the test name cards.
01-request.eml, 02-respond-input.eml, 03-request-answer.eml and 04-respond-done.eml: a four-email thread, each with a human part generated from its envelope.
05-forwarded.eml, 06-stale.eml, 07-tampered.eml: refused silently.
08-hint-mismatch.eml: headers that disagree with the envelope, which the receiver ignores.
09-file-digest.eml: a file that does not match its digest.
10-two-envelopes.eml, 11-auto-reply.eml, 12-stranger.eml: never handed to the agent.
13-reencoded.eml: the envelope re-encoded and re-laid out, which must still verify.
14-bounce.eml: a bounce for the request.
15-bridged-plain.eml: plain email from a person, for a bridge.
16-text-mismatch.eml: a human part that disagrees with its envelope. The agent acts on the envelope; software that shows the text to a person warns.
17-forged.eml: a forgery whose signature, sender and text all fail. The agent refuses it; software that shows it to a person shows that it failed.

The carrier test

A provider passes when it carries 01-request.eml from one of its addresses to another, and the receiving side recovers an envelope whose canonical form equals the one in cases.json, an agenda.txt whose SHA-256 equals the one listed there, and a text part whose digest equals the one the envelope signs. The sending side may rebuild the email through the provider's own interface, as long as it attaches the envelope and the file unchanged and leaves the text unchanged.

The reference checker

check-fixtures.mjs is a small reference receiver. Download the conformance folder, with lib.mjs and mail.mjs beside it, and run it with Node.js 20 or later. It needs nothing else installed.

node conformance/check-fixtures.mjs
# pass  e01  01-request.eml
# ...
# all 19 cases pass