一天寄不到 5,000 封，也該照 Gmail 大量寄件者的標準做

Google 的〈寄件者指南常見問題〉舉過一個例子：solarmora.com 每天從主網域寄 2,500 封、從 promotions.solarmora.com 再寄 2,500 封到個人 Gmail 帳號，兩個網域同屬一個主網域，合計 5,000 封，這個寄件者就被算成「大量寄件者」（bulk sender）。緊接著的說明寫著：達到標準一次，就永久被當成大量寄件者。

放到台灣的電子報上看。假設你的會員名單有 8,000 人，其中 5,000 人用 Gmail，平常分成好幾天寄，每天寄到 Gmail 的量離 5,000 封很遠，都沒事；週年慶那天一次寄給全部名單，那一天就碰到門檻，之後也不會回到一般寄件者。

Yahoo 則是根本不給門檻，它的寄件者常見問題寫著：「We will not specify a volume threshold.」

所以這篇的判斷是：台灣中小企業的電子報，不必先算自己到了 5,000 封沒有，直接照大量寄件者的標準做。兩家的大量寄件者要求，扣掉寄信伺服器本身的設定，落到你身上的是六件事：用自己的網域當寄件地址，並讓寄信平台用這個網域做 DKIM 簽章，寄件地址（From）的網域才會跟驗證的網域對齊；SPF 和 DKIM 兩個都設；DMARC 至少設成 p=none，而且要驗證通過；寄信平台支援一鍵退訂，內文另外放一個明顯的退訂連結；退訂要在 2 天內生效；垃圾郵件檢舉率壓在 0.1% 以下、絕不碰到 0.3%。前三件落在你的網域與 DNS 上，第四件主要是寄信平台的功能，後兩件看你怎麼管名單。下面的對照表逐項列出兩家的原文要求。

Gmail 與 Yahoo 的要求，一張表對照

Google 的〈寄件者指南〉把要求分成兩段：所有寄信到 Gmail 的寄件者都要做的，以及每天寄 5,000 封以上要再多做的，兩段都從 2024 年 2 月 1 日起適用。Yahoo 寄件者中心也有一段專門寫給大量寄件者的要求。

「誰來做」那一欄的依據，是 Google 寫給用第三方寄信服務的人的一句話：「If you use a third-party email provider to send email for your domain: Verify that the provider follows the guidelines on this page.」平台替你執行，確認的責任還是在你。

5,000 封的算法：個人 Gmail、24 小時、同一個主網域

Google 的定義原文是：「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.」寫的是「接近 5,000 封或以上」，不是剛好 5,000。

「個人 Gmail 帳號」指的是結尾為 @gmail.com 或 @googlemail.com 的帳號。

計算單位是主網域：「When we calculate the 5,000-message limit, we count all messages sent from the same primary domain.」開頭那個 solarmora.com 的例子就是這樣來的——改用子網域分開寄，量不會被拆小。

身分也沒有期限。常見問題寫：「Bulk sender status doesn't have an expiration date.」後面接著說，之後改變寄信方式，也不會影響已經被歸類的大量寄件者身分。

三條合在一起看，「我們一天只寄幾百封」描述的只是今天。名單會長大、活動會集中在同一天寄，而達標一次就回不去。

Yahoo 不公布門檻，也沒有逐一列出適用的信箱

Yahoo 常見問題對大量寄件者的定義只有一句質性描述：「A "bulk" sender is classified as an email sender sending a significant volume of mail.」接下來就是前面引過的那句，不公布數量門檻。

適用範圍寫的是「all domains and consumer email brands hosted by Yahoo Mail」，這是在回答「AOL 適不適用」的那一題；同一題也說明 Yahoo Japan 是另一個獨立實體，Yahoo 無法替它發言。

台灣讀者會想問 Yahoo 奇摩信箱算不算。我們查了 Yahoo 寄件者中心的〈Sender Best Practices〉與〈FAQs〉兩頁、Yahoo 奇摩說明中心的信箱說明，沒有找到任何一頁寫明 yahoo.com.tw 的信箱是否適用這套要求。查得到的只有 DNS：yahoo.com.tw 的收信主機（MX 紀錄）是 mx-tw.mail.gm0.yahoodns.net（2026-09-28 查詢）。收信主機是哪一台，和這套要求有沒有涵蓋這個信箱品牌是兩回事，官方頁面沒有把兩者連起來，所以到 2026-09-28 為止，這一題是查無明文。照大量寄件者標準做，這一題的答案是什麼都不影響做法。

三筆 DNS 紀錄各在做什麼，DMARC 要最後設

SPF 是你網域上的一行文字紀錄，Google 的說明是它「lists all the servers that send email for your domain」，收件伺服器收到信時查這一行，確認信是從授權過的伺服器寄出。用電子報平台寄信，平台的伺服器就要列進去。Google 寫明，第三方寄件者沒有列進 SPF 紀錄的話，這些信比較容易被標成垃圾郵件。

DKIM 用一對金鑰運作：私鑰放在寄信的伺服器上，替每一封寄出的信加上簽章；公鑰放在你網域的 DNS 紀錄裡，收件伺服器拿公鑰去讀簽章、驗證這封信。用電子報平台寄信時，簽章的是平台的伺服器，所以平台要用你的網域簽章，DKIM 驗過的網域才會是你的網域。

DMARC 告訴收件伺服器：從你網域寄出、卻沒通過 SPF 或 DKIM 的信要怎麼處理，選項是退回（reject）、隔離（quarantine）或照常投遞。p=none 對應的是照常投遞，但會把結果記進每日報告，寄到紀錄裡 rua 指定的信箱。rua 不是必填，但 Google 建議一律加上，Yahoo 也寫明強烈建議；沒有 rua，報告就沒有地方寄。DMARC 紀錄的主機名稱是 _dmarc 加上你的網域，例如 _dmarc.example.com。

DMARC 還多檢查一件事：信件標頭 From 欄位（寄件地址）的網域，要跟通過驗證的 SPF 或 DKIM 網域對得上，Google 的用詞是「aligned」。這一條決定了下一節的結論。

順序不能反。Google 的 DMARC 設定頁寫明，要先開 SPF 或 DKIM 才能用 DMARC；剛開始把政策設成 none，看懂報告之後再逐步改成 quarantine 或 reject。

用 @yahoo.com.tw 或 @gmail.com 當寄件人，會卡在 DMARC

對齊那一條，影響最大的是用免費信箱當電子報寄件地址的做法。

yahoo.com.tw 在 DNS 上公布的 DMARC 紀錄是 v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;（2026-09-28 查詢）。Yahoo 常見問題說明過它公布 p=reject 的用意：引導包括 Gmail 在內的收件方，退回「may not be legitimately sent by Yahoo」的信，防止別的郵件伺服器冒用 Yahoo 的信箱地址寄信。

照前面 SPF 與 DKIM 的機制推下去：從電子報平台寄出、From 卻寫 @yahoo.com.tw 的信，DKIM 簽章不是 Yahoo 的伺服器簽的；寄件伺服器也不在 yahoo.com.tw 的 SPF 授權裡，它的 SPF 紀錄是 v=spf1 redirect=_spf.mail.yahoo.com，指向 Yahoo Mail 的清單。兩樣都對不上，就落進 Yahoo 自己寫的那一句：「any message without a proper DKIM signature or SPF alignment will be rejected by Yahoo's mail servers.」

gmail.com 目前公布的是 v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com（2026-09-28 查詢）。p=none 這個政策本身，是要收件方照常投遞、只記進報告，不要求退信；但 Gmail 另有規定。Google 常見問題把「From 寫 @gmail 地址、信卻不是從 Gmail 伺服器寄出」定義為冒用 Gmail 的 From 標頭，接著寫：「As described in the timeline above, bulk senders that spoof gmail.com will start getting notifications about temporary failures.」寄件者指南也要求所有寄件者不要這樣做，並寫著「Gmail will begin using a DMARC quarantine enforcement policy」。

從電子報平台寄出、From 卻寫 @gmail.com 的信，DKIM 簽章與 SPF 驗證的都不是 gmail.com，From 的網域一樣對不上。常見問題的執行對照表，把「From: header and authentication don't align」的後果列為「Temporary or Permanent Failure codes, or spam foldering」：收件伺服器回傳暫時或永久失敗代碼，也就是信被退回，或是信被送進垃圾郵件匣。

結論只有一個：要發電子報，先有自己的網域。寄件地址換成 news@你的網域 這一類，前面三筆 DNS 紀錄才有地方設。

一鍵退訂是寄信平台的功能，你要確認它有開

一鍵退訂的規格是 IETF 在 2017 年 1 月發布的 RFC 8058。做法是在信件標頭放兩行：List-Unsubscribe 放退訂網址，List-Unsubscribe-Post 固定寫 List-Unsubscribe=One-Click。收件人在信箱介面按下退訂，信箱服務直接對那個網址送出 HTTPS POST 請求，寄件方收到就完成退訂，收件人不必再打開確認頁。RFC 8058 另外要求信件要有有效的 DKIM 簽章，而且簽章要涵蓋 List-Unsubscribe 與 List-Unsubscribe-Post 這兩行標頭。

這兩行標頭與 DKIM 簽章由寄信平台產生，你能做的是確認它有開。Google 只認這種標頭做法：常見問題寫明，mailto 與網址形式的退訂連結都不符合一鍵退訂的要求。Yahoo 則是強烈建議用 RFC 8058 的 POST 方式，mailto 方式也接受。兩家也都要求內文另外放一個明顯的退訂連結，Yahoo 註明這個連結可以導向偏好設定頁。

Google 常見問題寫明，一鍵退訂只要求行銷與促銷信，交易型的信不在內，舉的例子是密碼重設、訂位確認、表單送出確認。

退訂多快要生效，兩家的時限都是兩天。Yahoo 的大量寄件者要求寫明「Honor unsubscribes within 2 days」。Google 常見問題回答時限的那一題，用字是建議：「we recommend that you fulfill unsubscribe requests within 48 hours」；但同一頁的執行對照表，把「Unsubscribe requests aren't honored within 48 hours」列為不符合寄件者要求的情形，後果是「Delivery support or mitigations unavailable」（意思見〈2025 年 11 月起〉一節）。Postmaster Tools 也照這個時限判定：儀表板說明頁寫，Compliance status 裡「Honor unsubscribe」那一項顯示 Needs work（需要改善）的可能原因是「You might receive this entry if you don't honor the unsubscribe requests within 48 hours.」所以 Gmail 的 48 小時要當成要求來做。

台灣法律這一側，個資法第 20 條第 2 項寫的是當事人表示拒絕接受行銷時「應即停止」，沒有給天數；這部分另見〈行銷名單的規則其實在個資法裡〉。

檢舉率要低於 0.1%、不能碰到 0.3%，在 Postmaster Tools 看

Google 的要求段寫的是檢舉率低於 0.3%，但同一頁的常見問題把合規的線畫得更低：「To comply with the sender guidelines, keep your user-reported spam rate below 0.1% and prevent it from reaching 0.3% or higher.」並寫明對大量寄件者來說，超過 0.1% 現在就已經會拖累進收件匣的比例：「Even today, user-reported spam rates greater than 0.1% have a negative impact on email inbox delivery for bulk senders.」監控段也是同一個說法：「Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.」所以要盯的線是 0.1%，0.3% 是絕對不能碰的上限。

量這個數字的工具就是那句話裡的 Google Postmaster Tools。它要先驗證網域才會顯示資料；驗證完，寄量太低的日子也可能沒有資料，設定說明頁寫：「Data might be missing if the total number of messages for a given day is too low.」理由是保護使用者隱私，等寄量大到足以填滿儀表板才會出現數字。一天只寄幾百封的電子報，驗證完看到空的儀表板，不代表設定錯了。裡面的 Compliance status（合規狀態）儀表板列出你對寄件者要求的符合情形，其中 DMARC 驗證、一鍵退訂、退訂處理這三項只對大量寄件者顯示。

2025 年 11 月起，不合規的信可能直接被退回

Google 常見問題現在的寫法是：

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. Google〈Email sender guidelines FAQ〉，2026-09-28 查證

意思是沒設好的信除了進垃圾匣，還可能在收件伺服器那一關就被暫時或永久退回。

各項的後果不一樣。同一頁的執行對照表把後果分成兩類。第一類是 From 標頭跟驗證網域對不上、沒有同時通過 SPF 與 DKIM、寄件網域沒有有效的正反向 DNS 紀錄、沒用 TLS 傳送、格式不符 RFC 5322，後果是「Temporary or Permanent Failure codes, or spam foldering」，也就是暫時或永久退信，或進垃圾郵件匣。第二類是檢舉率超過 0.3%、沒有 DMARC 紀錄、行銷信沒有一鍵退訂、48 小時內沒處理退訂，後果是「Delivery support or mitigations unavailable」。但缺 DMARC 不只是拿不到投遞支援：同一頁常見問題的錯誤代碼表另外列了一條「4.7.31 Your email has been rate limited because the sending domain doesn't have a DMARC record, or the DMARC record doesn't specify a DMARC policy.」也就是寄件網域沒有 DMARC 紀錄、或紀錄沒寫政策時，信會被限速、收到暫時失敗。

第二類的 mitigation 指的是：信出現投遞問題時，寄件者可以透過 Google 的寄件者聯絡表單請 Google 處理。常見問題寫：「Starting in February 2024, we won't provide mitigation for email delivery issues to senders that don't meet the guidelines.」常見問題也寫明，缺一鍵退訂的信不會因此被自動退回或標成垃圾郵件，但沒有一鍵退訂的信比較容易被收件人檢舉，檢舉多了，之後的信就比較容易進垃圾郵件匣。

現在可以做的三件事