Salesforce Email Deliverability 設定教學：啟用、測試與除錯全流程
許多業務團隊在 Salesforce 裡設定好開發信範本後，才發現寄出的郵件大量落入垃圾夾或根本沒有送達。問題往往不在文案，而在 email deliverability salesforce 這個容易被忽略的系統設定：存取層級、測試流程與寄送記錄沒有被正確檢查。本文一步步說明如何啟用、測試與監控這項設定，讓 CRM 整合的 B2B 開發信流程真正可靠。
- Deliverability 設定決定 Salesforce 能否寄出自動化郵件，預設值常常過於保守或過於寬鬆
- Test Email Deliverability 功能只能驗證連線是否暢通，無法保證真實收件匣送達率
- Email deliverability log salesforce 記錄退信與封鎖原因，是除錯的第一手資料
- 大量開發信不該完全仰賴 Salesforce 原生寄信，應搭配獨立寄送網域降低共用風險
- 台灣個資法對行銷信有明確的退出義務，設定錯誤同時是技術問題也是合規問題
為什麼 CRM 原生寄信容易出問題
Salesforce 內建的郵件功能，最初設計是給業務代表寄送一對一往來信件、系統通知與交易確認信，寄送量小、對象固定，並非為每天幾十封、鎖定不同公司窗口的開發信而生。當團隊把 Salesforce 當成主要開發信通路時，寄送行為的模式（同一時間大量觸發、範本高度相似、連結重複）很容易被收件方的垃圾郵件過濾機制標記。
更麻煩的是，多數公司在 Salesforce 裡只用單一組織層級的寄信網域，業務、行銷、系統通知全部共用同一個寄件位址的信譽。只要有一個 Flow 或整合流程設定錯誤造成大量退信，整個網域的信譽都會被拖累，連正常的一對一開發信也會受影響。
如何啟用（turn on）與關閉（turn off）Email Deliverability
設定路徑在 Setup 搜尋「Deliverability」，進入 Email 底下的 Deliverability 頁面。這裡的核心欄位是存取層級（Access Level），共三種選項：不允許送出任何郵件（No Access）、僅允許系統與流程觸發的郵件（System Email Only）、允許所有郵件（All Email），涵蓋使用者手動寄送、Apex、Flow 與批次作業。
如果團隊要用 Flow 或 Apex Trigger 觸發開發信序列，必須把存取層級設為 All Email 才能讓自動化流程實際送出信件，這就是實務上所謂 turn on email deliverability salesforce 的操作。反過來，如果某個 sandbox 或測試環境不該對外寄出真實郵件（避免誤觸真實客戶信箱），就應該把存取層級調回 No Access，也就是 turn off email deliverability salesforce，這是新建 sandbox 後的標準檢查項目，常被忽略而導致測試資料意外寄給真實聯絡人。
- 登入 Setup，搜尋 Deliverability 並開啟頁面
- 檢查目前 Access Level 是否符合環境用途（production 通常為 All Email，sandbox 建議 No Access）
- 確認 TLS 加密選項已開啟，避免以明文傳輸信件
- 若使用 Email Relay 寄送到自有網域，確認 Relay 主機與連接埠設定正確
- 變更後儲存並記錄異動時間，方便日後追溯除錯
測試與確認寄送是否正常
Deliverability 頁面下方有一個 Test Deliverability 按鈕，點擊後系統會嘗試寄出一封測試信到目前登入使用者的信箱，用來驗證 Salesforce 與外部郵件伺服器之間的連線是否暢通。這是最基本的 test email deliverability salesforce 檢查，但只能證明信件寄得出去，不能證明信件會送達收件匣而不是垃圾夾。
要真正 check email deliverability salesforce 的實際送達品質，建議額外用第三方送達測試工具，或直接寄到自己在 Gmail、Outlook 上申請的測試信箱，檢查 SPF、DKIM、DMARC 是否對齊、信件是否落在垃圾夾，以及寄件網域的信譽分數。如果 Salesforce 是透過公司自有網域直接寄信，這個網域必須先在 DNS 完成 SPF 納入 Salesforce 的寄件伺服器、設定 DKIM 金鑰，並確保 DMARC 政策不會因為 Salesforce 的寄送路徑而失敗對齊。
常見的除錯流程：先用 Deliverability 頁面的 Test Deliverability 確認連線正常，接著手動用同一個範本寄一封信到自己申請的 Gmail 測試信箱，檢查信件標頭裡的 SPF=pass、DKIM=pass、DMARC=pass 是否齊全；只要有一項 fail，就回頭檢查 DNS 紀錄或寄件網域設定，而不是直接懷疑文案內容。
看懂 Email Deliverability Log 除錯
Salesforce 沒有單一畫面把所有退信原因攤在眼前，除錯需要拼湊幾個地方的資料：Email Administration 底下的 Email Log Files（匯出的 CSV，包含寄件時間、收件位址、寄送狀態與代碼）、Bounce Management 記錄的退信信箱與退信類型，以及若透過 Apex 寄信還要看 Apex Exception Email 記錄。這些合起來就是實務上說的 email deliverability log salesforce。
解讀退信代碼時，要先分清楚硬退信（信箱不存在、網域不存在）與軟退信（信箱已滿、伺服器暫時拒收）。硬退信應該立即在 CRM 裡把該聯絡人標記為無效，避免重複寄送持續傷害寄件信譽；軟退信可以保留重試，但如果同一位聯絡人連續多次軟退信，也應該視同無效處理。
數字為多次 B2B 開發信除錯案例的概略分布，非官方統計，僅供抓問題方向參考。
健康的寄送指標長怎樣
光看 Salesforce 的寄送成功與否還不夠，團隊需要一組基準值判斷開發信流程是否健康。這些數字沒有官方標準答案，但根據目標明確、小量、個人化的 B2B 開發信操作經驗，可以抓出一個合理區間，超出區間就代表寄送架構或名單品質有問題，需要回頭 check email deliverability salesforce 的設定與名單來源。
如果退信率長期超過這個區間，通常不是文案問題，而是名單品質（過期職稱、猜測式信箱格式）或寄送網域信譽的問題；如果開信率明顯偏低但退信率正常，則要回頭檢查主旨與寄件人名稱是否觸發垃圾信規則，而不是急著換 CRM 範本。
數字為小量、精準鎖定名單的冷開發信實務區間，會隨產業與名單品質波動，僅供參考。
常見錯誤
第一個常見錯誤，是把 Salesforce 原生寄信當成唯一的大量開發信通路，用 Flow 排程對數百個聯絡人同時觸發同一範本，這種寄送模式本身就是垃圾郵件過濾器最容易辨識的特徵，跟 Salesforce 設定對不對沒關係。第二個錯誤，是行銷、系統通知、業務開發信全部共用同一個組織層級寄件位址與網域，一旦某個環節出問題，會拖累所有信件的送達率。
- 忘記在新建的 sandbox 環境 turn off email deliverability salesforce，導致測試資料意外寄給真實客戶
- 只依賴 Test Email Deliverability 按鈕，誤以為連線正常等於送達率沒問題
- SPF 記錄只列了舊的寄件伺服器，加入 Salesforce 或第三方寄送工具後沒有更新
- 沒有定期匯出並檢視 email log，退信名單持續留在寄送清單裡
- 行銷信件未在第一次寄送時提供明確退出方式，違反個資法對行銷利用的告知與拒絕義務
LDM 的整合作法與檢查清單
在 LDM 的做法裡，Salesforce 保留它最擅長的角色：管理聯絡人資料、記錄開發信序列的往來、讓業務在同一個介面看到回覆並接手跟進；實際的開發信寄送則交給獨立的寄送網域與暖機機制處理，不佔用公司主網域的信譽額度。每一封信寄出、開信、回覆的狀態，會透過 API 同步回 Salesforce 的 Activity 或自訂物件，SDR 不需要離開 CRM 就能掌握整個對話狀態。
這種分工的好處是，即使某一批開發信名單品質不佳導致退信率短暫升高，受影響的是專用的寄送網域，不會波及公司原本用於報價單、合約、客服通知的主網域，也不會讓 Salesforce 裡其他一對一往來信件被連帶標記為垃圾信。
- 確認 production 環境 Access Level 為 All Email，sandbox 為 No Access
- 開發信寄送網域與公司主網域、行銷網域分離，各自獨立設定 SPF、DKIM、DMARC
- 每週匯出一次 email log，清理硬退信聯絡人
- 行銷或開發信第一次寄送即提供退出方式，符合個人資料保護法第20條關於行銷利用之告知與拒絕規定
- 新環境上線前，先用 Test Deliverability 加一次真人信箱測試，兩者都過才算合格
常見問題
Salesforce 的 Test Email Deliverability 顯示成功，為什麼實際送達率還是很差？
Test Deliverability 只驗證 Salesforce 與郵件伺服器之間的連線是否暢通，不會檢查信件內容、寄件網域信譽或收件方垃圾信規則。要真正 check email deliverability salesforce 的品質，需要另外用真實信箱與第三方工具檢查信件是否落入垃圾夾。
什麼時候應該 turn off email deliverability salesforce？
任何不該對外寄出真實郵件的環境，例如新建立的 sandbox 或資料遷移測試，都應該把 Access Level 設為 No Access，避免測試流程意外寄信給真實客戶聯絡人。
Email deliverability log salesforce 要去哪裡看？
退信與寄送狀態需要拼湊幾個地方：Email Administration 底下的 Email Log Files（CSV 匯出）、Bounce Management 記錄的退信信箱，以及若用 Apex 寄信則另外看 Apex Exception Email 記錄，目前沒有單一整合畫面。
用 Salesforce 直接寄送大量開發信可以嗎？
技術上可以設定 All Email 存取讓 Flow 或 Apex 觸發寄送，但 Salesforce 原生寄信架構不是為大量、鎖定名單的冷開發信設計的，長期用同一個組織網域大量寄送容易拖累整體信譽，建議搭配獨立的寄送網域，Salesforce 只負責記錄與追蹤。
退信率多高才算需要處理？
健康的 B2B 開發信退信率通常低於 2%，如果持續超過這個水準，多半是名單過期或信箱格式用猜測方式產生，需要先清理名單而不是調整 Salesforce 設定。
台灣個資法對開發信有什麼具體要求？
依個人資料保護法規定，蒐集聯絡人資料須有特定目的並告知當事人，首次進行行銷利用時必須提供當事人免費且明確的拒絕方式，一旦對方表示拒絕就必須停止對其行銷，這一點無論寄送工具是 Salesforce 或其他系統都適用。