這裡沒有任何把我們的意見包裝成規則的內容。如果檢查強制執行某項標準的規定,其下方會引用該標準中的原句。如果檢查強制執行的是 Google 或 Yahoo 的要求,則會連結至其頁面。如果是我們自己的判斷,則會明確註明。
驗證
接收伺服器是否能證明郵件確實來自其聲稱的來源。這是郵件送達能力中完全取決於 DNS 的一半,也是 Gmail 和 Yahoo 在 2024 年對大量寄件者強制要求的一半。
ARC 鏈 auth.arc
ARC 會保留郵件經過轉寄站時的驗證結果。若沒有 ARC,附加頁尾的郵件列表會破壞你的 DKIM 簽章,導致轉寄副本在最終接收端無法通過 DMARC。
如果失敗: 寄件者不需要採取任何動作。如果你營運郵件列表或轉寄站,這就很重要,也能解釋為什麼你的部分郵件在被他人轉寄後無法通過 DMARC。
扣除 我們評分滿分 100 分中的最多 2 分。
RFC 7960 §1 — Introduction
DMARC with restrictive policies causes problems for many Mailing Lists.
RFC 8617 §2.1 — Evidence
In ARC's situation, the "evidence" is a message's authentication assessment at any point along the delivery path between origination and final delivery.
Google — Requirements for bulk senders (5,000+/day)
DKIM 簽章 auth.dkim
DKIM 使用私密金鑰簽署郵件的部分內容,並在 DNS 中發布公開金鑰。我們會驗證郵件包含的每個簽章,並回報簽署網域、選取器和金鑰長度。
如果失敗: 在您的傳送平台啟用 DKIM,並發布平台提供給您的金鑰。使用 2048 位元(1024 位元仍可通過驗證,但正逐步淘汰)。
扣除 我們評分滿分 100 分中的最多 18 分 以及 傳統評分滿分 10 分中的最多 1 分。
RFC 6376 §3.5 — The DKIM-Signature Header Field
The signature of the email is stored in the DKIM-Signature header field.
RFC 6376 §6.1 — Extract Signatures from the Message
Verifiers MUST NOT attribute ultimate meaning to the order of multiple DKIM-Signature header fields.
Google — Turn on DKIM for your domain
Google — Requirements for bulk senders (5,000+/day)
DKIM 對齊 auth.dkim_alignment
有效的簽章不足以通過 DMARC。簽署網域必須與 From 標頭中的網域相符,依據您發布的政策,可能需要完全相符,或組織網域相符。
如果失敗: 使用您自己的網域簽署,而不是平台的網域。大多數平台都支援此功能,並將其稱為自訂或已驗證的傳送網域。
扣除 我們評分滿分 100 分中的最多 10 分 以及 傳統評分滿分 10 分中的最多 1 分。
RFC 7489 §3.1.1 — DKIM-Authenticated Identifiers
DMARC permits Identifier Alignment, based on the result of a DKIM authentication, to be strict or relaxed.
Google — Add a DMARC record
Google — Requirements for bulk senders (5,000+/day)
DMARC 結果 auth.dmarc
DMARC 將 SPF 和 DKIM 與讀者看到的網域連結起來,並告知接收方在兩者皆未對齊時應如何處理。我們會回報已發布的政策,以及這封郵件是否符合該政策。
如果失敗: 發布一筆 DMARC 記錄。先從 p=none 開始,閱讀幾週的報告,了解還有哪些來源以您的名義傳送郵件後,再改為 quarantine。
扣除 我們評分滿分 100 分中的最多 14 分。
RFC 7489 §6.6.2 — Determine Handling Policy
DMARC evaluation can only yield a "pass" result after one of the underlying authentication mechanisms passes for an aligned identifier.
RFC 7489 §6.3 — General Record Format
DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM].
Google — Requirements for bulk senders (5,000+/day)
Yahoo — Sender requirements and recommendations
Sender ID auth.sender_id
這項檢查與 SPF 相同,但會針對 From 標頭中的網域執行,而不是信封中的網域。它回答的是另一個問題:讀者看到的網域是否授權傳送郵件的伺服器。一封郵件可能以其信封通過 SPF,但可見的網域卻未替任何伺服器背書。
如果失敗: 為 From 標頭中的網域發布 SPF,而不只是為平台提供給您的退信網域發布。
扣除 我們評分滿分 100 分中的最多 5 分 以及 傳統評分滿分 10 分中的最多 0.5 分。
RFC 4406 §4 — Record Selection
After the above steps, there should be one record remaining and evaluation can proceed.
SPF auth.spf
SPF 是一筆 DNS 記錄,列出哪些伺服器可以為您的網域傳送郵件。接收伺服器會取得信封中的地址、查詢該網域的記錄,並檢查連線的 IP 是否包含在其中。我們會回報結果及該記錄所需的 DNS 查詢次數,因為評估會在十次時停止,超過此數量會是永久錯誤,而不是通過。
如果失敗: 發布一筆僅指定您的傳送平台、不包含其他項目的記錄。如果您的記錄接近十次查詢的限制,請展開您未使用的 include(今天能通過的記錄,可能會在供應商自行新增一個 include 的那天開始失敗)。
扣除 我們評分滿分 100 分中的最多 18 分 以及 傳統評分滿分 10 分中的最多 1 分。
RFC 7208 §4.6.4 — DNS Lookup Limits
SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror".
RFC 7208 §2.6 — Results of Evaluation
Section 4 defines check_host(), a model function definition that uses the inputs defined above and the sender's policy published in the DNS to reach a conclusion about client authorization.
Google — Define an SPF record
Google — Requirements for bulk senders (5,000+/day)
SPF 對齊 auth.spf_alignment
退信地址是否與讀者看到的 From 地址相符。SPF 授權的是信封,而 DMARC 只會在兩者對齊時採計該授權。
如果失敗: 向您的傳送平台申請屬於您自己網域的退信子網域。如果您的 DKIM 已經對齊,這並不急迫,但當 DKIM 在傳輸途中失效時,您將沒有備援機制。
扣除 我們評分滿分 100 分中的最多 5 分 以及 傳統評分滿分 10 分中的最多 0.5 分。
RFC 7489 §3.1.2 — SPF-Authenticated Identifiers
In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.
RFC 7489 §6.6.2 — Determine Handling Policy
If one or more of the Authenticated Identifiers align with the RFC5322.From domain, the message is considered to pass the DMARC mechanism check.
Google — Add a DMARC record
Google — Requirements for bulk senders (5,000+/day)
基礎設施與信譽
傳送郵件的機器和位址,以及網際網路上其他系統已經如何評價它們。
傳送主機名稱可解析 infra.a_record
在 HELO 中宣告的主機名稱是否具有位址記錄。
如果失敗: 為伺服器宣告的名稱發布 A 記錄。
扣除 我們評分滿分 100 分中的最多 5 分 以及 傳統評分滿分 10 分中的最多 3 分。
RFC 5321 §5.1 — Locating the Target Host
If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
Google — MX record values and troubleshooting
封鎖名單 infra.dnsbl
寄件 IP 是否列在收件端實際查詢的任何封鎖名單中。我們會依據每個區域本身記載的測試點檢查名單,而不是從網路搜尋結果拼湊,因為失效的區域會回應 NXDOMAIN,而這會被解讀為「乾淨」。
如果失敗: 依照列名營運方網站上的除名流程操作。被主要區域列入名單會直接阻擋郵件,因此應優先於頁面上的其他問題處理。
扣除 我們評分滿分 100 分中的最多 25 分 以及 傳統評分滿分 10 分中的最多 3 分。
RFC 5782 §2.1 — IP Address DNSxL
Each IPv4 address listed in the DNSxL has a corresponding DNS entry.
RFC 5782 §5 — Test and Contact Addresses
IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing purposes.
Google — Postmaster Tools: reputation and delivery errors
Google — Email sender guidelines
HELO 名稱 infra.helo
傳送伺服器在 SMTP 對話開始時用來宣告自身身分的名稱。它必須是可解析的完整網域名稱。
如果失敗: 將郵件伺服器的主機名稱設為你網域中的實際名稱,而不是容器 ID 或內部名稱。
扣除 我們評分滿分 100 分中的最多 5 分。
RFC 5321 §4.1.1.1 — Extended HELLO (EHLO) or HELLO (HELO)
The argument clause contains the fully-qualified domain name of the SMTP client, if one is available.
Google — Email sender guidelines
Google — Requirements for bulk senders (5,000+/day)
MX 記錄 infra.mx
From 標頭中的網域是否能接收郵件。若沒有 MX,回覆和退信將無處可送,而篩選器會將無法接收郵件的傳送網域視為不良跡象。
如果失敗: 為你用來寄信的網域發布 MX 記錄,即使它只會將郵件路由至你每月查看一次的信箱。
扣除 我們評分滿分 100 分中的最多 5 分 以及 傳統評分滿分 10 分中的最多 3 分。
RFC 5321 §5.1 — Locating the Target Host
The lookup first attempts to locate an MX record associated with the name.
Google — MX record values and troubleshooting
反向 DNS infra.rdns
傳送 IP 是否能反向解析為主機名稱,以及該主機名稱是否能正向解析回相同的 IP。重點在於往返解析:讓 PTR 指向任何位置都很容易,而相符的一對記錄則可證明該位址屬於你。
如果失敗: 要求 IP 的擁有者將 PTR 設為你控制的名稱,並確認該名稱具有指回此 IP 的 A 記錄。
扣除 我們評分滿分 100 分中的最多 12 分 以及 傳統評分滿分 10 分中的最多 1.5 分。
RFC 1912 §2.1 — Inconsistent, Missing, or Bad Data
Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.
Google — Email sender guidelines
Google — Requirements for bulk senders (5,000+/day)
傳輸加密 infra.tls
郵件是否透過 TLS 抵達,以及使用哪種加密套件。所有現代系統都會協商 TLS;以明文抵達的郵件表示傳送設定有問題。
如果失敗: 在傳送伺服器上啟用 STARTTLS。所有主流平台都已支援此功能,因此此處失敗通常表示傳輸路徑中有自行代管的轉送站。
扣除 我們評分滿分 100 分中的最多 5 分。
RFC 3207 §2 — STARTTLS Extension
The STARTTLS extension to SMTP is laid out as follows:
Google — Require TLS for secure message transport
Google — Requirements for bulk senders (5,000+/day)
垃圾郵件引擎
獨立內容篩選器如何判斷這封郵件。使用兩個引擎而非一個,因為單一引擎的分數只是該引擎的判斷。
AI 判定 spam.ai_judge
模型會根據技術檢查結果與內容量測數據,估算現代機器學習篩選器會如何處理該郵件。它看到的是事實,而不是郵件本文。
如果失敗: 單獨來看僅供詳細參考。其估算會納入下方的綜合判定。
僅顯示詳細資訊。絕不計分。
綜合判定 spam.panel
由有回應的引擎產生一個數值,並經過加權,讓最強烈的判定不會單純因平均而被稀釋。SpamAssassin 與 Postmark 因為共用規則庫,所以合計為一票。
如果失敗: 逐項處理個別檢查結果。它們變動時,此列也會跟著變動。
扣除 我們評分滿分 100 分中的最多 25 分。
Google — Why Gmail marks messages as spam
How this score is calculated
Postmark SpamCheck spam.postmark
第三方意見,預設關閉。其端點會接收整封郵件,而我們無法在不破壞受測內容的情況下遮蔽其中任何部分,因此啟用它就表示接受每封受測郵件都會複製給第三方。
如果失敗: 無須處理。關閉時,檢查會回報它已關閉,這不等同於通過。
僅顯示詳細資訊。絕不計分。
Rspamd spam.rspamd
第二個獨立開發的篩選器。它與 SpamAssassin 意見不一致的頻率高到值得詢問,這就是它出現在這裡的原因。
如果失敗: 僅供詳細參考。此引擎的意見會納入綜合判定,而不會單獨計分。
僅顯示詳細資訊。絕不計分。
SpamAssassin spam.spamassassin
經典的規則式篩選器,目前仍是大多數電子郵件測試工具背後的引擎。所有觸發的規則都會連同其權重列出。
如果失敗: 查看觸發的規則,而不是總分。只要能看出是哪些規則,大多數都很容易排除。
扣除 傳統評分滿分 10 分中的最多 3 分。
Google — Why Gmail marks messages as spam
Apache SpamAssassin — rule documentation
建議
值得採用,而且絕不計分。本節中的任何項目都不會扣分,這是由測試強制執行的產品決策。
BIMI advisory.bimi
網域是否發布 BIMI 記錄,這會在某些用戶端中於您的郵件旁顯示標誌。這需要先有強制執行的 DMARC 政策,以及需要付費的已驗證標誌憑證。
如果失敗: 當 DMARC 設為 quarantine 或 reject,且郵件量足以合理化憑證成本時,便值得實作。
建議項目。不扣分。
BIMI — draft specification, not yet an RFC
DKIM 金鑰使用時間與長度 advisory.dkim_key_rotation
簽署金鑰的長度,以及已使用多長時間。每過一年,離線攻擊短金鑰的成本都會降低。
如果失敗: 改用 2048 位元,並依排程輪替。發布新的選擇器,將簽署切換至該選擇器,然後停用舊的選擇器。
建議項目。不扣分。
RFC 8301 §3.2 — Key Sizes
Since short RSA keys more easily succumb to off-line attacks, Signers MUST use RSA keys of at least 1024 bits for all keys. Signers SHOULD use RSA keys of at least 2048 bits.
Google — Turn on DKIM for your domain
DNSSEC advisory.dnssec
網域是否已簽署。SPF、DKIM 和 DMARC 全都位於 DNS 中,因此能偽造 DNS 回應的攻擊者也能偽造這三者。
如果失敗: 在你的網域註冊商處啟用。通常只需開啟一個開關,其餘部分由網域註冊商處理。
建議項目。不扣分。
RFC 4033 §2 — Definitions of Important DNSSEC Terms
Authentication Chain: An alternating sequence of DNS public key (DNSKEY) RRsets and Delegation Signer (DS) RRsets
MTA-STS advisory.mta_sts
網域是否發布政策,要求其他伺服器拒絕向您進行未加密的郵件投遞。它保護的是寄給您的郵件,而不是您寄出的郵件。
如果失敗: 透過 HTTPS 發布 TXT 記錄與政策檔案(約需一個下午的工作,而且能防堵降級攻擊)。
建議項目。不扣分。
RFC 8461 §3 — Policy Discovery
To discover if a recipient domain implements MTA-STS, a sender need only resolve a single TXT record.
TLS 報告 advisory.tls_rpt
網域是否要求在有人無法透過 TLS 投遞至該網域時提供報告。與 MTA-STS 搭配使用:只有政策而沒有報告,會讓你無法判斷它是否正常運作。
如果失敗: 新增 TXT 記錄,並指定一個可接收每日報告的地址。
建議項目。不扣分。
RFC 8460 §3 — Reporting Policy
A domain publishes a record to its DNS indicating that it wishes to receive reports.