企業寄件人如何在 Microsoft 365 完成 DMARC 設定與驗證確認
使用 Microsoft 365 寄送商業開發信的企業，經常在 DNS 後台看到 dmarc policy not enabled 這類提示卻不知從何處理，結果信件陸續被收件方標記為垃圾或直接進站失敗。DMARC 設定本身不難，難的是理解它和 SPF、DKIM 之間的驗證邏輯，以及設定完成後如何確認真的生效。這篇文章會用實際操作步驟說明，讓負責寄送冷開發信的行銷或業務團隊，能自行完成設定並持續監控。
- DMARC 是建立在 SPF 與 DKIM 之上的驗證政策，三者缺一都會讓 dmarc check online 顯示未通過
- Microsoft 365 預設不會自動啟用 DMARC，dmarc policy not enabled 是常見的初始狀態而非錯誤
- 設定完成後應分階段從 p=none 調整到 quarantine 再到 reject，避免正常信件被誤擋
- 冷開發信因寄件量小、頻率穩定，特別依賴良好的網域驗證紀錄來建立寄件人信譽
- 定期用 dmarc 設定 確認 方法搭配報表判讀，比只做一次性設定更能維持長期送達率
為什麼 Microsoft 365 寄件人不能只做 SPF 就結束
SPF、DKIM、DMARC 是三層互相搭配的驗證機制，各自解決不同問題。SPF 告訴收件伺服器「哪些主機可以代表這個網域寄信」，DKIM 用簽章證明信件內容在傳輸過程沒被竄改，DMARC 則規定當 SPF 或 DKIM 驗證失敗時該怎麼處理，同時把驗證結果彙整成報表回傳給網域管理者。很多企業只設定了 SPF 就以為完成驗證，實際上收件方（尤其是 Gmail、Yahoo 等大型信箱服務）近年已把 DMARC 是否存在,列為判斷寄件人是否可信的重要依據。
對於執行冷開發信的企業來說，這件事的重要性又更高一層。冷開發信本身寄件量小、對象精準，但正因為是主動聯繫陌生收件人，收件伺服器會更嚴格檢視寄件網域的驗證完整度與過往紀錄。沒有完整 DMARC 設定的網域，即使內容完全合法、對象也經過篩選，仍可能被系統判定為風險寄件來源，導致近期寄出的信件進垃圾匣機率上升。
值得留意的是，透過 Microsoft 365 蒐集與使用企業聯絡人資料寄送商業開發信，仍需符合個人資料保護法對非公務機關蒐集、處理個人資料須有特定目的與合理關聯的規範。因此 DMARC 設定除了是技術層面的送達率議題，也是企業展現寄件行為正當、可被追溯查核的一環，而不是單純為了「繞過」垃圾郵件過濾機制。
三步驟完成 Microsoft 365 的 SPF、DKIM、DMARC 設定
在 Microsoft 365 系統管理中心，DMARC 相關設定實際上分散在網域的 DNS 紀錄與 Exchange 後台兩處，建議依序處理，避免漏掉其中一項導致驗證鏈中斷。
- 第一步：在網域 DNS 確認 SPF TXT 紀錄已包含 Microsoft 365 的寄件主機，內容通常包含 include:spf.protection.outlook.com，若企業同時用第三方寄信工具（如冷開發信平台）寄信，也要把該平台的 SPF 片段一併加入同一筆 TXT 紀錄
- 第二步：在 Microsoft 365 系統管理中心啟用 DKIM 簽章，針對寄件網域產生金鑰後，會得到兩筆 CNAME 紀錄，需分別加入 DNS 並等待 Microsoft 365 顯示簽章狀態為「已啟用」
- 第三步：新增一筆 DMARC TXT 紀錄，主機名稱為 _dmarc，初期建議設定 p=none 搭配 rua 標籤指定接收報表的信箱，先觀察一段時間再決定要不要升級政策強度
- 確認三筆紀錄（SPF、DKIM 的兩筆 CNAME、DMARC）都已在 DNS 生效後，再回到系統管理中心的網域頁面檢查驗證狀態，通常會標示為已驗證或待處理
一筆基本的 DMARC TXT 紀錄範例：主機名稱 _dmarc.yourcompany.com，內容為 v=DMARC1; p=none; rua=mailto:dmarc-report@yourcompany.com; pct=100，這筆紀錄的意思是先不做任何攔截動作，但把所有驗證結果的彙整報表寄到指定信箱供後續判讀。
如何確認 DMARC 是否生效：dmarc check online 工具與報表判讀
DNS 紀錄新增完成不代表立即生效，DNS 全球傳播通常需要數小時到一天，加上 Microsoft 365 本身的驗證狀態更新也有延遲。想確認 dmarc 設定 確認 方法最直接的做法，是使用 dmarc check online 類型的工具直接查詢網域的 DMARC 紀錄是否正確被 DNS 解析回傳，同時搭配 spf dkim dmarc check online 綜合檢測工具，一次確認三項紀錄是否都對齊，避免只檢查了 DMARC 卻忽略 SPF 記錄超過查詢上限或 DKIM 金鑰過期等問題。
除了即時查詢工具，DMARC 設定裡指定的 rua 報表信箱會定期收到 XML 格式的彙整報表，內容會列出哪些寄件來源通過驗證、哪些失敗。剛設定完成的前幾週建議每週檢查一次報表，觀察通過率是否穩定上升，再決定是否把政策從 p=none 逐步調整為 quarantine 甚至 reject。
數據為 LDM 協助企業客戶執行 B2B 精準開發信時觀察到的常見進度區間，僅供參考，實際速度依網域寄件來源複雜度而異。
常見錯誤：dmarc policy not enabled 到底是什麼意思
看到 dmarc policy not enabled office 365 這類提示，多半代表 Microsoft 365 系統偵測到網域目前沒有有效的 DMARC TXT 紀錄，而不是設定被關閉或出錯，這是很多剛開始處理的團隊會誤解的地方。真正需要排查的，通常是 DNS 紀錄本身的細節問題。
- SPF 記錄沒有涵蓋所有實際寄件來源，例如只寫了 Microsoft 365 卻漏掉冷開發信平台或行銷自動化工具的寄件主機
- DKIM 金鑰未在系統管理中心手動啟用，即使 DNS 已加入 CNAME 紀錄，簽章狀態仍顯示停用
- DMARC 政策長期停留在 p=none 沒有升級，導致即使驗證失敗也不會有任何實際攔截效果，等於形同虛設
- 企業使用多個子網域寄信（例如行銷用的 mail.yourcompany.com），但 DMARC 紀錄只設在主網域，子網域未被涵蓋
比例為 LDM 服務 B2B 精準開發信客戶時彙整的常見成因分布，僅供參考。
冷開發信情境下，DMARC 與寄件節奏如何搭配
完整的 DMARC 設定只是基礎，冷開發信的送達表現同時取決於寄件節奏是否穩定、內容是否個人化、以及回覆處理是否即時。LDM 在協助企業建立冷開發信流程時，會先確認網域的 SPF、DKIM、DMARC 三項都設定正確且通過率穩定在九成以上，才開始逐步提升每日寄件量，避免新網域或剛調整完驗證政策的網域一開始就承受高流量。
同時，冷開發信平台的寄件動作會寫入 CRM 供業務追蹤回覆，這也是為什麼驗證設定要做到位——當寄件人身分被收件伺服器信任，回覆率才會反映真實的名單品質，而不是被驗證失敗拖累的假性低回覆。
- 設定前先盤點所有會使用該網域寄信的服務（Microsoft 365、冷開發信平台、行銷工具），一次寫入 SPF
- DMARC 政策以 p=none 起步，觀察至少兩到三週報表再考慮升級
- 每次新增寄件來源（例如換用新的開發信工具）都要回頭更新 SPF 與確認 DKIM
- 把 dmarc check online 檢查排入每月例行維運，而不是設定完就不再回頭看
常見問題
dmarc policy not enabled 是不是代表帳號有問題？
不是帳號問題，而是網域的 DNS 目前沒有偵測到有效的 DMARC TXT 紀錄。只要照步驟在 DNS 新增一筆 _dmarc 紀錄並確認格式正確，這個提示就會消失。
設定完 DMARC 之後多久可以把政策調整為 reject？
建議先以 p=none 觀察至少兩到三週，確認合法寄件來源的通過率穩定在九成以上，再逐步調整為 quarantine，最後才調整為 reject，避免中間有漏掉的寄件來源被誤擋。
有推薦的 spf dkim dmarc check online 工具嗎？
市面上有多種免費線上工具可以同時查詢一個網域的 SPF、DKIM、DMARC 紀錄是否正確，選擇能同時顯示三項結果、並提供修正建議的工具會比較省時，不需要逐一分開查詢。
使用 LDM 這類冷開發信平台，還需要自己設定 DMARC 嗎？
需要。平台可以協助寄送與追蹤回覆，但 DMARC 是綁定在企業自有網域上的驗證設定，必須由網域管理者在 DNS 端完成，平台無法代為設定。
子網域也需要單獨設定 DMARC 嗎？
如果企業用不同子網域寄送不同類型的信件（例如行銷用一個子網域、交易通知用另一個），建議個別確認涵蓋範圍，或在主網域的 DMARC 紀錄中加上 sp 標籤，明確指定子網域的處理政策。