超過 90% 的網路攻擊始於偽造電子郵件。攻擊者會模仿可信賴的網域，寄送惡意訊息， 引導使用者點擊連結並洩露資料。一旦發生這種狀況，品牌可能會失去信任、遭受財務損失，並損害聲譽。 企業需要強而有力的方式來證明自身的郵件是真實的，而 DMARC 就能發揮作用。 DMARC 能協助郵件收件者確認來自您網域的郵件為正品，大幅增加偽造難度，同時提升 電子郵件送達率。 本指南說明何謂 DMARC、如何與 SPF/DKIM 整合，並透過五個簡單步驟完成設定。 您也能學習如何閱讀 DMARC 報告，以及逐步轉換至完整防護模式。
快速總結：DMARC 設定方式
什麼是 DMARC 紀錄？
DMARC 紀錄是儲存在網域 DNS 設定中的 DNS TXT 紀錄，它會指示 Gmail、Outlook、Yahoo 等郵件服務，當收件郵件未通過 SPF 或 DKIM 檢查時該如何處理。
DMARC 定義
DMARC（Domain-Based Message Authentication, Reporting, and Conformance，網域型訊息驗證、報告與一致性機制）是一項政策，用於規範接收伺服器該如何處理未通過郵件驗證的「偽裝自家網域寄送之郵件」。
DMARC 的用途
DMARC 可實現：
- 防止攻擊者利用您的網域寄送偽造郵件
- 保護品牌聲譽
- 提升送達率，讓收件者信任驗證後的郵件
- 取得濫用網域之寄件者相關報告
DMARC 關鍵參數：p=policy 政策
DMARC 政策用於指示郵件伺服器該如何處理未經授權的郵件。
| 政策 | 含義 |
|---|---|
| p=none | 僅監控，不封鎖 |
| p=quarantine | 將可疑郵件送至垃圾郵件 |
| p=reject | 完全封鎖可疑郵件 |
許多企業會從 p=none 開始，監控後切換至隔離模式，最終啟用拒絕模式。
DMARC 如何與 SPF、DKIM 協同運作
DMARC 與 SPF、DKIM 搭配運作，驗證 電子郵件寄送 的真實身份。SPF 驗證寄送伺服器的可信度，DKIM 確認郵件未被篡改，DMARC 則驗證兩者結果並決定執行動作。這套協同機制可防堵偽造郵件，並提升送達率。
SPF：驗證寄送伺服器
SPF 檢查郵件是否由網域核准的伺服器寄送。您需要建立 SPF 紀錄，列出授權來源。當未知或偽造的伺服器寄送郵件時，SPF 會將其標記為可疑，讓您能在郵件抵達使用者前阻擋偽造郵件。
DKIM：確保郵件完整性
DKIM 確認郵件在離開寄送伺服器後未被篡改。它會將透過私密金鑰生成的數位簽章加入郵件標頭，接收伺服器則使用 DNS 上的公開金鑰驗證簽章。若郵件遭到篡改，DKIM 驗證會失敗，保護網域免受篡改郵件威脅。
DMARC：最終執行機制
在 SPF 與 DKIM 驗證後，DMARC 會決定驗證失敗時的處理方式：
- 允許（p=none）
- 標記為垃圾郵件（p=quarantine）
- 完全拒絕（p=reject）
DMARC 會發送報告給來源網域，讓您能識別濫用網域的寄件者。
DMARC對齊機制：為何SPF與DKIM驗證通過仍會觸發DMARC失敗
你一定會疑惑：如果SPF、DKIM兩項驗證都顯示通過，DMARC為什麼還會判定失敗？關鍵就在對齊機制（Alignment），就算是資深郵件技術團隊也常栽在這一點。
對齊機制是讓DMARC完整運作的核心關鍵，它會比對收件者看見的寄件人From網域，與通過SPF或DKIM驗證的網域是否一致；就算SPF、DKIM各自都驗證成功，只要兩邊網域無法對齊，DMARC就會判定失敗。
什麼是DMARC對齊機制？
簡單解釋：SPF只負責驗證發送伺服器是否獲得授權，DKIM則驗證信件內容是否未遭竄改，但兩者都不會確認使用者看見的From地址，是否隸屬於本次驗證通過的網域。
這就是對齊機制的作用，DMARC規範必須符合以下任一條件才算通過：
- SPF對齊：Return-Path（MAIL FROM）的網域，必須與From表頭網域一致
- DKIM對齊：DKIM標籤d=內的簽署網域，必須與From表頭網域一致
只要其中一項完成對齊，DMARC驗證即為通過。
SPF對齊：Return-Path網域匹配規則
SPF驗證的是信封寄件位址（Return-Path / MAIL FROM），並非使用者可見的From地址。如果你的電子郵件服務商（ESP）使用第三方退回網域（例如bounce.youresp.com），SPF雖能針對該網域驗證通過，但無法和你的品牌From網域（yourcompany.com）完成對齊。
修復SPF對齊的方法：
- 使用自訂退回網域（Custom Bounce Domain），網域名稱需與你的From網域相同
- 範例：使用bounce.yourcompany.com，而非服務商預設的bounce.youresp.com
- 多數現代電子郵件服務商（包含Aurora SendCloud）皆支援自訂退回網域
DKIM對齊：d標籤網域匹配規則
DKIM透過私密金鑰簽署信件，並在DKIM表頭的d=標籤標註簽署網域；若要達成DKIM對齊，d標籤內的網域必須和From網域完全吻合。
對齊成功範例：
- From: newsletter@yourcompany.com
- DKIM d=: yourcompany.com
- ✅ 已完成對齊，DMARC驗證通過
對齊失敗範例：
- From: newsletter@yourcompany.com
- DKIM d=: youresp.com
- ❌ 未完成對齊，即便DKIM本身驗證通過，DMARC仍會失敗
修復DKIM對齊的方法：
- 務必在自家品牌網域建立DKIM金鑰，而非使用郵件服務商的網域
- 使用類似 s1._domainkey.yourcompany.com 的選擇器格式
寬鬆對齊 vs 嚴格對齊
DMARC提供兩種對齊模式，透過adkim=、aspf=兩個標籤進行設定：
| 模式 | 標籤參數 | 規則說明 | 範例 |
|---|---|---|---|
| 寬鬆對齊 | adkim=r / aspf=r | 允許子網域匹配 | From: marketing.yourcompany.com + DKIM d=: yourcompany.com → ✅ 已對齊 |
| 嚴格對齊 | adkim=s / aspf=s | 必須完整完全吻合 | From: marketing.yourcompany.com + DKIM d=: yourcompany.com → ❌ 未對齊 |
多數企業一開始會採用預設的寬鬆對齊，等到所有郵件驗證運作完全順利後，才切換為嚴格對齊模式。
團隊最常見的對齊錯誤
最典型的狀況如下：
「我們已經設定好SPF與DKIM，兩項驗證都顯示通過，但DMARC依舊失敗，問題出在哪？」 十次裡有九次都是對齊機制出錯，你的郵件服務商發信狀況會變成：
- SPF驗證通過的網域：bounce.youresp.com
- DKIM驗證通過的網域：youresp.com
- 但使用者看見的From地址：you@yourcompany.com
SPF、DK任一項都無法和你的品牌From網域對齊，因此DMARC判定失敗。
解決方案：聯繫你的郵件服務商，在自家網域建立專屬DKIM金鑰，並配置自訂退回網域。這也是眾多團隊選擇Aurora SendCloud的原因，我們簡化自訂DKIM與退回網域的設定流程，一上線就能達成完整對齊。
如何檢查對齊狀態
檢查對齊狀態最簡單的方式，就是查看DMARC彙整報告（RUA報告），報告會顯示：
- 所有以你的網域名義發送信件的來源
- 各來源的SPF、DKIM驗證結果
- 每個發送來源是否完成對齊
建議對齊率達到95%以上，再升級更嚴格的DMARC政策；若對齊率偏低，切勿直接設定p=quarantine隔離規則，應先修復所有對齊問題。
DMARC 5 步驟設定指南
只要依照清晰步驟操作，DMARC 設定非常簡單。在本篇 5 步驟指南中， 我們將從確認目前的郵件設定，到套用完整防護，依序說明每個步驟。 依序執行可避免常見錯誤，並確保您的網域套用了強固的 電子郵件驗證 機制。
步驟 1：設定前檢查（基礎建置）
在建立 DMARC 紀錄之前，您必須先完成郵件環境設定。 若 SPF 或 DKIM 無法正常運作，DMARC 也會失效。 請在此步驟確認所有功能運作順暢。
檢查現有 SPF 紀錄
使用 DNS 查詢工具檢查您的 SPF 紀錄，必須確認：
- 紀錄存在
- 包含所有您的寄送服務
- 未超過 10 次查詢限制
- 無 "+all" 或 "?all" 機制
基礎 SPF 紀錄範例如下：
v=spf1 include:mailserver.com -all
若您使用多種郵件服務，例如 Office 365、Google Workspace、CRM 工具或電子報平台，請確認每個服務都已列入清單。
驗證 DKIM 設定
請確保所有外寄郵件流程都已啟用有效的 DKIM。許多郵件業者會自動生成 DKIM 金鑰，但您必須將 DKIM 公鑰發布至 DNS。
請檢查以下項目的 DKIM：
- 主要郵件系統
- 行銷平台
- CRM 系統
- 交易式郵件 工具
DKIM 必須有效，且與網域正確綁定。
識別所有合法郵件寄件者
列出所有會以您的網域寄送郵件的服務，包含：
- 您的郵件業者
- 業務與 CRM 工具（例如 HubSpot、Zoho、Salesforce）
- 行銷工具（例如 Mailchimp、SendGrid）
- 帳務系統或客服系統
- 自訂應用程式
記錄每個服務的 IP 位址或網域。
此步驟可避免後續 DMARC 誤封合法郵件。
步驟 2：產生 DMARC 紀錄（政策建立）
當 SPF 與 DKIM 設定正常運作後，即可開始建立 DMARC 紀錄。此步驟會決定郵件伺服器該如何處理來自您網域的郵件。從正確的政策開始，能讓您監控活動、提早發現問題，並為後續強化做好準備。
從監控政策開始（p=none）
請務必從 p=none 開始。
此設定會告知郵件接收方：
- 檢查 SPF 與 DKIM
- 發送報告給您
- 暫時允許所有郵件通過
此階段可協助您蒐集數據，不會有郵件遺失的風險。
範例：
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com;
設定彙整報告（rua）
rua 參數用於設定接收每日 XML 格式報告的電子郵件地址，報告內容包含：
- 使用您網域寄送郵件的伺服器
- SPF 與 DKIM 驗證通過/失敗結果
- 郵件寄送總數
建議使用專屬信箱，範例：
rua=mailto:dmarc@yourdomain.com
選擇性設定鑑證報告（ruf）
鑑證報告會顯示單則寄送失敗的郵件範例，協助您快速偵測真實攻擊。
不過，部分業者會依隱私規則限制 ruf 報告。
範例：
ruf=mailto:dmarc-forensic@yourdomain.com
若您需要更詳細的可視化資訊，可加入此設定。
步驟 3：在 DNS 中發布 DMARC 紀錄（實際套用）
建立 DMARC 紀錄後，必須將其加入網域的 DNS 設定，讓郵件業者能讀取並套用政策。此步驟會啟用 DMARC 功能。您只需登入 DNS 控制台，建立 TXT 紀錄並貼上 DMARC 設定，儲存後政策即生效。
進入網域的 DNS 管理控制台
登入以下任一平台：
- 網域註冊商（GoDaddy、Namecheap）
- 主機業者（Cloudflare、Hostinger）
- DNS 業者（DNSMadeEasy、AWS Route 53）
找到新增 TXT 紀錄的選項。
為 DMARC 建立新的 TXT 紀錄
主機名稱必須設定為：
_dmarc.yourdomain.com
若輸入其他格式，DMARC 將無法運作。
輸入 DMARC 紀錄數值
貼上您在步驟 2 建立的完整 DMARC 紀錄。
基礎紀錄範例：
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;
儲存紀錄並等待 DNS 更新，傳播時間最長可能需要 24 小時。
步驟 4：分析報告並優化設定（監控階段）
此步驟非常重要，透過分析報告與對應處理，才能讓 DMARC 真正發揮效用。報告會顯示寄送您網域郵件的寄件者、驗證通過/失敗的郵件，以及問題發生位置。您可運用這些數據修復問題，並優化郵件驗證設定。
解析與理解彙整報告
彙整報告以 XML 格式提供，手動閱讀較為困難。
建議使用 DMARC 分析工具，將其轉換為易讀的圖表。
報告會顯示：
- 所有以您網域寄送郵件的伺服器
- 驗證結果
- 失敗案例與未知來源
快速檢查是否有可疑狀況。
識別並授權未知寄件者
若報告中出現未知來源寄送郵件：
- 確認是否為合法服務但忘記設定
- 若為合法服務，加入 SPF 或 DKIM 授權
- 若為未知來源，直接封鎖
這就是 DMARC 防範偽造的機制。
檢視驗證合格率
在切換至更嚴格的政策前，必須維持高驗證合格率。
建議目標：
- SPF 對齊率 95% 以上
- DKIM 對齊率 95% 以上
若成功率偏低，請先修復郵件驗證問題，再進入下一階段。
步驟 5：逐步套用更嚴格的政策（即時防護）
在監控報告並修復所有對齊問題後，即可開始套用更強的 DMARC 政策。在此階段，僅有通過驗證的 電子郵件寄送 能通過檢查，提升實際防護效果。逐步調整可避免封鎖合法郵件，同時阻擋無關寄件者。
切換至隔離政策（p=quarantine）
指示郵件業者將可疑郵件視為垃圾郵件處理。
範例：
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com;
再次監控報告至少 1-2 週。
切換至完全拒絕（p=reject）
穩定運作後，更新政策為完全拒絕。
範例：
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com;
這是最強力的防護模式，可阻止攻擊者濫用網域。
持續監控
達成 p=reject 後：
- 持續檢視每日報告
- 留意團隊開始使用的新服務
- 依需求更新 SPF/DKIM
- 軟體更新後檢查設定變更
DMARC 並非設定完成就結束，必須持續監控才能維持安全。
新手需避免的常見錯誤
許多新手在設定 DMARC 時都會遇到共通問題，這些錯誤會導致郵件寄送失敗，並降低防護效果。幸運的是，只要多加留意，大多數錯誤都能避免。提早瞭解這些典型錯誤，能讓您順利完成 DMARC 設定，並維持網域安全。
略過 SPF/DKIM 設定
若未設定 SPF 或 DKIM，DMARC 無法正常運作。因為 DMARC 依賴這兩項結果進行郵件驗證，所以兩組紀錄都必須有效。若缺少任一項，DMARC 會將大量郵件標記為未驗證，導致寄送問題，或無法防範網域偽造。
過早使用 p=reject
若未經監控就直接切換至 p=reject：
- 可能封鎖合法郵件
- 可能導致客戶無法接收訊息
- 無法得知寄送失敗原因
請務必從 p=none 開始。
忽略 DMARC 報告
若忽略報告：
- 無法發現潛在問題
- 錯過攻擊嘗試
- 無法識別濫用網域的對象
- 無法優化驗證完整性
報告是 DMARC 的核心功能。
結語
DMARC 會對所有外寄郵件執行 SPF 與 DKIM 檢查，強力保護您的網域免受偽造攻擊。它能驗證每封郵件的真實性與授權來源， 實現整體 電子郵件寄送 的可靠性與送達率提升。最安全的方式是從 p=none 開始，監控所有報告並修復驗證問題。 一切穩定後，再切換至隔離模式，最終啟用拒絕模式，達到完整安全防護。若您在任何階段需要協助， 我們 Aurora SendCloud 的電子郵件資安團隊將為您提供免費檢查服務，協助檢視 SPF、DKIM 與 DMARC 設定，引導您完成完整防護設定。
