Email agents
can act on.

Services already ask people to make decisions by email. Mail Action Protocol describes those requests so an agent or inbox can understand them, check the current proposal and help you act.

Mail Action Protocol · Working draft
From message to action

There’s work
in your inbox.

A campaign is ready to send. An article needs permission to go live. The request arrives in the email you already read, with a description an agent can understand.

01

A request arrives

The message identifies the service, what needs a decision and the choices available. A shared type says what each choice will do.

Campaign Send Approval · Exact terms
02

Your rules come first

A connection you approved reads the current proposal. A campaign send still needs your account permission. Your agent or inbox follows your rules and asks you when a decision needs approval.

Connected account · Current proposal · Your policy
03

The service checks again

The service checks the terms and your permission as it records the decision. A changed audience, revoked permission or earlier decision stops the action.

Same terms · Permission checked · Decision recorded
The specification
MAP↗
MAIL ACTION PROTOCOLWorking draft
Mail Action Protocol

Describe it once.

A type gives a decision the same meaning across services. Campaign approval names what will be sent, by whom, to which audience and when. Each service keeps its own interface and permissions.

MAP defines what the email says and what must be checked before anyone acts. A connection you approved uses the service's existing operations.

Read MAP
The service keeps its interface

An email.
Your existing service.

A request arrives by email. MAP says what the decision means. The service can keep its existing API, tool or messaging system, provided it can check permission and the exact proposal when the decision is made.

Explore the interface research
In the email

Publish this revision.

A proposal, its exact terms and the decisions you can make.

Type contractPublication ApprovalApprove · Decline · Request changes
At the hostTrusted binding

Read the current proposal. Check policy. Obtain confirmation when required.

What a binding establishes
At the serviceResearched interface families

Agents & tools

Use a connected service

The service checks permission and exact terms when it records the decision.

MAP can use existing service descriptions, account access and discovery. The interfaces shown here have been researched, not implemented as MAP integrations.

Explore the full research
MailSchema Types

A type gives the request its meaning.

Sending a campaign, publishing an article, confirming an address and reporting unfamiliar account activity are different decisions. Each type says exactly what its choices mean.

Try a decision

Follow a decision.

Review the campaign and its audience, then approve or decline. See what happens if the audience changes before your decision reaches the service.

Example inbox Interactive illustration
Example campaign serviceTo owner@example.net

Send product update

The product update is ready to send to the newsletter audience. Please review the email and approve this send.

Requested by
Campaign editor
Audience
4,210 newsletter subscribers
Timing
When approved
Inbox actionsservice.example

Read the current campaign through your connected account.

Inspect the exchange

The simulated service checks again when you decide. These cases run locally.

Local service model · TypeScript
Review the request, then choose an action to inspect the local call.

The service owns its request and result format. Inspect the worked HTTP and MCP exchanges →

Read the email's MAP description
{
  "@context": "https://mailschema.org/contexts/map-0.3.jsonld",
  "@type": "MailAction",
  "profile": "https://mailschema.org/profiles/map/0.3",
  "type": {
    "id": "https://mailschema.org/types/campaign-send-approval",
    "version": "0.1",
    "contractDigest": "sha-256:de3c88a0712adb1d0c6e82f437b825c83520d8e1c44c7b032a2cfcfe5ce55731"
  },
  "@id": "urn:uuid:0199a6c2-4b1e-7c3a-9d2e-5f8a1b2c3d40",
  "issuedAt": "2026-10-02T08:00:00Z",
  "expiresAt": "2026-10-03T08:00:00Z",
  "inLanguage": "en",
  "service": {
    "id": "https://service.example",
    "tenant": "urn:example:tenant:7"
  },
  "recipient": "owner@example.net",
  "subject": {
    "id": "urn:example:campaign:18",
    "title": "Send product update"
  },
  "terms": {
    "id": "urn:example:proposal:c18",
    "version": "c18-r2"
  },
  "human": {
    "url": "https://service.example/review/c18"
  },
  "details": {
    "summary": "The product update is ready to send to the newsletter audience. Please review the email and approve this send.",
    "requester": "Campaign editor",
    "content": {
      "id": "urn:example:content:18",
      "revision": "r2",
      "digest": "sha-256:86d8e5d2331a2c3bd211a71adb79149b644104ccbb7a4425b7ac5b26e94ef06d",
      "title": "Product update"
    },
    "sender": {
      "mailbox": "news@service.example",
      "name": "Service newsletter"
    },
    "audience": {
      "id": "urn:example:audience:9",
      "revision": "snapshot-3",
      "count": 4210,
      "label": "Newsletter subscribers"
    },
    "schedule": {
      "mode": "immediate"
    }
  },
  "operations": [
    {
      "id": "approve"
    },
    {
      "id": "decline"
    },
    {
      "id": "request-changes"
    }
  ]
}
Simulated inbox and service. No email is sent.How this type works
Contribute

Propose a type
for your workflow.

If your service asks people to decide something by email, show the request and what each choice does. A useful type should work for more than one service.

Prepare a type proposal