目錄
2026 年 9 月 22 日，Notion Mail 的 Inbox 將正式停止服務。單看公告，很容易把它理解成又一款壽命不長的 Email Client 下架，但對已經把郵件分類、常用回覆、Email-to-Task 與專案流程放進 Notion Mail 的使用者來說，真正要搬的從來不只有信件。Email 本身大多還在 Gmail，麻煩的是過去一年多慢慢養成的分類規則、Snippets、自訂 Views、提醒，以及郵件和其他工作流程之間的連接方式。
9 月 1 日，r/Notion 就出現一則很具代表性的求助。發帖者明確表示，真正捨不得的不是 AI 自動寫信，而是一鍵把 Email 轉進 Notion Task Database 的流程，以及已經設定好的 Snippets；現在希望找到一套免費、Web-based 的替代工具，卻發現很難找到完全一樣的組合。這個案例比單純問「哪個 Email App 最像 Notion Mail」更能說明問題，因為流失的其實不是收信功能，而是已經長進日常工作裡的一套操作方式。
Notion 自己對關閉原因的說法也很直接：隨著 Notion Agents 能做的事情增加，越來越多人直接把整理、回覆與收件匣維護交給 Agent，目前超過一半的 Notion Mail 使用者可以在完全不打開 Inbox 的情況下處理郵件，因此公司決定把資源集中到「讓 Agents 管理 Inbox」這條路。
這不代表傳統 Inbox 已經沒有價值，也不能從這個數字推論另外一半使用者都高度依賴 Notion Mail。Notion 沒有公布產品完整活躍用戶數、留存率或營收，所以目前無法判斷這是一個產品失敗、資源配置問題，還是單純的策略轉向；能確定的是，Notion 正在把 Email 從一個獨立操作介面，重新放回 Agent 可以搜尋、分類、草擬與執行動作的工作來源。
Notion Mail什麼時候關閉？從Skiff到Notion Mail的完整時間線
從正式推出到關閉約17個月，不是18個月
Notion 和 Email 的這段歷史可以從 2024 年 2 月 9 日開始看。當時 Notion 收購了主打隱私通訊與協作的 Skiff，Skiff Mail、Pages、Drive 與 Calendar 隨後在 2024 年 8 月停止服務，部分使用者的 Mail Forwarding 則延續到 2025 年 2 月。
2024 年 10 月 24 日，Notion 在 Make with Notion 發表會首次公開 Notion Mail Preview，當時仍標示為 coming soon；真正全面推出則是在 2025 年 4 月 15 日，主打 AI Auto Labels、Custom Views、Snippets、Notion Calendar 排程與 AI Email Drafting。
2026 年 6 月 25 日，Notion 宣布將結束 Notion Mail Inbox，並開放使用者匯出只存在 Notion Mail 裡的資料；9 月 21 日是最後保存期限，9 月 22 日 Web、Desktop 與 iOS 版本全部停止服務。從 2025 年 4 月正式 GA 到關閉約 17 個月，如果從 2024 年 10 月 Preview 開始算則接近 23 個月，所以原本的「18 個月產品生命週期」並不精確。
Notion為什麼決定關掉Mail？官方真正給出的理由是AI Agent
超過一半使用者已經不用打開Inbox處理郵件
Notion 在關閉公告裡留下了一個很關鍵的使用行為數據：超過一半的 Notion Mail 使用者，目前可以在不打開 Inbox 的情況下管理 Email。官方列出的情境包含讓 Agent 整理哪些郵件需要注意、回覆訊息，以及維持收件匣整潔，因此公司接下來會把方向集中在 Agents，而不是繼續維護一個獨立 Mail Inbox。
這和 Notion 2026 年前半年的產品方向確實接得起來。5 月 13 日推出 Developer Platform 時，Notion 表示團隊已經建立超過 100 萬個 Custom Agents，用來處理 Slack Q&A、週報、任務分流等工作，再進一步推出 Workers、External Agents 與其他開發能力，希望讓 Agent 能接觸更多外部系統與自訂邏輯。
但時間上的相關不等於「Developer Platform 推出，所以 Mail 必然被砍」。Notion 沒有公開這樣的內部決策過程。比較準確的理解是，兩項公告呈現同一個產品方向：Notion 正在增加 Agent 直接讀取資料與執行工作的能力，而傳統需要人持續停留在 Inbox 裡整理 Email 的介面，在這個方向裡重要性降低了。
Notion Mail關閉後，哪些資料會留下？
收過和寄過的Email本身不會消失
Notion Mail 一直和 Gmail 做雙向同步，因此已經收過與寄出的 Email 本來就存在 Gmail。9 月 22 日 Notion Mail 關閉後，這些郵件仍然留在原本的 Gmail Inbox，不需要為了保住歷史信件另外做完整 Mail Export。
另外，已經放進 Notion Page 裡的 Mail Blocks 不會因為 Mail App 下架而消失；Gmail AI Connector 也會繼續運作，仍可讓 Notion AI 搜尋 Gmail 或協助 Draft Reply。透過 Gmail 連線的 Agent Mail Tools，同樣不受 Notion Mail Inbox 關閉影響。
有一個比較容易被忽略的例外是 Synced Notion Mail Database Views。目前已經同步進 Notion 的 Email Records 和既有 Filtered Views 會留下，但 9 月 22 日之後不會再有新 Email 同步進來，所以 View 本身不會消失，只是資料會停在關閉當天，不再繼續更新。
9月21日前有哪些Notion Mail資料一定要另外保存？
草稿、排程信、Snippets與Auto Label Instructions只存在Notion Mail
官方列出四類需要在 9 月 21 日以前處理的資料。Drafts 要遷移到 Gmail，Scheduled Emails 同樣要移到 Gmail；Snippets 的文字內容需要匯出，Auto Label Instructions 也需要另外保存。如果這些資料到 9 月 22 日仍只存在 Notion Mail，關閉後就會永久刪除。
這裡不建議直接寫成「排程時間一定會完整自動搬過去，再到 Gmail 檢查就好」，因為官方只保證提供 Migrate scheduled emails to Gmail，沒有進一步說明所有排程狀態、時間設定與特殊條件一定原封不動轉移。遷移完成後重新確認一次 Gmail 的 Scheduled Folder 比較安全，但這屬於操作建議，不是官方承諾。
哪些Notion Mail設定就算匯出也搬不走？
Custom Views、Snippet附件與Email Reminders都需要另外處理
Notion 官方明確列出三類無法直接移到其他 Email App 的資料。第一是 Inbox 的組織方式，包括 Custom Views 與 Sorting；第二是 Snippets 上附帶的檔案，這些附件不會跟 Snippet Text 一起自動匯出，必須到 Notion Mail → Settings → Snippets 個別下載；第三則是設在 Email 上的 Reminders，目前無法轉移到 Gmail。
這三類資訊也是 Notion Mail 關閉後最難「找另一款 App 原封不動接手」的地方。Email 本身有標準協定和 Gmail 作為底層資料，但 View 怎麼排、什麼時候提醒、哪些回覆範本帶哪些附件，本來就是 Notion Mail 自己的 Product Logic。
因此，真正該保存的除了資料，還有邏輯。Custom View 無法 Export 時，可以把 Filters、Sorts、Groups 和使用目的寫成文字；Email Reminder 如果仍然有效，可以重新建立到 Calendar 或 Task System；Snippet Attachment 則在關閉以前先下載，不要只留下 Snippet Text。
為什麼社群很難找到完全對等的Notion Mail替代品？
缺少的不是Email Client，而是一整組已經綁在一起的工作方式
9 月 1 日 r/Notion 那則求助文其實把問題講得很清楚。發帖者真正依賴的是 One-click Email-to-Task，以及已經包含固定收件者與初始文字的 Snippets，AI Drafting 反而只是附加功能。
6 月關閉消息剛公布時，其他討論裡也有人特別提到 Snippets、Email-to-Notion Task、Ticketing Workflow，以及希望 Email 可以和 Project、Client、Task、Meeting 等 Notion Context 直接建立關聯。
因此，「找一款免費、Web-based、能收 Gmail 的工具」很容易；難的是同一套產品還要同時重建 Email Client、Task Bridge、Snippet Library、Custom Views 與 Notion Database Workflow。這些其實是不同問題，只是過去剛好被 Notion Mail 放在同一個介面裡。
Notion Mail關閉後，Custom Agent可以直接取代Auto Labels嗎？
可以做類似工作，但原本規則不會自動搬過去
官方 FAQ 的做法是先把 Auto Label Instructions 保存到一張 Notion Page，9 月 22 日之後再建立一個具有 Gmail Access 的 Custom Agent，讓它依照這些 Instructions 執行類似的 Labeling Workflow。這代表 Auto Label Logic 可以延續，但不是把原本的 Rule 按一下 Import 就完整移到 Agent。
Custom Agent 的 Mail Connection 目前可以 Search、Archive、Star、Delete、建立或移除 Labels、Unsubscribe、Block Sender，也可以 Draft 與 Send Email，所以從能力上確實可以重新建立不少 Inbox Automation。
不過這條路有兩個限制。Custom Agents 目前需要 Business 或 Enterprise Plan，而且每次 Run 會使用 Notion Credits，讀取內容越多、動作越多或 Trigger 越頻繁，Credits 消耗也越高。
所以「改成 Agent」不是所有 Notion Mail 使用者的無痛遷移路線。Free 或 Plus 使用者如果原本只是免費使用 Mail 的 Views、Snippets 和分類功能，為了復刻同樣的行為升到 Business，再加上 Agent Credits，成本結構已經完全不同。
已經在使用Notion Email Agent，9月22日後還會繼續跑嗎？
Gmail連線的Agent Mail Tools會留下
官方說明明確表示，已經在使用 Notion Agents 處理 Email，或已經把 Gmail、Outlook 接到 Notion 的 Workflow，不會因為 Notion Mail Inbox 下架而全部停止。Gmail AI Connector、Mail Blocks，以及透過 Gmail 連線的 Agent Mail Tools 都會繼續使用。
這裡比較需要注意的是資料來源。真正被下架的是 Notion Mail Inbox App，不是 Notion 整套 Email Capability。之後 Email 更像是一個供 Agent 與 Notion AI 使用的 Connected Source，而不是另一款需要持續打開的獨立 App。
受規範產業不能只記9月22日，HIPAA的官方轉換期限其實更早
Notion 特別提醒，Regulated Environment 可能需要在一般 Shutdown Date 以前完成遷移。如果組織依賴 Notion Mail 的 HIPAA Coverage，官方要求的規劃日期是 2026 年 6 月 30 日以前完成 Transition，也就是截至目前 9 月已經過了這個日期。
所以醫療或其他有明確 Compliance Requirement 的團隊不應該繼續把 9 月 21 日當成唯一 Deadline。還在使用 Notion Mail 的組織應直接確認內部 Admin、IT 或 Compliance Team 已經如何處理現有資料與工作流，而不是等到 App 真正關閉前一天才開始搬。
Notion Mail關閉前，9月21日以前可以先完成哪些事？
第一件事先救資料，不要先忙著挑新App
在選替代工具以前，應該先處理確定會消失的內容：Drafts、Scheduled Emails 移到 Gmail；Snippets 和 Auto Label Instructions 匯出；Snippet Attachments 手動下載；仍然有效的 Email Reminders 重新寫進 Calendar 或 Task System。Custom Views 雖然無法搬走，也可以把每一個 View 的 Filters、Sorting、用途與每天怎麼使用先記下來。
如果工作流程依賴 Synced Notion Mail Database，也要特別標記 9 月 22 日這個切點，因為舊資料還能看，新 Email 卻不會再進來。沒有另外補一條同步流程的話，最容易發生的不是 Database 消失，而是工作區看起來一切正常，幾天後才發現新信全部沒進去。
路線一：繼續留在Notion，用Gmail Connector和Custom Agent重建流程
這條路適合原本就使用 Business／Enterprise，而且 Email 最終需要進入 Notion Projects、Tasks 或其他 Database 的團隊。原本的 Auto Label Instructions 可以先保存到 Notion，再轉成 Agent Instructions；Mail Connection 則可以讓 Agent Search、Manage Labels、Archive、Draft 或 Send。
優點是 Email 和其他 Notion Context 仍然留在同一個工作環境，而且官方明顯仍在投資這條產品線；缺點則是 Custom Agent 不是免費替代品，還要重新設計 Triggers、Instructions、Tools & Access，並管理 Credits。
另外，原本喜歡手動整理 Inbox 的使用者也需要接受一個很實際的差異：Agent 可以重建「規則」，卻不會自動重建原本的視覺介面。Custom Views、Sorting 和那種打開 Mail 就能看到分類好的工作空間，仍然是已經消失的產品體驗。
路線二：回到Gmail，把Email本身和Notion工作流拆開
如果需求主要是 Email 穩定收發、Labels、Search 與簡單 Filters，直接回 Gmail 是遷移成本最低的選擇，因為歷史 Email 本來就在那裡，不需要再做 Mailbox Migration。
原本的 Auto Label Instructions 可以當成重新建立 Gmail Filters 的規格，常用回覆也能依實際需求重建成 Gmail Templates 或另外保存成文字片段。不過兩者不是一鍵轉移，Notion Mail 的 AI Label Instructions 也不一定能逐條翻成 Gmail 的條件式 Filter。
這條路最大的缺口是 Email-to-Notion Workflow。Gmail 本身不會自動補回一鍵轉 Task、寫入 Database 或其他 Notion 關聯，如果這才是原本最重要的功能，就還需要 Notion Worker、Automation、Agent 或其他 Integration 接上去。
路線三：換第三方Email Client，但先確認真正要補的是哪一層
如果核心需求是 Custom Inbox Views、Keyboard Workflow、Snippets 或快速 Triage，換另一套 Email Client 很合理，但比產品 Feature List 更重要的是先把原本使用 Notion Mail 的動作列出來。
例如 Email 本體可以留在 Gmail，另一套 Client 只負責呈現；Snippets 可以由另一個 Text Expansion Tool 管理；Email-to-Task 則交給 Automation。這樣不一定像 Notion Mail 一樣所有東西都在同一個畫面，但每一層可以分開替換，下一次其中一個服務關閉時，也不用整套系統重新搬一次。
評估第三方 Client 時，可以特別確認資料是不是仍以 Gmail／IMAP 為 Source of Truth、Rules 和 Templates 能不能 Export、服務停止後是否仍能回原生 Gmail，以及授權範圍是不是超過實際需要。
最值得留下的不是Notion Mail設定，而是工作流規格
Notion Mail 這次最麻煩的地方不是 Email 會消失，因為郵件本體本來就留在 Gmail；真正難搬的是那些沒有標準格式的東西，例如「哪類郵件先看」「哪些寄件人要進哪個 Project」「哪些情況使用哪個回覆」「收到什麼內容時要建立 Task」。這些規則如果只活在某個產品的設定頁，一旦產品關掉，就只能靠記憶重新拼一次。
比較實際的做法，是把重要 Workflow 留一份文字規格，不需要寫成很複雜的 SOP，只要能看懂 Input、分類條件、需要的 Action 和最後放到哪裡即可。之後不論換 Gmail Filter、Custom Agent、Worker 還是另一款 Email Client，這份文件都能拿來重新建。
Notion Mail 的結束也不需要被放大成「所有介面層產品都會被 Agent 淘汰」。目前真正有證據支持的只有 Notion 自己正在把 Email Workflow 往 Agent 移，而且超過一半 Notion Mail 使用者已經採用不打開 Inbox 的工作方式。其他產品會不會走同一條路，還是要看各自的使用行為與商業模式。
但有一點已經很明顯：工具可以下架，工作習慣卻不會跟著自動搬家。9 月 22 日以前最值得保存的，因此不只是幾份 Draft 和 Snippets，而是那些已經證明真的會每天使用的規則。下一套工具長什麼樣子可以再選，至少不用從零開始回想原本的工作到底是怎麼跑的。
常見FAQs
不能直接假設會自動留下。官方要求使用者在 9 月 21 日以前主動把 Drafts 與 Scheduled Emails Migrate to Gmail，如果沒有完成保存，9 月 22 日後會永久刪除。
Snippet 的文字內容可以 Export，但掛在 Snippet 上的 Files 不會自動跟著轉移，需要到 Notion Mail → Settings → Snippets 手動下載。
不能一鍵搬。官方建議先把 Auto Label Instructions 保存到 Notion Page，關閉後再使用有 Gmail Access 的 Custom Agent 建立類似 Labeling Workflow。
不是。Custom Agents 目前需要 Business 或 Enterprise Plan，而且每次執行會使用 Notion Credits，因此是否划算要看執行頻率、讀取內容量與需要的 Tool Calls。
不會。已經同步進 Notion 的 Email Records 和既有 Views 仍然保留，但 9 月 22 日以後不再同步新 Email，所以資料庫會停在關閉前的狀態。
不會因為 Notion Mail Inbox 關閉就一起停止。Gmail AI Connector、既有 Mail Blocks，以及透過 Gmail 連線的 Agent Mail Tools 都會繼續運作。
不是。Notion 官方要求依賴 HIPAA Coverage 的組織應規劃在 2026 年 6 月 30 日前停止使用 Notion Mail，因此這個日期目前已經過去。還在使用的相關組織應直接和內部 Admin 或 Compliance Team 確認處理方式。
不會。Notion Mail 一直和 Gmail 雙向同步，因此已收與已寄 Email 本來就存在 Gmail，關閉後歷史郵件仍留在 Gmail。需要另外處理的是 Drafts、Scheduled Emails、Snippets 與 Auto Label Instructions。
Notion Mail 的 Web、Desktop 與 iOS Inbox 會在 2026 年 9 月 22 日停止服務，9 月 21 日是保存 Notion Mail-only Data 的最後一天。所有方案都受影響。