Email in Spun is not a second inbox. There are no folders to stay on top of, no unified mailbox, and nothing separate to check at the end of the day. There is one conversation per person, and email is one of the channels that conversation can carry, next to WhatsApp, SMS and Spun Chat. You open the channel picker beside the contact name, choose Email, write, and send. When they answer, the answer appears in the same thread you sent from.
That framing decides nearly everything else on this page. Because you are writing to a person you already have a conversation with, Spun resolves the recipient itself from the contact record, refuses an address handed to it by the browser, and offers no CC and no BCC field at all. That is not an unfinished feature. It is the line between a conversation tool and a bulk mail tool, and Spun stays on one side of it on purpose.
How sending works, and why there is only ever one recipient
The mail goes out through your own Gmail account. You connect it once, through a Google client that asks for a send-only scope: it can send as you, and it has no permission to read your mailbox. The tokens Google hands back are encrypted before they are stored, and nothing in Spun ever shows them again. It is a separate connection from the one Google Meet uses, so connecting one does not connect the other, and only the person who connected a mailbox can send from it. A shared team inbox is not a shared mail identity.
When you press send, the server does the addressing. It takes the contact whose conversation you are in, reads the address on that contact record, and sends there. If the request arrives carrying an address of its own, the send is refused rather than trusted. The message Spun builds has exactly one primary recipient, and the code that builds it emits no Bcc header at all.
Replying into a thread that already has other people on it is the one case where more than one address is involved, and even there the set is not something you type. You turn Reply all on, and Spun works out at send time who is already a participant in that thread. Somebody who has not been accepted into the thread yet is left out, and there is no field for adding a stranger.
- An address supplied by the browser instead of resolved from the contact: the whole send is refused.
- An address that arrived from an enrichment lookup rather than a real relationship: never emailable at all.
- A contact with no address on file: the channel picker says so, and offers to add one there.
- A marketing purpose: refused on this path outright. This channel is for correspondence, not campaigns.
If you want one message to reach many people, that is a different tool with different machinery: recipient selection, pacing, and per-recipient reporting. Use broadcasts for that, and leave this channel for the one-to-one case it was built for.
Related: How broadcast campaigns work
What the composer actually gives you
The subject line is the part most email tools get lazy about, so Spun writes it from what the message is about rather than dropping a fixed default on every send. Pick a template and the subject comes with it: a meeting link, a task assignment, or a reminder each produce their own specific subject from the thing they are about. Free text is the one case where you write the subject yourself, because only you know what it is. On a reply the subject is fixed to the thread, which is what keeps the reply in the same conversation on the other person side too.
Everything else in the composer is the WhatsApp composer you already know, pointed at a different channel. Your saved quick replies are there. The AI writing panel is there, with the same tone, length, perspective and language controls. The composer expands to fill the conversation area when you are writing something long and collapses again when you would rather watch the thread. An email you started and did not send comes back next time you open that contact, with a line saying so and a way to throw it away.
Above the send button is a panel that tells you the truth before you commit: which of your connected mailboxes it goes from, the exact address it goes to, the address the reply will come back to, and how many sends you have left today and this hour.
How a reply finds its way back
This is the part that is genuinely different from every other way of sending email, and it is worth a minute. Your message leaves through Gmail, from your own address, so the person receiving it sees you. What it carries in its Reply-To header is not your address: it is a receive-only address on a Spun domain, with a random token in it that is bound to that one thread. Spun stores only a hash of that token, never the token itself, so the address in the header is the only place the plain value ever lives.
When they reply, it lands on that receive-only address, and the token tells Spun which conversation it belongs to. Then Spun checks who actually sent it. A reply from the person you wrote to, on a message whose domain authentication lines up, goes straight into the conversation and behaves like any other incoming message: the chat moves up your list, the unread count rises, and you get the notification you would expect.
A reply from anyone else is held aside instead. The held list shows the sender, the subject and the reason it was held, and nothing more, because the sender is exactly the one you have not vouched for yet. Accepting is a single tap with a few seconds to undo it, and from then on that person is part of that thread. Until you accept, a held message moves nothing at all: no unread count, no chat list reorder, no notification. Rejecting is final for that message.
An incoming email never triggers an automated action on its own. Reading an email cannot create a task, send a message, change a contact or write to your calendar, no matter what the email asks for, because the part of Spun that reads email has no ability to take those actions at all.
Reading what comes back, safely
Email is the one channel where the message body is a document written by whoever sent it, so Spun renders it as one. Every body goes into an isolated frame that is not allowed to load anything from the internet: no remote images until you ask for them, no scripts, no call back to the sender. Quoted history from earlier replies is folded away behind a toggle rather than repeated down the thread, so a long exchange reads as an exchange instead of a wall.
Files that arrive on a reply are kept alongside the message and listed with their size. File types Spun considers unsafe are listed but never offered for download, which is deliberate: hiding them would tell you less than showing you what arrived and refusing to hand it over. Automatic replies such as out-of-office are labelled as what they are, and the status next to a message is always a word rather than a tick.
Related: How Spun protects your data
What the AI can do here, and what it is not allowed to do
Spun can summarise an email thread for you, and it can draft a reply. Both are useful on the kind of thread that has been running for two weeks and now has five messages you have not read. The summary is a summary. The draft always opens in the composer for you to read, change and decide on, and a drafted reply goes through exactly the same eligibility checks and sending limits as one you typed yourself.
The boundary matters more than the capability. The model that reads your email is invoked with no tools: there is no function calling, no MCP surface, and nothing it can reach for. Content goes through a redaction pass before it reaches the provider. Held-aside mail and automatic replies are never fed to these features at all, so a message you have not vouched for cannot influence a summary or a draft.
On the writing side, the AI panel is the same one the WhatsApp composer has, and it never sends. When it has produced a version of your message, the send row offers both, so sending what the AI wrote is a separate, deliberate press from sending what you wrote.
Related: Where rules decide the moment and AI decides the wording
Limits, and the things Spun deliberately does not do
Every mailbox has a daily and an hourly ceiling, and the composer shows you where you stand before you send rather than after. There is also a limit on writing to the same person again and again within a day, and a send that repeats a message you have already sent to that person is refused. When one of these stops a send, the refusal says which one it was.
The honesty about status is the other half. Spun tells you when Gmail accepted a message and when the person replied, and it never tells you a message was delivered, because bounces go back to Gmail and never reach Spun, so a delivery claim would be a guess dressed up as a fact.
- No read tracking, no tracking pixel, and no rewritten links. If you want to know whether they read it, the honest answer is that nobody who tells you can prove it.
- No delivered state. The statuses are Sent via Gmail, then Replied, plus a plain admission when Gmail never confirmed the send.
- No CC field and no BCC field to type an address into, and never a Bcc header on the wire. Reply all is the one case that adds recipients, and even there the Cc is the thread participants Spun resolved itself.
- No bulk sending. One recipient per send, resolved by the server from the contact record.
- No automatic retry on a send Gmail did not confirm. Gmail may well have sent it, and sending it twice is the worse mistake.
- No marketing email on this path at all.
Where email shows up in the rest of Spun
- In the conversation, as ordinary messages in the same timeline as WhatsApp, each one naming its channel in its own header.
- In the chat list, where an Email filter narrows the list to conversations that have email, and an unread email view narrows it further. There is still exactly one unread count, not a second one to keep track of.
- In the contact panel, where the Email section lists the threads you have with that contact, how many messages each holds, when the last reply came, a way to jump straight in, and a button to start a new one.
- On contacts who only ever had an email address. A person who has never used WhatsApp still gets a conversation of their own, because the conversation is keyed on the person, not on the channel.
Setting it up
- 1
Connect your Gmail
Open Settings, go to the Google Calendar, Meet and Gmail tab, and use the "Connect Gmail for sending" card. This is a separate connection from Google Meet, and connecting one does not connect the other. Only the person who connected a mailbox can disconnect it.
- 2
Open a conversation with a contact you can email
Any one-to-one conversation with a contact who has an email address on their record.
- 3
Choose Email in the channel picker
The picker sits beside the conversation name. If Email is greyed out it tells you why, and where something can be done about it it offers the action right there: adding an address for a contact who has none, or connecting Gmail.
- 4
Confirm how you know them, once
The first time you write to an address that was never confirmed, Spun asks in one screen how you know them and why you are writing, and records that against the address. An address you typed in yourself needs no further confirmation, because entering it is itself the record.
- 5
Write it
Pick a template or write free text, check the subject, and write the message. Use the AI panel or your quick replies if they help.
- 6
Check the panel, then send
The panel above the send button names the sending mailbox, the recipient, the reply route, and what is left of your allowance for today and this hour. Send, and the row appears in the conversation as Sent via Gmail, changing to Replied when they answer.
Related: Security and privacy at Spun · The full email channel reference on docs.spun.com