本文整理 Google SMTP 標準參數、應用程式密碼建立與更換流程，並說明 587／TLS、465／SSL 的差異，以及常見寄信錯誤的排查方式。

Google SMTP 寄信設定一次搞懂：標準參數、應用程式密碼更換與常見錯誤

Google SMTP 要穩定寄信，關鍵只有兩件事：參數填對，應用程式密碼用對。

Google SMTP 是什麼？為什麼網站和設備需要它？

SMTP 是負責「寄出電子郵件」的通訊方式。當網站、公司系統或事務機需要寄信時，可以透過 Google 的郵件伺服器，把通知送到使用者信箱。

例如，會員在購物網站忘記密碼，系統必須寄出重設連結；辦公室事務機完成掃描後，也可能要把 PDF 寄給同事。這些設備本身沒有完整的 Gmail 操作介面，因此需要填入 SMTP 參數，借用 Google 帳戶完成寄送。

SMTP 主要處理寄信；若需要讓其他郵件軟體讀取 Gmail 收件匣，則會使用 IMAP 或 POP。三者用途不同，設定 SMTP 並不代表系統也能讀取帳戶內的信件。:contentReference[oaicite:1]{index=1}

圖片一｜建議配圖
網站、印表機或企業系統，透過 Google SMTP 將郵件送至收件人信箱的流程圖。

Google SMTP 的標準設定參數

大多數網站後台、WordPress 外掛、NAS、監控設備及事務機，都會要求填寫類似的欄位。Google 官方目前提供兩組安全連線方式：TLS 使用 587 連接埠，SSL 使用 465 連接埠。:contentReference[oaicite:2]{index=2}

例如，公司網站使用 [email protected] 寄送表單通知，SMTP 使用者名稱就必須填入完整的 [email protected]，不能只填 service。密碼欄位則不是日常登入 Gmail 的密碼，而是另外產生的應用程式密碼。

587 和 465 應該選哪一個？

系統支援 STARTTLS 時，可以先使用 587；若舊型事務機只有 SSL 選項，則改用 465。兩組設定都由 Google 支援，不能把 587 搭配純 SSL，也不能把 465 設成沒有加密。

例如，網站後台顯示「Encryption：TLS」，應搭配 587；設備選單若只有「SSL On／Off」，通常應啟用 SSL 並使用 465。連接埠與加密方式配錯，常會出現連線逾時或「Must issue a STARTTLS command first」錯誤。:contentReference[oaicite:3]{index=3}

圖片二｜建議配圖
以左右對照卡呈現「587＋TLS」及「465＋SSL」，避免使用者混合設定。

應用程式密碼不是你的 Gmail 登入密碼

Google 應用程式密碼是一組獨立的 16 位密碼，讓不支援「使用 Google 帳戶登入」的舊設備或第三方系統連接帳戶。帳戶必須先啟用兩步驟驗證，才能建立應用程式密碼。:contentReference[oaicite:4]{index=4}

例如，印表機無法跳出 Google 登入及手機驗證畫面，就可以使用應用程式密碼完成 SMTP 驗證。即使這組密碼外洩，你仍可單獨撤銷它，不必立刻更改所有裝置使用的 Google 主密碼。

應用程式密碼仍屬於敏感憑證，不應放在公開文件、GitHub 程式庫或聊天截圖中。系統支援環境變數或機密設定功能時，應將密碼存放在這些位置，而不是直接寫進程式碼。

如何建立新的 Google 應用程式密碼？

第一步：確認已開啟兩步驟驗證

先登入 Google 帳戶，進入「安全性」頁面，確認「兩步驟驗證」已啟用。沒有開啟兩步驟驗證，Google 不會提供應用程式密碼功能。:contentReference[oaicite:5]{index=5}

例如，你正在設定 WordPress SMTP 外掛，但密碼一直驗證失敗，可以先檢查兩步驟驗證。這通常比反覆修改 SMTP 主機或連接埠更有效。

第二步：進入應用程式密碼頁面

在 Google 帳戶的安全性設定中找到「應用程式密碼」，系統可能會要求你再次登入。接著輸入容易辨識的名稱，例如「公司官網 SMTP」、「辦公室事務機」或「NAS 通知」。

名稱不會影響寄信功能，但能幫助日後管理。當公司有三個網站共用同一信箱時，分別建立三組密碼，才能在其中一個網站停用時，只撤銷對應的權限。

第三步：產生並保存新密碼

Google 會顯示一組新的 16 位應用程式密碼。將它複製到網站、外掛或設備的 SMTP 密碼欄位，再保存設定並寄送測試信。

畫面中的空格通常只是方便閱讀，實際輸入時可依系統要求貼入完整密碼。不要把範例圖片裡的密碼當成可用憑證，也不要把自己的密碼放進操作教學截圖。

圖片三｜建議配圖
Google「應用程式密碼」建立畫面，密碼區域應以馬賽克完整遮蔽。

如何安全更換應用程式密碼？

應用程式密碼不能直接編輯成另一組內容。正確做法是建立新密碼、更新使用端設定，再撤銷舊密碼。

一般更換：先更新，再撤銷

先建立一組新的應用程式密碼，填入網站或設備後寄送測試信。確認新密碼可以正常寄信，再回到 Google 帳戶移除舊密碼，可以減少服務中斷時間。

例如，會員系統每天會寄出訂單通知，若先刪除舊密碼才開始處理新設定，操作期間的訂單信件可能全部失敗。先完成新設定並測試，風險較低。

懷疑外洩：先撤銷，再建立

若密碼曾貼到公開程式庫、傳到錯誤群組，或交給已離職人員，應立即撤銷舊密碼。即使會造成短暫寄信中斷，也不應繼續保留可能已外洩的憑證。

Google 也建議在裝置遺失或不再使用某個應用程式時，移除對應的應用程式密碼。撤銷後，使用該密碼的設備或系統就無法繼續存取帳戶。:contentReference[oaicite:6]{index=6}

更改 Google 主密碼後也要檢查

更改 Google 帳戶的主要登入密碼後，原有的應用程式密碼會被撤銷。這也是許多網站「昨天還能寄信，今天突然失敗」的常見原因。:contentReference[oaicite:7]{index=7}

例如，資訊人員因安全政策更新公司 Gmail 密碼後，WordPress、NAS 與監控主機可能同時停止寄信。此時不必一直調整 SMTP 連接埠，而是要重新產生應用程式密碼，逐一更新相關系統。

圖片四｜建議配圖
「建立新密碼 → 更新系統 → 寄送測試信 → 撤銷舊密碼」四步驟流程圖。

找不到「應用程式密碼」怎麼辦？

最常見的原因是帳戶尚未開啟兩步驟驗證。若已啟用仍看不到，可能是帳戶只允許安全金鑰、已加入 Google 進階保護，或公司與學校帳戶受到管理員政策限制。:contentReference[oaicite:8]{index=8}

例如，公司要求所有員工只能使用安全金鑰登入，使用者就不一定能自行建立應用程式密碼。這時不應嘗試繞過政策，而要請 Google Workspace 管理員確認是否允許 SMTP、OAuth 或 SMTP Relay。

常見錯誤訊息與排查方向

535：使用者名稱或密碼不被接受

先確認使用者名稱是否為完整電子郵件地址，再檢查密碼欄位使用的是應用程式密碼，而不是 Google 主密碼。Google 的 SMTP 錯誤說明將 535 5.7.80 定義為使用者名稱或密碼未被接受。:contentReference[oaicite:9]{index=9}

例如，從密碼管理器複製內容時多貼了一個空格，就可能造成驗證失敗。重新貼入密碼後，應使用另一個信箱收取測試信，確認郵件確實離開系統。

534：需要應用程式專用密碼

534 5.7.90 通常表示系統需要使用應用程式密碼。帳戶已啟用兩步驟驗證，但設備仍填入一般登入密碼時，就可能出現這個錯誤。:contentReference[oaicite:10]{index=10}

處理方式不是關閉兩步驟驗證，而是建立一組專用密碼。關閉安全功能來配合舊設備，會讓整個 Google 帳戶承擔更高風險。

530：需要驗證或 STARTTLS

530 5.7.0 可能代表尚未完成 SMTP 驗證，或系統應先建立 STARTTLS 安全連線。此時應檢查「需要驗證」是否開啟，以及 587 是否正確搭配 TLS。:contentReference[oaicite:11]{index=11}

例如，外掛只填了伺服器與連接埠，卻沒有啟用 SMTP Authentication，即使帳號密碼正確也無法寄送。把驗證功能打開後，再重新執行測試。

Google SMTP 適合寄什麼信？

Google SMTP 很適合少量、必要且由事件觸發的郵件，例如表單通知、密碼重設、每日報表、設備警報及掃描文件。這類情境寄送量不高，也能直接使用熟悉的 Gmail 或公司 Workspace 信箱。

它不適合拿來發送大量電子報或行銷名單。個人 Gmail 帳戶一天寄送超過 500 封信，或單封郵件包含超過 500 位收件人，可能暫時無法繼續寄信。:contentReference[oaicite:12]{index=12}

例如，網站每天只有 30 封訂單通知，Google SMTP 通常足以應付；若公司要一次寄給數千名會員，應改用具備退信管理、取消訂閱及寄送信譽管理的專業郵件服務。

應用程式密碼會一直是最佳方案嗎？

Google 明確表示，應用程式密碼並不是優先建議的登入方式。新式軟體若支援「使用 Google 帳戶登入」或 OAuth，應優先使用這類授權機制。:contentReference[oaicite:13]{index=13}

差別在於，OAuth 可以讓使用者授權特定權限，也能集中撤銷存取；應用程式密碼則較像為舊設備保留的相容方案。例如，十年前的事務機可能只能使用應用程式密碼，新開發的雲端系統則應直接規劃 OAuth。

這代表 Google SMTP 不會立刻消失，但使用方式正逐漸分流。舊設備可以暫時透過應用程式密碼維持運作，新網站與 SaaS 服務則應把 OAuth 或專業郵件服務列入後續升級計畫。

下一步：先盤點哪些系統正在使用這組密碼

不要直接刪除所有舊密碼。先列出網站、NAS、事務機、監控主機及排程工具，確認哪些設備正在使用 Google SMTP，再逐一建立獨立密碼並完成測試。

完成後，記錄密碼建立日期、用途及負責人，但不要記錄密碼明文。下一次需要更換憑證時，你就不必靠猜測找出哪一套系統會突然停止寄信。