DMARC

新增 DMARC 記錄

定義網域對於可疑電子郵件的處理方式

您可以在網域的 DNS 記錄中新增政策,藉此設定「網域型郵件驗證、報告與一致性」(DMARC) 驗證機制。這些政策會定義您的網域對於可疑電子郵件的處理方式。定義政策時,必須使用 TXT 記錄格式。

以下是您的網域在回應可疑電子郵件時,可能採取的三種 DMARC 政策:

  • 不對郵件採取任何處置,僅將郵件記錄於每日報告中。
  • 將郵件標記為垃圾郵件,並保留郵件以便進行其他處置 (隔離)。
  • 取消郵件,以免傳送給收件者。

請根據下方「DMARC 記錄中的常用標記」表格的說明,在 TXT 記錄裡以 p 標記設定 DMARC 政策。

先設定 SPF 和 DKIM

建議您在設定 DMARC「之前」,先設定寄件者政策架構 (SPF)DomainKeys Identified Mail (DKIM)。DMARC 會使用 SPF 和 DKIM 來驗證郵件,無法通過 SPF 或 DKIM 檢查的郵件就會觸發 DMARC 政策。

建立 DMARC 記錄

您可以建立 TXT 記錄並加入適當標記名稱和值,藉此定義您要在網域中使用的政策。

TXT 記錄名稱必須採用下列格式,其中「your_domain.com」為您的網域名稱:
 _dmarc.your_domain.com 

建立 DMARC TXT 記錄的提示

下列文章提供了建立 DMARC 記錄的相關詳細資訊:

DMARC TXT 記錄中的常用標記

注意:Gmail 不支援用於傳送失敗 (鑑識) 報告的 DMARC「ruf」標記。

標記名稱 是否必要 說明和值 範例

v

必要 通訊協定版本。此值必須為 DMARC1 v=DMARC1

p

必要

設定您的網域對於可疑郵件的處理方式:

  • none (無):不對郵件採取任何處置,僅將可疑郵件記錄於每日報告中。
  • quarantine (隔離):將郵件標示為垃圾郵件,並保留郵件以便進行其他處置。
  • reject (拒絕)取消郵件,以免傳送給收件者。
p=quarantine

pct

選用

設定要套用 DMARC 政策的可疑郵件百分比值。可疑郵件是指未通過 DMARC 檢查的郵件。預設值為 100

pct=20

rua

選用

回報匯總報告的統一資源識別項 (URI)。如要取得您網域中 DMARC 活動的相關報告,請使用這個選項並加入您的電子郵件地址。

rua=mailto:aggrep@example.com

sp

選用

為主網域中的子網域所寄送的郵件設定政策。如果您想為子網域設定不同的 DMARC 政策,請使用這個選項。可選用的值與 p 標記的值相同。

 

sp=reject

aspf

選用

設定 SPF 的校正模式 (ASPF),該模式會定義郵件資訊與 SPF 簽名的相符程度,預設值為「寬鬆」。

r:「寬鬆」設定允許部分比對吻合,例如針對網域中的子網域。

s:「嚴格」設定要求比對完全吻合。

aspf=r

 

逐步部署 DMARC

您可以同時使用政策 (p) 和百分比 (pct) 選項,在 Gmail 中逐步部署 DMARC。

如何逐步部署 DMARC 政策

使用政策 (p) 選項。您可以使用 TXT 記錄中的 p 標記值來設定及變更政策選項。建議您先從隔離政策開始,以便檢查可疑的郵件。接下來可根據您從已隔離郵件和每日報告中所得知的資訊,逐步修改政策。

  1. p=none:監控電子郵件流量並找出每日報告中顯示的問題,但允許所有郵件通過。請注意是否有假冒郵件和未經 DKIM 或 SPF 簽署的郵件。
  2. p=quarantine:等到您掌握每日報告中呈現的電子郵件模式後,即可將政策變更為「隔離」。請繼續檢閱每日報告,並查看遭歸類 (隔離) 為垃圾郵件的郵件。
  3. p=reject:確認所有您網域寄送的郵件都已經過簽署後,請將政策變更為「拒絕」,開始過濾垃圾郵件。同時也不要忘記繼續檢閱每日報告,確認您已過濾掉垃圾郵件,且傳送給收件者的電子郵件皆為有效郵件。

使用百分比 (pct) 選項。您可以使用百分比選項指定要套用 DMARC 政策的可疑郵件百分比;可疑郵件是指未通過 DMARC 檢查的郵件。這個選項的預設值為 100%,也就是將政策套用至所有可疑郵件。起初請先使用百分比選項過濾少量郵件,之後每隔幾日再隨著 DMARC 政策的修正情形提高百分比值。舉例來說,一開始您可以先將百分比選項設定為 20,過濾 20% 的遭拒絕或隔離郵件,然後下一週再將數值從 20 提高為 50,改為過濾 50% 的郵件。

部署範例:以下範例說明如何使用 p 和 pct 選項來逐步部署 DMARC 政策。請依序使用下列值調整 DMARC 政策:

  1. p=none pct=100
  2. p=quarantine pct=1
  3. p=quarantine pct=5
  4. p=quarantine pct=10
  5. p=quarantine pct=25
  6. p=quarantine pct=50
  7. p=quarantine pct=100
  8. p=reject pct=1
  9. p=reject pct=5
  10. p=reject pct=10
  11. p=reject pct=25
  12. p=reject pct=50
  13. p=reject pct=100

TXT 記錄範例

以下列出部分 DMARC TXT 記錄範例,您可以按照實際使用情況自行修改。請複製這些記錄,並將「<您的網域>.com」和「postmaster@<您的網域>.com」改為您的網域和電子郵件地址。

如有需要,請根據每日報告內容變更政策和百分比值。

TXT 記錄範例:「不採取處置」

針對所有看似從 <您的網域>.com 寄出但未通過 DMARC 檢查的郵件,皆不採取任何處置,同時將每日報告傳送至「postmaster@<您的網域>.com」。

"v=DMARC1; p=none; rua=mailto:postmaster@<您的網域>.com"

TXT 記錄範例:「隔離郵件」

在所有看似從 <您的網域>.com 寄出但未通過 DMARC 檢查的郵件中,隔離 5% 的郵件,同時將每日報告傳送至「postmaster@<您的網域>.com」。

"v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@<您的網域>.com"

TXT 記錄範例:「拒絕郵件」

拒絕所有看似從您的網域寄出但未通過 DMARC 檢查的郵件,同時將每日報告傳送至「postmaster@<您的網域>.com」和「dmarc@<您的網域>.com」。

"v=DMARC1; p=reject; rua=mailto:postmaster@<您的網域>.com, mailto:dmarc@<您的網域>.com"

DMARC 每日報告

DMARC 每日報告採 XML 格式,會提供與郵件收發情形相關的資訊。您可以透過每日報告掌握以下事項:

  • 確認外寄郵件來源已通過驗證
  • 確認從您網域寄出郵件的皆為正當的電子郵件伺服器
  • 如有新伺服器上線或現有伺服器出現設定問題,報告會回報相關資訊
DMARC 報告範例

以下提供報告摘錄內容,當中顯示從兩個 IP 位址寄出郵件的不同結果,其中一封郵件是直接傳送,另一封則是轉寄郵件;兩封郵件均已通過 DMARC 檢查。


<record>
<row>
<source_ip>207.126.144.129</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>
<record>
<row>
<source_ip>207.126.144.131</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<reason>
<type>forwarded</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
<identities>
<header_from>stefanomail.com</header_from>
</identities>
<auth_results>
<dkim>
<domain>stefanomail.com</domain>
<result>pass</result>
<human_result></human_result>
</dkim>
<spf>
<domain>stefanomail.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>

這篇文章實用嗎?
我們應如何改進呢?