台灣個資法下的 B2B 冷郵件合規指南（2026 版）

台灣《個人資料保護法》並未全面禁止 B2B 冷郵件，但要求你在蒐集階段有特定目的與法定事由、在首次利用前完成告知、並在第一次行銷時提供免費的拒絕方式。做到這三件事並留下稽核紀錄，冷郵件就站得住腳。

多數在台灣做 outbound 的團隊——不論是總部在倫敦、舊金山，還是把亞太業務中心設在香港、新加坡的公司——對台灣個資法的理解停在「台灣沒有反垃圾郵件法，所以可以隨便寄」。這個結論一半對、一半非常危險。台灣的《濫發商業電子郵件管理條例》確實從草案階段就未完成立法，但《個人資料保護法》（下稱個資法）本身就足以規範冷郵件的整條流程，而且 2023 年修法後的罰鍰上限，已經不是「寄錯信道個歉」的量級。

這份指南從法律要件、名單來源邊界、跨境差異、到可稽核的技術流程一路寫下來，目標是讓你的 SDR 團隊能繼續做 outbound，但不會在某個客戶投訴時才發現整套流程沒有任何紀錄可以拿出來。

台灣個資法到底管不管 B2B 名單？

個資法第 2 條定義的「個人資料」，是指自然人的姓名、出生年月日、聯絡方式等得以直接或間接識別該個人之資料。關鍵字是「自然人」——法人不在保護範圍內。

這條界線在實務上非常好用，但也常被誤用。

不受個資法保護的資料

• [email protected]、[email protected] 這類職務信箱，未連結到特定自然人時，通常被視為法人的聯絡資訊。
• 公司統一編號、公司地址、總機電話。
• 公開於商業司商工登記公示資料的公司登記事項（董監事姓名仍屬個資，需另行判斷）。

受個資法保護的資料

• [email protected] 這種以個人姓名構成的公司信箱——即使是工作用途，仍可間接識別特定自然人。
• 「王經理，採購部，分機 218」這類職稱＋姓名＋聯絡方式的組合。
• 從 LinkedIn、名片交換、展會登記表取得的姓名與職稱。

換句話說，B2B 名單裡真正有價值的那一部分——有名有姓、寄得到決策者的聯絡資料——幾乎全部落在個資法的射程內。以「我們只做 B2B」為由主張不適用個資法，在絕大多數 outbound 情境下站不住腳。

值得注意的是，歐盟 GDPR 的處理方式相近：Recital 14 明確排除法人資料，但只要 email 中含有姓名即構成 personal data（依歐洲資料保護委員會 EDPB 對個人資料範圍的一貫見解）。台灣與歐盟在這一點上的判準幾乎一致，這也讓一套跨市場的名單治理流程有機會共用。

合法寄送冷郵件的四個法律要件

一、蒐集必須有特定目的與法定事由（第 19 條）

非公務機關蒐集或處理個資，依個資法第 19 條，必須有特定目的，並符合列舉事由之一。B2B outbound 最常倚賴的是兩款：

1. 第 19 條第 1 項第 7 款：個人資料取自「一般可得之來源」，且當事人對該資料之禁止處理或利用，無顯然更值得保護之重大利益。
2. 第 19 條第 1 項第 2 款：與當事人有契約或類似契約之關係，並已採取適當之安全措施。

「一般可得之來源」是冷郵件的主要立足點——公司官網公開的團隊頁面、公開演講的講者資訊、政府公示資料庫。但這一款有第二個門檻：當事人是否有「顯然更值得保護之重大利益」。實務上這代表你不能無限擴張使用範圍，例如把某人公開在學術網站的聯絡方式拿去推銷完全無關的金融商品。

二、間接蒐集的告知義務（第 8 條、第 54 條）

這是台灣個資法最常被忽略、也最容易被證明違反的一條。

個資法第 54 條規定：非由當事人本人提供之個資（也就是你從網路、名單商、第三方取得的），應於處理或利用前，向當事人告知第 8 條第 1 項所列事項。第 8 條要求告知的內容包括：

1. 蒐集者的名稱
2. 蒐集之目的
3. 個人資料之類別
4. 利用期間、地區、對象及方式
5. 當事人得行使的權利及方式（查詢、複製、補充更正、停止蒐集處理利用、刪除）
6. 當事人得自由選擇提供個資時，不提供將對其權益之影響

好消息是，第 54 條允許你在首次利用時併同告知。對冷郵件而言，這意味著第一封信本身就可以是告知的載體——前提是告知內容完整，而不是一行「若不願收到請回覆退訂」。

三、行銷利用與拒絕權（第 20 條）

個資法第 20 條第 2 項與第 3 項規定：非公務機關利用個資行銷時，當事人表示拒絕接受行銷後應即停止利用；且首次行銷時，應提供當事人表示拒絕接受行銷之方式，並支付所需費用。

「支付所需費用」的意思是退訂機制必須對收件人免費——不能要求對方打付費電話、寄實體回函、或註冊帳號才能退訂。一個一鍵退訂連結，或明確的「回覆本信件並註明『取消』」都可以滿足。

四、正確性與保存期限（第 11 條）

第 11 條要求個資應維持正確，且特定目的消失或期限屆至時應主動或依當事人請求刪除、停止處理或利用。對名單經營而言，這代表：

• 退信（hard bounce）超過一定次數的聯絡人應標記為失效並清理。
• 明確表示離職、換公司的聯絡人資料應更新或刪除。
• 名單應該有保存期限政策，而不是無限期躺在 CRM 裡。

名單來源的灰色地帶在哪裡？

公司官網爬取

風險相對低。公司主動公開在官網的「聯絡我們」或團隊頁面，屬於一般可得之來源，且公開目的本身就包含商業聯繫。但爬取行為本身仍須注意網站的 robots.txt 與服務條款——那是另一個法律層次（契約與著作權），不因個資法合規而免除。

名單商購買

這是最高風險的來源。你買到的名單，賣方是否合法蒐集、是否已完成第 8 條告知，你無從驗證。而個資法的責任會落在你這個利用者身上。若要採購，至少要求供應商在合約中載明資料來源、蒐集時的特定目的、以及賠償條款，並保留書面證明。

LinkedIn 與社群平台

LinkedIn 的使用者條款明確禁止自動化擷取資料。即使個資法上可能主張「一般可得之來源」，平台契約層面的違反仍會導致帳號封鎖與潛在求償。使用 LinkedIn Sales Navigator 的原生功能導出，與用第三方 scraper 大量抓取，法律風險完全不同。

展會與活動名單

如果是主辦方提供的參展者名單，你仍是間接蒐集，仍須依第 54 條告知。若是你自己攤位收到的名片，且名片交換時有告知用途，則屬直接蒐集，事由更明確。

違規的代價有多高？

依《個人資料保護法》（法務部全國法規資料庫公布版本）：

• 第 48 條：非公務機關違反第 8 條告知義務、第 20 條行銷拒絕義務等規定，經限期改正而未改正者，處新臺幣 2 萬元以上 200 萬元以下罰鍰；情節重大者得直接處罰。2023 年 5 月修法後，違反安全維護義務且屆期未改正者，按次處新臺幣 15 萬元以上 1,500 萬元以下罰鍰。
• 第 41 條：意圖為自己或第三人不法之利益或損害他人之利益，違反相關規定足生損害於他人者，處 5 年以下有期徒刑，得併科新臺幣 100 萬元以下罰金。
• 第 29 條：被害人得請求損害賠償；不易證明實際損害額時，得請求每人每一事件新臺幣 500 元以上 2 萬元以下；同一原因事實之賠償總額以新臺幣 2 億元為上限。

第 29 條的團體訴訟機制是真正的尾部風險。一份 5 萬筆的名單如果被認定整批違法利用，即使以法定最低額計算，理論曝險也是千萬元等級。

監管面也在改變。行政院已成立個人資料保護委員會籌備處，推動設立獨立的個資監管機關，取代目前由各目的事業主管機關分散執法的架構。過去個資法執法密度偏低的狀態，不應該被當成長期假設。

台灣與其他亞太市場的差異在哪？

如果你的 outbound 名單涵蓋整個亞太，用一套流程打天下會出事。各市場的預設立場差異很大。

台灣

Opt-out 為主。合法取得＋完整告知＋首次行銷提供免費拒絕方式，即可寄送。無專法規範商業電子郵件本身。

香港

《個人資料（私隱）條例》第 VIA 部採 opt-in。使用個資作直接促銷前必須通知當事人並取得其「不反對」的明示回應。依個人資料私隱專員公署說明，未依規定使用個資作直銷可處罰款 50 萬港元及監禁 3 年；若將個資提供第三方作直銷牟利，最高可處罰款 100 萬港元及監禁 5 年。香港的門檻明顯高於台灣。

新加坡

PDPA 對電子郵件行銷採同意原則，但 Do Not Call Registry 只涵蓋電話號碼，不涵蓋 email；B2B 電子郵件另受 Spam Control Act 規範，允許 opt-out 模式但要求標示 <ADV> 或等效標記並提供退訂。2020 年修法後，依 Personal Data Protection Commission 公布內容，財務罰則上限提高至新加坡年營業額的 10% 或 100 萬新幣（取其高者）。

澳洲

Spam Act 2003 是嚴格的 opt-in 制度，僅有有限的推定同意（inferred consent）空間，例如對方公開發布了與其職務相關的工作信箱且未聲明拒絕廣告。依 Australian Communications and Media Authority 的執法紀錄，近年對大型企業的垃圾訊息裁罰已達數百萬澳元量級。

日本與韓國

日本《特定電子郵件法》原則採 opt-in，但對公開於網站之營業用郵件地址有例外。韓國《情報通信網法》對營利性廣告訊息要求事前同意，且夜間發送另需額外同意——是亞太最嚴格的市場之一。

實務建議

把台灣當成「可 opt-out 的市場」，把香港、澳洲、韓國當成「必須 opt-in 或有明確例外才寄」的市場，然後在 CRM 的聯絡人層級記錄 jurisdiction 與 legal_basis 兩個欄位。這是唯一能規模化的做法。

怎麼把合規變成可稽核的技術流程？

法遵最大的失敗模式不是「不知道規定」，而是「做了但無法證明」。以下是可以直接落地的四個元件。

1. 在資料模型上記錄法律基礎

每一筆聯絡人都應該帶著它的來源與事由。以 HubSpot 或 Salesforce 自訂屬性為例，最少需要這幾個欄位：

1{
2  "contact_id": "c_88213",
3  "email": "[redacted]",
4  "jurisdiction": "TW",
5  "source_type": "public_company_website",
6  "source_url": "https://example.com.tw/about/team",
7  "collected_at": "2026-01-14T09:22:11+08:00",
8  "legal_basis": "PDPA_TW_Art19_1_7",
9  "purpose_code": "040",
10  "notice_sent_at": "2026-01-16T10:03:00+08:00",
11  "notice_template_version": "tw-notice-v3",
12  "opt_out_at": null,
13  "retention_until": "2028-01-14"
14}

purpose_code 對應的是法務部公告的「個人資料保護法之特定目的及個人資料之類別」代號表——B2B 行銷常用的是 040（行銷）與 090（消費者、客戶管理與服務）。在系統裡存代號而非自由文字，稽核時省下大量爭論。

2. 讓第一封信同時是告知書

第 54 條允許首次利用時併同告知。實作上，在信件 footer 放一段固定區塊：

1【個人資料告知事項】
2蒐集者：○○股份有限公司
3蒐集來源：貴公司官方網站公開之聯絡資訊
4特定目的：040 行銷
5個資類別：C001 辨識個人者（姓名、公務電子郵件）
6利用期間：自蒐集之日起 2 年 / 地區：台灣、香港、新加坡
7利用對象：本公司及本公司委外之行銷服務供應商
8您得依個資法第 3 條，向本公司請求查詢、閱覽、複製、補充更正、
9停止蒐集處理利用或刪除。聯絡方式：[email protected]
10如不願再收到本公司訊息，請點選此處（免費）：{{unsubscribe_url}}

重點是「利用地區」要誠實填寫。如果你的 CRM 在美國、行銷自動化在新加坡、SDR 團隊在台北與胡志明市，那就是跨境利用，應如實揭露。

3. 建立全域 suppression list

退訂必須跨工具生效。SDR 用 Outreach、行銷用 HubSpot、客服用 Zendesk，三邊各自退訂等於沒有退訂。做法是建立單一 suppression 表，所有發送前查詢：

1-- 發送前檢查：排除已退訂、已逾保存期限、未完成告知者
2SELECT c.contact_id, c.email
3FROM contacts c
4LEFT JOIN suppressions s
5  ON lower(s.email) = lower(c.email)
6WHERE s.email IS NULL
7  AND c.notice_sent_at IS NOT NULL
8  AND c.retention_until > current_date
9  AND (
10    c.jurisdiction = 'TW'
11    OR (c.jurisdiction IN ('HK','AU','KR') AND c.consent_optin = true)
12  );

並把 suppression 設為永久——即使聯絡人換公司、名單重新採購，同一個 email 進來仍應被攔截。

4. 保留可重現的稽核軌跡

最低限度應保存：名單匯入批次紀錄（含來源與時間）、每次發送的模板版本與收件人清單雜湊、退訂事件的時間戳與來源。這些資料在被申訴時，是你唯一能證明「已限期改正」或「本來就合規」的東西。

AI 輔助的名單作業怎麼做才不踩線？

2026 年幾乎沒有團隊在純手工整理名單。LLM 被用來做公司研究、職稱正規化、個人化開場白生成——這些都帶來新的合規面向。

資料最小化優先。 要 LLM 幫你判斷「這家公司是否符合 ICP」，不需要把聯絡人姓名與 email 一起丟進去。把識別欄位留在本地，只送出公司名稱與產業描述。

注意模型端的資料留存。 使用公開消費級介面與使用企業版 API 的資料處理條款完全不同。OpenAI 在其 Enterprise privacy 說明中表示 API 輸入預設不用於訓練；Azure OpenAI Service 則提供區域部署選項。若你的利用地區告知寫的是「台灣、新加坡」，卻把個資送進未揭露的第三地模型，那就與告知內容不符。

個人化不等於臆測。 用 LLM 生成「我看到貴公司上個月開了台中廠」是基於公開新聞的合理利用；生成「注意到您最近在找工作」則是對個人狀態的推論，已經超出你告知的特定目的範圍。

把合規檢查也自動化。 比起事後人工抽查，更有效的是在發送 pipeline 中加一道程式化 gate：

1BLOCKED_JURISDICTIONS_WITHOUT_OPTIN = {"HK", "AU", "KR", "JP"}
2
3def can_send(contact) -> tuple[bool, str]:
4    if contact.opt_out_at:
5        return False, "opted_out"
6    if not contact.notice_sent_at and contact.jurisdiction == "TW":
7        return True, "notice_will_be_embedded"   # 第54條首次利用併同告知
8    if contact.jurisdiction in BLOCKED_JURISDICTIONS_WITHOUT_OPTIN \
9            and not contact.consent_optin:
10        return False, f"optin_required_{contact.jurisdiction}"
11    if contact.retention_until < today():
12        return False, "retention_expired"
13    return True, "ok"

這段邏輯的價值不在於程式本身，而在於它讓「合規規則」變成版本控管的程式碼，而不是一份沒人看的 PDF。

最常見的五個違規模式

1. 退訂連結需要登入或填表。違反第 20 條「支付所需費用」的精神——退訂必須對當事人免費且便利。
2. 告知只有一行字。「本信件為商業訊息，如不需要請回覆退訂」不構成第 8 條的完整告知，缺少蒐集者、目的、類別、期間與權利行使方式。
3. 跨工具退訂不同步。收件人退訂了行銷 EDM，兩週後又收到 SDR 的 sequence。這在申訴時等同未停止利用。
4. 把買來的名單當成自有名單。無法舉證來源合法性，責任全落在利用者身上。
5. 用同一套模板寄全亞太。台灣的 opt-out 模板寄到香港、澳洲，直接違反當地的 opt-in 要求。

導入檢查清單

在下一波 outbound 開跑前，逐項確認：

1. 名單中的每一筆是否都有記錄來源類型與取得時間？
2. 首封信是否包含第 8 條所列的完整告知事項？
3. 退訂機制是否一鍵完成、無需登入、且跨所有發送工具生效？
4. 是否為每個市場設定了不同的法律基礎判斷（台灣 opt-out／港澳韓日澳 opt-in）？
5. 是否設定了資料保存期限與到期清理的自動化排程？
6. 委外的行銷服務供應商、AI 工具供應商，是否已在告知的「利用對象」中揭露？
7. 收到查詢、更正、刪除請求時，是否有明確的處理流程與回應時限？

一個實作上的觀察

Branch8 曾為一家在台灣、香港、新加坡三地同時做 outbound 的 B2B 工業設備集團重整名單流程。原本的狀況是三個地區各用一套工具、各自維護 Excel 退訂清單。重整的做法不是換掉工具，而是在三套系統之外建一層共用的 suppression service，以 email 雜湊為索引，所有發送動作在排程階段先行查詢；同時把台灣的告知區塊做成版本控管的 MJML 模板，確保每次改版都留下紀錄。這裡的設計取捨很明確：中央化會增加一次 API 往返與運維負擔，但換來的是「任何一次退訂在所有通路即時生效」這個可以拿到監理機關面前的事實。

合規不是把 outbound 關掉

台灣的個資法在亞太屬於相對務實的制度——它沒有要求你在寄第一封信前就取得同意，但它要求你誠實揭露、並且在對方說不的那一刻真正停止。這兩件事都能用工程手段保證，而不需要靠業務的自律。

真正會拖垮 outbound 的，不是法規本身，而是三個地區用三套規則、五個工具、沒有單一事實來源的營運狀態。把治理層做對，你才能在合規的前提下擴大而不是縮小發送量。

如果你的團隊正在跨台灣、香港、新加坡或更廣的亞太市場做 B2B outbound，Branch8 的跨境數位營運團隊分布於香港、台北、新加坡、胡志明市與雪梨，熟悉各市場的個資法規差異與 CRM、行銷自動化整合實作。歡迎與我們談談如何把名單治理與退訂機制，做成一套能通過稽核的系統。

Sources

• 法務部全國法規資料庫 — 個人資料保護法
• 中華民國法務部
• 香港個人資料私隱專員公署 PCPD
• Personal Data Protection Commission Singapore
• Australian Communications and Media Authority — Spam
• European Data Protection Board
• 個人情報保護委員会（日本 PPC）
• Microsoft Learn — Azure OpenAI Service documentation