Mailbuttons, OpenClaw, and Why Email Is the Front Door to AI

When I first put my own mail server on the public internet, I knew it was going to be bad, really bad. I knew it would start with dns. As soon as I updated dns, that would be the trigger.

So within hours of deploying my mail server, the logs lit up. Old Exchange exploits. Botnets testing default passwords. Spam campaigns probing for open relays. A constant background hum of hostile curiosity, all aimed at one thing: getting email through a machine I controlled.

I absolutely hate it. It's loathsome. Only a few weeks ago I was talking to someone who's elderly father had been exploited into sending thousands of pounds to scammers. And it all started with an email. AI agents could have protected him from this, and in future, they will.

So with AI in mind, I built a hardened mail stack in the first place, and I'm convinced email will be the primary way normal people start interacting with AI agents — even if the conversation ultimately moves somewhere else.

In this article, I want to connect three threads: email as the secure, universal front door for AI; Mailbuttons as the way to put agents behind an email address safely; and OpenClaw as the personal automation fabric that lets me wire that inbox into everything I run.

The Internet Is Hostile by Default

Most discussions about AI agents start with product demos and UX. Mine starts with firewalls and log files.

If you stand up any service on the public internet — an SMTP server, a JSON API, a login page — you are not alone for long. Automated scanners will find it. They will throw every cheap exploit, leaked credential list, and misconfiguration test at your door, 24/7, forever.

Email is one of the oldest and most heavily attacked protocols we have. That is bad news if you treat it casually. It is excellent news if you take it seriously.

Over decades of abuse, we've built a global defensive fabric around email:

• SPF records that say “these are the only servers allowed to send mail for this domain”.
• DKIM signatures that cryptographically bind a message to a sending domain.
• DMARC policies that tell receivers how to treat failures.

The result is a network where sender identity is not perfect, but it is good enough and getting better — and critically, it is universal. Every serious sender participates. Every serious receiver checks.

The thing most people hate about email — that it is old, boring, and heavily policed — is exactly what makes it the right foundation for secure agent interfaces.

What Running My Own Mail Taught Me About Security

When you run your own mail server, you stop thinking of email as “that legacy system we should replace” and start seeing it as a remarkably battle-tested identity and delivery layer.

Three principles shaped how I think about agent security.

1. Minimise the Attack Surface

Every public API endpoint you expose is an invitation. A login page can be brute-forced. A REST API can be fuzzed and scraped. A webhook receiver can be replayed and poisoned.

With SMTP, the surface is narrow and well-understood. You expose a standards-compliant mail interface — and that is it. No bespoke JSON shapes. No artisanal authentication schemes. No one-off OAuth integration someone wrote in a hurry five years ago.

Everything interesting happens behind the curtain, on my terms. That is how I want my agents to live on the internet as well.

2. Let the Protocol Do the Heavy Lifting

If you design your own security layer, you also design your own bugs.

My mail stack leans heavily on standards instead of cleverness:

• SPF/DKIM/DMARC as first-class signals for whether to trust a sender.
• Strict TLS and modern MTAs that are actively maintained.
• Reputation and rate limits long before any application logic gets involved.

You do not win points for inventing a better password reset format. You win by wiring together boring, widely-reviewed components in a clean way.

3. Assume Everyone Is Lying, Then Verify

The most important rule in my stack is simple: text is not truth.

• “From” headers can lie.
• IPs can be spoofed via compromised relays.
• Perfectly valid SPF can still come from a compromised sender.

So the system layers checks: domain posture, sending patterns, IP reputation, structural heuristics. Only once a message passes several filters do I treat it as something a human — or an AI — should act on.

That paranoid posture is exactly what you want in front of anything powerful, including agents with access to tools, data, or workflows.

Why Email Is the Natural Interface for AI Agents

Most AI product pitches assume a new surface: a custom web app, a proprietary chat widget, a mobile app with an onboarding funnel.

I think that is backwards. If an AI agent is genuinely useful, the average person should not need a new account, a new password, or a new app. They should be able to do what they have always done: write an email.

Everyone Already Has It

You do not need to explain what “compose” means to a CFO or a customer support rep. They already know how to address a message, add context, forward a thread, and CC someone else.

That is a fully-featured UX you get for free on every device on earth. When you put an AI agent behind [email protected], you are not inventing a new paradigm — you are plugging into an old one that is already deeply learned.

Identity Is Built In

Most web-based AI agents end up re-implementing identity: “Sign in with Google”, “Connect your Slack workspace”, “Paste your API key here”. Every one of those is a new risk surface.

With email, identity is federated and enforced upstream. Providers authenticate users. SPF/DKIM/DMARC validate who sent what. Abuse teams at the major providers burn cycles cleaning up junk so you do not have to.

Mailbuttons leans heavily on this. An agent can say “only people from @yourcompany.com can talk to me” and rely on the global email ecosystem to enforce that boundary. There is no public login page to attack.

Asynchronous by Nature

Agents need time to think, to call tools, to wait on external systems. Trying to squeeze that into an interactive web request leads to timeouts, spinner fatigue, or agents that are forced to act before they really should.

Email is asynchronous by design. You send a request. Some time later, you get a reply. That gap is a feature, not a bug. It gives agents permission to be thoughtful instead of reactive.

Built-In Audit Trail

Every AI interaction over email is threaded, searchable, forwardable, and archivable. Legal, compliance, and operations teams already know how to live in that world.

For the PE-backed boards I advise through Codecutter, this matters far more than UI chrome. The mailboxes are the audit logs.

Email as the Front Door, Not the Whole House

None of this means the entire agent experience has to live inside an inbox forever. In fact, I think the healthy model looks like this:

• You start in email, because that is where people already are and where identity and security are strongest.
• You deepen the interaction elsewhere when it makes sense: a web app, a dashboard, Slack, Teams, whatever the right channel is.
• Email becomes passwordless login into those richer experiences.

Concretely, that looks like this:

• You email [email protected] with a complex request.
• The agent replies with a summary and a link: “If you want to review and tweak the changes before we apply them, click here.”
• That link is a signed, short-lived, one-time token tied to your email identity — effectively passwordless login.
• Clicking it drops you into a web UI, pre-loaded with the exact context from the email thread.
• When you are done, the confirmation (and any resulting actions) are written back to the email thread for your records.

The email thread becomes the spine of the interaction: where the request originates, how you authenticate, and where the durable record lives. The “house” — dashboards, visualisations, rich flows — lives wherever it makes sense. Email is the front door and the root of trust.

What OpenClaw Actually Is

If Mailbuttons is how I put an agent behind an email address, OpenClaw is how I give that agent serious capabilities.

OpenClaw describes itself as a personal AI assistant you run on your own devices — a local-first gateway that connects to WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, Microsoft Teams, WebChat, and more, and routes everything through a central Gateway with tools, skills, browser control, cron, and device nodes.

In practice, that means:

• A single, local control plane for sessions, agents, channels, and tools.
• A very opinionated security model with safe defaults for DMs and optional Docker sandboxes for anything that is not “you”.
• A platform that is designed to feel local, fast, and always-on, but with real guardrails.

If Mailbuttons is the inbox-side plumbing, OpenClaw is the automation fabric that can actually do things once a request has been authenticated and interpreted.

Why I'm Connecting Mailbuttons to OpenClaw

So why bother wiring these two together? Because I want this flow:

Anyone I trust can email an address. Mailbuttons handles deliverability, sender security, and policy. OpenClaw handles everything from “what does this mean?” to “go do the work across all my systems and channels.”

In other words: email in, automation everywhere out.

Mailbuttons: Secure, Universal Entry Point

Mailbuttons gives each agent an email address and wraps it with:

• Allowlists so only specific email addresses or domains can reach a given agent.
• Email-native trust via SPF/DKIM/DMARC, without asking end users to manage API keys or passwords.
• No public API endpoint to scan, brute-force, or reverse-engineer. If you are not on the list, the agent effectively does not exist.

It is the perfect perimeter: hostile internet on the outside, clean, structured events on the inside whenever an allowed message lands.

OpenClaw: Automation Fabric and Orchestrator

Once Mailbuttons has accepted a message and fired a webhook or event, I want that event to land in OpenClaw's world:

• As a session in the Gateway, with full context (sender identity, thread history, attachments).
• With access to all the tools OpenClaw already exposes: browser automation, cron jobs, chat channels, local device actions, and more.

That is where “automate everything” stops being a slogan and starts being an architecture.

Some concrete examples:

• A customer emails a support agent; Mailbuttons verifies they are allowed; OpenClaw looks up their account, reproduces the issue via browser automation, posts updates into an internal Slack channel, and schedules a follow-up if a human needs to intervene.
• A family emails a concierge agent; Mailbuttons enforces the family allowlist; OpenClaw searches for flights and hotels, proposes itineraries into a WhatsApp group, and updates a shared calendar when a decision is made.
• A PE firm emails a diligence agent; Mailbuttons ensures only the deal team can talk to it; OpenClaw pulls repo stats, CI history, and security scans, then summarises risk in board-ready language and pushes drafts into the channels the team already lives in.

I do not want to reinvent a generic automation platform per use case. OpenClaw is already a mature, multi-channel, tool-rich system. Mailbuttons simply becomes a secure, email-native way to feed it work.

Email as Passwordless Login into OpenClaw-Powered Surfaces

The other reason this combination makes sense is authentication. I want to be able to start a conversation via email and, when needed, send back a magic link that drops the user into an OpenClaw-powered surface — without ever asking them to create a separate account.

The fact you control that inbox, plus the checks Mailbuttons and the broader email ecosystem have already done, is your identity. OpenClaw does not have to guess who you are; it gets a signed, time-limited, one-time token from an email that only you could have received.

That is a far cleaner story than bolting home-grown auth onto every agent UI.

The Security Model Most People Never See

If I do my job right, the average user should never have to think about SPF alignment, DMARC enforcement modes, webhook replay protection, Docker sandboxing, or token expiry policies.

They should experience something much simpler: they send an email to an agent, they get a fast, accurate, policy-aware response, and when they need more power — a UI, a dashboard, a workflow — they click a link and are just there. Under the hood, OpenClaw quietly fans out across channels and tools to do the work.

Behind that is a very opinionated view of how agents should live on the internet:

• Identity before content: decide who is talking before caring what they say.
• Protocol before product: ride on SMTP, SPF/DKIM/DMARC, and OpenClaw's Gateway protocol rather than rolling bespoke security each time.
• Default deny: start from “no one can talk to this agent” and add back specific groups, not the other way round.
• Email as root of trust: use inbox control as the anchor for passwordless login and channel handoffs.
• Local, inspectable automation: run OpenClaw on machines you control, with logs you can read, configs you can version, and sandboxes you can tune.

Where This Goes Next

I do not think every AI interaction will happen over email. There will always be room for deeply integrated UI components, real-time chat, voice, and multimodal interfaces.

But I do think a huge percentage of meaningful, high-value interactions will start in email:

“Just email the agent. If you need more, it will take you where you need to go.”

New hires can email an HR agent with questions, then jump into a portal from a magic link when they need to upload documents. Customers can email a product agent for support, then click through to a guided troubleshooting flow, authenticated by their inbox. Executives can email a strategy agent with a deck attached and move into a collaborative workspace to iterate on scenarios.

Underneath that simplicity, there needs to be an infrastructure that treats email as the serious, adversarial environment it is, uses it as a secure root of trust, and then fans out into a rich, multi-channel, tool-rich automation layer.

That is why I am connecting Mailbuttons to OpenClaw. Mailbuttons is how people talk to my agents, safely, from anywhere. OpenClaw is how those agents can actually do things — across all my devices, tools, and channels — with the same bias toward security and control that led me to run my own infrastructure in the first place.