濫用郵件常把收件人熟悉、信任的組織網域填進信頭的寄件者（From）欄位[1]。SPF 與 DKIM 能在網域層級驗證郵件來源，DMARC 則把兩者的結果和收件人看到的 From 網域連起來，讓網域擁有者在 DNS 公告驗證失敗時希望收件端怎麼處理，並請收件端寄回報告[1]。三者各自是什麼，網路釣魚與商業郵件詐騙已有簡介；這篇談實際部署：找出所有代表公司寄信的系統、逐一設好 SPF 與 DKIM、把 DMARC 從只監控逐步提高到拒收，並把不寄信的網域一併鎖上。

這也不再只是「建議」。Gmail 與 Yahoo 自 2024 年 2 月起要求大量寄件者設定 SPF、DKIM 與 DMARC[2][3]，Outlook.com 也自 2025 年 5 月跟進[4]；有寄電子報或大量通知信的公司若沒設好，信件可能進垃圾郵件匣甚至被退回。這篇寫給管理 DNS 與郵件系統的 IT 人員，以及需要核定導入時程的主管。

先盤點：誰在用公司網域寄信

DMARC 進入隔離或拒收政策後，沒設定好的合法寄件來源會和偽冒信一起被擋下，所以第一步是盤點。RFC 9989 提醒，除了最簡單的環境，網域擁有者很容易漏掉某台伺服器，或不知道有哪些第三方在代為寄信[1]。常見的寄件來源包括公司信箱（Microsoft 365、Google Workspace 或自建郵件伺服器）、行銷電子報平台與 CRM、電子發票與請款通知、客服工單系統、網站表單與電商訂單通知、人資招募與活動報名系統，以及事務機掃描寄信、監控告警、ERP 排程報表等內部設備與程式。

盤點可以三管齊下：檢查現有 SPF 紀錄 include 了哪些服務；請採購與各部門列出所有以公司名義寄信的 SaaS 合約；發布 p=none 的 DMARC 紀錄後，再從彙整報告找出清單上沒有的來源（見後文）。每個來源記下負責窗口、使用的寄件網域、SPF 的設定方式、能否用公司網域做 DKIM 簽章，以及能否自訂退信（Return-Path）網域。

不在 IT 直接控管下的服務，例如大量寄送的行銷信，Microsoft 建議改用子網域（例如 marketing.example.com）寄送，避免這些郵件的問題拖累主網域的信譽；每個子網域也各自有 SPF 紀錄與 DNS 查詢額度[5][6]。

SPF 與 DKIM：每個寄件來源都要設好

SPF：一筆紀錄、十次查詢

SPF 是發布在網域上的 TXT 紀錄，列出可以用這個網域當作信封寄件者（MAIL FROM）的伺服器，例如多數 Microsoft 365 組織需要 v=spf1 include:spf.protection.outlook.com -all[5]。DMARC 只採用 SPF 對信封寄件者網域的驗證結果[1]，這個網域和收件人看到的 From 網域是否相符，要看下一節的「對齊」。設定時最常踩到的地雷：

  1. 一個網域只能有一筆 SPF 紀錄：查到多筆以 v=spf1 開頭的紀錄時，結果是 permerror[7]。新增服務時要把 include 併進原有紀錄，而不是照廠商說明再新增一筆。
  2. DNS 查詢合計不得超過 10 次：include、a、mx、ptr、exists 與 redirect 都會觸發 DNS 查詢，超過 10 次即回傳 permerror；ip4、ip6 與 all 不計入[7]。被 include 的紀錄裡若還有 include 也要一併計算，所以 include 不到 10 個，不代表查詢不到 10 次[5]。收件端也應把查無結果的「空查詢」限制在 2 次，超過同樣是 permerror[7]；include 指向的網域若已查不到 SPF 紀錄，也會導致 permerror，停用服務時要記得一併移除[5]。
  3. 超過上限時：Microsoft 建議把外部服務移到子網域（每個子網域各有 10 次額度）、整併寄信服務，或把 IP 固定且有公開文件的廠商改寫成 ip4／ip6。這種「扁平化」不適合 Microsoft 365 等 IP 經常變動的雲端服務；若採用，至少每季核對一次廠商公布的 IP[5]。
  4. ~all 還是 -all：-all（fail）明確表示未列出的主機無權使用此網域；~all（softfail）只是「可能未授權」的弱聲明，標準建議收件端不要只因 softfail 就拒收[7]。Microsoft 建議已設定 DKIM 與 DMARC 的網域使用 -all[5]。

SPF 還有一個先天限制：信件經過轉寄或別名信箱轉送後，送達時的連線 IP 已不是原寄件伺服器，SPF 多半會失敗，DKIM 簽章則一般仍然有效[1]。這也是 DMARC 不能只靠 SPF 的原因。

DKIM：每個服務各用自己的金鑰

DKIM 由寄件端以私鑰簽章，收件端到 DNS 上的 選擇器._domainkey.example.com 取得公開金鑰驗證[6]。部署重點：

  • 每個寄件服務都要用公司網域簽章：不少代管寄信服務預設以服務商自己的網域簽章，客戶完成設定後才會加上客戶網域的簽章[6]。以 Microsoft 365 為例，自訂網域目前預設不做 DKIM 簽章，必須在 DNS 建立 selector1 與 selector2 兩筆 CNAME 後再啟用[6]。
  • 金鑰長度：寄往 Gmail 個人帳號的郵件，DKIM 金鑰至少要 1024 位元，Google 建議在 DNS 服務商支援時使用 2048 位元[2]。
  • 不要共用金鑰：M3AAWG 不建議多個單位共用同一組 DKIM 金鑰[8]。每個服務使用自己的選擇器，日後停用某項服務時也能單獨撤除。
  • 定期輪替：M3AAWG 建議至少每六個月輪替一次[8]。做法是先發布新選擇器的公開金鑰，等 DNS 生效後改用新私鑰簽章，舊公開金鑰保留一段時間讓途中的郵件仍能驗證，再予移除[8]。第三方服務常以 CNAME 把選擇器指向服務商管理的金鑰，讓對方輪替時不必每次都請你修改 DNS[8]。

DMARC：從監控到拒收

DMARC 紀錄是發布在 _dmarc.example.com 的 TXT 紀錄[1]。目前的標準是 2026 年 5 月發布的 RFC 9989，取代原本的 RFC 7489，彙整報告的格式則另外定義在 RFC 9990[1][9]。也要記得：DMARC 政策只是給收件端的處理建議，收件端可以不照做；DMARC 通過也只代表寄件網域的使用經過授權，不代表信件安全[1]。

對齊：relaxed 與 strict

DMARC 通過的條件，是 SPF 或 DKIM 至少一項通過，而且通過驗證的網域與 From 網域「對齊」[1]。relaxed（寬鬆）只要求兩者屬於同一個組織網域，例如 DKIM 以 mail.example.com 簽章、From 是 news.example.com；strict（嚴格）則要求完全相同。預設是 relaxed（adkim=r、aspf=r），RFC 9989 指出幾乎所有網域擁有者都認為 relaxed 已經足夠[1]。

報告中常見的狀況，是 SPF 或 DKIM 顯示通過、DMARC 卻失敗：第三方服務用自己的退信網域通過 SPF、用自己的網域簽 DKIM，兩者都沒有和你的 From 網域對齊。解法是在該服務設定自訂退信網域，或啟用公司網域的 DKIM 簽章。RFC 9989 建議 SPF 與 DKIM 都要設定，讓每封信至少有一個、最好兩個對齊的驗證結果[1]。

分階段提高政策

RFC 9989 建議的順序是：SPF、DKIM 與報告信箱都就緒後，先以 p=none 搭配 rua 進入監控模式，用報告稽核自己的郵件流；報告中屬於合法來源卻未通過的郵件流，必須在改成強制政策之前修好[1]。視寄信頻率而定，可能要累積好幾個月的報告，才能確定所有郵件都已正確驗證[1]。紀錄可以這樣演進（example.com 換成自己的網域）：

  1. 監控：v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
  2. 隔離試行：v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com
  3. 隔離：v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com
  4. 拒收：v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com

t=y 是 RFC 9989 新增的測試旗標：p=quarantine 加上 t=y 時，收件端實際套用低一級的 none；p=reject 加上 t=y 時則套用 quarantine[1]。它取代了舊版的 pct 標籤，因為實務上 pct 除了 0 與 100 以外很少被準確執行，新標準已把 pct 列為歷史標籤[1]；依舊版標準用 pct 逐步調高套用比例的做法，在新標準下已不適用。收件端是否已採用 t 標籤，以報告中實際套用的處理結果為準[9]。

改成 reject 之前，RFC 9989 有兩項提醒：設為 reject 的網域不得只依賴 SPF，必須有有效的 DKIM 簽章；有使用者會在外部郵件論壇（mailing list）發言的網域不宜設 reject，若仍要設，應先以 p=none 至少一個月、再以 quarantine 同樣長的時間比較處理結果，並告知使用者參與郵件論壇可能受影響[1]。導入前，先問清楚哪些同仁會用公司信箱參與外部郵件論壇，例如開源專案。政府的先例可作為時程參考：美國國土安全部 2017 年 10 月發布的 BOD 18-01，要求聯邦機關在 90 天內為所有二級網域發布至少 p=none 並指定報告收件者的 DMARC 紀錄，一年內把所有二級網域與寄信主機設為 reject[10]。

子網域的政策

沒有另外設定時，主網域的 p 也適用於子網域；sp= 指定既有子網域的政策，RFC 9989 新增的 np= 則指定「不存在的子網域」的政策，np 未設定時依序沿用 sp、p[1]。例如主網域仍在 quarantine 觀察期，但想立刻拒收冒用 invoice.example.com 這類根本沒建立的子網域的信，可以發布 v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc-reports@example.com。子網域也可以發布自己的 _dmarc 紀錄覆蓋主網域的設定[6]；若把子網域委派給第三方管理，對方可能加上覆蓋主網域政策的 DMARC 紀錄，M3AAWG 建議稽核所有委派出去的網域[8]。

看懂彙整報告

彙整報告是收件端每天（或更頻繁）寄來的 XML 檔，建議以 gzip 壓縮[9]。每份報告只涵蓋一個網域，內容包括收件端找到並套用的政策、實際的處理方式、SPF 與 DKIM 各自驗證的網域與結果、是否對齊，以及每個來源 IP 的郵件數量[9]。報告格式設計給程式解析，RFC 9989 建議使用第三方分析服務或自建工具[1]。判讀時依來源分類：已知服務且通過的，持續觀察即可；已知服務卻未通過的，通常是沒有對齊或沒有 DKIM，是進入強制政策前必須清空的項目；經過轉寄、SPF 失敗但 DKIM 仍通過且對齊的，DMARC 照樣通過，不必處理[1]；不明來源且未通過的，可能是偽冒，也可能是被遺忘的系統，先對照盤點清單與 IP 歸屬查證。

rua 若指向其他網域（例如外部報告分析服務），接收報告的網域必須在 DNS 發布 example.com._report._dmarc.報告服務網域 的授權紀錄，否則收件端會忽略這個報告位址；專門的報告服務可以用萬用字元紀錄一次授權所有網域[9]。另一種「失敗報告」（ruf）可能包含大部分信件內文與信頭，有意外洩漏個資的疑慮，CISA 指出只有少數業者寄送[10]，微軟也表示 Outlook.com 沒有寄送 ruf 的計畫[4]，多數情況只設 rua 即可。

不寄信的網域也要鎖上

防禦性註冊的相似網域、舊品牌網域、只放網站的網域，都可能被拿來冒名寄信。M3AAWG 對這類不收也不寄信的「停放網域」，建議同時發布以下紀錄[11]：

  • SPF：v=spf1 -all，表示沒有任何 IP 可以代表此網域寄信。
  • DKIM：不發布任何金鑰，偽造的簽章就無從驗證通過。
  • DMARC：在 _dmarc 發布 v=DMARC1; p=reject;，rua 可視需要加上，但要指向其他有在收信的網域。
  • Null MX：MX 0 .（右邊只有一個點），表示這個網域不收信。
  • 子網域：以萬用字元 *.example.com 同樣發布 v=spf1 -all 與 null MX。

網域很多時，可以讓各網域的 _dmarc 以 CNAME 指向同一筆集中管理的拒收紀錄[11]。這組設定只適用於不收也不寄信的網域[11]；仍在使用的主網域，則靠前一節的 np=reject 保護不存在的子網域。

信箱業者的寄件要求與下一步

Gmail、Yahoo 與 Outlook.com

2024 年起，主要信箱業者陸續把郵件驗證列為寄件條件，最嚴格的要求都針對大量寄件者：

  • Gmail：2024 年 2 月 1 日起，寄信到個人 Gmail 帳號的所有寄件者都要設定 SPF 或 DKIM、寄件網域或 IP 要有有效的正向與反向 DNS（PTR）紀錄、使用 TLS 傳輸，並讓 Postmaster Tools 回報的垃圾郵件率低於 0.3%；每天寄送 5,000 封以上者還要同時設定 SPF 與 DKIM、發布 DMARC（政策可以是 none）、From 網域與 SPF 或 DKIM 網域對齊，行銷與訂閱郵件要支援一鍵退訂並在內文放明顯的退訂連結[2]。Google 計算 5,000 封時，會合併同一主網域下所有子網域的寄信量，一旦達到就永久視為大量寄件者；自 2025 年 11 月起並加強執法，不符合要求的郵件會遭到暫時或永久拒收等處置[12]。
  • Yahoo：2024 年 2 月起分階段執行，所有寄件者至少要有 SPF 或 DKIM、垃圾郵件率低於 0.3%；大量寄件者要同時有 SPF 與 DKIM、發布至少 p=none 且必須通過的 DMARC（強烈建議設定 rua，relaxed 對齊即可），支援一鍵退訂並在 2 天內處理退訂[3]。
  • Outlook.com：微軟 2025 年 4 月宣布，寄往 hotmail.com、live.com、outlook.com 個人信箱且每天超過 5,000 封的網域，SPF 與 DKIM 都要通過，DMARC 至少 p=none 並與 SPF 或 DKIM 對齊；4 月 29 日的更新改為直接拒收不符合的郵件（錯誤碼 550 5.7.515），自 2025 年 5 月 5 日起生效[4]。

三家的最低要求都是 p=none，但 none 的意思是網域擁有者沒有表達任何處理偏好[1]，只是拿到門票，擋不住冒用你網域的信。

下一步：MTA-STS、TLS-RPT 與 BIMI

SPF、DKIM 與 DMARC 處理的是別人冒用你的網域寄信。完成之後，還有兩項值得評估：

  • MTA-STS 與 TLS-RPT：保護寄給你的信在傳輸途中的加密。MTA-STS 讓收件網域公告自己支援 TLS，並要求寄件伺服器在 MX 主機沒有提供可信憑證的 TLS 時拒絕投遞；做法是發布 _mta-sts.example.com 的 TXT 紀錄，並在 https://mta-sts.example.com/.well-known/mta-sts.txt 放置政策檔，模式分為 testing、enforce 與 none[13]。testing 模式下郵件照常投遞，同時支援 TLS-RPT 的寄件端會回報驗證失敗，適合先觀察再改為 enforce[13]。
  • BIMI：在支援的信箱中顯示品牌標誌。以 Gmail 為例，DMARC 政策必須是 quarantine 或 reject（不支援 none）並套用到全部郵件，還要向憑證機構取得 VMC 或 CMC 憑證；VMC 要求標誌已註冊商標，商標程序可能需要 6 到 12 個月[14]。BIMI 適合當作 DMARC 進入強制政策後的成果。

行動清單

  • 列出公司擁有的所有網域，包括防禦性註冊、舊品牌與只放網站的網域，逐一查詢 SPF、DKIM、DMARC 與 MX 紀錄；不寄信的網域一次設好 v=spf1 -all、p=reject 的 DMARC 與 null MX。
  • 建立寄件來源清單：服務名稱、負責窗口、寄件網域、SPF 設定方式、DKIM 選擇器、能否自訂退信網域；新導入的 SaaS 若會寄信，列入採購檢核項目。
  • 確認每個網域只有一筆 SPF、DNS 查詢不超過 10 次；外部行銷寄信改用子網域。
  • 每個寄件服務都啟用公司網域的 DKIM（Microsoft 365 自訂網域要手動啟用），優先使用 2048 位元金鑰，並把每半年輪替排進維運行事曆。
  • 本週發布 p=none 加 rua 的 DMARC 紀錄，選定報告分析工具，每週檢視並修正未對齊的合法來源。
  • 訂出時程與負責人：none、quarantine、reject 逐步提高，同時設定 np；改成 reject 前，確認所有來源都有對齊的 DKIM 簽章。
  • 寄電子報或大量通知信的部門，對照 Gmail、Yahoo 與 Outlook.com 的要求檢查退訂機制與垃圾郵件率。
  • DMARC 進入強制政策後，再評估 MTA-STS、TLS-RPT 與 BIMI；需要外部協助檢視郵件與 DNS 設定時，可參考資安健檢，冒用網域的實際案例則可追蹤釣魚相關通報。