Guide
Why can't Claude send my email?
Claude wrote a perfect reply, then told you it could not send it. That is almost never a Claude problem. It is a connector problem, and every cause has a fix.
Claude cannot send your email for one of three reasons: the connector it is using is read-only or has no send tool, sending is deliberately gated behind a confirmation you have not given, or the connection's auth has expired or its scopes are too narrow. Each cause has a different fix, and only one of them is actually a problem.
Key takeaways
- Most email connections let Claude read and summarize but expose no send tool at all.
- If Claude asks you to confirm before sending, that gate is a feature, not a failure.
- Expired auth or narrow scopes silently strip capabilities; reconnecting often fixes it.
- A custom connector adds real in-thread drafting plus a gated `send_email` action you approve.
Is my email connector read-only?
Very often, yes. Many default and directory email connections are built for reading: they can search your inbox, fetch threads, and summarize messages, but they expose no tool that sends. When Claude says it cannot send, the most common reason is that no send capability exists in the connector at all.
Claude can only do what its connected tools allow. If the connector exposes read tools and nothing else, Claude will happily write a beautiful reply in the chat window and then have no way to move it into your mailbox or out the door.
The quick test: ask Claude to create a draft in your actual mailbox, not just write text in the chat. If it cannot, the connector has no write tools, and no amount of rephrasing your request will change that.
The fix is a connector with write tools. That can mean switching to a more capable connector for your provider, or having a custom one built that includes draft_reply and send_email alongside the read tools.
Why does Claude ask for confirmation before sending?
Because sending is deliberately gated. In a well-built connector, outbound actions like `send_email` are separate tools that always wait for your approval. Claude preparing everything and then stopping to ask is the system working exactly as designed, not a limitation to work around.
It is worth separating two very different situations. In one, Claude has no send tool and genuinely cannot send. In the other, Claude has a send tool and is pausing for your confirmation. The second is a feature.
Email is irreversible. Once a message leaves your mailbox, there is no undo, so the send action should always keep a human in the loop. Drafting can flow freely because a draft is harmless until sent.
The pause is the point
If Claude drafts the message and then asks you to approve the send, nothing is broken. That confirmation gate is what makes giving Claude send access safe in the first place.
Has my connector's authentication expired?
Possibly. Connectors authenticate to your email provider with tokens that expire or get revoked, and connections made with narrow scopes may cover reading but not sending. If a connector that used to work suddenly cannot act, expired auth or missing scopes are the usual suspects.
Two related causes hide here. The first is expiry: the token behind the connection has lapsed, and everything the connector does starts failing, not just sending. Disconnecting and reconnecting the integration usually resolves it.
The second is scope. When a connection is authorized, it is granted specific permissions. A connection scoped for reading mail cannot send it, even if the connector technically has a send tool. Reconnecting and granting the fuller permission set is the fix, assuming the connector requests it at all.
If reconnecting restores reading but sending still fails, you are back to the first cause: the connector or its granted scopes simply do not include send, and you need a connector that does.
How do I actually let Claude send email for me?
Use a connector with real write tools. A custom MCP connector authenticates as your own account, lets Claude create drafts in the right thread with `draft_reply`, and puts sending behind a gated `send_email` tool you approve. Drafting flows freely, and nothing leaves your mailbox without your confirmation.
Once the connector has write tools, the workflow becomes what you probably expected from the start: you ask Claude to reply to a thread, it reads the history, writes the response in your voice, and creates a real draft in your mailbox on the original thread.
Sending stays a separate step. You review the draft, approve it, and only then does send_email run. Because the connector acts as your account, it can only send from addresses you can already send from, and it never reaches mail you cannot see.
That is the durable fix for all three causes at once: the send tool exists, the gate is deliberate and yours to approve, and the auth is scoped correctly for the job from day one.