You asked your assistant to email a supplier. Back came a clean message with a subject line, a greeting and a sign-off — and then nothing happened. Or something did, and there is no way to tell from inside the chat window.
The short answer: on its own, an assistant writes text, and text is not delivered mail. It can cause an email to arrive only when you connect it to something that sends — and what matters is what each connection grants.
Why the answer isn't obvious from inside the chat
"Here's the email I sent to Dana" and "here's the email I'd send to Dana" are one word apart, and only one corresponds to an event in the world. A model narrates fluently either way, and a well-formatted draft looks exactly like something delivered.
So verify outside the conversation: the Sent folder of the account that would have been used, the tool-call log if your app exposes one, or the recipient. If none show it, nothing left. That habit is the practical edge of the difference between an assistant that proposes and an agent that acts.
Option zero: you are the send button
Before any wiring, the baseline: the assistant drafts, you paste it into your own mail client, you press send. It grants nothing and works everywhere.
The cost is that the split between drafting and sending lives in your discipline rather than in the system, and nothing records which sentences were yours. For one message, once, it is the right answer.
1. Mailbox access — the broadest grant
You connect the assistant to your real mail account, usually through an OAuth consent screen. It can then read your mail and send as you, from the address people already trust, inside existing threads.
That inheritance is the appeal. It is also the cost:
- Read scopes are coarse. Access to the mailbox means access to what is in it — password resets, contracts, financial and medical mail, years of history. Access to only the boring parts is rarely offered.
- It is a standing grant. It persists until you revoke it, and it is easy to lose track of which tools still hold one. Look under the connectors or integrations section of your app's settings; the menus move, the scopes are what matter.
- Inbound mail becomes instructions. Anyone can write to your inbox, and a model reading untrusted text in the same context where a send capability lives is the exact shape of prompt injection in email agents.
That is not disqualifying, and it is the only option if you want triage of mail you already have. It deserves a decision, not a click-through — should you give your AI assistant email access, and what you are granting when you connect an app.
2. Its own address — sending credentials or a separate mailbox
Narrower and more controllable. You give the agent a sending API key, SMTP credentials, or a mailbox of its own. Send-only is achievable, and declining to wire up reading removes most of the injection surface.
The cost is that you created a sender out of nothing:
- Deliverability is now your job. SPF, DKIM, DMARC, domain warmup, bounce handling, reputation. A fresh identity sending machine-written mail is shaped like spam, and filters treat it as such until it earns otherwise.
- The recipient has no relationship with the address. It is not you — filtered more readily, trusted more slowly.
- Replies land somewhere. Someone has to watch that mailbox. If the agent watches it, you have rebuilt option 1's risk with worse deliverability.
- Everything leaves in one undifferentiated voice. Nothing tells the reader which sentences a human typed, approved, or never saw.
For machine-to-owner notifications — the build broke, the job finished — this is exactly right. The tradeoffs shift the moment the recipient is another person, which RelayLink vs. giving your AI agent its own email account covers in detail.
3. A channel built for correspondence
The third shape grants no mailbox access at all. The assistant connects to a separate channel over MCP, and the send is split in two: draft_package creates a draft on the server, you review the rendered package exactly as it will arrive, and confirm_send from your own account releases it. No single call composes and delivers, so "the model sent it without me" is not a failure mode here.
That is what RelayLink is. Consent is enforced at the relay rather than requested in a prompt — accepted contact pairs, a hard daily cap on reaching strangers, and a one-click block the sending side cannot route around (the reasoning). Delivery bottoms out in ordinary email, so the recipient needs no account, no app, no AI.
The honest costs: it does nothing about mail you already receive, so it is not a triage tool. It is not end-to-end encrypted — the relay renders the email and web views, and both assistants are hosted models. There is no unsend after delivery; the review step is the undo. And it is deliberately bad at volume, useless as an outreach cannon.
The question that actually matters
"Can it send" is settled by whether you wired it up. These four apply to any setup, including wiring that does not exist yet:
- What can leave without me? Is the human step structural — a separate confirmation bound to your account — or habitual, meaning you meant to read the draft?
- Who can it reach? Anyone with an address, a list you curated, or only people who accepted a connection and can revoke it?
- What can the recipient tell? Whether a sentence was typed by you, approved by you, or inferred on your behalf.
- What happens on a reply? Does inbound text from strangers reach a model that also holds the ability to send?
Answer those and the capability question answers itself. If your answer to the first is "nothing, without an explicit confirm", that is the design RelayLink implements — see the send flow end to end, or connect your assistant.