200 萬封廣告信，換來 6 週業務停擺：從 K 公司事件看 Email 基礎建設

大多數公司把電子郵件當工具看待，覺得「能收能發就好」。但電子郵件其實更像公司大樓裡埋在牆壁和地板下的管路系統：施工期間看不出好壞，一旦封起來，要改管路就得打牆，代價是原本施工成本的數倍。

本文從設計思維出發，說明企業電子郵件基礎建設為什麼要在第一天就規劃清楚，以及如何做。

第一章：你不能控制別人怎麼評價你

企業電子郵件設計最根本的問題，不是技術，是信譽。

Gmail、Outlook、Yahoo 這些收信方，會對每一個寄件 IP 和網域建立信譽評分。這個評分是黑盒子，你無法申訴，只能管理。評分好壞影響你的信件進收件匣還是垃圾桶，而評分的影響因素包括：

• 這個 IP 過去寄了什麼類型的信
• 收件人有沒有點開、有沒有標記垃圾
• Bounce rate（退信率）多高
• 是否有正確設定 SPF / DKIM / DMARC
• 這個網域存在多久

問題的核心在於：不同性質的信件，天生就有不同的風險等級。

行銷促銷信容易被收件人標記為垃圾；OTP 驗證碼是用戶主動觸發的、高度期待的信件。如果這兩類信件共用同一個網域和 IP 發出，行銷信拖累信譽，客戶收不到密碼重設信——這不是理論風險，是真實發生過的事。

K 公司：200 萬封廣告信引發的災難

K 公司是一家成立數年、員工約 50 人的電商公司。某次年度促銷，行銷團隊決定對累積的名單大規模發送廣告信，總量約 200 萬封，全部從公司主網域的同一台 mail server 送出。

發送後 48 小時內，事情開始出錯：

• 退信率（bounce rate）衝破 18%，遠超業界警戒值 2%
• 大量收件人點了「標記為垃圾」，Gmail 的 Postmaster Tools 顯示信譽等級從「高」直接掉到「差」
• Spamhaus 和 Barracuda 將公司 IP 列入黑名單
• 主機商收到大量投訴，以違反服務條款為由暫停了整台 mail server

暫停的後果遠超預期：不只是廣告信停了，全公司 50 名員工的日常信件全部中斷。 客戶的詢價信收不到、合約確認信發不出去、廠商對帳信沉沒在黑名單裡。公司的業務實質上停擺了數天。

最後的解決方法是直接把主機轉移到另一家供應商，取得乾淨的新 IP 重新出發。但這裡有個附帶的問題：被放棄的舊 IP 最終會回到供應商的 IP 池，之後再分配給其他客戶。如果下一個承接這個 IP 的人剛好也要架設 mail server，就會繼承一個已經在各大黑名單裡的 IP，在完全不知情的狀況下從一開始就處於劣勢。IP 的歷史會跟著 IP 走，不會跟著原來的主機商走。 申請 VPS 或主機時，建議先用工具（MXToolbox、Spamhaus）查一下分配到的 IP 有沒有黑名單歷史，再決定要不要要求更換，這個動作花不到五分鐘，卻能避免繼承別人留下的爛攤子。

後續的代價：

K 公司後來重新建了整套 email 架構，把行銷信移到獨立 subdomain 和獨立 IP，主網域只給員工用。但這件事暴露了一個殘酷的現實：這些設計在第一天就能做，代價接近零；等到出事再做，代價是數週的業務損失加上永久受損的網域信譽。

第二章：Subdomain 分層的本質是隔離污染源

以 stanwu.org 為例，設計思維是這樣的：

高價值信件（OTP、帳單）   → 保護起來，獨立 subdomain 和 IP
中等風險（客服回覆）       → 隔離但不需要最高規格
高風險（行銷、電子報）     → 接受較低信譽，但不讓它污染其他人

實際的 subdomain 對應：

每個 subdomain 各自一條 SPF 設定，互不干擾。換服務供應商時，只影響該 subdomain，主網域完全不受波及。

信譽金字塔

graph TD
    A["stanwu.org\n最珍貴，只給員工用"]
    B["billing.stanwu.org\n帳單收據，交易型"]
    C["mail.stanwu.org\n系統通知 OTP，交易型"]
    D["crm.stanwu.org\n客服回覆，中等量"]
    E["noreply.stanwu.org\n單向通知，中等量"]
    F["marketing.stanwu.org\n行銷活動，批量"]
    G["news.stanwu.org\n電子報，批量"]

    A --> B & C
    B --> D
    C --> E
    D --> F
    E --> G

越往下越容易觸發過濾，但也越能容忍。關鍵是物理隔離，防止下層污染上層。

第三章：多服務整合的 DNS 設計全貌

現代企業通常不只用一個服務發信。以常見的組合為例：

DNS 設定範例：

# 主網域（Google Workspace）
stanwu.org          MX    1  aspmx.l.google.com
stanwu.org          TXT   "v=spf1 include:_spf.google.com ~all"
google._domainkey   TXT   "v=DKIM1; k=rsa; p=<Google 提供>"
_dmarc.stanwu.org   TXT   "v=DMARC1; p=reject; rua=mailto:[email protected]"

# Mailchimp 行銷
marketing.stanwu.org      TXT   "v=spf1 include:servers.mcsv.net ~all"
k1._domainkey.marketing   CNAME k1.dkim.mcsv.net
_dmarc.marketing.stanwu.org TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

# Postmark 系統通知
mail.stanwu.org       TXT  "v=spf1 include:spf.mtasv.net ~all"
pm._domainkey.mail    TXT  <Postmark 提供>
pm-bounces.stanwu.org CNAME pm.mtasv.net

第四章：SPF / DKIM / DMARC 各解決什麼問題

這三個機制常被混為一談，但各自解決的問題不同：

SPF（Sender Policy Framework） 驗證「這封信是從授權的 IP 寄出的嗎」。你在 DNS 的 TXT 記錄裡列出所有允許代你發信的 IP 或服務，收信方核對。

DKIM（DomainKeys Identified Mail） 驗證「信件內容在傳輸過程中有沒有被竄改」。寄件方用私鑰對信件簽章，收信方用 DNS 上的公鑰驗證。轉寄信不會破壞 DKIM，但會破壞 SPF。

DMARC（Domain-based Message Authentication） 策略層。告訴收信方：如果 SPF 或 DKIM 驗證失敗，你應該怎麼處理？三個選項：

p=none        只收報告，不擋信（監控期）
p=quarantine  失敗的信進垃圾桶（過渡期）
p=reject      失敗的信直接拒收（強制期）

DMARC 部署的正確順序

直接設 p=reject 是最常見的錯誤，會誤擋合法信件：

第一階段（2-4 週）：p=none
→ 只收報告，了解誰在用你的網域發信
→ 常常會發現你不知道的服務也在發信

第二階段（2-4 週）：p=quarantine; pct=25
→ 25% 的失敗信件進垃圾桶，觀察有無誤殺

第三階段：p=reject
→ 完全阻擋偽冒
→ 同時達到 BIMI 資格（Gmail 顯示公司 Logo）

第五章：容易被忽略的設計面向

Inbound（收信端）幾乎沒人想到

大多數的設計思考都聚焦在「寄出去」，但收信端同樣有設計問題：

• MX 備援：Primary MX 掛掉時有沒有 Secondary MX 接手？
• Catch-all 的風險：*@stanwu.org 全接，等於幫垃圾郵件測試哪些地址有效，成為 dictionary attack 目標
• Shared inbox 策略：support@、sales@、hr@ 這類 role address，要進 ticketing system 還是個人信箱？沒規劃就會漏信

RFC 強制要求的地址

RFC 2142 規定某些地址必須存在，否則部分 mail server 會降低信任評分：

[email protected]   必須能收信，且有人處理
[email protected]        垃圾郵件檢舉用，ISP 會寄報告到這裡

很多公司完全沒設，但這兩個是郵件系統評分項目。

Subdomain Takeover — 最容易被忽略的攻擊面

Subdomain takeover 是真實且常被忽略的攻擊面。若 marketing.stanwu.org 的 DNS 記錄仍指向已停用的第三方服務，攻擊者可能重新佔用該資源並控制這個子網域。若遺留的郵件相關 DNS 設定剛好仍可被利用，攻擊者就可能以該子網域進行高可信度釣魚，甚至在某些配置下通過 SPF 或 DKIM。

離職員工建立的 subdomain + 忘記清理的 DNS = 潛在的釣魚攻擊入口

停用第三方服務時，必須同步清理相關 DNS 記錄與驗證設定。

IP 暖機期無法壓縮

新 IP 或新 subdomain 不能直接大量發信，Gmail 和 Outlook 對新 IP 的前幾千封信會觀察行為：

Week 1: 每天約 200 封
Week 2: 每天約 500 封
Week 3: 每天約 2,000 封
...

這個過程需要數週到數月，無法用錢跳過。要用 dedicated IP 就必須提前規劃暖機期，不能等到要大量發信時才申請。

SPF 的 10 個 DNS Lookup 限制

SPF 有個規範：驗證過程中的 DNS lookup 次數不能超過 10 次。多個 include: 會迅速累積：

v=spf1 include:_spf.google.com        ← 算數次
       include:servers.mcsv.net       ← 繼續累積
       include:spf.mtasv.net          ← ...
       include:mail.zendesk.com       ← 超過就靜默失敗

超過 10 次不會報錯，只會靜默失敗。解法是 SPF Flattening，把所有 include 展開成直接的 IP 清單，用工具（dmarcian、easydmarc）定期更新。

MTA-STS — 傳輸層加密的強制策略

SPF / DKIM / DMARC 解決的是「這封信是不是你寄的」，但不保護傳輸過程。MTA-STS 告訴其他 mail server：「跟我通訊必須用 TLS，不接受降級」。沒設的話，中間人可以讓連線降級到明文傳輸。

_mta-sts.stanwu.org  TXT  v=STSv1; id=20260416
https://mta-sts.stanwu.org/.well-known/mta-sts.txt
  version: STSv1
  mode: enforce
  mx: mail.stanwu.org
  max_age: 604800

員工離職的 Email 生命週期

沒有明確政策就會讓客戶信件石沉大海：

離職當天 → 停用登入，信箱繼續收信
30 天內  → 自動回覆告知新聯絡人
90 天後  → 信件轉給主管或封存
1 年後   → 永久關閉

法規與封存需求

第六章：為什麼逆向成本這麼高

用管路工程來類比：

事前規劃好   →  施工成本
事後才改     →  打牆 + 施工 + 修復牆面 = 5-10x 成本

K 公司的案例是最直接的數字對照：

以下是幾個典型的高逆向成本場景：

主網域信譽受損 — 幾乎不可逆

主網域用來發行銷信，信譽被拖垮後，唯一解法是換新網域。員工信箱全換、名片重印、所有系統重設。一個用了五年的網域信譽歸零，損失無法量化。

Subdomain 結構改動 — 牽一髮動全身

第一天用 [email protected] 發客服信，之後要改成 [email protected]，所有歷史客戶的回信地址需要更新，CRM 系統設定要改，舊地址還要繼續收信避免遺漏。而如果第一天就規劃好 subdomain，遷移成本是零。

DMARC 順序不能跳

直接設 p=reject 可能讓合法信件被擋，緊急改回 p=none 時信譽已受損。這個順序強制你先做功課。

IP 歷史無法用錢買

新 IP 信譽從零開始，暖機期無法壓縮，無法付錢跳過。要用 dedicated IP 就必須提前規劃。

第七章：務實的分階段執行建議

設計要完整，但執行要務實。規模決定優先順序。

以 50 人規模的組織為例

以 stanwu.org 這樣 50 人左右的組織來說，郵件流量大概是這樣的分布：

在這個規模，行銷信還不需要 dedicated IP（門檻是月發 10 萬封以上），用 Mailchimp 的 shared IP pool 就夠。但subdomain 隔離從第一天就應該做，因為這個設定的成本幾乎是零，而等到規模大了再改的代價，K 公司的案例已經說明了。

現在就做（無論規模大小）

Google Workspace 主網域
  → 員工信件、Groups shared inbox

Postmark 或 AWS SES
  → 系統通知、OTP，獨立 subdomain（mail.stanwu.org）

Mailchimp 或同類服務
  → 行銷信走 marketing subdomain，永遠不用主網域

DMARC p=none 開始收報告
  → 先看清楚誰在用你的網域發信

RFC 必要地址
  → 確認 postmaster@ 和 abuse@ 有人處理

量上來之後再做

Zendesk 客服系統 → crm subdomain 隔離
Dedicated IP → 月發送量 > 10 萬封
SPF Flattening → 先確認有沒有超過 10 個 lookup
MTA-STS → 強制傳輸層 TLS
BIMI → DMARC p=reject 之後，申請 Gmail Logo 顯示

常見錯誤清單

結語

電子郵件基礎建設最貴的不是設定本身，而是沒有規劃好之後被迫遷移時的商業損失。

水管的設計原則完全適用：

預埋空管   → 之後擴充不用打牆（subdomain 預先規劃）
閥門分區   → 某區出問題不影響全棟（信譽隔離）
主幹管夠粗 → 之後支管擴充不用換主幹（主網域保持乾淨）
施工圖留存 → 之後維修找得到管路（DNS 文件化）

這套架構看起來複雜，但真正需要在第一天做的決定只有幾個：主網域只給員工用、系統通知走獨立服務、行銷信用獨立 subdomain、DMARC 從 p=none 開始。其他的可以等規模到了再加。

基礎建設的價值，永遠在你需要它的那一天才會真正顯現。