新預約系統上線：先驗收確認電郵的寄件認證

驗收的是哪條寄件路徑？

先請供應商示範：客人完成預約後，系統實際會怎樣發出確認信。銷售人員寄來的樣板，或後台的電郵預覽，都未必使用正式寄件設定。店方可以用虛構姓名及自己控制的收件地址，走一次真正的預約流程。這是新系統的驗收工作，並不表示店舖已經出現漏信。

先定好客人看見的寄件地址：用程式供應商的網域，還是店舖自己的網域？若店方接受供應商的寄件身分，可以把它列為初期方案；若要用自家網域，就要查清訂閱方案是否支援，以及誰有權修改網域紀錄。設定費、所需權限、可提供的寄件紀錄，都應在決定前問清楚。另外要實測客人按「回覆」後由誰收信，免得改期要求留在沒人查看的信箱。

用一張清單分清責任

清單以「程式及寄件身分」為單位；確認信、提醒信和取消通知若用不同設定，就分開記錄。預約程式供應商未必就是實際寄信的服務商，不能單看商標判斷。負責人的姓名、職責和支援聯絡方法已足夠，不要把密碼放進驗收表。清單的用途是讓店長知道下一步找誰，毋須把整間公司的資訊系統都盤點一次。

從測試信留下可核對的證據

用店方控制的個人 Gmail 信箱直接收取測試信。根據 Google 的標頭查看說明，在網頁版開啟該信，於「回覆」旁的更多選單選擇「顯示原始郵件」。把測試日期、預約編號、Message-ID 及原始標頭存入只限相關人員查看的專案資料夾。請供應商逐項解釋收件系統寫入的 Authentication-Results，列明 SPF、DKIM、DMARC 的結果及涉及的網域。使用測試資料，之後交給支援人員核對時便不會帶出客人的行程。

SPF 用來核對寄件主機是否獲網域授權，DKIM 則提供可驗證的簽章。Google 的認證說明列出標頭中的 spf=pass 或 dkim=pass，可用來確認相應檢查是否通過。不過，驗收表不能只寫一個 pass；還要知道通過的是哪個網域。若結果屬於供應商網域，就要對照原先同意的寄件身分；若使用店方網域，應請供應商說明 DMARC 如何與客人看見的 From 網域對齊。

驗收時要分開記錄三件事：程式有沒有產生通知、收到的樣本是否通過相關認證、樣本最後落在哪個資料夾。一次測試不能代表以後每封信的結果。若完全收不到，先向供應商索取寄件紀錄及退信或延遲回應，因為此時根本沒有收件標頭可查。若認證通過卻進了垃圾郵件匣，則另查投遞問題。兩種情況都不能直接當成預約失敗。

分清 Gmail 規則與一般投遞檢查

Google 這份寄件指引的適用對象是個人 Gmail 帳戶。一般寄件者的認證基本要求是 SPF 或 DKIM；大量寄件者則須具備 SPF、DKIM 和 DMARC，直接寄出的郵件亦須符合網域對齊要求。TLS 及有效的正向、反向 DNS 同樣有要求。這裏只摘出與驗收相關的項目，並非完整合規清單；應請寄件服務商核實所屬寄件量類別及全部適用要求。通過認證不保證進入收件匣，其他收件服務亦有各自的規則。

香港店舖若同時提供中英文通知，兩種語言都應各走一次預約流程，核對日期時間、分店地址、回覆去向及寄件身分。再選一個客人常用、由員工控制的其他收件服務作測試，記錄投遞情況。這部分屬於一般投遞觀察，不能寫成「通過 Gmail 認證」。最後註明已測的範本及收件服務；只驗過確認信，就不要連未測試的提醒信也一併簽收。

先修設定，再決定是否轉平台

例如一間髮型屋準備上線，店長原本以為客人會看見店方網域，測試信卻用了程式供應商的網域。即使認證通過，仍未證明設定符合原來要求。這時先查現有方案是否支援所需身分，取得設定指示，待獲授權的人員完成修改後重測。相反，若維修店一開始已同意使用供應商寄件身分，並確認認證及回覆安排，該路徑可以納入驗收。以上是說明判斷方式的假設例子，並非客戶實績。

預算有限時，第一筆工作應是請現有供應商查設定。要求列明負責人、欠缺的證據或改動、費用及重測日期。只有在確認現有服務無法提供所需寄件身分、證據或支援安排後，才比較轉平台；比較時連同月費、連接工作、網域改動和重新測試一併計算。必要檢查尚未完成期間，可指定員工沿用店方已同意的聯絡方法確認試行預約，並留下聯絡紀錄，避免發出互相矛盾的通知。

下一步可安排店長、程式支援及網域管理員一同驗收：填好清單、查看實際樣本，再為未解決事項指定負責人。若發現限制後需要重新選軟件，可參考現有的 SaaS 比較指南；若牽涉另外維護的系統連接，則可帶同證據包，按系統整合服務的範圍界定需要調查的部分。