測試帳號若已加入允許清單、建立永不進垃圾郵件規則，或曾手動移動同來源郵件，結果可能反映那些條件，不能直接代表沒有相同設定的讀者。先記錄帳號狀態，保留原始觀察；不要為了提高成績而在測試途中偷偷改規則。
先定義樣本要代表什麼
你可以測一個持續使用的內部帳號，也可以觀察工具提供的控制樣本，但兩者歷史不必相同。重點是說明條件與限制，而不是宣稱有一組完全代表全體臺灣人的信箱。測試用途是縮小問題，不是用少量帳號替市場作抽樣背書。
- 在測試紀錄中列出已知的允許或封鎖規則、是否轉寄及是否曾手動處理此來源；不了解的部分寫未知。
- 寄送前先保存設定與版本，不在看到不理想位置後才臨時變更，再回報同一次已通過。
- 若需要驗證個人設定修復，將它另列為設定前後測試，與自然分類觀察分開。
- 對照結果時保留不同帳號條件，不把受特例影響的結果與一般樣本混算成單一保證。
假設案例：自己永遠收到，顧客卻漏信
假設臺灣店主的 Gmail 長期把自家地址設為永不進垃圾郵件，測試一直正常，顧客則回報某封信在垃圾郵件。這個假設並不矛盾；店主帳號有特定規則。應查顧客原信與設定範圍，不能用自己的綠燈結束所有回報。
另一個場景是同事為驗證客服教學，先把信手動移回收件匣，後來只提供移動後畫面。這張圖可證明當時位置，卻不能證明最初落點。請要求記錄操作前後，而不是批評同事做錯；證據用途不同，需要標示清楚。
不要刻意訓練來製造好結果
反覆開信、點擊、移動或加規則，若是為了測試介面操作，應說明這個目的；不應拿來讓原本的分類問題看起來消失。若你想了解讀者如何整理信件，可以另設情境，但它不等於對沒有相同行為的真實名單做了預測。
使用外部樣本時，通常無法掌握所有歷史與服務內部判斷。報告應承認限制，不宣稱某種新鮮帳號必然更真實，或一組固定樣本能永久代表分類。平台更新、時間與內容變動也都可能造成差異，因此需要保留每次條件。
若目的只是查寄件驗證，可從原信讀技術結果；它與個人是否允許此寄件者又是不同問題。不要因允許後看得到，就宣稱 SPF、DKIM 或 DMARC 已修復，也不要因分類差異便覆蓋原本正確的網域設定。
本篇不建議大量建立帳號或規避服務限制，也不要求移除持有人必要的私人防護。測試必須由有權使用帳號的人操作，截圖遮蔽無關規則及個人地址。需要保持業務收信安全的帳號，不宜為了追求某種測試條件隨意重設。
結案時可寫「此帳號在已知規則下的觀察」，並列出還缺哪些未受特例影響的證據。透明呈現條件，比稱它為自然到達率更精確；日後換帳號或刪規則，也要重新記錄，不能直接與歷史圖表比較。
資料依據與後續觀察
完成上述檢查後，可用去除個資的同版內容開始郵件測試；先確認當下可選的收件服務，結果僅描述本次樣本，不能推估所有臺灣顧客。測試方法與限制說明觀察範圍；工具不會代查商店後台或收件者私人設定。