Email Spam Tester 執行測試 · 給 AI 代理 · API

測試如何運作

傳送一封郵件至一次性地址,系統就會對其執行 39 項檢查。本頁列出所有檢查:每項檢查的內容、失敗時會扣除多少分,以及依據的標準章節。

這裡沒有任何把我們的意見包裝成規則的內容。如果檢查強制執行某項標準的規定,其下方會引用該標準中的原句。如果檢查強制執行的是 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

內容

郵件本身:其結構、連結、圖片,以及篩選器在做出判斷前讀取的內容。

圖片 alt 文字 content.alt_attributes

圖片是否帶有 alt 屬性。郵件用戶端預設會封鎖遠端圖片,因此在最初幾秒內,alt 文字就是您的訊息。

如果失敗: 撰寫能傳達含義的 alt 文字,絕不要讓主要視覺元素缺少 alt 文字。

扣除 我們評分滿分 100 分中的最多 4 分 以及 傳統評分滿分 10 分中的最多 0.5 分。

Google — Email sender guidelines

script 與 iframe content.forbidden_tags

HTML 是否包含任何郵件用戶端都不會執行的標籤。它們往好處說會被移除,往壞處說會被視為規避訊號。

如果失敗: 移除 script、iframe、object 和 embed。任何互動功能都應放在連結後方。

扣除 我們評分滿分 100 分中的最多 10 分 以及 傳統評分滿分 10 分中的最多 1 分。

Google — Email sender guidelines

純文字與 HTML 的平衡 content.html_text_ratio

訊息中的標記相對於可讀文字有多少。整頁標記只包著一句話,是篩選器能辨識的形式。

如果失敗: 撰寫內容與 HTML 相同的純文字部分,而不是佔位內容。

扣除 我們評分滿分 100 分中的最多 3 分 以及 傳統評分滿分 10 分中的最多 0.3 分。

RFC 2046 §5.1.4 — Alternative Subtype

Systems should recognize that the content of the various parts are interchangeable.

Google — Why Gmail marks messages as spam

純文字與 HTML 部分 content.html_version

訊息是否在 HTML 之外也附帶純文字替代版本。部分篩選器會衡量是否缺少它,而且每個螢幕閱讀器都需要它。

如果失敗: 使用 multipart/alternative 傳送實際的純文字版本,而不是空白部分或一行要求在瀏覽器中檢視的文字。

扣除 我們評分滿分 100 分中的最多 5 分。

RFC 2046 §5.1.4 — Alternative Subtype

The "multipart/alternative" type is syntactically identical to "multipart/mixed", but the semantics are different. In particular, each of the body parts is an "alternative" version of the same information.

Google — Email sender guidelines

HTML 大小 content.html_weight

HTML 部分有多大。Gmail 會截斷約超過 102 KB 的訊息,並將其餘內容隱藏在連結後面,連帶使取消訂閱頁尾也被隱藏。

如果失敗: 精簡行內 CSS 和重複的樣式區塊(移除未使用的規則後,大多數範本的大小可控制在限制的三分之一以內)。

扣除 我們評分滿分 100 分中的最多 3 分 以及 傳統評分滿分 10 分中的最多 0.3 分。

Google — Email sender guidelines

圖片大小 content.images_weight

郵件載入的所有圖片總大小。過大的圖片會讓郵件在手機上載入緩慢,而只有圖片的郵件是篩選器會視為可疑的形態。

如果失敗: 壓縮圖片,並確保關閉圖片後仍可閱讀郵件。

扣除 我們評分滿分 100 分中的最多 3 分 以及 傳統評分滿分 10 分中的最多 0.3 分。

Google — Email sender guidelines

附件掃描 content.malware

附件是否含有已知惡意軟體。在已關閉掃描器的部署環境中,此項會回報掃描未執行,而不是回報附件安全。

如果失敗: 如果此項觸發,請停止傳送,並查明建立郵件的機器上有什麼問題。

扣除 我們評分滿分 100 分中的最多 60 分。

Google — Why Gmail marks messages as spam

ClamAV — how detection works

預覽文字 content.preheader

用戶端在主旨旁顯示的預覽行。若未設定,則會顯示郵件正文最前面的內容,通常是瀏覽器檢視連結。

如果失敗: 在郵件正文中加入隱藏的預覽文字區塊,並將其設為第一個元素。

扣除 我們評分滿分 100 分中的最多 2 分。

Google — Email sender guidelines

主旨行 content.subject

長度、大小寫及篩選器評分的模式。我們測量解碼後的主旨,因此西里爾字母或 CJK 主旨行會按文字而非其編碼來判定。

如果失敗: 將長度控制在約 60 個字元以內,避免使用全大寫和驚嘆號。

扣除 我們評分滿分 100 分中的最多 3 分。

RFC 5322 §2.2 — Header Fields

Header fields are lines beginning with a field name, followed by a colon (":"), followed by a field body, and terminated by CRLF.

RFC 2047 §2 — Syntax of encoded-words

An 'encoded-word' is defined by the following ABNF grammar.

Google — Why Gmail marks messages as spam

縮短連結 content.url_shortener

連結是否經過公開的短網址服務。短網址服務會隱藏目的地,而這正是篩選器被訓練去懷疑的行為。

如果失敗: 連結至您自己的網域,或在您自有網域的子網域上使用平台的追蹤網域。

扣除 我們評分滿分 100 分中的最多 5 分 以及 傳統評分滿分 10 分中的最多 0.5 分。

Google — Why Gmail marks messages as spam

大量寄件者規則

Gmail 和 Yahoo 針對任何大量寄件者公布的要求。這些要求適用於群發郵件,對於看起來不像群發郵件的訊息則會略過。

已發布 DMARC 政策 compliance.dmarc_present

From 網域是否有發布 DMARC 記錄,這與此郵件是否通過 DMARC 是兩回事。Gmail 和 Yahoo 要求大量寄件者發布此記錄。

如果失敗: 發布一筆記錄。p=none 足以符合要求,並會提供可供後續處理的報告。

扣除 我們評分滿分 100 分中的最多 6 分。

RFC 7489 §6.3 — General Record Format

p: Requested Mail Receiver policy (plain-text; REQUIRED for policy records).

Google — Requirements for bulk senders (5,000+/day)

Yahoo — Sender requirements and recommendations

List-Unsubscribe compliance.list_unsubscribe

郵件是否帶有郵件用戶端可執行的取消訂閱標頭。Gmail 和 Yahoo 要求大量寄件者提供此標頭,而且不論其他條件如何,缺少此標頭都會被納入過濾判斷。

如果失敗: 新增含有 HTTPS URI 的 List-Unsubscribe 標頭。所有寄件平台都能做到這一點。

扣除 我們評分滿分 100 分中的最多 10 分 以及 傳統評分滿分 10 分中的最多 1 分。

RFC 2369 §3.2 — List-Unsubscribe

The List-Unsubscribe field describes the command (preferably using mail) to directly unsubscribe the user (removing them from the list).

Google — Requirements for bulk senders (5,000+/day)

Yahoo — Sender requirements and recommendations

一鍵取消訂閱 compliance.one_click_unsubscribe

更嚴格的形式:一個 HTTPS URI、一個「List-Unsubscribe-Post」標頭,以及一個涵蓋這兩個標頭的有效 DKIM 簽章。三者缺一不可,否則收件方不會顯示按鈕。

如果失敗: 通常漏掉的是簽章:平台會簽署「List-Unsubscribe」,卻忘了「List-Unsubscribe-Post」。這兩個標頭名稱都必須出現在同一個簽章的 h= 標籤中。

扣除 我們評分滿分 100 分中的最多 8 分。

RFC 8058 §4 — Additional Requirements

The List-Unsubscribe and List-Unsubscribe-Post headers MUST be covered by the signature and included in the "h=" tag of a valid DKIM-Signature header field.

RFC 8058 §3.1 — Mail Senders

The List-Unsubscribe header field MUST contain one HTTPS URI.

Google — Requirements for bulk senders (5,000+/day)

Yahoo — Sender requirements and recommendations

建議

值得採用,而且絕不計分。本節中的任何項目都不會扣分,這是由測試強制執行的產品決策。

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.