為什麼會跳出 DMARC Policy Not Enabled 警告？逐步排解全指南

許多企業在 GoDaddy、cPanel、Hostinger、Namecheap 或 Office 365 的後台,某天突然看到「DMARC policy not enabled」的警示,卻不清楚代表什麼、該去哪裡修。這不是單純的技術瑕疵——沒有生效的 DMARC 政策,代表寄件網域缺少最後一道防偽驗證,冷開發信很容易被判定為可疑來源,連帶拖累到達率與寄件信譽。本文整理各家主機的排解步驟,以及後續該如何驗證與監控。

「DMARC Policy Not Enabled」警示是什麼意思？

登入 GoDaddy、cPanel、Hostinger 或 Namecheap 的後台,突然看到網域健康檢查跳出「dmarc policy not enabled」的紅字警示,第一反應通常是不知道要點哪裡。這句警示的字面意思很單純：系統在你的網域 DNS 裡查不到有效的 _dmarc TXT 記錄,等於這個網域完全沒有發布 DMARC 政策,不代表帳號被停權,也不代表 SPF、DKIM 一定沒設定,但確實少了信件驗證機制裡最後也是最關鍵的一環。

對冷開發信寄件人來說,這個警示格外值得重視。SPF、DKIM 只能各自驗證郵件路徑或簽章,真正告訴接收端信箱「如果驗證失敗該怎麼處理、又要把報告寄給誰」的,是 DMARC。沒有這道政策,寄出的開發信在 Gmail、Outlook 等主流信箱眼中,就像一封身分不明的信——輕則被丟進垃圾郵件夾,重則整個網域的寄件信譽被拖累,連帶影響日後所有郵件的到達率。

各家主機的逐步修復流程：GoDaddy、cPanel、Hostinger、Namecheap、Office 365

不同主機介面用詞不同,但修復邏輯完全一樣：新增一筆 TXT 記錄,主機名稱固定是 _dmarc,數值放 DMARC 政策字串。

• GoDaddy：網域管理 → DNS → 新增紀錄,類型選 TXT,主機名稱填 _dmarc,數值填入 DMARC 字串,儲存後等待網域健康檢查重新掃描。
• cPanel：登入後台 → Zone Editor 或 Email Deliverability 工具,若已提示「未啟用」,通常會直接給一鍵新增按鈕,按下後系統會自動帶入建議的 SPF/DKIM/DMARC 記錄,仍建議手動核對 rua 收件信箱是否正確。
• Hostinger：登入 hPanel → 網域 → 進階 DNS 記錄,新增 TXT,主機名稱 _dmarc,內容同上;hPanel 的 DNS 傳播通常需要數小時。
• Namecheap：Domain List → Manage → Advanced DNS → Add New Record,類型選 TXT Record,主機打 _dmarc,數值貼上 DMARC 字串,注意介面會自動幫網域加上根網域,主機欄只需填 _dmarc,不要重複填整個網域名。
• Office 365 / Microsoft 365：這個警示通常出現在 Microsoft Defender 合規中心的網域或反垃圾郵件報告,實際設定仍要回到你網域的 DNS 供應商新增 _dmarc TXT 記錄,Microsoft 365 本身不提供 DNS 託管,只負責讀取與提示。

設定完成後,如何確認 DMARC 真的生效

新增記錄之後,不要只看主機後台的燈號變綠就結案。DNS 傳播需要時間,快則十分鐘,慢則一整天,這段期間內主機面板仍可能顯示未啟用。比較可靠的做法是自己用指令覆核,例如在終端機下 dig TXT _dmarc.你的網域.com（Windows 可用 nslookup -type=TXT）,或使用線上的 DMARC 檢測工具,直接貼上網域就能看到目前發布的完整政策字串,包含 p、rua、pct 等標籤是否正確。

如果覆核後仍查不到任何內容,多半是下列幾種狀況造成,而不是單純的「DNS 還沒跑完」。

五個常見的 DMARC 設定錯誤

就算主機面板顯示綠燈,也不代表政策設定得夠穩健。以下是實務上最常見、也最容易被忽略的錯誤。

• 把記錄主機名打成 dmarc 而不是 _dmarc,導致 DNS 查不到任何政策。
• 同一個網域底下同時存在兩筆 _dmarc TXT 記錄,造成解析衝突,等同沒有設定。
• 直接跳到 p=reject,沒有先用 p=none 觀察報告,結果誤擋了合法的行銷信或轉寄信。
• rua 標籤留空或填錯信箱,導致完全收不到彙總報告,看不見誰在冒用網域。
• 只設定主網域,卻忽略實際寄送冷開發信用的子網域,子網域的 DMARC 繼承規則被忽略。
• 設定完立刻檢查就下結論「沒生效」,其實只是 DNS 傳播還沒跑完,通常需要數小時到一天。

政策等級如何影響到達率與品牌保護

DMARC 有三個政策等級：p=none（只監控,不影響信件收送）、p=quarantine（驗證失敗就丟進垃圾郵件夾）、p=reject（驗證失敗直接拒收）。多數指南都建議先從 none 開始,原因很實際——如果一開始就設 reject,你可能還沒發現自己的 SPF 記錄裡漏了某個寄件服務商,合法的開發信就已經被攔截,而你完全不會收到退信通知。

隨著彙總報告持續進來,確認所有真正的寄件來源(公司信箱、CRM、行銷平台)都對齊驗證後,再逐步升級。從實務經驗看,政策等級與主流信箱的到達率大致呈正相關,但這也表示升級前的準備工作不能省。

上線前檢查清單,以及 LDM 如何處理寄件網域驗證

以下是正式排程冷開發信前,建議逐項確認的清單。

• 確認 SPF 記錄存在且沒有超過 10 次 DNS 查詢上限。
• 確認 DKIM 已由寄件平台正確簽署,並在 DNS 完成公鑰發佈。
• 新增 _dmarc TXT 記錄,先以 p=none 起步並填妥 rua 彙總報告信箱。
• 用 dig 或線上工具覆核記錄,確認主機面板顯示的已啟用與 DNS 實際查詢結果一致。
• 觀察兩到四週的彙總報告後,再考慮升級到 p=quarantine、最終 p=reject。
• 針對冷開發信,額外使用獨立的寄件子網域,與公司主網域的日常信件分流,降低單一網域信譽受牽連的風險。

常見問題