通知信已打開卻幾乎空白，先確認是不是外部圖片未載入，而不是直接判定郵件內容被刪除。訂單時間、必要操作與客服方式應有可讀文字；如果重要資訊只存在一張圖片裡，收件者的圖片設定就可能讓通知失去用途。
先保留原始觀看條件
請記下收件服務、應用程式及是否顯示載入圖片提示。不要先按允許圖片再截圖回報，否則原本的問題就被掩蓋。若網頁版正常、手機程式空白，分開記錄兩者；同一封已收到的信在不同介面呈現不同，不代表有兩種 SMTP 投遞結果。
- 以同一封測試信查看圖片開啟與關閉兩種情境，記錄哪些必要資訊會消失。
- 確認主旨、文字內文與主要按鈕仍能說明用途，圖片替代文字應描述內容而非重複無意義檔名。
- 檢查圖片網址是否可由收件環境正常取得，但不要為了方便將含個資圖片改成公開分享。
- 修正版從原寄送流程重測，保留內容版本與畫面，另外記錄資料夾位置，不將版面改善當成分類保證。
假設案例：取貨期限寫在海報上
假設臺南甜點店把取貨期限、地址和注意事項全做成一張海報，收件者關閉外部圖片後只看到店名。這個假設需要改善文字資訊層級，而不是要求顧客永久載入所有陌生來源圖片。可讓通知直接以文字提供必要內容，再把海報作為補充。
若圖片本身是動態個人化內容，也需檢查資料權限與有效性。不要把真正顧客的訂單圖上傳到公開測試工具；以自有測試訂單產生示範內容即可。只看編輯器預覽，無法驗證收件端能否取得外部資源。
從可用性走回技術證據
若連文字也沒有，請網站維護者查看實際收到的 MIME 結構與內容，不要只依視覺猜測。HTML 和純文字替代部分是否存在、是否為正確版本，需從原始信判斷；轉寄後截圖不足以證明原信結構。必要時將去除敏感資訊的原檔交可信支援。
測試需包含常見讀取方式，但不必宣稱涵蓋所有裝置。選擇與自己顧客實際回報相關的環境，註明未測部分。若某環境不支援特定樣式，優先讓關鍵文字和連結仍可用，不依賴精確像素或圖片一定顯示。
Google 的圖片設定文件只說明該服務的行為，不能直接套用到每一個企業閘道。某些組織還有額外保護；遇到限制時由收件方管理者確認，不要求一般員工自行繞過。外部樣本能呈現一組畫面，不等於所有讀者都開啟相同設定。
這篇不聲稱圖文比例有固定安全數值，也不把移除圖片當成避開垃圾信的公式。圖片處理、內容品質和分類是不同檢查；需要比較落點時固定其他變因。版面調整的直接目標，是讓已收到信的讀者能理解訊息與完成必要操作。
完成後保留關圖畫面、開圖畫面及文字檢查結果。若之後換了海報或活動日期，重新核對關鍵資訊是否仍一致；舊版測試通過不能替新圖片內的錯字、過期時間或錯誤地址作證。
資料依據與後續觀察
完成上述檢查後，可用去除個資的同版內容開始郵件測試；先確認當下可選的收件服務，結果僅描述本次樣本，不能推估所有臺灣顧客。測試方法與限制說明觀察範圍；工具不會代查商店後台或收件者私人設定。