WordPress 聯絡表單郵件排錯紀錄｜SMTP、DNS、Log 與收件驗證

WordPress 聯絡表單最容易出現一種尷尬狀況：前台顯示「送出成功」，但管理者沒有收到通知信；或站方收到信，訪客卻沒有收到自動回覆。這時如果只說「表單壞了」或「SMTP 壞了」，通常會讓排查方向變得很混亂。

我會把聯絡表單郵件問題拆成一條可驗證的遞送鏈：表單是否真的送出、WordPress 是否建立郵件、SMTP 是否接受、DNS 身分是否可信、收件端是否拒收，以及回滾前後是否留下證據。這篇是一份排錯紀錄寫法，不需要暴露真實信箱、token 或客戶資料，也能讓下次維護更快定位問題。

先把症狀分成「送出」與「送達」

表單送出成功，只代表前端流程完成，不等於郵件已送達。排查時我會先把問題描述拆清楚：

Symptom scope
- frontend submit: success / failed / timeout
- WordPress mail event: created / not created / unknown
- SMTP handoff: accepted / rejected / unknown
- recipient inbox: inbox / spam / missing / bounced
- affected form: contact / quote / support / all forms

如果只有某一個表單失敗，可能是表單外掛設定或收件人欄位問題；如果所有表單都失敗，才更像 SMTP、主機 mail()、DNS 或寄件網域聲譽問題。先分清楚範圍，才能避免一開始就亂改外掛。

觀察表單送出，不要先改 SMTP 密碼

排查第一步應該是保存目前狀態。可以先用無破壞性的觀察方式確認表單頁、REST API、外掛狀態與最近錯誤 log。

curl -I https://example.com/contact/
curl -I https://example.com/wp-json/
wp plugin list --fields=name,status,version --format=table

若網站有啟用 WordPress debug log，紀錄時要取一小段時間範圍，而不是只貼最後一行：

Mail log observation
- time: 09:42-09:48
- form: contact-form-main
- frontend result: success message shown
- WordPress log: mail event created
- SMTP result: authentication failed
- private fields: redacted before sharing

這裡的重點不是把真實 log 全部公開，而是讓維護者知道「送出成功」和「SMTP 驗證失敗」其實是不同層級。若直接更換 SMTP 密碼，可能會覆蓋掉原本能判斷問題的證據。

SMTP 驗證要記錄成功與失敗原因

SMTP 外掛通常會提供測試信功能，但只看「測試信已寄出」不夠。比較有用的紀錄會包含寄件者、收件者、TLS/port、伺服器回應與測試結果。

SMTP test record
- from: no-reply@example.com
- to: internal-test@example.com
- host: smtp.example.com
- port: 587
- encryption: STARTTLS
- result: accepted by SMTP server
- note: do not store password or API key in the report

如果測試信成功，實際表單仍失敗，就要回頭看表單外掛的收件欄位、寄件人欄位、反垃圾驗證與通知模板。如果測試信失敗，才優先處理 SMTP 帳號、port、防火牆、主機封鎖或外部寄信服務設定。

DNS 與寄件身分會影響收件端判斷

很多表單郵件不是「沒寄出」，而是被收件端判定不可信。這時候 DNS 記錄就很重要，尤其是 SPF、DKIM、DMARC 與寄件網域對齊。

DNS mail identity check
- SPF: includes current SMTP provider
- DKIM: selector exists and passes provider check
- DMARC: policy exists and report address is valid
- from domain: matches the authenticated sending domain

公開文章不需要貼完整 DNS 值，但內部維護紀錄應該標註檢查結果與來源。例如「SMTP provider panel 顯示 DKIM pass」比「DNS 應該沒問題」更有追蹤價值。

收件驗證要包含 inbox、spam 與 bounce

寄信服務顯示 accepted，仍不代表使用者在 inbox 看得到。最小驗收可以用幾個不同收件端測試：站內信箱、Gmail、Outlook 或客戶常用網域。

Recipient verification
- internal mailbox: inbox received at 09:55
- Gmail test: spam folder at 09:56
- Outlook test: inbox received at 09:57
- bounce mailbox: no new bounce within 10 minutes

如果 Gmail 進垃圾信，而 Outlook 正常，問題可能不是 WordPress 表單本身，而是內容、寄件網域信譽、DMARC 政策或郵件模板。這類判斷要寫進紀錄，避免下次又從停用外掛開始。

變更與回滾要寫成 decision log

聯絡表單通常牽涉業務線索，不能在正式站上反覆試錯。每次修改 SMTP、表單收件人、寄件者或 DNS，都應該留下 change / verify / rollback。

Change record
Change
- update SMTP port from 465 to 587
- enable STARTTLS
- keep previous config screenshot in private ops folder

Verify
- contact form submits successfully
- SMTP log: accepted
- internal mailbox: received
- Gmail test: received in inbox

Rollback
- restore previous SMTP port and encryption
- disable new DNS record only if provider check fails

如果排查中需要更換 API key、SMTP 密碼或第三方服務 token，公開文章只描述欄位與驗證方式，不記錄實際秘密值。真正的密碼輪替要走安全的憑證管理流程。

上線後把證據收斂成可重用模板

一次排錯結束後，最有價值的不是「已修好」，而是留下下次能重用的判斷順序：

前台表單是否送出成功。
WordPress 是否建立 mail event。
SMTP 是否接受或拒絕。
DNS 身分是否通過。
收件端 inbox / spam / bounce 結果。
變更前後與回滾方式是否保存。

這份紀錄也能延伸成網站維護 SOP：新表單上線前先跑一次測試信、每次更換網域或 SMTP provider 後重新檢查 SPF/DKIM/DMARC、每次外掛更新後保留一筆表單送信驗證。對內容站來說，這些小證據會比事後補救更省時間。

小結

WordPress 聯絡表單郵件排錯，不應該只靠「重寄一次看看」。把送出、SMTP、DNS、收件與回滾拆開，才能知道問題真正卡在哪一層。只要每次維護都留下簡短但可驗證的紀錄，下次遇到表單送信失敗，就不需要從猜測開始。

WordPress 聯絡表單郵件排錯紀錄：從送出、SMTP 到信箱收件留下證據