電子郵件送達率怎麼救？SPF、DKIM、DMARC 設定與退信率排查

去年秋天我幫一位做線上課程的朋友檢查網站，她抱怨「學員都說沒收到上課通知」。我請她自己用 Gmail 註冊一次，通知信果然靜靜躺在垃圾郵件匣裡。她的網站已經穩定跑了兩年，內容沒問題、主機沒問題，出問題的是沒有人會去看的那三筆 DNS 記錄。

那次之後我養成一個習慣：接手任何一個會寄信的網站，第一件事不是看外掛，是去查 SPF、DKIM 和 DMARC。這三個字母縮寫聽起來很技術，但它們決定的事情非常世俗——你的信到底算不算「你」寄的。郵件送達率之所以難救，是因為多數人一開始就把它當成內容問題，花力氣改標題、刪連結、少放圖，結果真正的破口在網域設定，改再多文案都沒用。

更麻煩的是，2024 年之後這件事從「建議」變成「門檻」。Gmail、Yahoo 陸續對大量寄件者訂出硬性要求，Outlook.com 在 2025 年也跟進；而 DMARC 的規範本身在 2026 年 5 月被三份新的 RFC 整個換掉。如果你手上的設定筆記是 2023 年寫的，裡面至少有兩個地方已經過時。

這篇是我自己在用的排查順序，從「先分清楚退信和垃圾桶」開始，一路寫到 DNS 記錄怎麼填、WordPress 的 wp_mail 為什麼幾乎必死、交易信服務怎麼挑，以及退信率與投訴率該看哪幾個數字。所有門檻數字都逐條回到官方頁面核對過，查核日一律是 2026 年 8 月 6 日。查不到的我會直接寫「官方未公布」，不會替它編一個看起來很精確的數字。

先分清楚：信「沒送到」和「送到了但進垃圾桶」是兩件事

我看過太多人把兩種狀況混在一起講。使用者說「沒收到信」，可能是伺服器根本拒收（你會收到退信通知），也可能是對方收到了、只是被丟進垃圾郵件匣（你什麼都不會收到）。這兩件事的成因、排查方法和修法完全不同，混在一起查就是浪費一個下午。

退信這一側有明確的技術訊號。RFC 3463（Enhanced Mail System Status Codes，2003 年 1 月，Standards Track）把狀態碼分成三類：2.X.X 是成功，4.X.X 是「persistent transient failure」，5.X.X 是「permanent failure」。規範對 5.X.X 的定義是「A permanent failure is one which is not likely to be resolved by resending the message in the current form.」——同一封信再寄一次也不會成功，這就是硬退信的技術定義。

常見的兩個碼很有代表性。5.1.1 是「The mailbox specified in the address does not exist.」，也就是收件位址根本不存在；4.2.2 則是「The mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity.」，信箱滿了，過幾天可能就好了。把 4.2.2 當成 5.1.1 處理、直接把人從名單刪掉，是很多自製寄信腳本會犯的錯。

進垃圾桶那一側則幾乎沒有回饋。收件方不會告訴你「我把它歸類為垃圾信」，你只會看到開信率莫名其妙從 30% 掉到 4%。這也是為什麼送達率要用「主動監測」而不是「等客訴」的方式管理——等到有人抱怨，通常已經壞了好幾週。

下表只列我能找到官方出處的幾個碼。市面上流傳的「退信碼對照表」很多都把各家自訂的訊息當成標準碼在列，實際上 5.7.x 之後的細分很大一部分是各收件方自己定義的，查的時候要回到該收件方的文件。

狀態碼	類別	官方定義	出處
2.X.X	成功	「Success specifies that the DSN is reporting a positive delivery action.」	RFC 3463
4.X.X	持續性暫時失敗	「the message as sent is valid, but persistence of some temporary condition has caused abandonment or delay」	RFC 3463
5.X.X	永久失敗	「not likely to be resolved by resending the message in the current form」	RFC 3463
5.1.1	永久失敗	「The mailbox specified in the address does not exist.」	RFC 3463
4.2.2	暫時失敗	「The mailbox is full because the user has exceeded a per-mailbox administrative quota or physical capacity.」	RFC 3463
5.7.515	永久失敗（Outlook.com 自訂）	「Access denied, sending domain [SendingDomain] does not meet the required authentication level.」	Microsoft 官方公告

三層原因：驗證、信譽、內容

我習慣把「為什麼進垃圾桶」拆成三層，由下往上檢查。第一層是驗證層：你的網域有沒有正確宣告誰能代表你寄信、信有沒有帶簽章、From 有沒有對齊。驗證層是唯一一個「全對或全錯」的層次，也是唯一一個你可以在一個下午內完全修好的層次，所以永遠先修它。

第二層是信譽層：你的寄件 IP 和網域在各家收件方眼中的歷史紀錄，包含退信率、垃圾回報率、有沒有打到蜜罐位址。信譽層修起來以週為單位，因為它本質上是統計，你必須用一段時間的好行為把平均值拉回來。

第三層才是內容層：主旨寫法、圖文比例、連結網域、有沒有附加追蹤參數。內容層是三層裡影響最小、也最容易被過度優化的一層——如果前兩層沒修好，內容改再乾淨也只是把一封「來路不明的信」變成「乾淨但來路不明的信」。

順帶一提，這個分層邏輯和我在電子報行銷入門那篇談從 0 建立訂閱名單的做法是互補的：那篇處理的是「名單怎麼來」，這篇處理的是「信怎麼進得去」。名單品質差會直接毀掉信譽層，所以兩件事其實是同一個系統的兩端。

驗證層的分工：SPF、DKIM、DMARC 各自解決什麼

這一段是全篇最容易寫錯、也最值得慢慢看的地方。網路上很多中文教學會說「SPF 用來防止別人冒用你的網域寄信」，這句話嚴格來說是錯的。SPF 完全不看收件人在信箱裡讀到的那個寄件者位址，它看的是信封層的回郵位址（RFC5321.MailFrom）。

RFC 7208（Sender Policy Framework for Authorizing Use of Domains in Email, Version 1，2014 年 4 月，Standards Track，取代 RFC 4408）定義的就是這件事：網域擁有者在 DNS 發佈一筆 TXT 記錄，列出哪些 IP 位址有資格代表這個網域送信，收件伺服器拿連線來源 IP 去比對。比對的對象是連線的 IP 和信封寄件網域，不是收件人畫面上顯示的 From。

DKIM 走的是另一條路。RFC 6376（DomainKeys Identified Mail Signatures，2011 年 9 月，Internet Standard STD 76）讓寄件方用私鑰對信件的標頭與內文簽章，公鑰放在 DNS。規範自己的說法是：「DKIM permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message.」注意這句話的關鍵字是「claim some responsibility」——DKIM 宣告的是「某個網域願意為這封信負責」，它同樣沒有規定簽章網域必須等於 From 網域。

所以真正把「收件人看到的 From」綁進來的是 DMARC。DMARC 引入「identifier alignment」（識別符對齊）的概念，要求 SPF 或 DKIM 通過的那個網域，必須和 From 標頭的網域相符，才算 DMARC 通過。換句話說：SPF 和 DKIM 各自只驗一半，DMARC 才是那個把驗證結果和使用者實際看到的身分接起來的協定——這就是三者的分工。

項目	SPF	DKIM	DMARC
規範	RFC 7208（2014-04，Standards Track）	RFC 6376（2011-09，Internet Standard STD 76）；密碼學部分由 RFC 8301 更新	RFC 9989／9990／9991（2026-05，Proposed Standard），取代 RFC 7489
驗證什麼	連線來源 IP 是否被信封寄件網域授權	信件標頭與內文自簽章後未被竄改，且某網域承擔責任	SPF 或 DKIM 通過的網域是否與 From 標頭網域對齊
DNS 記錄	網域根層一筆 TXT，v=spf1 …	選擇器._domainkey.網域 的 TXT，v=DKIM1; k=rsa; p=…	_dmarc.網域 的 TXT，v=DMARC1; p=…
能否直接防止 From 偽造	否（不檢查 From）	否（簽章網域可與 From 不同）	是（對齊是其核心機制）
轉寄會不會壞掉	會（轉寄後來源 IP 換了）	通常不會（除非郵件被改寫）	取決於底下哪一個還活著
失敗的處置由誰決定	收件方自行決定	收件方自行決定	網域擁有者用 p= 表達偏好，收件方仍保有裁量權

表格最後一列值得多說一句。RFC 9989 全文把 p 標籤的作用描述成網域擁有者的「message handling preference」（訊息處置偏好），而第 5.4 節則寫得更直接：「The final handling of any message is always a matter of local policy and is left to the discretion of the Mail Receiver.」也就是說，你設 p=reject 不等於全世界都會替你拒收，它是一個很強的訊號，但不是一個開關。

SPF 實際怎麼填：格式、機制與那個 10 次查詢上限

一筆最基本的 SPF 記錄長這樣，發佈在網域根層的 TXT：v=spf1 include:_spf.google.com include:amazonses.com ~all。前面的 include: 表示把該網域的 SPF 記錄整段納入判斷，最後的 ~all 表示「其他來源算 softfail」。把 ~all 改成 -all（hardfail）是收緊，改成 +all 則等於宣告任何人都能代表你寄信，那是災難。

RFC 7208 定義的結果只有七種：pass、fail、softfail、neutral、none、temperror、permerror。其中 permerror 最值得警覺，因為它代表你的記錄本身有結構性錯誤，收件方無法完成判斷——這種時候「設了 SPF」等於「沒設 SPF」。

10 次 DNS 查詢上限：最常見的隱形殺手

這是我在實務上抓到最多次的問題。RFC 7208 第 4.6.4 節寫得非常直白：「SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.」會計入這 10 次的是 include、a、mx、ptr、exists 五個機制，加上 redirect 修飾詞。

不計入的則是：「The other terms — the ‘all’, ‘ip4’, and ‘ip6’ mechanisms, and the ‘exp’ modifier — do not cause DNS queries at the time of SPF evaluation (the ‘exp’ modifier only causes a lookup at a later time), and their use is not subject to this limit.」（exp 不是完全不查 DNS，只是查在判定之後，所以不佔這 10 次）這句話直接給了你一條解法：把 include 換成寫死的 ip4:／ip6: 區段（業界俗稱 SPF flattening），查詢次數就能歸零。

問題是這個上限很容易在不知不覺中被吃光。Google Workspace 一個 include、電子報平台一個、發票系統一個、客服工單一個、CRM 一個——看起來才五個，但每個 include 進去之後可能還會再展開兩三層。10 次是「總計」不是「第一層」，這是最多人誤解的地方。

規範還有兩個容易被忽略的細節。其一是 MX 的展開限制：「The evaluation of each ‘MX’ record MUST NOT result in querying more than 10 address records — either ‘A’ or ‘AAAA’ resource records.」其二是空查詢限制：「SPF implementations SHOULD limit ‘void lookups’ to two.」void lookup 指的是查了卻回空的查詢，通常來自你 include 了一個已經停用的服務——這種殘留在實務上非常常見。

另外兩條規則也請一起記住。ptr 機制的官方態度是「This mechanism SHOULD NOT be published.」，理由是「slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the .arpa name servers」。而一個網域只能有一筆生效的 SPF 記錄：「A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record.」，一旦查到兩筆，結果直接是 permerror。

兩筆 SPF 這件事我遇過三次，成因都一樣：換了新的寄信服務，新增一筆記錄卻沒刪掉舊的。正確做法是把新服務的 include: 併進既有那一筆，而不是新增第二筆 TXT。

最後是長度。規範建議「the results of a query for it will fit within 512 octets」，更嚴格的說法是讓 DNS 名稱與該型別所有記錄文字的合計長度低於 450 octets，以避免 UDP 封包被迫退回 TCP。如果你的 SPF 已經長到需要擔心 450 octets，那幾乎可以確定它同時也踩到 10 次查詢上限了。

自己驗一遍：三行指令

不需要買工具。macOS 和 Linux 內建的 dig 就夠了：dig +short TXT example.com 看 SPF、dig +short TXT 選擇器._domainkey.example.com 看 DKIM、dig +short TXT _dmarc.example.com 看 DMARC。三筆都查得到、內容都符合預期，你就通過了驗證層的靜態檢查。

動態檢查則要看真實信件的標頭。寄一封信給自己的 Gmail，打開信件後選「顯示原始郵件」，在 Authentication-Results 那一行會看到 spf=pass、dkim=pass、dmarc=pass 三個結果。靜態記錄正確但實際標頭 fail，通常代表你漏設了某一條寄信路徑，例如網站表單走的是主機的本機寄信，而不是你設定的 SMTP。

如果你正在同時處理網域轉移或剛換註冊商，DNS 那一側的操作細節可以對照我寫過的網域名稱選擇與轉移實務那篇。轉移期間最常見的事故就是 DNS 記錄沒有一併搬過去，寄信在轉移完成後靜靜地全數失效。

DKIM：金鑰長度、選擇器，以及 TXT 記錄的長度陷阱

DKIM 的設定流程通常由你的寄信服務代勞：它產生一組金鑰，把公鑰字串給你，你到 DNS 新增一筆 選擇器._domainkey.你的網域 的 TXT 記錄。選擇器（selector）的作用是讓同一個網域可以同時掛多把金鑰，這樣你換服務、輪替金鑰時不必中斷寄信。

Google Workspace 的預設選擇器前綴是 google，官方也建議直接沿用；如果你的網域上已經有一把用 google 前綴的金鑰，才需要另外指定。我的習慣是選擇器命名帶上服務名和年份，例如 ses2026，日後看 DNS 就知道哪把是誰的、哪把可以刪。

金鑰長度有明確規範。RFC 8301（Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail，2018 年 1 月，Proposed Standard）寫的是：「Signers MUST use RSA keys of at least 1024 bits for all keys.」以及「Signers SHOULD use RSA keys of at least 2048 bits.」同一份規範也把舊演算法判了死刑：「rsa-sha1 MUST NOT be used for signing or verifying.」，並要求驗證方不得把小於 1024 bits 的簽章視為有效。

Google Workspace 的說明頁同樣支援 1024 與 2048 兩種，並建議在網域服務商支援的前提下選 2048，理由寫得很樸素：「Longer keys are more secure than shorter keys.」Yahoo 在寄件者最佳實務裡則直接把「至少 1024-bit 的 DKIM 金鑰」列為大量寄件者的要求。

2048-bit 金鑰貼不進 DNS 怎麼辦

這是實作上最惱人的一個坑。2048-bit 的公鑰字串會超過單一 DNS 字串 255 個字元的長度限制，有些 DNS 管理介面會直接拒絕、有些會靜靜地截斷。Google 的官方說法是「Some domain providers limit TXT record length.」，並另外開了一篇說明處理字元上限——這代表這是普遍現象，不是你的操作錯誤。

解法有三種：一是改用支援自動切段的 DNS 服務商（多數現代 DNS 平台會替你把長字串拆成多段引號並在查詢時串回），二是自己手動用引號分段輸入，三是退而求其次先用 1024-bit 上線、之後再升級。不要為了貼得進去就把公鑰字串手動刪掉幾個字元——那會讓所有簽章驗證失敗，而且錯誤訊息不會告訴你原因。

設定完成後一定要實際寄一封信驗證，不能只看 DNS 查得到。DKIM 最典型的假成功是：DNS 記錄正確，但寄信服務那一側的網域驗證還停在「待驗證」狀態，於是信根本沒被簽章。

DMARC 在 2026 年變了：RFC 7489 已被三份新 RFC 取代

如果你只從這篇帶走一件事，我希望是這件。長年被引用的 DMARC 規範 RFC 7489（2015 年 3 月，Informational）已經被廢止，取而代之的是 2026 年 5 月發佈的三份 Proposed Standard：RFC 9989 是協定本體、RFC 9990 是彙總報告（aggregate reporting）、RFC 9991 是失敗報告（failure reporting），三份共同「obsoletes and replaces RFC 7489」，RFC 9989 同時也取代了 RFC 9091。

從 Informational 升級為 Proposed Standard 這件事本身就有意義：DMARC 從一份「業界共識文件」正式變成標準軌文件。對一般網站經營者來說，日常設定不會因此天翻地覆，但有兩個標籤層級的改變你必須知道。

改變一：pct 標籤被移除了

RFC 9989 的附錄 A.6 標題就叫「Removal of the ‘pct’ Tag」。過去大家熟悉的漸進做法是先設 p=quarantine; pct=5，讓 5% 的失敗信被隔離，再慢慢往上加。新規範把這個標籤拿掉了，改用 t 標籤來表達「我還在測試」——第 4.7 節對 t=y 的定義是網域擁有者「has an expectation that the policy applied to any failing messages will be one level below the specified policy」，也就是套用比宣告值低一級的處置（宣告 quarantine 就當 none、宣告 reject 就當 quarantine），預設值是 t=n。附錄 A.6 也把來歷交代得很清楚：新的 t=y／t=n 就是舊 pct=0／pct=100 的替身——因為實務上除了 0 和 100，其他百分比各家實作差異太大。

這裡有個現實中的過渡期問題我必須誠實說明：Google Workspace 的 DMARC 說明頁在我查核當天（2026 年 8 月 6 日）仍然在教 pct=5 的漸進寫法。我的判斷是——這是判斷不是官方說法——短期內兩種寫法並存，保留 pct 不會讓記錄失效，但既然規範已把它移除，新做的設定不應該把成敗押在 pct 上。

改變二：用 DNS Tree Walk 取代公用後綴清單

DMARC 需要判斷什麼是「組織網域」（Organizational Domain），才能決定 news.example.com 要不要套用 example.com 的政策。舊做法依賴一份靜態的公用後綴清單（Public Suffix List）。RFC 9989 第 4.10 節改用 DNS Tree Walk：收件方沿著網域樹逐層查詢來找出適用的政策記錄，並明訂最多 8 次查詢以避免被拿來做阻斷服務攻擊。

對設定者的實質影響是：子網域的政策繼承變得更可預測，而 sp（既有子網域政策）與 np（不存在的子網域政策）這兩個標籤的重要性上升。np 特別實用——它讓你可以對「根本不存在的子網域」直接下 reject，這正是釣魚信最愛用的攻擊面。

DMARC 記錄標籤一覽（依 RFC 9989 第 4.7 節）

標籤	預設值	用途
v	必填	識別這筆記錄是 DMARC 政策記錄
p	none	驗證失敗時網域擁有者希望的處置：none／quarantine／reject
sp	沿用 p	既有子網域的政策
np	沿用 sp 或 p	不存在的子網域的政策
adkim	r	DKIM 對齊模式：r 寬鬆／s 嚴格
aspf	r	SPF 對齊模式：r 寬鬆／s 嚴格
rua	無	彙總報告收件位址
ruf	無	失敗報告收件位址
fo	0	失敗報告產生條件
t	n	測試模式；y 表示請收件方套用低一級的處置
psd	u	標示本網域是否為公用後綴網域

對齊模式值得展開一句。寬鬆（relaxed）只要求組織網域相符，所以 mail.example.com 簽的章可以對齊 example.com 的 From；嚴格（strict）要求完全一致。絕大多數自架站應該維持預設的寬鬆模式，因為交易信服務常常用自己的子網域簽章，切成嚴格會讓一堆本來好好的信突然對齊失敗。

從 none 走到 reject 的漸進策略

Google Workspace 建議的順序是三段式：先 v=DMARC1; p=none; rua=mailto:[email protected] 至少維持一週，官方描述是「Messages are delivered normally. There is no risk of messages being rejected or marked as spam.」這一階段唯一的工作是讀報告，把「原來這個系統也在用我的網域寄信」全部找出來。

第二段進入 p=quarantine，Google 的範例是搭配小比例起步再逐步拉高，效果是「Messages that don’t pass DMARC go to the recipient’s spam folder.」。依 RFC 9989 的新寫法，這一段可以改用 p=quarantine; t=y 起步，觀察報告穩定後再拿掉 t。

第三段才是 p=reject。Google 的警語寫得很重：「The reject policy means that messages that don’t pass DMARC are rejected by receiving servers and never delivered.」還有一條前置條件很多人跳過：官方明講要在設定 DMARC 之前「至少 48 小時」先把 DKIM 和 SPF 設好，讓 DNS 有時間傳播。

我自己的節奏是：p=none 兩週、quarantine 四週、reject。這比官方最低建議保守，理由是自架站往往有一堆被遺忘的寄信來源——舊的表單外掛、主機端的排程通知、某個只在年底才跑的報表——它們只會在報告裡出現一次，太快收緊就會直接誤殺。

兩種報告差在哪：rua 與 ruf

DMARC 的價值有一半在報告，但很多人設了 rua 就收到一堆看不懂的 XML 附件，然後把它丟進垃圾桶。先搞清楚兩者的差別：彙總報告（rua，規範在 RFC 9990）是統計性的，失敗報告（ruf，規範在 RFC 9991）是逐封的。

彙總報告的內容依 RFC 9990 定義，是收件方產生的 XML 檔，包含 SPF 與 DKIM 的驗證結果、DMARC 政策實際套用的處置、以寄件 IP 分組的信件數量，以及套用了政策例外時的原因。換句話說，你拿到的是「上週有哪些 IP 用你的網域寄了多少封、各自驗證結果如何」——這正是找出你不知道的寄信來源最有效的工具。

有一個機制常被誤傳成「新規範才加的」，這裡要講清楚：外部報告目的地的驗證（RFC 9990 第 4 節「Verifying External Destinations」）不是新東西，舊的 RFC 7489 第 7.1 節就叫同一個名字了。它的作用是：如果你想把報告寄到別的網域（例如某個 DMARC 報告分析服務），該網域必須透過 DNS 檢查表態同意，避免有人把報告導到任意位址去做資料蒐集。

RFC 9990 附錄 C 自己列了相對於 RFC 7489 的實際差異，都偏向格式面：XSD 結構被大幅釐清、報告識別碼多了結構、明確規範一份報告該涵蓋幾個網域、報告結構新增擴充機制、PSD 正式納入規格，以及「Selector is now required when reporting a DKIM signature」。對設定者來說，這些改的是報告分析工具作者的工作，不是你的 DNS 記錄——這也是為什麼換新 RFC 不需要你重設 rua。

失敗報告則完全是另一回事。RFC 9991 定義的是「details about individual messages that failed to authenticate」，也就是單封信的細節。正因為含有逐封資料，這份規範花了大量篇幅談隱私：報告可能包含來自標頭與內文的個人可識別資訊，因此建議營運方限縮報告範圍、謹慎驗證接收端，並做去識別化處理。

我的實務建議是：一定要設 rua，ruf 則除非你有具體的鑑識需求，否則可以先不設。原因很現實——失敗報告的量可能非常大，而且你要為收到的個資負保管責任。

至於 XML 怎麼看：初期可以直接用文字編輯器打開，重點只看兩欄——來源 IP 和 disposition。把所有出現過的來源 IP 列出來，逐一對應到你認識的服務，對不上的那幾個就是你的排查清單。

Gmail、Yahoo、Outlook.com 的寄件者門檻（2024–2025 陸續上路）

2024 年是分水嶺。在那之前，郵件驗證是「做了比較好」；在那之後，對大量寄件者是「不做就進垃圾桶」。三家都把 DMARC 從選配變成大量寄件者的必要條件，但有一件事常被中文教學寫混：只有 Gmail 和 Outlook.com 公布了「每日 5,000 封」這個數字，Yahoo 是明確拒絕公布門檻的。

Gmail（Google Workspace 管理員說明，2026-08-06 查核）

官方頁面把要求分成「所有寄件者」與「每日 5,000 封以上」兩個區塊，並以 2024 年 2 月 1 日為起算日：「Starting February 1, 2024, all email senders who send email to Gmail accounts must meet the requirements」，而超過門檻者要另外遵守「Requirements for sending 5,000 or more messages per day」那一節。注意這裡的「to Gmail accounts」——計算基礎是「寄給個人 Gmail 帳號的封數」，不是你的總寄件量；官方對「個人 Gmail 帳號」的定義是結尾為 @gmail.com 或 @googlemail.com 的帳號。

門檻的實際判定比「5,000」這個整數寬鬆一點，這點值得抄下來。FAQ 的原文是：「A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period.」「close to 5,000」——也就是逼近 5,000 就可能被算進去，而且是滾動的 24 小時而不是自然日。抓 4,800 封當安全線是自欺欺人。

垃圾回報率的要求分兩個數字：硬性要求是「Keep spam rates reported in Postmaster Tools below 0.3%」，建議值則是「Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher」。0.10% 是操作目標、0.30% 是紅線，這兩個數字要分開記——用 0.3% 當日常目標，等於把自己貼著紅線在開。

另外三條要求分別是：所有寄件者都要設定 SPF 或 DKIM；大量寄件者要 SPF 和 DKIM 都設，再加上 DMARC；行銷信與訂閱信必須支援一鍵退訂並附上明顯的退訂連結。TLS 這一條要看清楚：官方「Sender requirements updates」表格把「Use a TLS connection for transmitting email」的 Date added 標成 2023 年 12 月，那是它被加進清單的日期，不是提前生效——生效日和其他要求一樣是 2024 年 2 月 1 日。

還有一個 2026 年才該注意的變化：FAQ 頁面現在頂端就掛著「Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic. Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.」換句話說，2024 年那一波的懲罰主要是「進垃圾桶」，2025 年 11 月起 Gmail 已經把永久拒收也放上檯面——這條規則的成本正在變高。

同一份 FAQ 還有兩條影響很大、但很少被翻譯出來的規則。第一，子網域的量會併入主網域計算——官方舉的例子是 solarmora.com 和 promotions.solarmora.com 合計。第二更關鍵：「Bulk sender status doesn’t have an expiration date. Email senders that have been classified as bulk senders are permanently classified as such.」——只要曾經達標一次，你就永久是大量寄件者，不會因為量掉下來而恢復。

這條規則對做促銷檔期的網站特別要命：一年只有雙十一那幾天會破 5,000，但從那天起你就要永久符合大量寄件者的所有要求。所以我的建議是——只要你的名單有機會在單日突破 5,000 封，就直接按大量寄件者的標準做，不要賭。

Yahoo（Sender Hub 最佳實務，2026-08-06 查核）

Yahoo 和 Gmail 一樣把要求切成兩層。所有寄件者：SPF 或 DKIM 至少實作一項、垃圾回報率低於 0.3%、寄件 IP 要有正反向 DNS 記錄。大量寄件者則要 SPF 與 DKIM 都設、發佈至少 p=none 且必須通過的 DMARC 政策（Yahoo 明講 relaxed 對齊可接受），From 標頭網域必須與 SPF 或 DKIM 網域對齊。Yahoo 官方的措辭是「strongly urges all senders to publish a DMARC policy for each domain that sends mail」——注意是每一個會寄信的網域，不是只有主網域。

這裡要更正一個在中文圈流傳很廣的說法：Yahoo 從來沒有公布過大量寄件者的封數門檻，而且是明文拒絕公布。官方 FAQ 對「How does Yahoo classify a ‘bulk sender’?」的回答只有兩句：「A ‘bulk’ sender is classified as an email sender sending a significant volume of mail.」以及「We will not specify a volume threshold.」網路上把「每日 5,000 封」寫成「Google 與 Yahoo 的共同門檻」是誤植——那是 Google 的數字。實務上的意思是：你無法用封數替自己算出一條 Yahoo 的安全線，只能直接照大量寄件者的規格做。同一份 FAQ 還交代了認定單位：「For the purposes of enforcement, a ‘sender’ is viewed at the authenticated domain or From header domain level.」——看的是網域，不是 IP 也不是公司。

DKIM 金鑰長度則要注意層級。Yahoo 把「至少 1024-bit 的 DKIM 金鑰」寫在頁面下半的「Additional Recommendations for Senders」區塊，而不是上半的 Requirements 區塊——它是建議不是硬性要求。不過既然 RFC 8301 本身就規定「Signers MUST use RSA keys of at least 1024 bits」，這條建議在實務上等同底線。

退訂這一塊 Yahoo 給了具體時限：要實作可運作的 List-Unsubscribe 標頭、支援行銷信與訂閱信的一鍵退訂，並且退訂請求要在 2 天內完成處理。Yahoo 強烈建議採用 RFC 8058 的 POST 方式，mailto 雖然可接受但不是首選。

生效時程方面，Yahoo 的說法是自 2024 年 2 月開始執行，並在該年上半年逐步推行。「逐步推行」意味著沒有一個乾淨的斷點，你不會收到通知，只會看到某一天送達率開始掉。

Outlook.com（Microsoft 官方公告，2025 年 4 月 2 日發佈，2026-08-06 查核）

Microsoft 的公告明確限定範圍：「This applies to Outlook.com – our consumer service, which is supporting hotmail.com live.com and outlook.com consumer domain addresses.」也就是說，這套要求針對的是消費者信箱，不是企業版的 Microsoft 365 租戶。

門檻同樣是每日 5,000 封：「For domains sending over 5,000 emails per day, Outlook will soon require compliance with SPF, DKIM, DMARC.」三項要求分別是 SPF 必須 Pass、DKIM 必須 Pass、DMARC「At least p=none and align with either SPF or DKIM (preferably both)」。DKIM 也被列為必須 Pass，這比 Gmail 對一般寄件者「SPF 或 DKIM 二選一」的要求嚴格。

生效日是 2025 年 5 月 5 日。這裡我要提醒一個容易誤讀的地方：這篇公告在 4 月 29 日更新過，先寫了「we have made a decision to reject messages that don’t pass the required authentication requirements」，緊接著又寫「After May 5th, 2025, Outlook will begin routing messages from high volume non-compliant domains to the Junk folder」，最後補上「NOTE: that in the future (date to be announced), non-compliant messages will be rejected」。三段話讀起來是矛盾的——這是官方文件本身自相矛盾，不是翻譯問題。

我採信的是「先進垃圾郵件匣、全面拒收日期未公布」這個版本，理由是公告前段的「What’s Changing?」小節本來就這樣寫：「Non-compliant messages will first be routed to Junk. If issues remain unresolved, they may eventually be rejected.」公告裡有兩處都指向「先 Junk 後 reject」，只有 4 月 29 日更新那一段寫成立即拒收，而該段自己又在下一句改口。實務上該預期的是：現在被丟垃圾桶，未來某個未公布的日子開始被 550 拒收。

被拒收時的退信字串官方也給了：「550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.」如果你在退信紀錄裡看到 5.7.515，不用再查別的，那就是驗證沒過，去修 DNS。

要求項目	Gmail	Yahoo	Outlook.com（消費者信箱）
大量寄件者門檻	24 小時內「close to 5,000 messages or more」寄給個人 Gmail 帳號	官方明文拒絕公布：「We will not specify a volume threshold.」，僅定性為「significant volume of mail」	每日 5,000 封以上
生效日	2024-02-01（TLS 一項於 2023-12 加入清單，生效日相同）；2025-11 起加強執法含永久拒收	2024 年 2 月起逐步推行	2025-05-05
SPF	所有寄件者：SPF 或 DKIM 擇一；大量寄件者：必設	所有寄件者：SPF 或 DKIM 擇一；大量寄件者：必設	必須 Pass
DKIM	所有寄件者：SPF 或 DKIM 擇一；大量寄件者：必設	大量寄件者必設；「至少 1024-bit」列在建議區非要求區	必須 Pass
DMARC	大量寄件者必設	至少 p=none，且需對齊	至少 p=none，且需對齊 SPF 或 DKIM
垃圾回報率	所有寄件者皆須低於 0.3%，建議低於 0.10%	所有寄件者皆須低於 0.3%	該頁未列出數字
一鍵退訂	行銷信與訂閱信必須支援	必須支援，2 天內處理	列為建議（Functional Unsubscribe Links）

WordPress 用 wp_mail 直接寄信，為什麼幾乎必進垃圾桶

這一段是自架站經營者最該看的。WordPress 內建的 wp_mail() 官方文件開頭第一句就是：「Sends an email, similar to PHP’s mail function.」「類似 PHP 的 mail 函式」這句話翻成白話就是：預設情況下它把信直接交給主機的本機郵件程式送出，沒有經過任何有信譽的寄信基礎設施。

官方文件緊接著的第二句更值得裱起來：「A true return value does not automatically mean that the user received the email successfully. It just only means that the method used was able to process the request without any errors.」很多「表單有送出、通知信卻沒到」的案例，就是因為外掛只檢查了 wp_mail() 的回傳值就顯示「已送出」。

第三個問題出在寄件位址。WordPress 核心的原始碼裡，預設寄件者名稱是 WordPress、寄件位址是 wordpress@你的網域，而且核心的註解自己承認了風險：「Some hosts will block outgoing mail from this address if it doesn’t exist, but there’s no easy alternative.」——一個不存在的信箱，當然沒辦法通過任何以「這個位址是真的嗎」為前提的檢查。

把這幾件事疊起來，你就懂為什麼預設狀態下送達率會這麼慘：信從共享主機的 IP 送出（那個 IP 上還有幾百個你不認識的網站）、沒有 DKIM 簽章、寄件位址不存在、SPF 幾乎不可能涵蓋主機的本機寄信路徑。四層驗證與信譽訊號同時缺席，收件方沒有任何理由相信這封信。

還有一個容易被忽略的細節：wp_mail() 的預設內容類型是 text/plain，要送 HTML 信必須透過 wp_mail_content_type 濾鏡改掉，而且官方特別警告改完要記得改回來，否則「could lead to unexpected problems with e-mails from WP or plugins/themes」。這條在多外掛環境下很常出事，症狀是某個外掛的信突然變成一堆原始 HTML 標籤。

正確的修法：把寄信這件事外包出去

解法不是去調 PHP 的 mail()，而是讓 WordPress 改走 SMTP 或 API 送到專業的交易信服務。技術上這件事很單純：wp_mail() 底層用的是 PHPMailer，透過 phpmailer_init 這個動作鉤子就能把它切換成 SMTP 模式，市面上所有 SMTP 外掛做的都是這件事。換句話說，你不是在裝一個「寄信外掛」，你是在把 WordPress 原本的寄信路徑整條換掉。

設定時有兩個地方一定要一起改：寄件位址要換成一個真實存在、而且屬於你已通過驗證網域的信箱（例如 hello@你的網域），以及回覆位址要能真的收信。Microsoft 在公告裡把這條列為 hygiene 建議：「Ensure the ‘From’ or ‘Reply-To’ address is valid, reflects the true sending domain, and can receive replies.」

另外請一併打開失敗記錄。WordPress 有 wp_mail_failed 這個動作鉤子，多數 SMTP 外掛會用它來寫寄信日誌。沒有日誌，你就永遠只能靠使用者回報「我沒收到」來發現問題，而那通常是最貴的發現方式。

如果你的站上已經裝了一堆外掛、擔心再加一支會有衝突，可以先用外掛衝突的診斷順序做一次盤點；長期來說，我在把網站精簡到 11 支外掛的取捨清單裡也把 SMTP 列為少數「值得留」的類別。寄信這件事一旦壞掉是靜默的，所以它值得佔一個外掛名額。

還有一個常被忽略的前提：主機商本身的政策。有些共享主機會限制或封鎖對外的 25 埠，有些則對每小時寄信量設上限。選主機時把「能不能用外部 SMTP、對外埠有沒有限制」列進去，比事後才發現要搬家便宜得多——這一點在共享、VPS 與託管型主機的取捨那篇也提過。

SMTP 與交易信服務怎麼選（含官方定價）

先講分類，因為選錯類別比選錯品牌貴得多。交易信服務（transactional email）處理的是一對一觸發的信：註冊確認、密碼重設、訂單通知、表單回覆。電子報平台處理的是一對多的行銷信：名單管理、分眾、自動化流程、退訂管理。

兩者的技術棧其實高度重疊，但計費邏輯完全不同：交易信按「封數」算，電子報平台多半按「聯絡人數」算。如果你兩種都要寄，實務上最常見的組合是：交易信走 API／SMTP 服務，電子報走行銷平台，兩邊用同一個網域但不同的 DKIM 選擇器。

下表是我在 2026 年 8 月 6 日逐頁核對過的官方定價。所有數字都是官方定價頁當天顯示的月繳價、幣別為美元。這四家當天都沒有年繳折扣可套：SES 與 Mailgun 按月計費，Postmark 的 FAQ 寫「Do you offer annual plans? Not right now」，Resend 的 FAQ 寫「No, we only provide monthly plans.」——所以不會有「年繳均攤價被誤當月費」的問題。報價會變動，實際請以你下單當天的官網為準。

服務	免費額度	入門付費方案（月繳）	超量計價	備註
Amazon SES	新 AWS 客戶最高 200 美元 Free Tier 抵用金；免費方案本身只開放 6 個月，抵用金須於開戶起 12 個月內用完	à la carte（單項計價）0.10 美元／1,000 封；但新帳號預設落在 Essentials 方案 0.16 美元／1,000 封	同左，按量計費	附件另計 0.12 美元／GB；Managed 專用 IP 15 美元／月／帳號起＋每封費用；Standard 專用 IP 24.95 美元／月／IP
Postmark	100 封／月，官方稱「never expires or runs out」	Basic 15.00 美元／10,000 封	1.80 美元／1,000 封（Basic）	官方註明目前不提供年繳方案；專用 IP 每個 50 美元／月起，且需月寄 300,000 封以上
Resend	3,000 封／月，且每日上限 100 封	Pro 20 美元／50,000 封	0.90 美元／1,000 封	再上一級是 Scale 90 美元／100,000 封；官方 FAQ 明寫「No, we only provide monthly plans.」；專用 IP 30 美元／月且限 Scale 方案
Mailgun	100 封／日，日誌保留 1 天	Basic 15 美元／10,000 封起	1.80 美元／1,000 封起	定價頁提供 USD／EUR／GBP 切換，本表為 USD

順帶一提：Brevo 與 MailerLite 的定價頁預設顯示的是「年繳攤月價」

這兩家是行銷平台不是交易信服務（計價軸是聯絡人／訂閱者數而不是封數），所以我沒有放進上面那張表。但它們的定價頁示範了一個所有人都該學會辨識的陷阱，值得單獨講：兩家的計費切換器預設都停在「年繳」，你第一眼看到的數字是打完 9 折的攤月價，不是你按月付會付的錢。

Brevo 的頁面原始碼裡，「Yearly (-10%)」那顆按鈕帶著 aria-checked="true"；頁內結構化資料同時列了兩組價格：Starter 的 period: MON 是 9 美元、period: ANN 是 96.96 美元。96.96 除以 12 等於 8.08——那個 8.08 就是你進站看到的數字，但真正的月繳價是 9 美元。免費方案是每日 300 封（官方文案「Free forever, no credit card needed」），Starter 起於每月 5,000 封。

MailerLite 的做法一樣，只是藏在前端狀態裡：初始值寫死 billing: 'yearly'，旁邊配一句「Save 10% by paying yearly」。以 500 位訂閱者計，價格陣列的兩個數字分別是月繳與年繳攤月：Comfort 月繳 12 美元、年繳攤月 10.80 美元；Power 月繳 25 美元、年繳攤月 22.50 美元。免費方案是 250 位訂閱者、每月 2,500 封。

把這件事講白：看任何 SaaS 定價頁，第一個動作都應該是找計費切換器並確認它停在哪一邊。差 10% 聽起來不多，但你若照攤月價編預算、實際又按月付，每一期都會短。這兩家的方案內容比較可以參考我另外寫的Email 行銷工具比較。

選擇邏輯：三個問題就能決定

第一個問題：你一個月寄幾封？低於 10,000 封而且只是網站通知信，SES 的 à la carte 單項計價幾乎不可能被打敗——一萬封是 1 美元。但這裡有一個 2026 年才出現、而且很容易多付錢的陷阱：SES 定價頁的註腳明寫「New SES accounts and account x region combinations with no metered SES activity since June 1, 2025 will start on the Essentials plan beginning July 21, 2026.」也就是說，今天新開的帳號預設不是 à la carte，而是 Essentials（0.16 美元／1,000 封，一萬封是 1.6 美元）；同一段也寫了「You can upgrade or switch to à-la-carte pricing at any time」，所以那 1 美元要靠你自己去切換方案才拿得到。

另外兩個 SES 的老問題也還在：介面對非工程背景的人不友善，而且新帳號預設在沙盒模式，要開通生產環境得寫申請說明。

第二個問題：你需不需要看得懂的後台？Postmark 和 Resend 的日誌與事件檢視體驗明顯好於 SES，對「信到底發生什麼事」的排查效率差很多。如果你是幫客戶維運、需要在客戶問起時三分鐘內給答案，這個差異值得那 15 到 20 美元。

第三個問題：你會不會同時寄行銷信？會的話就要注意，多數交易信服務的服務條款對行銷信有額外限制，而且把交易信與行銷信混在同一個寄件網域，會讓行銷信的投訴率污染到交易信的信譽。標準做法是用子網域隔離：交易信走 mail.你的網域，行銷信走 news.你的網域，各自獨立累積信譽。

退信與投訴率：該看哪些數字、超過多少要停手

驗證層修好之後，剩下的功夫全在這一節。M3AAWG（Messaging, Malware and Mobile Anti-Abuse Working Group）的 Sender Best Common Practices 對兩種退信給了清楚定義。硬退信是「a permanent failure such as the email address no longer exists or has never existed, or the domain no longer exists or has never existed」，軟退信則是「a temporary failure such as a full mailbox, a connection problem, a technical issue at the Mailbox Provider, or throttling of the connecting IP」。

兩者的處理方式截然不同：硬退信要立刻從名單移除，軟退信則要重試。M3AAWG 對軟退信的移除門檻給了一個可以直接照抄的做法：「remove an address from the list if it bounces consecutively at least two times over two weeks or more」——連續兩次、跨越兩週以上才移除，用時間差把接收端的暫時性故障濾掉。

具體門檻：以 Amazon SES 公布的數字為錨

多數收件方不公布自己的容忍門檻，但寄信服務商會，因為那關係到你的帳號會不會被停。Amazon SES 的寄件審查 FAQ 是我見過講得最白的一份：「For best results, you should maintain a bounce rate below 2%.」「If your bounce rate is 5% or greater, we’ll place your account under review. If your bounce rate is 10% or greater, we might pause your account’s ability to send additional email.」

投訴率的數字更嚴苛：「For best results, you should maintain a complaint rate below 0.1%.」「If your complaint rate is 0.1% or greater, we’ll place your account under review. If your complaint rate is 0.5% or greater, we might pause your account’s ability to send additional email.」0.1% 的意思是每 1,000 封只能有 1 個人按「檢舉垃圾郵件」，這個標準比多數人直覺想的嚴格一個數量級。

SES 對退信率的計算方式也值得注意：「Your bounce rate includes only hard bounces to domains you haven’t verified. Hard bounces are permanent delivery failures such as ‘address does not exist.’ Temporary and intermittent failures such as ‘mailbox full,’ or bounces due to blocked IP addresses, don’t count toward your bounce rate.」也就是說軟退信不計入——但這不代表軟退信無害，它只是不算在這個特定指標裡。

還有一個常被誤解的點：SES 的比率不是按固定期間計算，而是用「representative volume」（代表性寄件量），官方說明是「the representative volume is different for each user and changes as the user’s sending patterns change」。所以你在主控台看到的數字無法自己重算，官方也明講「Can I calculate my own bounce rate…? No.」——它只能當趨勢指標用。

投訴資料從哪裡來：FBL 與 Postmaster Tools

投訴率的原始資料來自兩個地方。一是回饋迴路（Feedback Loop, FBL）：收件方把使用者按下「檢舉垃圾郵件」的信件副本回傳給寄件方。M3AAWG 的說法是「the largest source of complaint data senders receive are from automated Feedback Loops (FBLs) set up by mailbox providers」，而且寄信服務必須有系統同時處理 FBL 訊息與直接投訴。

二是 Gmail 的 Postmaster Tools，它提供垃圾回報率、網域與 IP 信譽、驗證通過率、傳遞錯誤等儀表板。有一個限制要先知道：官方明講資料量太低時不會顯示——「Data might be missing if the total number of messages for a given day is too low. This is to protect users’ privacy.」

這個「太低」到底是多低，Help Center 從頭到尾沒給數字，但 Postmaster Tools API 的開發者文件給了，而且是我找了半天才翻到的一句：「Only domains that send mail to at least 50 users per day receive statistics.」請注意單位——是「50 個收件人」不是「50 封」，同一個人收你十封只算一個。網路上流傳的「至少 100 封／天」「幾百封／天」我在 Google 任何官方頁面都找不到出處，那是民間推測；官方唯一寫出來的數字就是每日 50 個收件人。

對每天收件人不到 50 個的小站來說，這代表 Postmaster Tools 大概率是一片空白。這種情況下的替代做法是：用你寄信服務商後台的退信與投訴事件當主要指標，並定期用不同信箱做人工收信測試。

名單品質才是根本解

把退信率壓下來的方法不是重試策略，是一開始就不要收到爛位址。M3AAWG 把訂閱方式分成三級，最高一級是 Confirmed Opt-in：使用者填完 Email 之後會先收到一封確認信，必須點擊連結或回信才算完成訂閱。規範對最低一級的 Single Opt-in 的評語是「should be used with extreme caution as it allows unconfirmed addresses to be added to mailing lists」，因為打錯字或惡意填入的位址會被照單全收。

確認信的時效也有建議：應在使用者送出位址後「immediately… or as soon as possible (within 24 hours)」寄出，而且要用和未來寄信相同的寄件位址，方便收件人加入通訊錄。另外 M3AAWG 建議把寄確認信的伺服器和一般大量寄信的伺服器分開，避免行銷信的信譽波及到這封最關鍵的確認信。

退訂那一側，M3AAWG 的立場是「Senders must process all unsubscribe requests without delay」，而且退訂連結本身要包含完成退訂所需的全部資訊（訂閱者識別碼、要退訂哪一份名單、驗證權杖）。不要做那種「退訂後還要登入才能完成」的流程——那不只違反最佳實務，也會直接把使用者推去按檢舉鍵。

關於名單的成長節奏與退訂率控制，我在訂閱名單從 0 到 1000 的那篇寫得比較細。兩篇合起來看的邏輯是：名單怎麼長決定了投訴率，投訴率決定了信譽，信譽決定了送達率。

一鍵退訂：RFC 8058 的標頭到底要怎麼下

Gmail 和 Yahoo 都把一鍵退訂列為大量寄件者的硬性要求，而它的技術規範是 RFC 8058（Signaling One-Click Functionality for List Email Headers，2017 年 1 月，Standards Track）。規範要求兩個標頭同時存在：「The List-Unsubscribe header field MUST contain one HTTPS URI.」以及 List-Unsubscribe-Post 這個標頭「MUST contain the single key/value pair ‘List-Unsubscribe=One-Click’」。

生效日期這件事在中文圈有兩個版本流傳，這裡把官方的說法整理清楚。Gmail 的所有要求（含一鍵退訂）都以 2024 年 2 月 1 日為起算日，但 FAQ 另外給了一個過渡期：「Senders that already include an unsubscribe link in their messages have until June 1, 2024 to implement one-click unsubscribe in all commercial, promotional messages.」所以 2024-06-01 不是另一個獨立的生效日，而是「本來就有退訂連結」那一群人的補做期限——現在兩個日期都已經過了，實際上只剩一種狀態：該做而沒做。

還有一個範圍問題常被寫錯：官方明講「One-click unsubscribe is required only for marketing and promotional messages. Transactional messages are excluded from this requirement.」密碼重設、訂位確認、表單送出確認這類交易信不需要一鍵退訂——但也不要因此把促銷內容塞進交易信裡，那會讓它變成需要退訂的信。

收件方執行退訂時，會對那個 HTTPS 網址送出 POST 請求，內容就是那組鍵值對；規範說「The POST content SHOULD be sent as ‘multipart/form-data’ or MAY be sent as ‘application/x-www-form-urlencoded’」。這代表你的退訂端點必須接受 POST，而且不能要求任何登入或二次確認——收件方的伺服器不會替使用者點按鈕。

最容易被漏掉的是簽章要求。RFC 8058 明訂：「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.」並且「senders MUST apply at least one valid DKIM signature to the message」——換句話說，一鍵退訂在技術上依賴 DKIM，沒有 DKIM 就沒有合規的一鍵退訂。

實務上，如果你用的是成熟的電子報平台或交易信服務，這兩個標頭多半會自動加上；但如果你是自己用程式寄信，就必須自己實作。自建退訂端點時記得做防重放與權杖驗證，否則任何人拿到那個網址就能把別人退訂掉。

台灣這邊的法律要求

台灣目前沒有專門的反垃圾郵件專法（「濫發商業電子郵件管理條例」草案多年未完成立法），但《個人資料保護法》第 20 條對行銷有明文規定，而且這一條是現行有效條文。第二項的原文是：「非公務機關依前項規定利用個人資料行銷者，當事人表示拒絕接受行銷時，應即停止利用其個人資料行銷。」

第三項則規定了首次行銷的義務：「非公務機關於首次行銷時，應提供當事人表示拒絕接受行銷之方式，並支付所需費用。」「支付所需費用」這五個字常被忽略——意思是拒絕行銷的管道不能要求當事人自己負擔成本，這在 Email 情境下等於退訂必須免費且不得設置障礙。

要提醒的是版本問題。全國法規資料庫在 2026 年 8 月 6 日顯示，個資法在民國 114 年 11 月 11 日有一次大幅修正（含增訂第 20-1 條等），但該次修正的施行日期由行政院定之、尚未生效；第 20 條本身不在該次修正的條文清單內，所以上面引用的文字就是現行有效版本（該資料庫當時的法規整編資料截止日為民國 115 年 7 月 31 日）。

如果你的網站會蒐集訂閱者資料，個資責任的實作面向可以延伸看接案者的客戶管理與個資責任那篇，帳密與存取權限的部分則可以參考密碼管理器的選擇與交接流程。寄信服務的 API 金鑰一旦外流，攻擊者就能用你的網域寄出通過所有驗證的釣魚信——那是驗證做得越好、傷害越大的一種事故。

內容層：官方明講的幾件事，和一件沒人替你說的事

把驗證層和信譽層都修好之後，內容層才輪得到你操心。這一層網路上的說法最多、可驗證的最少，所以我只寫官方文件真的有寫的部分。凡是「主旨不能超過幾個字」「圖文比例要幾比幾」這類具體數字，我查不到任何一家收件方的官方出處，那些應該當成傳說而不是規則。

Microsoft 在高量寄件者公告裡列的四條 hygiene 建議是少數白紙黑字的內容層要求。第一條是寄件位址：「Ensure the ‘From’ or ‘Reply-To’ address is valid, reflects the true sending domain, and can receive replies.」「can receive replies」這三個字很關鍵——那種 no-reply@ 又設成黑洞的信箱，技術上通過驗證，實務上是負分。

第二條是可用的退訂連結，第三條是名單與退信管理：「Remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages.」第四條則直指內容本身：「Use accurate subject lines, avoid deceptive headers, and ensure your recipients have consented to receive your messages.」——標題要準確、標頭不得誤導、收件人必須同意過。

M3AAWG 在訂閱環節也給了一條可以直接照做的內容規則：註冊時的說明應該清楚寫出這份名單的類型，並在可能的情況下讓使用者自己選擇要加入或排除哪些名單。官方舉的例子很生活化——使用者可能願意收自己買過的產品更新通知，但不想收相關產品的推銷。

最後是那件沒人替你說的事，這是我的經驗判斷而不是官方說法：內容層真正致命的不是用字，而是「這封信和使用者當初訂閱時的預期不一致」。一份標榜「每月一封技術筆記」的名單，突然開始每週寄三封促銷，投訴率會在兩期內爆掉，而你會以為是主旨寫壞了。

這也是我一直不建議把交易信和行銷信混在同一個寄件網域的原因。使用者對「訂單通知」和「限時優惠」的容忍度差了一個數量級，混在一起等於用行銷信的投訴率去賭訂單通知的送達率。

一份可以照做的排查順序

把上面所有東西壓縮成一個可執行的流程，大概是這樣。順序很重要：每一步都是下一步的前提，跳著做只會讓你分不清是哪一步生效。

第一步：確認問題類型。先分清楚是退信還是進垃圾桶。翻寄信服務的日誌或退信通知，看到 5.X.X 就是被拒收、看到 4.X.X 是暫時性失敗、什麼都沒看到卻沒人回應就是進了垃圾桶。

第二步：查三筆 DNS 記錄。用 dig +short TXT 分別查根網域、選擇器._domainkey 與 _dmarc。三筆都在、只有一筆 SPF、SPF 沒有 ptr、DKIM 公鑰完整沒被截斷，才算過關。

第三步：算 SPF 的查詢次數。把每個 include 逐層展開數一遍，確認總數在 10 以內，順便把已經不用的服務從記錄裡刪掉。這一步花的時間最長，但抓到的問題最多。

第四步：寄一封測試信看標頭。寄到 Gmail，開「顯示原始郵件」，確認 Authentication-Results 三項都是 pass，並確認 From 網域與 DKIM 簽章網域對齊。

第五步：把所有寄信路徑找齊。網站表單、訂單通知、電子報、客服系統、發票系統——用 p=none 收兩週的 DMARC 彙總報告，報告會告訴你有哪些你根本不知道的系統在用你的網域寄信。

第六步：把 WordPress 的寄信改成 SMTP。換掉預設的 wordpress@ 寄件位址，改用真實存在的信箱，並開啟寄信日誌。

第七步：收緊 DMARC 政策。報告乾淨之後，依序推進到 quarantine（可搭配 t=y）與 reject，每一階段至少觀察一週。

第八步：建立監測。註冊 Gmail Postmaster Tools、開啟寄信服務的退信與投訴通知，把退信率 2%、投訴率 0.1% 設成自己的警戒線。流量與轉換那一側則可以搭配 GA4 的事件追蹤設定來看信件帶進來的實際行為。

整套跑完，我通常會在 DNS 那一層留一份文字紀錄：每筆記錄是誰用的、什麼時候加的、可不可以刪。這份紀錄的價值會在兩年後你想「這個 include 到底還要不要留」的時候顯現出來——而那正是 SPF 查詢次數爆掉的典型現場。

順帶一提，做完這些之後請把 DNS 設定納入備份範圍。大部分人的備份策略只涵蓋檔案與資料庫，DNS 記錄完全沒有備份，一旦誤刪就只能靠記憶重建。

常見問題

我的網站每天只寄十幾封信，也要做這些嗎？

驗證層要做，門檻要求則不必按大量寄件者的規格。Google 官方對「所有寄件者」的要求是至少設定 SPF 或 DKIM 其中一項，這對任何規模都適用；而 Gmail 的 5,000 封門檻一旦達成就永久有效，所以只要你的名單有機會在某一天突破，現在就按大量寄件者的標準做最省事。從成本角度看，設 SPF、DKIM、DMARC 三筆 DNS 記錄是零元的，沒有理由不做。

我設了 DMARC 之後，轉寄的信全部驗證失敗，正常嗎？

正常，而且這是 DMARC 的已知副作用。信件被轉寄之後來源 IP 換成轉寄伺服器，SPF 幾乎必然失敗；只要 DKIM 簽章沒有被中途改寫，DMARC 仍然可以靠 DKIM 那一側通過對齊，這就是為什麼 DKIM 一定要設，不能只靠 SPF。如果 DKIM 也失敗，通常是郵遞論壇或某些轉寄服務改寫了主旨或內文導致簽章失效。

p=reject 是不是越早設越好？

不是。太早收緊的代價是誤殺自己的信，而且你不會收到任何通知。Google 官方的順序建議是先 p=none 至少一週、再進 quarantine、最後才 reject，並且要在設 DMARC 前至少 48 小時就把 SPF 和 DKIM 準備好。我自己會拉得更長，因為自架站通常有好幾個被遺忘的寄信來源，需要時間讓它們在報告裡現形。

退信率和投訴率超標了，該怎麼止血？

先停掉可疑的那一批寄送，不要一邊發現問題一邊繼續寄。接著把硬退信位址立刻移除、軟退信依「連續兩次、跨兩週」的原則清理，並停止寄給長期沒有互動的收件人。特別提醒：不要用「重新確認訂閱」的方式去救一份已經很髒的名單——這種再互動活動風險很高，可能同時推高退信率、投訴率與蜜罐命中率。先讓指標回落，再談重新活化。

用免費信箱（Gmail、Yahoo）當網站的寄件位址可以嗎？

技術上可以送出，但你會失去對驗證的控制權，而且很容易撞上這些網域自己的嚴格 DMARC 政策，導致以他們的網域為 From 從第三方伺服器寄出的信被拒收。正確做法是用你自己的網域當 From，把免費信箱留給人際往來——這也是為什麼「先有網域再談寄信」是不能跳過的順序。如果你連網域都還沒有，自架站新手的六個決策那篇可以當起點。

我需要專用 IP（dedicated IP）嗎？

絕大多數自架站不需要。專用 IP 的價值在於把你的信譽和其他人隔離，但前提是你的量足以讓收件方為這個 IP 建立穩定的信譽模型。Postmark 的官方條件就寫得很明白：專用 IP 每個 50 美元／月起，而且限月寄 300,000 封以上的客戶（2026-08-06 查核）。量不夠卻用專用 IP，反而會因為信譽資料稀疏而更不穩定。

資料來源

• RFC 7208｜Sender Policy Framework (SPF) Version 1：SPF 的現行規範，本文的 10 次 DNS 查詢上限、void lookup 限兩次、ptr「SHOULD NOT be published」、單一 SPF 記錄與 512／450 octets 建議，全部出自此文件第 3、4、5 節。
• RFC 6376｜DomainKeys Identified Mail (DKIM) Signatures：DKIM 的 Internet Standard（STD 76）本體，證明 DKIM 宣告的是「簽章網域願意為信件負責」而非驗證 From。
• RFC 8301｜DKIM 密碼學演算法與金鑰使用更新：證明 rsa-sha1 已被禁止、RSA 金鑰至少 1024 bits、建議 2048 bits。
• RFC 7489｜DMARC（已廢止）：舊版 DMARC 規範，其 RFC Editor 頁面顯示已被 RFC 9989、9990、9991 取代，是本文「2023 年的筆記已過時」這個判斷的直接依據。
• RFC 9989｜DMARC 協定本體（2026-05，Proposed Standard）：現行 DMARC 規範，證明 pct 標籤已被移除、t 標籤的語意、標籤預設值表，以及最多 8 次查詢的 DNS Tree Walk。
• RFC 9990｜DMARC 彙總報告：定義 rua 彙總報告的 XML 格式與第 4 節「Verifying External Destinations」外部報告目的地驗證機制；附錄 C 逐條列出相對 RFC 7489 的差異（XSD 釐清、報告識別碼結構、擴充機制、PSD 納入、DKIM selector 必填），可用以證明外部目的地驗證並非新增機制。
• RFC 9991｜DMARC 失敗報告：定義 ruf 失敗報告，並說明其中可能含個資、需限縮範圍與去識別化。
• RFC 8058｜一鍵退訂的標頭規範：證明 List-Unsubscribe 必須是 HTTPS URI、List-Unsubscribe-Post 的固定值，以及兩個標頭必須被 DKIM 簽章涵蓋。
• RFC 3463｜Enhanced Mail System Status Codes：證明 4.X.X 為暫時性失敗、5.X.X 為永久失敗，以及 5.1.1 與 4.2.2 的定義。
• Google Workspace 管理員說明｜Email sender guidelines：Gmail 大量寄件者門檻 5,000 封／日、2024-02-01 生效、所有寄件者與大量寄件者兩份清單、垃圾回報率 0.3%／0.10%、TLS 一項於 2023 年 12 月加入清單（Date added 欄）、一鍵退訂要求的原文出處。
• Google｜Email sender guidelines FAQ：bulk sender 定義為 24 小時內「close to 5,000 messages or more」寄給個人 Gmail 帳號、子網域量併入主網域計算（solarmora.com 例）、大量寄件者身分「permanently classified」不會失效，以及 2025 年 11 月起加強執法含 temporary and permanent rejections；並證明一鍵退訂的 2024-06-01 是「原本已有退訂連結者」的補做期限而非獨立生效日，且交易信不在一鍵退訂要求範圍內。
• Google Workspace｜建議的 DMARC 推進流程：p=none 至少一週、逐步進入 quarantine、最後 reject，以及設 DMARC 前 48 小時要先備妥 SPF／DKIM。
• Google Workspace｜設定 DKIM：支援 1024／2048 bits、建議 2048、預設選擇器前綴為 google、部分 DNS 商限制 TXT 長度。
• Google｜Postmaster Tools 說明：說明可監看垃圾回報率、信譽、驗證與傳遞錯誤，並證明資料量過低時不顯示（該頁未給數字）。
• Google Workspace 開發者文件｜Postmaster Tools API：Retrieve email statistics：官方唯一寫出數字的頁面——「Only domains that send mail to at least 50 users per day receive statistics.」，單位為每日收件人數而非封數（2026-08-06 查核）。
• Yahoo Sender Hub｜Best Practices：Yahoo 所有寄件者 SPF 或 DKIM 擇一、垃圾回報率 0.3%、大量寄件者需 SPF 與 DKIM 皆設並發佈至少 p=none 且必須通過的 DMARC、退訂 2 天內處理、2024 年 2 月起逐步推行；並證明「至少 1024-bit DKIM 金鑰」列於 Additional Recommendations 而非 Requirements 區塊。
• Yahoo Sender Hub｜FAQs：證明 Yahoo 不公布大量寄件者的封數門檻——「A “bulk” sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold.」，並說明 Yahoo 以「authenticated domain 或 From 標頭網域」為認定單位。
• Microsoft Defender for Office 365 Blog｜Outlook 高量寄件者新要求：適用範圍限 Outlook.com 消費者信箱、每日 5,000 封門檻、2025-05-05 生效、SPF／DKIM 必須 Pass、DMARC 至少 p=none 且對齊，以及 550 5.7.515 的退信字串。
• WordPress 開發者文件｜wp_mail()：證明它「類似 PHP 的 mail 函式」、回傳 true 不代表送達、預設內容類型為 text/plain，以及核心原始碼中 wordpress@$sitename 預設寄件位址與「有些主機會擋掉」的註解。
• Amazon SES 文件｜寄件審查流程 FAQ：退信率 2%／5%／10% 與投訴率 0.1%／0.5% 的門檻原文、退信率只計硬退信、representative volume 的計算方式。
• Amazon SES 官方定價頁：à la carte 0.10 美元／1,000 封、Essentials 方案 0.16 美元／1,000 封、附件 0.12 美元／GB、Managed 專用 IP 15 美元／月／帳號、Standard 專用 IP 24.95 美元／月／IP、新客戶 200 美元 Free Tier 抵用金與 6 個月／12 個月兩個期限，以及註腳「新帳號自 2026-07-21 起預設落在 Essentials 方案」（2026-08-06 查核）。
• Postmark 官方定價頁：免費 100 封／月、Basic 15.00 美元／10,000 封、超量 1.80 美元／1,000 封、專用 IP 50 美元／月起且需月寄 300,000 封以上、目前無年繳方案（2026-08-06 查核）。
• Resend 官方定價頁：免費 3,000 封／月且每日上限 100 封、Pro 20 美元／50,000 封、Scale 90 美元／100,000 封、超量 0.90 美元／1,000 封、專用 IP 30 美元／月，以及 FAQ「No, we only provide monthly plans.」（2026-08-06 查核）。
• Mailgun 官方定價頁：免費 100 封／日、Basic 15 美元／月含 10,000 封、超量 1.80 美元／1,000 封起，頁面提供 USD／EUR／GBP 切換（2026-08-06 查核）。
• Brevo 官方定價頁：計費切換器預設停在「Yearly (-10%)」（該按鈕帶 aria-checked="true"），頁內結構化資料同列 Starter 的 MON 9 美元與 ANN 96.96 美元；免費方案每日 300 封、Starter 起於每月 5,000 封（2026-08-06 查核）。
• MailerLite 官方定價頁：前端初始狀態 billing: 'yearly' 搭配「Save 10% by paying yearly」，500 訂閱者級距的 Comfort 為月繳 12／年繳攤月 10.80 美元、Power 為月繳 25／年繳攤月 22.50 美元；免費方案 250 位訂閱者、每月 2,500 封（2026-08-06 查核）。
• M3AAWG Sender Best Common Practices（Version 3）：硬／軟退信定義、「連續兩次跨兩週以上才移除」的清理原則、Confirmed Opt-in 為最佳做法、確認信 24 小時內寄出、退訂須立即處理、FBL 是投訴資料最大來源。
• 全國法規資料庫｜個人資料保護法第 20 條：拒絕行銷應即停止、首次行銷應提供拒絕方式並支付所需費用的現行條文；同頁的沿革顯示民國 114 年 11 月 11 日修正未涵蓋第 20 條且施行日期由行政院定之。

免責聲明：本文所引用之法規條文與官方要求，均為 2026 年 8 月 6 日查核當日之公開資訊，法規與各服務商政策可能隨時變動。文中對《個人資料保護法》之引述僅供一般性參考，不構成法律意見；涉及個資蒐集、處理、利用之具體個案，請洽詢執業律師或主管機關。文中所列價格幣別皆為美元；除明確標示為「年繳攤月價」者外，一律為官方定價頁當日的月繳價，實際費用以你下單當日的官網與帳單為準。