Brevo 交易通知沒收到，先在交易紀錄找到該收件者的事件。若顯示 Blocked，重點可能在平台的聯絡人或寄送狀態，而非信已進對方垃圾郵件；應先取得具體原因，再決定由帳號管理者或收件端處理。
從正確的紀錄範圍開始
電子報與交易通知可能使用不同流程。臺灣店家用官網外掛經 SMTP 寄送時，先確認外掛實際連到 Brevo，而不是網站仍由主機直接發信。找不到紀錄時，不能只因帳號有訂閱服務，就推定所有郵件都經過那裡。
- 進入 Brevo 的 Transactional > Logs，依收件者、時間或訊息識別縮小範圍，注意介面時區與你紀錄的臺灣時間。
- 開啟單筆事件查看歷史與可用預覽，記錄狀態及原因，區分平台未送出、被阻擋、延後或遠端接受。
- 若原因涉及聯絡人被封鎖或取消接收，核對其來源與用途，不為了測試擅自解除顧客偏好。
- 如果是帳號或寄件身分設定，請具權限管理者處理；如果是遠端回應，再依該回應請相應人員追查。
假設案例：網站有成功訊息，平台卻未送
假設臺中課程網站通知付款後，使用者沒看到信，網站畫面只顯示表單已送出。Brevo 紀錄若另指出該地址被阻擋，下一步應查阻擋原因，而不是要求使用者回報非垃圾郵件。這是假設示例，並未指稱任何真實帳號或聯絡人狀態。
若阻擋與過去退信或申訴有關，需先確認地址正確性及該訊息用途，依平台正式流程處理。不要建立另一筆相同聯絡人或換寄件者來繞過狀態；這既失去可追溯紀錄，也可能忽略收件者明確拒收的原因。
登入識別不是顧客看到的寄件者
官方 SMTP 排查文件提醒技術登入身分與 From 用途不同。管理者應核對使用的是平台支援且已驗證的寄件身分，不把 SMTP 登入字串貼到顯示寄件地址。排查問題單不需要公開密碼或金鑰，只需確認設定角色與失敗訊息。
若你只能看到部分紀錄，先確認權限與保留範圍。匯出檔可能含收件地址、主旨和連結，應存放在組織核准的位置，且只交付本案需要的資料。本文不承諾所有帳號有相同保留期限，也不要求讀者啟用新的 API 或事件接收整合。
平台預覽可協助核對寄出版本，但不會重現每位收件者的個人規則與分類。當狀態顯示遠端接受，仍需請對方搜尋信件；如果原信找不到，保留位置待查，不把有開信摘要或預覽正常當成收件匣證明。
測試應使用自有聯絡人及沒有真實帳務資訊的內容，避免重新寄送過期付款連結。修正後建立新事件，保留前後狀態與負責人；舊事件不會因解除設定而自動變成新成功。這樣才能讓營運同事知道修好了哪一段，而非只得到一句「現在可以寄」。
資料依據與後續觀察
若同一地址有多次嘗試，請逐筆列出事件而非只看最近結果；最後一次成功不能取代之前失敗的原因，尤其是顧客正在追查某封有時效的通知時。
完成上述檢查後，可用去除個資的同版內容開始郵件測試；先確認當下可選的收件服務，結果僅描述本次樣本，不能推估所有臺灣顧客。測試方法與限制說明觀察範圍；工具不會代查商店後台或收件者私人設定。