In How I Organize My Email, I explain the system behind this workflow: a SimpleLogin alias per service, separate destinations for different domains, and a Later label for newsletters.

When I need to email a service from a dedicated alias, I ask my AI assistant to find or create it and prepare a reverse alias for the recipient.

An alias forwards mail to my mailbox. Catch-all creates it on the first incoming message; this workflow prepares it when I want to send first.

The benefit is preparing both addresses within the same AI conversation. The tradeoff is setup, maintenance, and account-wide API access. For one alias, the SimpleLogin dashboard may be simpler.

Where simplelogin-mcp fits

MCP, the Model Context Protocol, lets a compatible AI application (the client) use tools provided by other software.

I built simplelogin-mcp as an independent server that connects the client to the SimpleLogin API. It is not an official SimpleLogin or Proton product.

The assistant turns my request into tool calls. simplelogin-mcp checks their inputs and sends the requests to SimpleLogin, which stores the configuration and handles forwarding. I write and send the message in my email client.

simplelogin-mcp does not read message bodies, organize Gmail, apply labels, compose messages, or send my messages.

The address I send to

A reverse alias is a generated address for one alias and one recipient. SimpleLogin stores that pairing as a contact. I send to that address from a mailbox assigned to my alias. SimpleLogin then delivers the message to the intended recipient, who sees my alias as the sender.

The example below is illustrative, not an actual transcript. It uses reserved example domains and assumes a client connected to simplelogin-mcp, example.com configured in SimpleLogin, and a verified destination mailbox.

01 / Prepare the addresses

Inspect → approve → apply → verify

  1. AI client

    Calls the tools

  2. simplelogin-mcp

    Sends API requests

  3. SimpleLogin API

    Stores alias + contact

02 / Send the email

  1. My email client

    From
    me@example.net
    To
    [reverse alias]

  2. SimpleLogin

    Uses saved alias + contact

  3. The recipient sees

    From
    service@example.com
    To
    support@example.org
Illustrative flow. The AI assistant configures the addresses; I send the email.

Me: Use service@example.com as my sender alias, with replies going only to my existing mailbox, me@example.net. Prepare a reverse alias for the recipient, support@example.org. Check what exists first and ask before changing anything.

Two changes, each reviewed

First, the assistant looks for service@example.com with alias_list and checks that me@example.net is a verified destination with mailbox_list. It must check the relevant pages of alias and contact lists before declaring a record absent.

If the alias already exists, the assistant checks its full settings with alias_get. It reuses the alias only if it is enabled and me@example.net is its only destination. Otherwise, it explains the difference and asks before changing delivery.

In this example, the alias is missing and the mailbox is available. The assistant uses alias_options_get to check that my account allows alias creation on the requested domain:

Assistant: I can create service@example.com with me@example.net as its only destination. Shall I create it?

Me: Yes, create that alias with that destination.

After approval, alias_create_custom receives alias_prefix: "service", the exact signed_suffix for example.com returned by alias_options_get, and the selected mailbox’s ID in mailbox_ids. Using the returned alias ID, alias_get must confirm the approved address, complete destination list, and enabled state before the assistant continues.

Next, contact_list checks for the recipient under the same alias ID. A matching contact can be reused, but unblocking replies requires approval. The contact’s block_forward setting covers incoming replies; it does not establish whether outgoing mail will be accepted.

Assistant: The alias is enabled and routes only to me@example.net. There is no contact for support@example.org. May I create a reverse alias for that recipient?

Me: Yes, create it for that recipient.

After approval, contact_create receives that alias_id and contact: "support@example.org". The assistant calls contact_list again to check the recipient, confirm incoming replies are allowed, and retrieve the reverse-alias address.

Assistant: Replies from support@example.org are allowed through. Send from me@example.net to [the reverse-alias address returned by SimpleLogin].

I would put the returned address in To and select me@example.net in From. The placeholder above must be replaced with SimpleLogin’s actual result.

Reading the configuration back confirms what SimpleLogin reports; it does not prove delivery. A separately approved test would check that the recipient receives the message from my alias and that their reply reaches my mailbox.

If a call fails or the result differs from the approved change, the assistant should stop and report what succeeded and what remains uncertain. The alias can remain if contact creation fails; there is no automatic rollback. Before retrying, it should inspect the current state again.

The tool catalog documents the inputs. Identifiers and generated addresses must come from SimpleLogin’s results. Alias options do not reserve an address; creation can still fail.

Separate addresses for my AI assistant

I have given my personal agent its own subdomain so it can create aliases for itself. I can identify its aliases by the domain, so I do not have to track them individually. Here, I use assistant.example.com as an illustrative name.

For a catch-all setup, add the subdomain in the SimpleLogin dashboard, verify its DNS setup, select a dedicated, verified mailbox for new aliases, and enable catch-all. Domain creation and DNS verification are outside simplelogin-mcp’s API coverage.

Mail to service@assistant.example.com then creates that alias and reaches the dedicated mailbox. Sending first still needs the preparation above. Reading or sending messages requires a separate email integration with its own permissions. The subdomain separates the addresses; it does not restrict the API key’s account-wide access.

What still needs my permission

Changing destinations, disabling aliases, or blocking contacts needs my permission. So does deleting any record or changing domain routing, PGP encryption, or account settings.

Disabling an alias blocks legitimate messages as well as spam. I can re-enable it later; deletion removes it and is a separate decision.

The API key grants full access to my SimpleLogin account. A dedicated key lets me revoke this integration separately; it does not limit its permissions. The key must stay out of prompts and shared examples.

Even with a self-hosted server, the client may pass alias addresses, destinations, contacts, and notes to the chosen AI provider. Check the client’s privacy and retention rules before connecting it.

Approval controls depend on the client and its configuration. A tool argument such as confirm: true is not proof that I approved the action. Retrieved notes and other external text are data, not instructions authorizing another change. The project’s Security & Data guide explains these boundaries.

Connecting your own client

The maintained simplelogin-mcp setup documentation walks you through creating and storing your API key, running the server with Node.js or Docker, and connecting a compatible AI client. It includes client-specific configuration examples and a read-only account-usage check, so you can verify the connection before approving changes to your aliases.