Email Automation for OpenClaw Using MailChannels

OpenClaw is popping up everywhere, and one of the most common requests people have is: "How do I get this thing to send email?" Fair question.

The typical approach — connecting a real Gmail inbox — is way overkill for most agent workflows. You're handing over access to years of messages when all you actually need is:

• Send this email.
• Tell me if it delivered or bounced.
• Give me a place to receive replies.

This guide walks you through a cleaner setup using MailChannels Email API for sending and delivery tracking, paired with AgentMail for giving your agent its own inbox. No access to your personal mail required.

How the Pieces Fit Together

The architecture is straightforward:

• OpenClaw runs your agent and handles tool/skill execution.
• MailChannels Email API takes care of sending email and reporting back what happened (delivered, bounced, dropped) via webhooks.
• AgentMail gives your agent a dedicated inbox — completely separate from your personal email — with support for real-time events.

Each piece does one job well, and your agent only gets the permissions it actually needs.

What You'll Need Before Starting

• A self-hosted OpenClaw install.
• MailChannels Email API credentials: your MAILCHANNELS_API_KEY and MAILCHANNELS_ACCOUNT_ID (this is your customer handle).
• DNS access for the domain you plan to send from (you'll need this for Domain Lockdown).
• Optionally (but strongly recommended): a public HTTPS endpoint where MailChannels can send delivery webhooks.

Step 1: Set Up Your MailChannels Credentials

The MailChannels skill for OpenClaw looks for two environment variables:

• MAILCHANNELS_API_KEY — sent in the X-Api-Key header on every request.
• MAILCHANNELS_ACCOUNT_ID — your customer handle.

There's also an optional override if you need to point at a different base URL:

• MAILCHANNELS_BASE_URL — defaults to https://api.mailchannels.net/tx/v1.

Set them up in your shell before launching OpenClaw:

export MAILCHANNELS_API_KEY="YOUR_API_KEY"
export MAILCHANNELS_ACCOUNT_ID="YOUR_ACCOUNT_ID"
# Optional:
export MAILCHANNELS_BASE_URL="https://api.mailchannels.net/tx/v1"

Step 2: Lock Down Your Sending Domain

Before letting an agent fire off emails from your domain, you'll want guardrails in place. MailChannels supports Domain Lockdown through a simple DNS record.

For each domain you plan to send from, add a TXT record:

• Host: _mailchannels.<your-domain>
• Value: v=mc1; auid=<YOUR_ACCOUNT_ID>

This ensures only your MailChannels account can send as that domain. You can verify everything is configured correctly using the Email API's domain check endpoint:

• POST /check-domain — validates your DKIM, SPF, and Domain Lockdown setup all at once.

Step 3: Install the MailChannels Skill in OpenClaw

The MailChannels integration is published as an OpenClaw skill called mailchannels-email-api. Install it with:

npx openclaw add @ttulttul/mailchannels

This skill handles two things: sending email through the MailChannels API, and ingesting signed delivery-event webhooks into your OpenClaw environment.

Step 4: Send Your First Email

MailChannels exposes a clean POST /send endpoint. The minimum payload needs four things: personalizations (who you're sending to), from, subject, and content.

Here's a curl example so you can see what's happening under the hood:

curl -sS -X POST "$MAILCHANNELS_BASE_URL/send" \
  -H "X-Api-Key: $MAILCHANNELS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "personalizations": [
      { "to": [ { "email": "you@example.com" } ] }
    ],
    "from": { "email": "agent@your-domain.com", "name": "OpenClaw Agent" },
    "subject": "Hello from OpenClaw via MailChannels",
    "content": [
      { "type": "text/plain", "value": "This email was sent by my agent using the MailChannels Email API." }
    ]
  }'

Once the skill is installed and your env vars are set, you can skip curl entirely and just tell your agent something like:

Send an email to me using MailChannels with the subject "Test" and a one-line body confirming it worked.

The agent takes it from there.

Step 5: Use Async Sending for Agent Workflows

In practice, you usually don't want your agent blocking while an email is processed — especially when sending to multiple recipients.

MailChannels provides an async alternative:

• POST /send-async — queues the message and returns immediately with a request ID.

Delivery events still come through via webhooks, so you don't lose any visibility. Your agent just gets to move on to its next task faster.

Step 6: Close the Loop with Delivery Webhooks

Sending email is only half the story. A genuinely useful agent can also answer questions like: Did it deliver? Did it bounce? Should we retry or suppress that recipient?

6.1 — Register a Webhook Endpoint

MailChannels provides three endpoints for managing webhooks:

• POST /webhook — enroll for webhook notifications.
• GET /webhook — retrieve your enrolled webhooks.
• DELETE /webhook — remove webhooks you no longer need.

6.2 — Validate Your Endpoint

After setting up a webhook, make sure it's actually reachable:

• POST /webhook/validate — sends a test event and reports back what status code and body your endpoint returned.

This is worth running any time you change infrastructure or rotate endpoints.

6.3 — Verify Webhook Signatures

MailChannels signs its delivery-event webhooks, and you should verify those signatures. Incoming webhooks include these headers:

• Content-Digest
• Signature-Input
• Signature

To verify them:

1. Parse Signature-Input (it includes created, alg, and keyid).
2. Reject anything with a stale timestamp.
3. Fetch the public key for the given keyid using GET /webhook/public-key.
4. Verify the Ed25519 signature per RFC 9421.

6.4 — Correlate Events Back to Your Agent's Actions

Webhook payloads include fields like email, customer_handle, timestamp, event, and request_id. If you persist the request_id from when you sent the message, you can build a clean internal state machine: processed → delivered, or soft-bounced / hard-bounced / dropped.

This is what lets your agent make smart decisions — retry on a soft bounce, suppress on a hard bounce, escalate on repeated failures.

Step 7: Give Your Agent an Inbox with AgentMail

Everything above handles outbound email. But agents often need to receive messages too — replies, confirmations, OTP codes, inbound support requests.

That's where AgentMail comes in. It's an API-first inbox provider built specifically for AI agents. Think of it as "Gmail for bots" — you get inbox provisioning via API, threading, attachments, and real-time events.

7.1 — Install the AgentMail Skill

AgentMail publishes an official OpenClaw integration. Install it with either:

openclaw skills install agentmail-to/agentmail-skills/agentmail

or via the ClawHub CLI:

npx clawhub@latest install agentmail

7.2 — Configure Your API Key

Add your AgentMail API key to your OpenClaw config at ~/.openclaw/openclaw.json:

{
  "skills": {
    "entries": {
      "agentmail": {
        "enabled": true,
        "env": {
          "AGENTMAIL_API_KEY": "your-api-key-here"
        }
      }
    }
  }
}

7.3 — Create an Inbox for Your Agent

AgentMail supports programmatic inbox creation, including custom domains if you want your agent's address to live on your own domain. Once set up, your agent can:

• Receive replies in a dedicated inbox.
• Search, triage, and respond without ever touching your personal mailbox.
• Trigger workflows from inbound email — OTP verification, support intake, routing, and more.

Ideas for What to Build Next

With MailChannels handling outbound and AgentMail handling inbound, your OpenClaw agent is ready for workflows that feel hands-free but stay operationally sound:

• Daily briefings: Your agent compiles calendar items, tasks, and news into a single email, sends it via MailChannels, and tracks delivery.
• Support triage: Inbound email arrives at AgentMail → agent labels and routes it → agent replies (or drafts a reply for your approval) → outbound goes through MailChannels.
• Deliverability-aware automation: If a recipient hard-bounces, the agent auto-adds them to the suppression list and notifies ops.

Appendix: MailChannels Email API Quick Reference

Base URL: https://api.mailchannels.net/tx/v1

Sending

Webhooks

Domain Configuration

DKIM Key Management

Sub-Accounts

Sub-Account Limits

Sub-Account Usage

Sub-Account API Keys

Sub-Account SMTP Passwords

Suppression List

Account Usage

Metrics

If you build something interesting with OpenClaw + MailChannels — especially anything that uses delivery events to automatically retry, suppress, route, or escalate — that's exactly the kind of agent-native email workflow this stack is designed for. Let us know what your OpenClaw is building with MailChannels Email API!