Email reaches a Slack channel through one of three routes, each with its own plan requirement, owner and way of failing. Below is what Slack’s help articles say as of 2026-11-11, what I could not confirm, and a claim rule with a reply test.
Three routes from email into Slack
Slack’s “Send emails to Slack” article lists these routes:
| Route | Plan requirement | Who can set it up | Fits |
|---|---|---|---|
| Channel or DM email address | “Paid plans” | Any channel member by default; owners and admins can restrict it | Mail that belongs to one shared channel |
| Personal forwarding address | “Available on all plans” | “All members (by default)” | One person’s inbox |
| Email add-ons (Gmail, Outlook) | “All plans” | The user, plus a Google Workspace admin for Gmail if needed | Mail that must stay in the mailbox, with selected messages shared into Slack by hand |
The add-on requirements are narrower than the table suggests. For Gmail, if you cannot install the add-on yourself, the article says to “ask a Google Workspace administrator at your company to approve Slack for Gmail.” For Outlook, “The Outlook email add-in is only available for Office 365,” and it needs the Exchange mail protocol, so POP/IMAP setups fail. On-premises SharePoint and Office 365 plans on a Microsoft national cloud deployment are “not currently supported.” HIPAA-compliant Enterprise organizations cannot send email to Slack at all.
Decision rules:
- If the mail belongs to one customer’s shared channel, use that channel’s address. The email then sits next to the Slack Connect conversation with the same people.
- If one support mailbox serves many customer groups, forward it to one channel per group. A catch-all channel means each email is claimed by everyone or by no one.
- If the mailbox has to stay in Gmail or Outlook and you only want to share selected messages into Slack by hand, use the add-on. It does not route mail automatically, so use a channel address or forwarding rule for routing. Check that your Outlook setup meets the Office 365 and Exchange requirements first.
- If the workspace is on the Pro plan, owners and admins cannot manage incoming emails. Business+ and Enterprise owners and admins can enable or disable them, so check the plan before you debug a forwarding rule.
Set up the channel address and the forwarding rule
On desktop, open the channel, click its name in the header, open the About tab, select “Send emails to this channel,” and click “Get Email Address.” Copy the address from there. On mobile, tap the channel name in the header and select “Copy channel email.”
Then create the forwarding rule in the support mailbox. In Gmail, click the Settings icon, choose “See all settings,” open the Forwarding tab (some layouts label it “Forwarding and POP/IMAP”), and click “Add a forwarding address.” Gmail’s help page says that after you add the address, “we send a verification link to the address,” and forwarding works only after you verify it. A Slack channel address receives that mail as a channel message, so the link should appear in the channel. That is my inference, not something either help page says, so confirm it in your test.
To forward only some messages, Gmail’s page says to “turn off automatic forwarding and set up a filter to choose which messages get sent,” with a separate filter for each forwarding address. I did not verify Microsoft’s steps for Outlook.
The failure to plan for is silent. Slack’s article says “If a conversation’s email address is deleted, emails sent to it will not be posted in Slack.” The article does not say the sender is told. A customer’s email to a deleted address simply never appears. Fix it with a standing check: once a week, send a test email from an outside account to each channel address and confirm it appears in the channel. Keep the list of addresses in one place so the check is complete.
If an address leaks, open the About tab, click “Delete Address,” and confirm with “Delete email address.” Slack’s article says owners, admins and members with permission to create email addresses can delete the address for any channel or DM they are part of. Then create a new address the same day and update the forwarding rule.
For paid plans, the article names “Enable domain allowlist for channel email addresses and personal forwarding email addresses” and says “Workspace Owners and Org Owners can create an email domain allowlist.” If your customers write from a known set of company domains, allowlist those domains. If they write from free mail providers or from dozens of unrelated domains, the allowlist will block real customers, so leave it off.
Who claims each email
A forwarded email arrives as one new message. Without a rule, two people answer the same customer, or nobody does. Use the first reply in the thread as the claim, and make it a sentence. An emoji reaction does not tell anyone who owns the thread.
A claim line that works: “Claiming this one. I’ll reply by 3 pm.” Be aware that in a Slack Connect channel the customer can read that thread, so keep internal names and notes out of it.
The rule: if nobody has claimed a thread 15 minutes after it arrives during business hours, the on-duty lead assigns it and says so in the thread, for example “Ravi, this one is yours.” Fifteen minutes is a starting value to tune against your own first-response target. It is not a benchmark.
Worked example, hypothetical numbers: a four-person team with 12 channel addresses gets 40 emails on a weekday. Mail for the Acme channel shows up in Slack at 10:02. Nobody claims it by 10:17, so Maya, the lead, assigns it to Ravi at 10:17. The 10:02 Slack post time is the earliest start the record can show, because the customer’s email may have been sent a few minutes before it posted. If it was sent at 9:58 and your SLA starts the clock at send time, the wait was four minutes longer than the Slack record shows. The 10:17 assignment does not change either start.
Replying back into the email thread
This is the part Slack’s articles do not settle. The two articles I read do not say whether a reply typed in a channel goes back to the sender as email, which address it comes from, or how the subject and threading are set. I did not run this test for this page, so do not assume an answer. Run it on a throwaway address first.
The test, once per channel address:
- Send an email from an outside personal account to the channel address, with the subject “Thread test 1.”
- Confirm the message appears in the channel.
- Reply in Slack with “Testing the reply path.” Check the outside inbox. Did it arrive, from which address, with which subject? In Gmail, open “Show original” on the reply and read the In-Reply-To and References headers.
- Reply to that message from the outside inbox. Check whether the answer lands in the same Slack thread or as a new top-level message.
Record each run in a row with the date, the channel, the sender address on the reply, the subject, whether the customer’s answer threaded, and the gap between sending and the Slack post.
Failure modes to look for: the reply comes from the channel address instead of your support address; the subject changes; or the customer’s answer arrives as a new top-level message, so the claim sits on a thread the customer has left. Under the first-response rules in the SLA guide, a new top-level customer message starts a new request with its own clock.
Decision rules, by outcome:
- If Slack replies do not reach the customer, send the answer from the support mailbox and use Slack for the claim, discussion and handoff. A reply from the mailbox might read: “Thanks for the details, Priya. The import failed on 412 rows with a blank region code. We’ve corrected the mapping and re-run the import.” Then add an internal note in the Slack thread, such as “Sent from the support mailbox at 14:20 with the re-run confirmation,” so the next person does not send a second answer.
- If Slack replies reach the customer and the customer’s answers thread back, you can reply from Slack. Repeat the test every quarter, because the behavior is not documented in the articles I read.
Before and after: the same mailbox, two workflows
| Step | Before: shared mailbox, forwarded by hand | After: one channel address per customer group |
|---|---|---|
| Arrival | One inbox. Someone copies the message into Slack when they notice it | The email posts into the channel. The Slack post time is the earliest arrival record, and the email’s sent time may be earlier |
| Claim | Whoever notices first, often unrecorded | First reply in the thread; lead assigns after 15 minutes |
| Reply | Typed in the mailbox, pasted into Slack for context | Depends on the reply test; use the mailbox until the test passes |
| Visibility | People with mailbox access | Slack’s article says “Any email sent to that channel will be visible to all members.” |
| Failure signal | The customer follows up | Weekly test email to each channel address |
The biggest change is the arrival timestamp. A message copied into Slack late starts the response clock late, so the team’s numbers look better than the customer’s experience. A channel address records when the message posted in Slack. Compare that with the email’s sent time and use whichever your SLA defines. The Slack post time is a lower bound on the customer’s wait.
I could not verify whether external members of a Slack Connect channel can see the channel email address on the About tab. Check this in a test channel with an external member before you post the address anywhere.
What the Slack pages leave open
As of 2026-11-11, the two Slack articles I read do not cover the following. Test each before you depend on it:
- Delivery delay between the customer’s send and the Slack post. I did not test this gap. Measure it with your own test emails: the sent time is in the outside inbox and the post time is in the channel.
- Attachment and message size limits for email sent to Slack.
- What happens to mail sent to an archived channel.
- Bounces, rejected mail and spam filtering. The only delivery failure message the forwarding-address section gives is “incoming emails may have been disabled for your workspace or org.” If a customer says mail never arrived, check that setting and the channel address first.
- Whether an AI agent’s reply in a thread behaves like a person’s. The articles do not mention agents. Test an agent’s replies with the same protocol, and keep claims tied to named people.
- Retention. Slack says email sent to a channel is posted in Slack and visible to all members, so treat those messages as channel messages for retention and access planning. I did not verify retention rules for email-sourced messages, so confirm your workspace’s settings with your admin.
Where a shared inbox tool fits
Weft is a support inbox for Slack Connect channels and email from your own support address. Check its current feature list before relying on it for the claim rule. A shared inbox does not change Slack’s channel-address or forwarding rules, which is why the plan and setup checks come first.
The vendor’s pricing page, read on 2026-11-11 in USD before tax, lists the Free plan at “$0” with “Up to 2 people who reply” and “Up to 3 channels: Slack Connect channels or mailboxes.” Starter is “$39” per seat per month billed annually, and Growth is “$89” per seat per month billed annually. The Starter and Growth prices are billed annually. I did not record a monthly per-seat price, so none is quoted here. “Every workspace starts with a 14-day Growth trial, no card needed.”