SPF DKIM DMARC設定：公司寄件驗證與逐步收緊政策指南

SPF DKIM DMARC設定：先拆解一封看似公司寄出的信

同事收到一封顯示公司地址為寄件人的電郵，內容卻要求更改付款資料。看見「From」欄寫着自己域名，不代表郵件一定由公司授權系統發出。SPF DKIM DMARC設定的作用，是為收件系統提供不同層次的寄件驗證與處置政策；商戶先要查清有哪些真正寄件來源，才可安全設定及逐步收緊。

本文用文字拆出三層：SPF 核對傳送來源對特定網域是否獲授權，DKIM 驗證郵件簽章與簽章網域，DMARC 再看驗證結果是否與信件上可見的寄件網域對齊，並提供相關政策與報告。它們不能代替員工判斷可疑付款要求，也不能保證所有正常電郵都必然進入收件箱。

如果公司尚未分清郵箱、寄件帳戶及網站通知由誰管理，可先看公司電郵設定指南整理基礎名單。這篇專注網域驗證與政策推出次序，不重講新同事開戶步驟。所有 DNS 改動都應由獲授權人員按實際供應商文件處理，不用把文章中的概念直接複製成正式設定值。

第一層：SPF 判斷某個來源是否可替網域寄信

轉寄會令來源檢查變得複雜

郵件由甲郵箱自動轉寄到乙郵箱後，乙所見的傳送來源可能是轉寄主機，而不是原來的寄件系統。這時單看 SPF 的 pass 或 fail，容易誤判整封信的真偽；還要查看 DKIM 是否仍能通過，以及寄件網域有沒有符合 DMARC 對齊條件。轉寄方如採用特殊處理，也要依實際標頭判讀，不能因某個平台常見做法而假設所有信都一樣。排查時保留原始標頭，比轉寄後只留一張畫面截圖有用。

別把所有收件主機的 IP 加進 SPF 以修正個別轉寄問題，因為授權的是替你寄信的來源，而不是任何收件來源。看到不明白的 DNS 片段，先找出由哪個供應商提供、當初對應哪種郵件服務；保留清單後才決定是否需要移除。

先辨認技術上的寄件身分

SPF 根據寄件伺服器的網絡來源，對 SMTP 使用的相關網域進行核對，不是單憑收件人眼中可見的「From」文字作判斷。RFC 的SPF 規格說明其授權概念。商戶不必先記下所有技術字段，但要知道：一封信能通過 SPF，不代表顯示給收件人的公司地址已經通過 DMARC 對齊。

假設公司日常職員透過商務郵件平台寄信，網站表單透過另一個外部服務寄通知，報價系統亦會自動發信。三種來源可能分別由不同伺服器處理。若只為職員電郵設置授權，卻漏掉網站與報價系統，正常郵件便可能遇到驗證問題。上線前應從真正會寄出的服務開始盤點。

一個網域的 SPF 資料要有清晰管理者

DNS 中的 SPF 設定通常以 TXT 記錄形式發布，應由負責網域的人核對現有資料後再修改。不能因新服務說「加一條 SPF」就直接新增另一條同用途的 SPF 紀錄，造成多份相互衝突的安排。要整合不同寄件來源，也須查服務提供者目前指示與 SPF 規格限制，避免內容愈加愈長而失效。

另一個重點是誰批准移除已停用來源。過去用過的行銷平台若已沒有寄信需要，仍留在授權資料中，會擴大可替公司網域寄信的範圍。可在供應商更換時更新寄件來源清單，列出用途、負責人與確認日期，再由技術人員安排設定及測試。不要只因看見陌生網域就立即刪除，應先查它是否仍承擔訂單或帳戶通知。

第二層：DKIM 讓收件端核實郵件簽章

簽章金鑰輪換需要連同發信端測試

DKIM 一般會用識別用的 selector 指向 DNS 上的公開資料；寄件服務以相應的私密資料簽署郵件。更新金鑰時，應先依供應商文件確認新 selector 已刊登、服務已切到新簽署設定，再留意舊信仍在傳遞時是否需要保留原有紀錄一段過渡期。不要未測試就刪掉仍可能被使用的紀錄，也不要把私密金鑰當成一般網站文章或電郵附件任意傳閱。

一個公司可能由電郵主機、網店和活動平台分別寄件，三者未必使用相同 selector；應逐個來源寄測試信，檢查簽署結果及簽署網域。供應商說「DKIM 已開」只代表設定的一部分，實際郵件經過範本修改、轉寄或轉碼後仍需在收件端驗證。

簽章由寄件服務使用，公開資料由網域提供

DKIM 讓寄件服務在郵件加上簽章，收件端可以利用網域發布的公開資料作驗證。其技術規格描述簽章網域及選擇器等概念。商戶需要知道哪個服務會替郵件簽署、DNS 記錄由誰加入，以及更換金鑰時誰處理；不需自己設計密碼學方法，更不應把私人金鑰抄進網站文章。

假設公司有兩個不同寄件平台，它們可能各有設定要求及識別用的選擇器。接入新平台時先核對現有 DNS 與舊服務，按提供者文件新增必要公開資訊，再寄測試信驗證。不要為了令一個新來源通過測試，便把原有正常寄件服務所需資料清走。

簽章通過，也要看是否與可見網域相關

DKIM 成功驗證某個服務的簽章，只代表相應簽章能被核對，未必表示可見寄件地址的網域與之相同。這就是 DMARC 為甚麼仍要考慮「對齊」。有些合法代寄服務會使用自己的網域簽章，若沒有按公司網域完成相應配置，收件端可能看到簽章通過，DMARC 卻不因此通過。

因而不能只向供應商問「有沒有 DKIM」，應問發出的郵件中使用哪個簽章網域、能否按公司寄件地址配置，以及有甚麼測試方式。若寄件服務無法滿足需要，可與它討論可行安排或調整寄件地址，不要在不知道結果時立即加嚴網域政策。

第三層：DMARC 把驗證結果連到可見的寄件網域

網域對齊的檢查例子

假設員工在收件者眼中以公司網域作 From，實際寄件來源的 SPF 驗證卻只通過另一個無關網域，則 SPF 通過不等於和這個 From 對齊。如果 DKIM 簽章所屬網域也不對齊，DMARC 可能無法通過。反過來說，只要通過的 SPF 或 DKIM 其中一個符合適用的對齊規則，便可能符合 DMARC 驗證要求。判讀時要分清標頭 From、信封寄件網域與 DKIM 簽章網域，三者不是同一欄。

當公司有子網域寄件時，別單憑主網域已發布紀錄就假設所有子網域都按預期受控；要了解政策如何套用及實際寄件網域的配置。調整前用具代表性的測試信確認收件方看到的標頭，並記錄是哪個團隊擁有該寄件來源。

對齊比單純通過更接近冒認問題

DMARC 參考 SPF 或 DKIM 驗證結果，檢查至少一條通過的路徑是否與郵件標示給收件人的寄件網域符合對齊規則。DMARC 的規格說明可供技術人員核對；實務上先理解為：陌生人即使用自己的合法郵件服務通過某項驗證，也不能因此冒認與公司相同的可見地址。

DMARC 包含讓收件方了解政策的 DNS 資料，也可提供報告接收方式。它是向收件系統表達處理建議，實際投遞仍由各收件服務按自身機制決定。因此不要把「已設定 DMARC」寫成保證收件或完全杜絕欺詐。公司仍要管理寄件帳戶、員工驗證習慣及付款確認流程。

由觀察到收緊，先確保正常郵件有路可走

政策可先採觀察方式，收集能取得的報告並盤點正常來源，再按已修正的結果考慮更嚴格處理。若一開始就要求收件系統嚴格處理未通過的郵件，而公司網站通知尚未對齊，真實訂單或查詢通知可能受到影響。先找出所有寄件路徑，測試重要郵件，才有條件逐步推進。

「收緊」也不是日期到就自動更改。每次修改前要有數據判讀、受影響服務清單、負責人及回退方法；修改後核對外部收件結果。若報告顯示某來源不明，先查它是否是公司授權的舊服務或代寄系統，不能直接以發信數目多寡判斷是否攻擊。

先做寄件來源盤點，避免傷及正常工作

人手發信以外的系統最容易被漏掉

帳單系統、網站表格、網店訂單、預約提醒及外部行銷平台，都可能以公司域名寄出郵件。請逐項列用途、發信地址、發送服務、負責人及能否在受控環境寄出測試信。就算某個服務每月只寄一次，也不應因平日看不到便忽略；政策變動後才發現遺漏，可能已影響客戶收取重要通知。

若網站程式曾直接從主機寄信，應向維護者查明使用哪個身份與伺服器，以及是否符合現有寄件安排。網站程式及表格開發會影響通知來源，主機與電郵寄存服務也可能提供不同發送路徑。兩邊需要共同核對，不能只由管理郵箱的人自行猜測網站用甚麼寄信。

代辦服務需提供可以核實的技術資料

公司可能由供應商代管 DNS 或商務電郵，不一定親自編輯記錄，但仍需知道哪個網域受影響、資料由誰核對，以及新增寄件服務時該聯絡誰。若所有設定只寫「供應商處理」，下次換報價系統便沒有人知道原有授權會否衝突。可以保留經核實的設定摘要與聯絡方法，不用向所有同事公開完整管理權限。

若網域持有人或註冊商帳戶仍未釐清，先參考域名控制權與續期的檢查方法，確定誰能批准 DNS 變動。登入權與改記錄權若掌握在離職同事手上，即使知道 SPF、DKIM、DMARC 應怎樣設，也可能無法安全落實。

DNS 更新：查清目前資料，按供應商指示修改

TXT 記錄名稱與位置不能憑印象

SPF 與 DMARC 的發布位置不同，DKIM 常涉及選擇器指定的名稱。操作時應對照提供者正式指示、目前 DNS 管理平台與域名實際資料，不要把一段示例字串貼到所有位置。某些平台會自動補上網域名稱，若再手動輸入完整名稱，可能造成設定在錯誤位置。修改後須從公開解析結果與實際測試兩方面核對。

主網域與子網域也可能有不同寄件用途。假設帳單用一個子網域發送，不能只檢查主網域便宣稱所有郵件已通過。公司應按服務提供者的要求列出需要的寄件網域，並在資料表中保留每項記錄目的。若日後移除某個服務，才能知道相應資料是否可安全清理。

避免同時更換郵箱與加嚴政策

若公司正搬遷商務郵箱、改網站寄件服務及部署 DMARC，最好分階段測試，保存每步前後的結果。一次改動多個來源，遇到收件失敗時較難定位。先確認新舊郵件系統各自寄出一封測試信的驗證狀態，再按切換計劃逐步改記錄，比只等一段時間看有沒有人投訴更可靠。

DNS 資料可能有快取與傳播時間，測試應記錄查詢時點、所用域名與服務方顯示的結果。看到部分收件方結果不同，先檢查是否取到同一版設定，不要不停新增記錄試圖「補足」。經批准的回退方案亦需保存舊內容，讓負責人可以按證據恢復，而非靠人手記憶重打一段設定。

驗證郵件：看標頭，也看收件結果

每個來源都要寄到不同收件環境

從職員郵箱、網站表格和其他自動系統各寄一封不含真實客戶資料的測試信，核對收件方可見地址、驗證結果及內容是否正常。若只有職員信通過，而網站通知落入垃圾郵件，便要針對該寄件來源檢查，不應再改動所有帳戶共用的設定來碰運氣。

收件介面可能顯示摘要的驗證資訊，技術人員亦可檢查郵件標頭，但不同提供者用語不完全一致。商戶要保留的是哪個來源、哪個地址、送往哪種收件服務、得到甚麼結果。測試通過後還要回到業務流程：客戶是否收到訂單確認、客服是否收到查詢通知，不應只停在技術標籤。

轉寄及郵件清單可能影響單一路徑

正常郵件若經第三方轉寄，收件系統看到的傳送來源可能改變，SPF 結果可能受影響；DKIM 是否仍有效則要看轉寄過程有沒有改動已簽章的內容。不能因某封經轉寄的郵件驗證出問題，便直接判定原寄件系統全部錯誤。應記下郵件完整路徑，由技術人員判斷如何處理。

公司若靠多人轉寄共用查詢郵箱，應在部署更嚴格政策前把這條路徑列入測試。收信安排與寄信驗證有關，但不等於要取消所有轉寄。可按現有供應商支援的方式討論收件與群組安排，維持日常操作之餘減少不必要的驗證落差。

讀 DMARC 報告：來源分類比看到一個數字有用

用報告建立待調查清單

報告若顯示某來源反覆寄信，先問它是不是日常系統，例如職員郵箱、網站表單通知或外部活動平台。若來源在清單內，但不能通過對齊，就核查設定、寄件路徑與供應商指引；若來源不認識，也不應即時假定是攻擊，應與業務團隊交叉查找是否有被遺忘的發信工具。報告中的接收端、時間區間及驗證結果，可以幫助收窄問題範圍，但不能單憑 IP 就認定一個具名寄件人。

建立「已確認合法、待跟進、未知」三種處理狀態，記下負責人與下次檢查日期。若政策收緊後合法郵件受到影響，這張清單能指出哪個來源、從何時開始、曾作甚麼改動。涉及可疑冒認時，保留調查資料，避免公開貼出含內部郵件路徑或個人資料的完整報告。

先找正常寄件來源與未知來源

如果已設定報告接收，可由獲授權人員整理來源網絡、驗證情況及涉及網域。報告反映收件方觀察到的部分郵件，不能單靠一份資料精確判定全部攻擊或全部正常。要先把來源與公司寄件清單對照，查出漏登記的服務及無法解釋的郵件，再逐項核實。

未識別來源有可能是未盤點的合法系統，也可能與冒認有關。不要只因顯示大量失敗便自行封鎖某組來源，亦不要把表面上通過的來源全當作公司員工。應找技術負責人檢視 SPF、DKIM 與可見寄件網域的關係，並記錄每項判斷的依據與尚待查明的部分。

報告收件箱本身也要有人管理

大量機器產生的報告若寄去日常客服郵箱，可能令員工難以分辨正常查詢。可指定合適的接收地址與處理人，限制只有需要的人能查閱。報告中可能包含發送來源及網域資料，應按公司資料處理要求保管；定期提供管理摘要即可，不必把原始報告轉發給所有部門。

摘要可包括新發現的正常來源、待確認來源、需要調整的寄件服務，以及政策仍不能收緊的原因。這比只報「通過率改善」更能讓公司決定下一步。若一項重要通知仍無法穩定對齊，便先修該來源，再考慮政策變更，不應只為追一個數字而犧牲正常郵件。

政策推出要有回退與商戶確認

每次改動要有前後對照

可先以觀察與盤點為主，再由網域負責人按實際寄件情況決定是否調整政策；轉到較嚴格的處理時，應同時記下舊 DNS 設定、改動原因、實施人及何時覆核。驗收郵件要涵蓋內部職員、網站系統通知，以及經外部平台代寄的郵件，並由真實收件路徑檢查標頭與收件結果。不能只檢查 DNS 查詢顯示有一筆紀錄，就宣稱信件已能如常送達。

若遇到正常郵件被隔離或拒收，先辨認受影響來源，回查最近修改及對齊結果，再由授權人決定修正寄件配置或調整政策。回退亦需考慮 DNS 更新傳播需時，不宜在很短時間連續改多次而不記錄。把「誰決定、誰檢查、誰通知使用者」寫入工作單，遇上假期或人手交接才不會靠記憶處理。

先檢查最怕漏收的郵件

公司可列出查詢確認、訂單收據、帳戶復原、付款通知等高影響郵件，指定負責人在政策修改前後各驗證一次。若無法在測試環境完整發出，應安排合適的正式測試方式，避免與真實客戶訂單混淆。測試結果應包括收件時間、郵件是否到達及驗證資訊。

如果政策收緊後某類正常郵件突然送不到，先按預先訂好的程序核對 DNS 版本、該系統寄件身分與收件回應，再決定是否需要回退。不要只重試寄信或叫客戶到垃圾郵件尋找，因為問題可能影響所有後續郵件。遇到無法即時處理的情況，業務同事也要知道可用的臨時聯絡方法。

冒認風險不能只交給 DNS

SPF、DKIM、DMARC 能改善驗證及提供處置訊號，仍不能防止有人用近似拼法的其他網域、已被接管的真實帳戶或社交手法行騙。財務更改收款資料時，應沿已知渠道再次核實，而不是只看寄件地址或圖示。公司網站亦可提供清晰正式聯絡方法，方便收到可疑通知的客戶查證。

將電郵帳戶管理與網站及帳戶保安盤點連起來，檢查離職帳戶、復原地址與第三方寄件權限是否仍合適。三種網域驗證處理的是郵件可信度的一部分；帳戶權限與內部流程，仍需要有人負責跟進。

常見的設定交接錯漏

公司換電郵供應商時，容易只更新職員郵箱的 MX 和 SPF，卻忘了網店通知、會計郵件及行銷系統仍使用原本的寄件路徑。先整理每一類信的實際發件系統、標頭 From、操作帳戶及內部負責人，再逐類送測試信。MX 主要處理收信路徑，不能把「收信成功」當作寄件驗證成功；寄件政策要按真實外發路徑另行核對。

另一個錯漏是把各部門獲得的 DNS 指示逐條貼上去，未檢查相同名稱有沒有互相矛盾的紀錄。更改前先匯出目前 DNS 資料，標明由誰管理，找出是否已有同用途設定；若供應商指引寫得含糊，要問明白應合併、替換還是另設子網域。後續若發現寄件失敗，保留原始設定、原始郵件標頭及改動時間，技術同事才能逐步追查。

對於小公司而言，最實用的交接文件不是一串專有名詞，而是一張表：哪個系統為哪種業務寄信、使用哪個 From 網域、誰可以改它、如何寄測試信、收件端應看到甚麼結果。資料齊全後，即使將來換人接手，也較容易理解每筆 SPF、DKIM、DMARC 設定的用途。

常見問題

只設 SPF，是否足夠防止別人冒認寄件地址？

不夠。SPF 驗證 SMTP 使用的相關寄件網域與來源，收件人看到的寄件地址可能並非同一網域。DKIM 提供簽章驗證，DMARC 再檢查是否與可見寄件網域對齊及宣告政策。即使設定齊全，也要持續管理帳戶與員工付款核實流程。

DMARC 開始就使用最嚴格政策，是否比較安全？

若公司尚未盤點合法寄件來源，嚴格政策可能影響網站通知或其他正常郵件。先核對來源、測試對齊與閱讀可用報告，再有計劃地調整政策。每一步都應保留重要郵件的實際收件結果，以及遇上異常時誰決定回退。

改了 DNS，為何網站寄出的信仍未通過？

可能是網站仍透過未盤點的服務寄信、簽章網域沒有對齊，或測試時看到舊的 DNS 結果。先記下具體來源、收件方及驗證資訊，由電郵與網站維護人員對照當前設定；不要未查原因便新增另一份 SPF 記錄或直接把政策放寬。

郵件通過驗證，是否就一定進收件箱？

不一定。各收件服務仍有自己的垃圾郵件判斷與投遞規則，驗證結果只是其中一部分。若某來源有收件問題，應蒐集退信、時間、寄件與收件地址及可取得的驗證結果，先分辨是設定、內容或其他原因，再找相關服務方協助排查。

準備設定公司寄件網域前，可把職員郵箱、網站通知及所有外部寄件系統列成一張清單，向 Black Media 詢問電郵與網域設定的配合。先查清合法來源，再逐步測試與調整政策，才較有把握保障日常收發。