通用面試：如何安全推進 DMARCbis 與 SPF、DKIM 對齊？
題幹與適用場景
公司準備把多個郵件供應商納入同一個寄件網域。請解釋 DMARC 對齊和 2026 年 RFC 9989、9990、9991 的職責，並設計從 p=none 逐步走到 reject 的驗證與回滾方案。
題目適合平台工程、安全工程、郵件基礎設施，以及需要跨團隊排查投遞問題的職位。它測試協定判斷和遷移控制，不要求候選人聲稱某家收件服務已支援全部新 RFC。
面試官考察點
- 是否能分開 SPF、DKIM、DMARC 的角色和檢查對象。
- 是否知道 DMARC 通過需要 SPF 或 DKIM 至少一項通過，並且與可見的 From 網域對齊。
- 能否區分 RFC 9989 核心協定、RFC 9990 彙總報告和 RFC 9991 失敗報告。
- 能否用觀測資料分批收緊策略，而非直接把
p改成reject。 - 能否處理轉寄、第三方供應商、子網域、報告隱私和回滾。
回答前需要釐清的問題
- 受保護的是主網域還是多個子網域，所有寄件系統的 From、Return-Path 和 DKIM d 網域分別是什麼？
- 目前 SPF、DKIM、DMARC 通過率按供應商和子網域如何分布，是否能收到彙總報告？
- 組織是否同時寄送行銷、交易和員工郵件，是否需要不同子網域或策略？
- 收件服務的策略支援和報告行為是否已驗證，還是只能以標準和實測為準？
30 秒回答框架
DMARC 檢查可見 From 網域的身分是否與 SPF 的驗證網域或 DKIM 的 d 網域對齊；兩條鏈路至少一條通過且對齊，訊息才通過 DMARC。RFC 9989 定義核心協定，RFC 9990 和 RFC 9991 分別定義彙總與失敗報告。遷移先把 p=none 當觀測模式，收集並解析報告，按供應商、子網域和訊息類型修復對齊問題，再逐步提升到 quarantine 和 reject。每一步保留指標、抽樣驗證和快速回滾，不能把新 RFC 編號等同於所有收件服務的即時支援。
分步驟深入解答
1. 畫出三條身分鏈路
SPF 驗證寄件伺服器是否獲授權，通常觀察 SMTP 信封中的 MAIL FROM 網域；DKIM 用簽章驗證訊息，簽章中的 d 網域參與對齊；DMARC 關注收件者看到的 From 網域，並依對齊結果套用策略。三者輸入不同，不能只看一行 Authentication-Results 就跳過網域核對。
2. 用對齊而非單純通過率判斷
DMARC 的核心條件是 SPF 或 DKIM 至少一項通過，且驗證網域與 From 網域依組織選擇的 relaxed 或 strict 模式對齊。一個供應商可能 SPF pass 但 envelope-from 不對齊，也可能 DKIM pass 但 d 網域屬於供應商；兩種情況都要修正網域、簽章或寄件邊界。
3. 說明 2026 年三份 RFC 的邊界
RFC 9989 是 DMARC 核心規範，取代早期 RFC 7489 的歷史定位；RFC 9990 描述彙總報告，協助網域擁有者按來源觀察長期分布；RFC 9991 描述失敗報告。面試中應把「規範已發布」和「每個收件服務都會產生相同報告」分開，具體支援仍要靠實測和供應商文件確認。
4. 設計逐步收緊策略
先發布 p=none，設定受控的 rua，並把報告送到有存取控制的分析信箱或管道。按來源聚合 SPF、DKIM、From、子網域和失敗原因，先修復合法寄件者。可對高風險子網域使用 sp，也可以拆分交易和行銷子網域。只有合法流量穩定通過且未知來源能解釋後，才逐步採用 quarantine，最後再採用 reject。
5. 把驗證和回滾寫進變更單
上線前保存 DNS 記錄、供應商設定和目前報告基線。每次收緊後觀察合法郵件到達率、DMARC pass、對齊失敗、投訴和報告延遲；用真實測試信箱覆蓋轉寄、列表和附件場景。若合法流量下降，先回到上一策略或縮小子網域範圍，再定位是 SPF 傳播、DKIM 簽章、轉寄改寫還是報告缺失。
高品質示範回答
我會先盤點每個寄件系統的 From、MAIL FROM 和 DKIM d 網域，再按供應商和子網域計算通過與對齊結果。DMARC 不要求 SPF 和 DKIM 同時通過，而是至少一條通過並對齊。RFC 9989 負責核心策略，RFC 9990 和 RFC 9991 負責兩種報告；報告可見性不能假設所有收件服務一致。遷移先用 p=none 收集彙總報告，修復第三方寄件者、轉寄和子網域問題，穩定後再小範圍進入 quarantine，最後才是 reject。每一步設定通過率、合法郵件到達率和未知來源占比門檻，並保留 DNS 回滾和獨立子網域隔離。這樣策略變更可稽核，失敗時也能快速降低影響。
常見錯誤
- 看到 SPF 或 DKIM pass 就宣布 DMARC 通過，忽略 From 網域對齊。
- 把 SPF 的 MAIL FROM、DKIM 的 d 網域和可見 From 當成同一欄位。
- 把 RFC 9989、9990、9991 都稱為「DMARC 核心協定」，說不清報告職責。
- 沒有報告基線就直接使用
p=reject，把合法第三方郵件一起攔截。 - 假設轉寄一定保留 SPF 或 DKIM，未設計轉寄和郵件列表測試。
- 把 DNS 記錄公開給所有人，忽略報告中可能出現的地址和組織資訊。
追問及應對
SPF pass 但 DMARC fail，先查什麼？
先比較 SPF 驗證網域與 From 網域，確認 relaxed 或 strict 對齊模式；再檢查子網域繼承、改寫和真實郵件標頭。不要只看寄件 IP 是否在 SPF 中。
DKIM pass 但轉寄後失敗怎麼辦？
檢查轉寄方是否改寫正文或關鍵標頭，確認簽章 d 網域和選擇器仍可解析。對無法控制的轉寄路徑，評估穩定的 DKIM 簽章、列表處理和隔離子網域，不能用盲目放寬策略掩蓋未知來源。
如何決定從 quarantine 到 reject？
用按供應商、子網域和訊息類型切分的報告資料證明合法流量持續對齊，並完成轉寄、行銷和交易場景測試。門檻應包含合法到達率、對齊失敗率、投訴和未知來源趨勢，且必須有回滾窗口。
報告地址在另一個網域時要注意什麼？
確認接收報告的網域明確授權該報告關係，並限制報告管道的存取和保留時間。跨網域報告不應被當成自動可信的資料出口。
資料來源：RFC 9989、RFC 9990、RFC 9991、Google Gmail《Email sender guidelines》、Dataford《Explaining Email Authentication Clearly》（完整連結見 meta.json）。