大多數公司把電子郵件當工具，覺得「能收能發就好」。但電子郵件其實更像公司大樓裡埋在牆壁和地板下的管路系統：施工期間看不出好壞，一旦封起來，要改管路就得打牆，代價是原本施工成本的數倍。
真實事件：一封廣告信讓全公司收不到信
K 公司是一家員工約 50 人的電商公司。某次年度促銷，行銷團隊對累積名單大規模發送廣告信，總量約 200 萬封，全部從公司主網域的同一台 mail server 送出。
發送後 48 小時內，事情開始出錯：
- 退信率（bounce rate）衝破 18%，遠超業界警戒值 2%
- 大量收件人點了「標記為垃圾」，Gmail 信譽等級從「高」直接掉到「差」
- Spamhaus 和 Barracuda 將公司 IP 列入黑名單
- 主機商收到大量投訴，以違反服務條款為由暫停了整台 mail server
暫停的後果遠超預期：不只是廣告信停了，全公司 50 名員工的日常信件全部中斷。 客戶的詢價信收不到、合約確認信發不出去、廠商對帳信石沉大海。
後續代價：
- IP 解除黑名單：向 Spamhaus 申請人工審核，等待超過 2 週
- 重建 mail server：申請新 IP，從零暖機，歷時約 6 週
- 部分大型企業客戶的 IT 手動將公司網域加入黑名單，永久無法撤回
- 即使 IP 換了，主網域信譽已受損，交付率長期偏低
K 公司後來重新建了整套 email 架構。但這件事暴露了一個殘酷的現實：這些設計在第一天就能做，代價接近零；等到出事再做，代價是數週的業務損失加上永久受損的網域信譽。
根本原因：你不能控制別人怎麼評價你
Gmail、Outlook、Yahoo 這些收信方，會對每一個寄件 IP 和網域建立信譽評分。這個評分是黑盒子，你無法申訴，只能管理。
問題的核心在於：不同性質的信件，天生就有不同的風險等級。
行銷促銷信容易被標記為垃圾；OTP 驗證碼是用戶主動觸發的、高度期待的信件。如果這兩類信件共用同一個網域和 IP 送出，行銷信一拖累信譽，客戶就收不到密碼重設信。
解法只有一個：把不同性質的信件物理隔離。
什麼是 Subdomain 隔離？
以 stanwu.org 為例，正確的設計是這樣：
stanwu.org→ 員工日常往來，信譽最高，只給人用mail.stanwu.org→ 系統通知、OTP，高重要性crm.stanwu.org→ 客服回覆、工單系統billing.stanwu.org→ 帳單、收據，交易型marketing.stanwu.org→ 行銷活動、促銷，批量發送news.stanwu.org→ 電子報，訂閱制noreply.stanwu.org→ 單向自動通知
每個 subdomain 各自獨立的 SPF 設定，互不干擾。換服務供應商時，只影響該 subdomain，主網域完全不受波及。
越往下越容易觸發過濾，但也越能容忍。關鍵是物理隔離，防止下層污染上層。
SPF / DKIM / DMARC 各解決什麼
這三個機制常被混為一談，但各自解決的問題不同：
SPF 驗證「這封信是從授權的 IP 寄出的嗎」。你在 DNS 的 TXT 記錄裡列出所有允許代你發信的 IP 或服務，收信方核對。
DKIM 驗證「信件內容在傳輸過程中有沒有被竄改」。寄件方用私鑰對信件簽章，收信方用 DNS 上的公鑰驗證。轉寄信不會破壞 DKIM，但會破壞 SPF。
DMARC 是策略層。告訴收信方：如果 SPF 或 DKIM 驗證失敗，你應該怎麼處理？
三個選項：
p=none：只收報告，不擋信（監控期）p=quarantine：失敗的信進垃圾桶（過渡期）p=reject：失敗的信直接拒收（強制期）
直接設 p=reject 是最常見的錯誤。 正確順序是 none → quarantine → reject，每個階段觀察 2-4 週，確認沒有合法信件被誤擋再往下走。
五個你可能沒想到的地方
1. 收信端幾乎沒人設計
大多數人只想「寄出去」的問題。但 MX 備援、catch-all 風險、shared inbox 策略，這些收信端問題同樣會讓你漏掉重要信件。
2. RFC 強制要求的地址
postmaster@ 和 abuse@ 是 RFC 2142 規定必須存在的地址，很多公司完全沒設，但這兩個是 mail server 信任評分項目。
3. Subdomain Takeover
Subdomain takeover 是真實且常被忽略的攻擊面。若 marketing.stanwu.org 的 DNS 記錄仍指向已停用的第三方服務，攻擊者可能重新佔用該資源並控制這個子網域。若遺留的郵件相關 DNS 設定剛好仍可被利用，攻擊者就可能以該子網域進行高可信度釣魚，甚至在某些配置下通過 SPF 或 DKIM。
離職員工建立的 subdomain + 忘記清理的 DNS = 潛在的釣魚攻擊入口
4. IP 暖機期無法壓縮
新 IP 需要數週到數月的暖機期，無法用錢跳過。Week 1 每天約 200 封，Week 2 約 500 封，Week 3 約 2,000 封⋯⋯要用 dedicated IP 就必須提前規劃，不能等到要大量發信時才申請。
5. SPF 的 10 個 DNS Lookup 限制
多個服務的 include: 會快速累積 DNS lookup 次數，超過 10 次不會報錯，只會靜默失敗。解法是 SPF Flattening，把所有 include 展開成直接的 IP 清單。
50 人規模的務實建議
以 50 人左右的組織為例，現在就該做的事：
立刻做，成本幾乎是零：
- Google Workspace 主網域只給員工用
- Postmark 或 AWS SES 負責系統通知，走獨立 subdomain- Mailchimp 行銷信走 marketing subdomain，永遠不用主網域- DMARC 從
p=none開始收報告，先看清楚誰在用你的網域發信 - 確認
postmaster@和abuse@有人處理
等規模到了再做：
- Zendesk 客服系統走 crm subdomain 隔離- Dedicated IP（月發送量超過 10 萬封才值得）
- SPF Flattening（先確認有沒有超過 10 個 lookup）- MTA-STS（強制傳輸層 TLS）
K 公司的事件對照
K 公司案例最直接的數字：
- Subdomain 隔離設定 → 事前 1 小時 DNS 設定 vs 事後 6 週重建
- Bounce 處理機制 → 事前選 Mailchimp 時順手開啟 vs 事後 IP 進黑名單只能換 IP 重養
- DMARC 監控 → 事前一條 DNS 記錄 vs 事後部分客戶網域永久封鎖無法撤回
結語
電子郵件基礎建設最貴的不是設定本身，而是沒有規劃好之後被迫遷移時的商業損失。
水管的設計原則完全適用：
- 預埋空管 → 之後擴充不用打牆（subdomain 預先規劃）
- 閥門分區 → 某區出問題不影響全棟（信譽隔離）- 主幹管夠粗 → 之後支管擴充不用換主幹（主網域保持乾淨）- 施工圖留存 → 之後維修找得到管路（DNS 文件化）
基礎建設的價值，永遠在你需要它的那一天才會真正顯現。
原文刊載於 blog.stanwu.org
