Email Deliverability 指南：SPF、DKIM、DMARC 與 15 項驗收
直接答案：Email Deliverability（電郵送達率）並非靠避開「免費、優惠」等個別字眼便可以改善。中小企應先核實 SPF、DKIM、DMARC、From domain alignment、PTR、TLS 及退訂，再確保名單有同意、移除無效地址、分開交易與促銷郵件、由活躍收件人開始穩定寄送，並監察 spam complaint、bounce、authentication、reputation 及 SMTP errors。顯示 Delivered 只代表收件伺服器接受郵件，不等於進入 Inbox。
Email Deliverability 問題發生在哪一層？
| 結果 | 實際意思 | 可否當作成功送達 Inbox？ | 下一步 |
|---|---|---|---|
| Sent | 寄送平台已嘗試交給收件伺服器 | 不可以 | 查看 SMTP response 及 delivery log |
| Delivered／Accepted | 收件伺服器接受郵件 | 不可以，之後仍可進 Spam／Junk | 按收件網域查看投訴、信譽及互動 |
| Temporary deferral／Soft bounce | 暫時延遲，例如 rate limit、信譽或容量問題 | 不可以 | 按回應碼減速並修正原因，不盲目重試 |
| Permanent reject／Hard bounce | 郵件被拒或地址永久無效 | 不可以 | 移除無效地址，按錯誤碼處理認證或政策 |
| Spam／Junk placement | 已接受但分類到垃圾郵件 | 不可以 | 檢查同意、投訴、內容、信譽及認證 |
| Inbox placement | 郵件進入主要或分類收件箱 | 較接近成功，但仍要看商業結果 | 量度 click、reply、conversion 及 unsubscribe |
Google 明確表示不會追蹤 open rate，也不能核實第三方 open rate 的準確度；低開信率本身不一定代表送達或 spam 分類有問題。因此診斷時不要只看 Open，而要由 authentication、server response、spam complaint、domain／IP reputation、bounce 及收件人互動逐層排查。
Email Deliverability：Gmail、Yahoo 與 Outlook 主要寄件要求
| 收件平台／情況 | 認證 | 退訂與投訴 | 其他要求／提醒 |
|---|---|---|---|
| Gmail：所有寄件人 | SPF 或 DKIM；Google 建議兩者及 DMARC 都設定 | Spam rate 要低於 0.3% | 有效 forward／reverse DNS、TLS、RFC 5322、準確寄件身份 |
| Gmail：每日向 Gmail 寄超過 5,000 封 | SPF 及 DKIM；DMARC 至少可由 p=none 開始；From 與 SPF 或 DKIM 對齊 | 促銷／訂閱郵件要支援 one-click unsubscribe，正文亦要有清楚退訂 | 避免突增寄量並用 Postmaster Tools 監察 |
| Yahoo／AOL 大量寄件 | 有效 SPF、DKIM；發布 DMARC，按其大量寄件要求執行 | 促銷郵件支援 one-click unsubscribe；可見退訂毋須登入，Yahoo 建議兩日內處理 | 用 opt-in 確認訂閱、移除無效地址、按用途分開寄送信譽 |
| Outlook：每日超過 5,000 封 | SPF、DKIM、DMARC 必須通過；DMARC 至少 p=none 並與 SPF 或 DKIM 對齊 | 清晰有效退訂、名單衛生及透明寄送 | Microsoft 已以 550 5.7.515 拒絕不符合高量認證要求的寄件網域 |
| 低於 5,000 封／日 | 不應把數量門檻當豁免；仍建議完整 SPF、DKIM、DMARC | 同意、退訂、投訴及無效地址同樣影響信譽 | 要求可按平台、網域、IP 及時間更新 |
「每日 5,000 封」是特定收件平台對大量寄件人的門檻，不是全球統一法律定義，也不代表低量寄件可以忽略認證。每個發送網域及服務供應商都要核對最新要求；同一機構從不同系統向同一平台寄送的數量，亦可能被合併判斷。
Email Deliverability 認證：SPF、DKIM、DMARC 與 Alignment 點樣配合？
| 項目 | 回答問題 | 常見錯誤 | 驗收方法 |
|---|---|---|---|
| SPF | 這個 Envelope From domain 是否授權該 IP／服務寄信？ | 多個 SPF records、漏列第三方、超過 DNS lookup、使用過寬設定 | 列出所有寄件系統，檢查 DNS 及實際 header 的 SPF result |
| DKIM | 郵件是否由持有私鑰的網域簽署，內容傳送途中有沒有被改動？ | selector 錯、key 太短、未為自訂網域啟用、轉寄後簽署失效 | 測試郵件 header 顯示 DKIM pass，d= 為預期網域 |
| DMARC | From domain 與 SPF 或 DKIM 認證網域是否對齊，失敗時怎樣處理？ | 未盤點寄件來源便直接 p=reject、rua 報告無人看 | 先監察 aggregate reports，再逐步收緊 policy |
| Alignment | 使用者看見的 From domain 是否與通過 SPF 或 DKIM 的網域一致？ | 平台用供應商網域認證，但 From 顯示品牌網域而沒有對齊 | 查看 RFC5322 From、Return-Path／MAIL FROM 及 DKIM d= |
| PTR／reverse DNS | 寄件 IP 是否反查到有效 hostname，並可正向解回同一 IP？ | 自建 SMTP 沒 PTR 或 hostname 不匹配 | 核對 forward 與 reverse DNS |
| TLS | 傳送途中是否使用加密連線？ | 舊系統或中繼伺服器未支援 | 檢查 delivery log 及接收 header |
SPF、DKIM 或 DMARC 顯示 Pass 只代表身份及政策檢查通過，不等於保證 Inbox。收件平台仍會考慮 spam complaint、無效地址、寄量模式、網域／IP reputation、內容、連結安全及收件人行為。相反，單靠「寄件平台話已設定」亦不足夠，必須用品牌自訂網域實際寄一封測試郵件，再讀取完整 header。
促銷郵件與交易郵件要分開
| 類型 | 例子 | 主要期望 | 寄送治理 |
|---|---|---|---|
| Transactional | 訂單確認、密碼重設、服務通知 | 由使用者行動觸發，資訊必要而及時 | 不混入促銷；可使用獨立 From、DKIM domain 或 IP |
| Marketing／Promotional | 優惠、新產品、活動、Newsletter | 收件人已合理預期及同意該類訊息 | 清楚退訂、頻率控制、按參與度分批 |
| Lifecycle／Nurture | Welcome、教育內容、跟進序列 | 與訂閱來源、階段及需要一致 | 每個流程有退出條件，避免與促銷重疊轟炸 |
| One-to-one Sales | 對真實查詢的個人回覆及會議跟進 | 內容與現有對話相關 | 不可把批量推廣偽裝成私人回覆 |
Yahoo 建議按郵件功能分開 IP 或 DKIM domain，因不同 IP 及簽署網域各自累積信譽；Google 亦建議不同訊息類型使用一致而清楚的 From address，不要把促銷內容混入收據或帳戶通知。分開用途不是用來逃避壞信譽，而是避免一個促銷活動拖累必要交易訊息。
Email Deliverability 名單同意、退訂與清理規則
| 環節 | 應保留證據 | 不可做 | 自動化動作 |
|---|---|---|---|
| Opt-in | 來源、日期、通知版本、用途、頻率及渠道 | 購買名單、預先勾選、把一般查詢當永久促銷同意 | 按需要發送確認及歡迎訊息 |
| Import | 名單擁有者、收集依據、最後互動及允許用途 | 把來源不明、過時或第三方名單直接匯入 | 先隔離、去重及抽樣核對 |
| Bounce | SMTP code、時間、網域及重試結果 | 對 hard bounce 地址反覆寄送 | 永久錯誤即時 suppress；暫時錯誤按政策減速 |
| Complaint | 收件平台回報、campaign、segment | 只刪除投訴者但不找來源原因 | 即時 suppress 並暫停高風險來源／流程 |
| Unsubscribe | 要求時間、範圍、渠道及完成時間 | 要求登入、收費、繼續寄或偷偷重新加入 | 中央 suppression list 跨活動及供應商生效 |
| Inactive | 最後有效 click、reply、purchase 或服務互動 | 無限期重複寄予長期無反應地址 | 降低頻率、再確認或按政策停止 |
香港私隱專員公署指引要求，在使用個人資料作直接促銷前向資料當事人提供訂明資訊並取得同意或不反對；收件人可隨時免費要求停止使用，其要求必須遵從。退訂資料不宜全部刪走至無法執行 suppression，應按必要性保留最少的 opt-out 紀錄，同時刪除不再需要的其他個人資料。
One-click Unsubscribe 要點
正文有「取消訂閱」連結，不等於已支援 RFC 8058 one-click unsubscribe。Gmail 大量寄件人的促銷／訂閱郵件需要在 header 提供 List-Unsubscribe 及 List-Unsubscribe-Post: List-Unsubscribe=One-Click，同時正文保留清楚可見的退訂連結。Yahoo 亦要求適用的促銷郵件支援 one-click，並建議退訂流程毋須登入及兩日內處理。
- 一按即完成，不先要求登入、回答問卷或輸入密碼；
- 退訂網址使用 HTTPS，並能處理收件平台送出的 POST request；
- 正文退訂連結清楚可見，列明退訂全部或指定郵件類別；
- 要求寫入中央 suppression list，同步 CRM、ESP、Sales 及外判供應商；
- 每次發送前以最新 suppression list 排除，並以測試帳戶驗證。
應該監察哪些 Email Deliverability KPI？
| KPI | 回答問題 | 警號 | 限制 |
|---|---|---|---|
| Authentication pass rate | SPF、DKIM、DMARC 是否穩定通過及對齊？ | 某服務或網域突然 fail | Pass 不保證 Inbox |
| Spam complaint rate | 有幾多 Gmail／Yahoo 收件人標記 Spam？ | Google 建議低於 0.10%，避免達 0.30% 或以上 | 只覆蓋平台可見及回報的投訴 |
| Hard bounce rate | 永久無效地址比例 | 新匯入來源突然升高 | 不同 ESP 分類可能不同 |
| Temporary deferral rate | 有幾多郵件被暫時延遲？ | 寄量突增、特定網域 4xx 上升 | 要配合 SMTP code 及重試結果 |
| Domain／IP reputation | 收件平台如何評價寄件身份？ | Postmaster Tools reputation 下跌 | 不同平台各自計算，不可直接互換 |
| Unsubscribe rate | 內容、頻率或分眾是否不符預期？ | 某 campaign／segment 異常增加 | 退訂比投訴健康，不應隱藏 |
| Click／reply／conversion | 真正有意義的互動及商業結果 | Delivered 很高但沒有任何下游行動 | 受追蹤、私隱及歸因設定影響 |
| Open rate | 第三方估算的開啟訊號 | 只用 Open 判斷送達或清理名單 | Google 不追蹤亦不能驗證第三方準確度 |
Email Deliverability 常見症狀與診斷流程
| 症狀 | 較可能原因 | 先查甚麼 | 處理 |
|---|---|---|---|
| 突然大量 5.7.26 | Gmail 認證或 alignment 失敗 | SPF、DKIM、DMARC、From 及實際 header | 修正網域認證後小量測試 |
| Outlook 550 5.7.515 | 高量寄件網域未達 SPF／DKIM／DMARC 要求 | 三項 pass、DMARC alignment 及每日寄量 | 修正 DNS／ESP 設定，停止盲目重試 |
| Delivered 正常但投訴增加 | 同意、來源、內容或頻率不符預期 | campaign、segment、opt-in source、退訂流程 | 暫停問題來源，縮小至活躍及已同意人群 |
| 新網域第一批便延遲 | 沒有寄送歷史或寄量突然增加 | volume、frequency、4xx、reputation | 由活躍收件人開始，穩定逐步增加 |
| 某 ESP 正常，另一個失敗 | SPF 漏列、DKIM 未啟用或 From 不對齊 | 按寄件系統逐一讀 header | 更新寄件 inventory、DNS 及 selector |
| 退訂後仍收到郵件 | 多份名單／供應商未同步 suppression | CRM、ESP、Sales tool、分公司及外判名單 | 中央化 opt-out，發送前強制排除 |
| Open rate 大跌但 click 穩定 | 開啟追蹤或客戶端行為改變 | click、reply、conversion、delivery errors | 不要單憑 Open 更換網域或清空名單 |
7 步改善 Email Deliverability
1. 建立完整寄件 Inventory
列出每個網站表單、CRM、ESP、電商、帳單、客服、活動及個人銷售工具使用的 From domain、Return-Path、DKIM d=、IP、訊息類型、日寄量、owner 及供應商。未經盤點不要直接收緊 DMARC。
2. 驗證 SPF、DKIM、DMARC、PTR 與 TLS
逐一從每個系統寄往 Gmail、Yahoo 及 Outlook 測試帳戶，保存完整 header 及 SMTP log。先讓 SPF／DKIM 穩定，再由 DMARC p=none 收集報告；修正所有合法來源後才逐步 quarantine／reject。
3. 分開郵件用途與寄件身份
把交易、促銷、培育及一對一銷售分開，使用清晰一致的 From name／address、DKIM domain 或按需要分開基礎設施。不可用分域掩蓋未經同意或高投訴寄送。
4. 清理同意、無效地址及退訂
保留 opt-in 證據，停止購買或來源不明名單；hard bounce、complaint 及 unsubscribe 即時 suppression。對長期無有效互動人士降低頻率、重新確認或停止，而不是一次過大量「喚醒」。
5. 實作 One-click 與內容 QA
驗證 RFC 8058 headers、正文退訂、HTTPS POST、品牌身份、Reply-To、實體聯絡資料、主旨準確、連結安全、HTML／plain-text、手機顯示及所有個人化 fallback。
6. 由活躍收件人逐步增加寄量
新網域、新 IP、新 ESP 或大幅改 header／template 後，先寄給近期 click、reply、purchase 或主動訂閱人士，以穩定頻率逐步擴大。若 4xx、bounce 或 complaint 上升，立即減速及找原因。
7. 建立監察、暫停與復原規則
用 Google Postmaster Tools、Yahoo Complaint Feedback Loop、ESP logs、DMARC aggregate reports 及業務數據做每週監察。為認證 fail、spam rate、hard bounce、deferral、退訂同步及異常寄量設警報、owner、暫停門檻和復原步驟。
發送前 15 項驗收清單
- 全部寄件系統、網域、IP、From、Return-Path 及 DKIM selector 已登記；
- 每個發送來源的 SPF、DKIM 及 DMARC 實際 header 均 Pass；
- From domain 與 SPF 或 DKIM 通過的網域符合 DMARC alignment；
- 自建 SMTP 的 forward／reverse DNS、PTR、TLS 及 RFC 5322 已驗證；
- 交易、促銷、培育及一對一郵件已按用途分開；
- 名單有來源、日期、通知版本、用途、頻率及同意紀錄；
- 購買、來源不明、hard bounce、complaint 及已退訂地址已排除；
- List-Unsubscribe、List-Unsubscribe-Post 及正文退訂已測試；
- 退訂毋須登入、沒有收費，並同步所有 ESP、CRM 及外判名單；
- From name、Reply-To、主旨及預覽文字清楚準確，不偽裝回覆；
- 所有連結使用預期 HTTPS 網域，沒有可疑 redirect 或壞鏈；
- HTML、plain-text、圖片 alt、手機版及個人化 fallback 已檢查；
- 測試 seed accounts 的 Inbox／Spam、header、連結及退訂均已記錄；
- 寄量由近期活躍收件人開始，沒有突發式大批發送；
- Postmaster、CFL、DMARC、SMTP、bounce、complaint 與暫停 owner 已設定。
常見問題
SPF、DKIM、DMARC 全部 Pass，是否一定入 Inbox？
不是。認證是必要身份基礎，但收件平台仍會考慮 spam complaint、地址質素、寄量變化、IP／domain reputation、內容、連結及收件人互動。Pass 後仍應按收件網域查看錯誤、投訴與信譽。
每日少過 5,000 封，是否不用做 DMARC？
不建議這樣理解。5,000 是 Gmail 及 Outlook 某些大量寄件要求的門檻，不是安全或送達保證。低量寄件一樣可能被冒認、投訴或拒收；完整 SPF、DKIM、DMARC 亦有助保護品牌及找出未授權寄件來源。
刪除所有長期沒有 Open 的收件人可以改善送達嗎？
不要只靠 Open。Google 表示不追蹤亦不能驗證第三方 open rate，部分郵件客戶端亦會影響像素。應綜合 click、reply、purchase、登入、服務互動、bounce、complaint、訂閱來源及時間，再決定降低頻率、重新確認或停止。
換一個新寄件網域是否可以即時解決 Spam？
通常不可以。若同意、名單、內容、頻率及寄送習慣沒有改善，新網域只會重新累積相同負面訊號，亦可能令交易郵件、品牌識別及 DMARC 管理更複雜。應先診斷根本原因，再決定是否按用途設子網域。
官方參考：Google：Email sender guidelines、Gmail sender guidelines FAQ、Google Postmaster Tools、Yahoo Sender Best Practices、Yahoo Sender FAQs、Microsoft：Outlook High-volume Sender Requirements及香港私隱專員公署：直接促銷指引。
如要規劃訂閱後培育，先閱讀Email Marketing 與 CRM 培育流程；如要按配合度及互動排序，可參考Lead Scoring 中小企指南；如要管理銷售跟進，可閱讀CRM Sales Pipeline 指南；如要統一活動來源，參考UTM 參數與 GA4 命名指南；如要建立監察報告，可閱讀Looker Studio 報告指南。需要整合網站名單、CRM、自動化及數據驗收，可了解ITOB Group 數碼營銷服務。
編輯與審閱：ITOB Group 編輯團隊；由ITOB Group 數碼營銷顧問團隊審閱。最後實質更新：2026 年 7 月 20 日。
本文依據 Google、Yahoo、Microsoft 及香港私隱專員公署官方資料，配合 ITOB Group 的 Email、CRM 與數據驗收流程整理。收件平台要求、門檻、錯誤碼及介面會更新；完成技術設定不保證 Inbox placement、開信、查詢或收入。實際執行須按寄量、網域、供應商、訊息用途、合約及個人資料用途核對最新規則。詳見編輯政策與資料更正原則。
