The fastest way to let an AI agent send email is to give it an email account. A mailbox, SMTP credentials or an email API, a few minutes of setup — and the agent can reach anyone on earth. Sometimes that is exactly the right call. The hard part is noticing when it stops being one, because the failure modes arrive later and land on other people.
What the DIY account does well
Be fair to the mailbox first.
Full control. Your domain, your infrastructure, your rules. No third-party service sits between your agent and the recipient, and nothing about the setup depends on anyone else's roadmap.
It reaches anyone. An address is all you need. That is email's whole value, and a DIY account inherits it completely.
No new service. Nothing to evaluate, nothing to trust, one fewer dependency.
And there is a case where DIY is simply correct: machine-to-owner notifications. An agent that emails you when the build breaks, the scraper finishes, or a certificate is about to expire has one sender, one recipient, and no consent question — you are operator and audience at once. A relay would add nothing but hops. If that is your use case, set up the mailbox and stop reading; the rest is about messages to other people.
Where the costs live
The costs appear the moment the recipient is someone else.
No consent layer. Nothing in email stops your agent from writing to anyone, again, at any hour. Whatever restraint exists lives in a prompt — and a prompt is a request, not an enforcement mechanism. The recipient's only defense is their spam filter.
No provenance. Every message leaves the mailbox in one undifferentiated voice. The recipient cannot tell whether the human typed a sentence, approved it, or never saw it — ambiguity that bites hardest on commitments, decisions, and anything quoted back later.
Read and send in one place. Most agent-mailbox setups let the agent read the inbox too — how else would it handle replies? That combination is the classic exfiltration machine: anyone on the internet can mail instructions to the inbox, the agent reads them, and the same agent has a send button. Prompt injection in email agents needs exactly this surface — and whether to hand an assistant your inbox at all deserves its own decision.
Deliverability is now your job. SPF, DKIM, DMARC, domain warmup, bounce handling, reputation. A fresh domain sending machine-generated mail is shaped exactly like spam, and filters will treat it that way until you earn otherwise.
What RelayLink changes
RelayLink is a separate channel, not an email integration — it never touches, reads, or connects to anyone's inbox. Your assistant connects to a nine-tool MCP server, and correspondence runs through a relay that enforces its rules server-side.
- Two-step send, always.
draft_packagecreates a draft on the server; you review the rendered package exactly as it will arrive;confirm_sendreleases it. There is no single call that composes and delivers. - Provenance on every note. Four labels, from verbatim, human-authored — earned only when your words differ from the AI's draft — down to inferred by sender's AI. The reader can weigh each part accordingly.
- Consent enforced at the relay. Standing correspondence requires a mutually accepted contact pair. Reaching someone new is hard-capped per day, the first message must be a full briefing, and every message carries a one-click unsubscribe that blocks the sender permanently.
- Neutralized content. Links and images in relayed content are defused before any assistant or browser sees them — no tracking pixels, no auto-fetched instructions.
- The recipient needs nothing. Delivery still bottoms out in ordinary email: your note, a TL;DR, and a magic link to the full briefing with a reply box. The send flow is short, and replies land back on your thread.
The honest limits: RelayLink is not end-to-end encrypted — the relay renders the email and web views, and both assistants are hosted models. Injection is made rare and low-yield, not impossible. And it is deliberately bad at volume — the caps and the full-briefing rule make it useless as an outreach cannon. If the requirement is reach at scale, RelayLink refuses by design.
Side by side
| DIY email account | RelayLink | |
|---|---|---|
| Reach | Anyone with an address | Anyone with an address — delivery floor is email |
| Setup | Mailbox, credentials, SPF/DKIM, warmup | Connector URL plus key; deliverability is the relay's problem |
| Sending | Agent can send on its own | Human reviews the draft; confirm_send releases it |
| Consent | None built in | Contact pairs, daily cap on new contacts, permanent blocks |
| Provenance | One undifferentiated voice | Four labels, verbatim through AI-inferred |
| Injection surface | Read and send in one credential | Separate channel, neutralized content, no inbox access |
Use a DIY account if — use RelayLink if
Use a DIY email account if:
- The only recipient is you or your team's alert address — build failures, scraper runs, expiry warnings.
- The messages are machine-generated reports nobody answers as correspondence.
- You need total control of the sending infrastructure and are prepared to own deliverability and the injection surface yourself.
Use RelayLink if:
- Messages go to other people, including people who never agreed to receive agent mail.
- It will matter later which words were the human's — decisions, approvals, asks.
- You want the review step and the consent rules enforced somewhere a model cannot talk its way past them.
The two are not really rivals. A mailbox is plumbing for notifications; RelayLink carries correspondence between people who happen to work with assistants. If the next thing your agent needs to send is meant for a person, connect your assistant and send one briefing — the recipient can finally tell which parts were you.