Email to channel: how any service posts into your team chat without a bot — and why an address beats a bot token
Most of what a team needs to see during the day is not typed by a colleague. It is produced by a machine: the uptime monitor that noticed a slow endpoint, the payment processor that received an invoice, the helpdesk that opened a ticket, the CI pipeline that failed. Getting those messages into the place where the team actually talks is called "an integration", and in most chat tools it means a bot: create it, get a token, store the token, write or configure a sender, keep the token alive.
InterMIND takes a shorter route. Every channel has its own email address. Anything that can send email can post into the channel, and nearly everything can send email. There is nothing to create on the InterMIND side beyond the address itself, nothing to install, and no token to keep. This post is the full mechanics of that route, plus an honest comparison with bot-based delivery on the four things that matter in practice: setup, secrets, delivery guarantees, and who can switch it off.
The setup itself is on the Email to Channel feature page; the reference is in the docs.
How it works
1. The address
The channel host opens the channel's display settings (the gear icon in the chat header), chooses Email to channel and clicks Create address. The result is a private address of the form <token>@in.intermind.com. Only the host can see it, rotate it (New address) or remove it; both take effect immediately, and the old address stops working the moment a new one exists.
Your personal Inbox has the same kind of address, visible to you alone. A channel address is for what the team should see; the Inbox address is for what only you should.
2. The sender
Paste the address wherever a tool asks for a notification email. That field is the integration. An uptime monitor's alert channel, an error tracker's alert rule, a helpdesk's "notify on new ticket", a billing system's receipts, a CI server's build notifications, a form builder's submissions, a newsletter subscription — all of them have that field, and none of them need to know what InterMIND is.
3. What lands in the channel
The email arrives as a regular channel message:
- Attributed to the sender. The message carries the sender's name and address, not the host's, and is translated for each reader the way any external message is.
- Subject first. The subject line becomes the first line of the message.
- Text, not boilerplate. The plain-text part is used; an HTML-only email is converted to text. Signatures and quoted reply tails are stripped, so a forwarded thread shows the new content rather than the whole history. Bodies are capped at 100,000 characters.
- Attachments kept. Each attachment becomes a file message, up to 25 MB per file.
4. Where it is read
Members with the channel open see the message arrive live on web and desktop. Members who are not looking get a push on mobile. Each reads it in their own language, and it stays in the channel history like everything else. The flow is one-way: replying in the channel does not send email back to the sender.
Limits, stated plainly
- Attachments count toward the team's storage pool. When storage is full, the text still arrives and the attachment is skipped, with a note in the message saying so.
- Up to 30 emails per hour per address; anything beyond that in the same hour is dropped.
- Mail to an address that does not exist is dropped silently: no bounce, no reply. A guessed address gets no signal back.
- Available on every plan.
The same job with a bot
A bot-based integration is not hard. It is just longer, and every step is a thing that can later break. Here is the Telegram version, because we ran one ourselves for our monitoring alerts until this week, and the Slack version, because it is the reference most teams know.
Telegram. A bot is created through BotFather, which issues a token; every message is an HTTP call to the Bot API with that token and the numeric id of the target chat, and the token can be revoked and reissued through BotFather (Telegram Bot API documentation, Bots: From Beginner to Advanced, checked September 2026). So the sender needs the token and the chat id, and every place that sends needs both.
Slack. Incoming Webhooks give an app a unique URL per channel; the URL is the secret, and Slack's own documentation tells you to treat it as one and to keep it out of public repositories (Slack — Sending messages using incoming webhooks, checked September 2026). One URL per channel per app, stored on every sender.
Our own alert setup, before the switch, needed five things to exist and stay correct: a bot token in the monitoring vendor's variables, two secrets on the hosting platform, a webhook signing secret, a sender inside the error tracker's webhook handler, and a sending step inside the post-deploy watcher script. The email version of the same setup is one address, entered into each vendor's "notification email" field. On the InterMIND side the change is zero.
Address vs token: four properties
| Channel email address | Bot token / webhook URL | |
|---|---|---|
| What you create | One address, from the channel itself | A bot or app, then a token or URL, then a sender that uses it |
| Where the secret lives | Only in the tools that send; the host sees it in the channel | On every sender, plus wherever the bot is administered |
| Delivery when the receiver is down | Store-and-forward: SMTP requires a sender to queue mail it cannot deliver and retry it later (RFC 5321 §4.5.4.1) | One HTTP call; retry only if the sender implements it |
| Who can switch it off | No single party: email is a federated protocol between independent servers | The platform that issued the token or URL |
The last two rows are the ones that decide incidents. A bot API is a single vendor's endpoint on a single vendor's network: if the call fails, the message is gone unless the sender wrote retry logic, and if the platform is unreachable from where you are, so is the integration. Email was designed in the opposite direction. The sending server keeps the message and tries again; no one operator sits between sender and receiver.
Rotation follows the same logic. Revoking a bot token means updating every sender that holds it. Rotating a channel address means updating the same senders, but with the difference that the address was never stored in your own code or infrastructure to begin with: it exists in the vendor's notification field and nowhere else.
What this is for
The obvious use is machine messages: alerts, receipts, tickets, build results. The less obvious one is people. A client who will never install anything can be told "send it to this address" and the whole team reads the thread in the channel, in their own language, with the attachments. A supplier's weekly report, a regulator's notice, a partner's contract draft: all of it lands where the work is already happening, without asking anyone to join anything.
That is the point of a persistent space rather than a meeting: what arrives stays, in the language each member reads. Email-in is one more door into the same room. Telegram is another; that route is described in How to bring your Telegram chats into InterMIND.
Try it
- Read the Email to Channel feature page — the mechanics in one screen, with a demo.
- Open the docs — creating and rotating the address, the Inbox address, limits.
- Try the live demo — a meeting with an AI participant, no signup.
FAQ
Which services can post into a channel by email? Any service that can send email to an address you specify: uptime and error monitoring, ticketing and helpdesk systems, CRMs, billing and invoicing, CI pipelines, form builders, newsletters. If the tool has a field for a notification email, that field is the whole integration.
Who can see the channel's email address? Only the channel host. The host creates it, rotates it and removes it from the channel's display settings. Members see the messages, not the address.
What happens if the address leaks? Anyone who has it can post into the channel, so treat it like a password. Issue a new address from the same dialog; the old one stops working immediately. Mail to an unknown address is dropped without a bounce, so a guessed address learns nothing.
Do attachments come through? Yes, as file messages, up to 25 MB per file. They count toward the team's storage pool; when storage is full, the text still arrives and the attachment is skipped with a note.
Are inbound emails translated? Yes. The message is attributed to the external sender and translated for each reader like any other external message in the channel.
Can members reply to the sender from the channel? No. The flow is one-way, email into the channel. Replies in the channel stay in the channel.
Is email-in available on the free plan? Yes. Email to channel is available on every plan; the only plan-dependent part is the storage pool that attachments count against.
Why not just add a bot to Telegram or Slack? You can, where the tool you want to connect supports it. The difference is what you maintain afterwards: a bot needs a token or a webhook URL stored on every sender and administered on the platform, delivers with one HTTP call, and depends on that platform being reachable. An address needs nothing stored on your side, is retried by the sender's mail server when delivery fails, and has no single operator who can switch it off.
Sources: Telegram Bot API and Bots: From Beginner to Advanced (token issued by BotFather; sendMessage takes a chat id; token revocation); Slack — Sending messages using incoming webhooks (one webhook URL per channel per app; the URL is a secret); RFC 5321 §4.5.4.1 — Sending Strategy (queued mail retried until delivered or given up). Checked September 2026.