小村軟體有限公司
日本語 English 한국어 繁體中文 العربية
聯絡我們
選單

不被特定服務綁住的中小企業群發郵件設計方式

· · 郵件派送, 既有資產活用, 洽詢動線改善, Web 製作・SEO, B2B

「不想增加專用的 EDM 服務，想用既有的網域與官網發送數十至數百封的通知郵件」。 這個問題的實務答案，不是 Bcc 一次塞爆，而是做一套最小派送平台：對每位收件人個別寄送、訂閱管理、退訂、SPF / DKIM / DMARC 都齊備。

本文所說的「不使用特定服務」並不是「什麼都不用」。 指的是：SMTP 這個標準、訂閱者清單、範本、退訂動線由自家掌握，發送管道本身之後能隨時更換。

本文前提是 寄給既有客戶、會員、資料索取者、電子報訂閱者等有某種關係或同意的對象。 不是把公開信箱蒐集起來亂寄的情境。廣告郵件有法律前提，品質面上這種做法也撐不久。12

以下內容基於 2026 年 4 月時點能查閱的日本「特定電子郵件法」公開資訊，以及 Google／Yahoo／Outlook 的寄件者準則。12345

1. 先下結論

中小企業要對外發群發郵件，實務上大致採取這 4 點：

  1. 對每位收件人個別寄送
    不要用 Bcc 一次塞爆，改以 1 封一封寄的前提切好佇列。
  2. 訂閱狀態由自家保管
    用自家的資料庫或 CSV 明確管理 active、unsubscribed、bounced。
  3. 自動接受退訂
    不要靠人工處理「不要再寄給我」。在信件本文放顯眼的連結，可能的話加 List-Unsubscribe。345
  4. 做好寄件網域認證
    SPF / DKIM / DMARC、反解析 PTR、TLS 一起到位。就算能寄出，缺這些也會被判為難以送達。345

總之，這不是郵件軟體怎麼操作的問題，而是派送平台的問題。

如果把「想群發」理解成「在 To / Cc / Bcc 塞一大堆人」就會崩。 真正需要的是：

  • 可以寄給誰
  • 不能再寄給誰
  • 是基於什麼目的取得同意的
  • 退訂要怎麼接
  • 寄件端是否被信任

2. 為什麼 Bcc 一次塞爆 不夠用

對外發群發郵件時，Bcc 看似簡單，但運營上該有的東西它都沒有。

問題 會怎樣 之後會被什麼卡住
追不到退訂 「請別再寄」會用回信或電話回來 下一次派送容易誤發
沒有 bounce 管理 對不存在的地址照寄 信譽下滑
沒有同意紀錄 說不出來何時、在哪同意的 法務／客訴很弱
發送類型混雜 行銷信與通知信從同一個箱寄出 日常收發訂單的信也會受影響
速度無法控制 一次全塞出去 容易觸發限制或被判垃圾信
過度依賴個人 靠某人與他的郵件軟體操作 不好交接

最可怕的是，「能寄出」這件事會造成一種「系統已經成立」的錯覺。 但實際上沒有退訂管理、沒有防止 bounce、沒有同意紀錄、沒有寄送紀錄，人數稍微一增加，人工流程就垮了。

Bcc 不是完全不能用。 小範圍的社內聯絡、關係封閉的小型會員通知、臨時的一次性聯絡，有時還行。 但作為 對外持續性發送的底層，它真的太弱。

3. 「不依賴特定服務」實際上是什麼意思

常見誤解：「不用服務」= 「全部手做」，其實並不是。

實務上，只要把下列 3 件事留在自家，就能大幅避免 vendor lock-in。

3.1 自家要持有的東西

  • 訂閱者資料
    • 郵件地址
    • 同意時間
    • 同意取得來源
    • 派送類別
    • 退訂狀態
  • 派送規則
    • 什麼寄給誰
    • 以什麼速度寄
    • bounce 與退訂如何反映
  • 寄件者 identity
    • 寄件網域
    • SPF / DKIM / DMARC
    • 接收回覆的郵件信箱
    • 退訂 URL

3.2 可以之後替換的東西

  • 實際丟送的 SMTP relay
  • 管理介面的實作方式
  • 派送佇列的實作位置
  • 記錄的保存位置

也就是說，「不依賴特定服務」的核心在於 不把派送規則與狀態完全交給對方。

  • 收件清單在自家 DB
  • 退訂 URL 掛在自家網域
  • 標題與本文樣板在自家
  • SMTP 出口之後可以換

有這樣的架構後，一開始用既有郵件基礎，之後也能無痛換到別家發送管道。

4. 中小企業的實際組合

4.1 最小元件

每次發數十到數百封規模，一開始不需要搞很大，但下列元件最好還是拆開：

  1. 訂閱者表
  2. 抑制（黑名單）表
    • 退訂
    • hard bounce
    • 投訴
  3. 派送範本
    • 標題
    • 本文（HTML / text）
    • 派送類別
  4. 派送佇列
    • 每位收件人的狀態
    • 寄送結果
    • 重試次數
  5. SMTP relay
    • 沿用既有郵件基礎
    • 或自架
  6. 紀錄
    • 什麼時候寄給誰
    • 成功／失敗
    • 退訂 / bounce 反映狀況

開信率、點擊率這種比較進階的量測，一開始不是必備。 真正該先確保的是：能安全地寄、能喊停、能說明。

4.2 派送對象表要放的欄位

至少要有這些：

欄位 例 理由
email user@example.com 收件人本身
status active / unsubscribed / bounced 判斷能否寄
consent_at 2026-03-20 12:34:56 何時取得同意
consent_source 表單 / 展會 / 既有合約 / 手動輸入 從哪來的可解釋性
consent_purpose 電子報 / 研討會 / 維護通知 同意用於什麼派送
unsubscribed_at 2026-03-29 09:10:11 退訂的佐證
last_bounce_at 2026-03-30 08:00:00 判斷是否再送
notes 業務轉介 / 既有客戶 補充

即使最初的資料來源是 Excel 或既有客戶名冊，也要先拆到這個層級。 尤其重要的是：抑制資訊一定要優先於任何來源。

舉例來說：業務 Excel 裡還留著某人的地址，但抑制表上是 unsubscribed，就不可寄。 沒有這條規則，退訂過的人會從別條路徑再被塞回去，事故就發生了。

4.3 架構圖

flowchart LR
    A[官網 / 訂閱表單] --> B[訂閱者表]
    A2[既有客戶名冊 / 會員名冊] --> B

    C[派送範本<br/>標題 / HTML / text] --> D[派送佇列]
    B --> D
    E[抑制表<br/>退訂 / bounce / 投訴] --> D

    D --> F[SMTP relay<br/>既有郵件基礎 或 自架 relay]
    F --> G[收件人]

    G --> H[退訂 URL]
    G --> I[回覆]
    G --> J[bounce / 投訴]

    H --> E
    J --> E
    I --> K[運維窗口]

    L[SPF / DKIM / DMARC / PTR / TLS] --> F

這張圖的關鍵在於 發送管道並不是中心。 核心是 訂閱者表、抑制表、派送佇列。

SMTP relay 只是出口。 把出口獨立出來之後，將來要換發送服務，過去的退訂與同意紀錄也不會一起被丟掉。

5. 規模別做多少

5.1 每月 1 次、數十封

這種規模下，最小配置常常已經夠：

  • 專用的套版（合併欄位）
  • 每位收件人個別寄送
  • 退訂 URL
  • 寄送紀錄
  • SPF / DKIM / DMARC 的設定

關鍵是 人少也不要退回 Bcc。 哪怕 50 人以下，只要是對外持續派送，先把「個別寄送 + 狀態管理」做起來，之後比較省。

5.2 每月數次、數百封

這個階段再加上這些會比較穩：

  • 派送佇列
  • 派送速度控制
  • bounce 反映
  • 退訂即時反映
  • 發送專用子網域
  • 審批流程
    • 測試寄送
    • 正式派送
    • 結果確認

另外，要把日常的人際往來信件與行銷／通知郵件分開。 Google 建議依訊息類型區分 From 位址或 IP；Yahoo 也提醒 bulk / marketing 不要與 transactional / alerts 混用同 IP 或 DKIM 網域。34

例如這樣分就能整理不少：345

  • 訂單確認、帳單系：billing@example.com
  • 系統通知、維護公告：notice@example.com
  • 電子報、活動通知：news@example.com

5.3 單日接近數千封時

走到這規模後，「不依賴特定服務」常常會變成目的本身。

Google 針對 Gmail 明確要求：單日超過 5,000 封 的寄件者要做 SPF / DKIM / DMARC、From 網域對齊、單鍵退訂等。 Outlook 對單日超過 5,000 封的網域也要求 SPF / DKIM / DMARC，不符的訊息可能被判垃圾信或被拒收。35

到這個量級，真正要面對的是：

  • IP 信譽
  • 投訴率
  • bounce 率
  • 退訂處理
  • 擴張量的節奏
  • 監控

這個階段時，改用專用服務反而比較便宜 的情境也不少。

換句話說，本文的結論不是「無論量多大都要自己做」，而是 數十至數百封規模，把狀態與規則掌握在自家手上的小型派送平台剛好。

6. 法務與發送品質上，最低限度要守的事

6.1 同意

廣告與宣傳郵件原則上需要事前同意。 日本的「迷惑郵件相談中心」也明確指出：原則上未經事前同意不得發送廣告宣傳郵件。2

Google 與 Yahoo 也要求：只能寄給明確希望收的人、不可使用購買來的名單、避免預設勾選的 opt-in。34

實務上至少要保留：

  • 同意時間
  • 同意來源
  • 同意用於什麼派送
  • 說明文字
  • 取得同意的畫面或文案

日本法律在對公開於網站上的事業用信箱上有例外條款。 但 不要把派送基礎建立在這個例外上。 從客訴、送達率、信譽、實際回應率，任一角度都不耐久。2

6.2 標示義務與退訂

就算有同意，寄件者仍有標示義務。 迷惑郵件相談中心要求至少要放：2

  • 寄件者名稱
  • 接收拒收通知的郵件地址或 URL
  • 可以拒收的陳述
  • 寄件者地址
  • 客訴／聯絡窗口

Footer 最起碼要像這樣：

寄件者: 株式会社○○
退訂: https://example.com/unsubscribe/xxxxx
如需停止收件，請透過上方 URL 辦理。
地址: 東京都...
聯絡: support@example.com

另外主要收件方很在意「退訂好不好做」：

  • Google：大量寄件者需要一鍵退訂3
  • Yahoo：要求／建議 List-Unsubscribe 與本文內連結，並於 2 天內生效4
  • Outlook：建議易找到且可用的退訂機制5

所以至少要把本文退訂連結顯眼呈現，並盡量加這些標頭：34

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 認證與送達率

主流收件方現在關注的已經不是「能不能寄出」，而是「有沒有通過認證」。

Google 的公開準則要求：3

  • 所有寄件者：SPF 或 DKIM
  • 大量寄件者：SPF + DKIM + DMARC
  • PTR（正／反解一致）
  • TLS
  • 低垃圾郵件率
  • 大量寄件者：一鍵退訂

Yahoo 方面：4

  • SPF / DKIM / DMARC
  • DMARC alignment
  • 有效的正／反 DNS
  • 退訂
  • spam rate 低於 0.3%
  • opt-in
  • bulk 與 transactional 分開

Outlook 對大量寄件者也有要求：5

  • SPF pass
  • DKIM pass
  • DMARC（至少 p=none，並與 SPF 或 DKIM 對齊）
  • 真實的 From / Reply-To
  • 退訂
  • 清單衛生（list hygiene）

最低限度的檢查表：

項目 最少要做的事 目的
寄件網域 設定 SPF / DKIM / DMARC 防偽冒、提升送達率
寄件伺服器 能正確反解、固定環境、啟用 TLS 不拖垮收件方信任
From / Reply-To 真實存在、能收回覆的地址 能接客訴與退訂請求
退訂 本文連結 + List-Unsubscribe 降低投訴率
名單品質 僅保留 opt-in、淘汰無效地址 守住信譽
發送速度 不要一次暴衝，維持固定節奏 避免被限速或被判垃圾信
監控 追蹤 bounce / spam rate / complaints 早點止損

Google 建議：增量時要 從小量開始、以反應良好的對象為主、保持穩定節奏。 突然暴衝或一次翻倍，容易觸發限制或造成信譽下降。3

7. 推進實作的順序

想以最小化起步時，這個順序實際：

  1. 把郵件種類分開
    • 通知信
    • 電子報
    • 活動通知
    • 既有客戶通知
  2. 做訂閱表單或同意取得流程 在官網把說明與取得同意做在一起。 「會寄什麼、寄多頻繁」要寫清楚。4
  3. 訂閱者表與抑制表分開 這件事先做，之後換任何平台都不會亂。
  4. 決定寄件用的網域／子網域 例如 news.example.com 或 mail.example.com。 至少不要和日常訂單信、個人信箱混在一起。34
  5. 設定 SPF / DKIM / DMARC / PTR / TLS 自寄的話這塊最優先。 不要用「無法反解」的環境當寄件基礎。34
  6. 管理介面不用華麗 需要的是：
    • 編輯標題
    • 編輯本文
    • 測試寄送
    • 正式寄送
    • 派送對象預覽
    • 設定批次大小
    • 結果確認
  7. 第一次只寄少量 對既有客戶或反應好的訂閱者，維持固定節奏。 沒事再擴大對象。3
  8. 最優先把退訂與 bounce 的反映打通 連這兩個都沒動起來前，先別管開信率。

這樣規劃就能從「反正寄得出去」升級成 「能長期不出事地持續寄」。

若要連訂閱表單、同意文案、退訂頁面都一起重新審視，可與 官網製作 一起整理。 若前提是要對接既有客戶名冊、內部系統、Windows 工具，從 技術諮詢／設計審查 切分職責會更安全。

8. 常見的失敗

常見問題大致如下：

  • 把人際通訊信件與行銷／通知郵件從同一個寄件源寄出
  • 把同意只用 free text 的備註管理
  • 退訂靠回信的人工處理
  • 把舊名片名單整批塞入
  • 突然用史上最大量寄
  • 在通知信裡混入行銷文案
  • 把寄送結果停在「寄件 API 成功」
  • 既有客戶名冊的優先度高過抑制表

最後一條真的很容易翻車： 業務方的 Excel 還有某人的 email，但他已經退訂電子報。 如果沒有「退訂資訊永遠優先」的規則，他就會從別條路徑再被寄回去。

9. 總結

中小企業若想不用特定服務就發相當數量的郵件，要思考的不是「按哪顆按鈕」。

真正需要的是這 5 點：

  • 不用 Bcc，改為 每位收件人個別寄送
  • 訂閱者表 與 抑制表
  • 自動接受退訂的動線
  • SPF / DKIM / DMARC / PTR / TLS
  • 通知系與行銷系分離的運維

一句話：「擁有寄信手段」不是首要，「擁有寄信規則」才是。

每次數十到數百封規模，不用專用服務也完全跑得起來。 即使如此，做法也不是「用郵件軟體一次塞大家」，而是 把它當成一座小型派送平台來設計。

相關文章

參考資料

  1. 日本消費者廳，特定電子郵件之發送適正化等相關法律（特定電子郵件法） ↩ ↩2

  2. 迷惑郵件相談中心，特定電子郵件法 ↩ ↩2 ↩3 ↩4 ↩5

  3. Google Workspace Admin Help, Email sender guidelines ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  4. Yahoo Sender Hub, Sender Best Practices ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  5. Microsoft Community Hub, Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

為什麼郵件安全裡 PPAP 行不通？正確的做法是什麼？

本文整理為什麼把附件壓成有密碼的 ZIP 後再用同一條郵件路徑寄出密碼的 PPAP 在當今環境下並不安全，並從竊聽防護、寄錯防護、惡意程式檢查與真實性等角度說明問題，再以 TLS、S/MIME、附帶驗證的下載等實務替代方案，協助讀者重新設計符合目的的郵件與檔案交付控制。

閱讀文章

偽隨機數與真正隨機數的差異 - 如何區分的整理

本文整理偽隨機數與真正的隨機數差異，重點不在輸出外觀而在產生器結構：一般 PRNG 重視可重現性、CSPRNG / DRBG 主打不可預測性、NRBG 則以物理熵源為基礎。文中說明 seed 與 reseed、health test 的角色，並給出資安、模擬、抽籤等用途的選...

閱讀文章

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

聯絡我們

公開連結

回到部落格一覽