為什麼網店的「訂單確認信」總是石沉大海？
在香港經營網店或跨境電商，不少商戶都遇過類似的困擾：客戶完成下單付款後，投訴收不到訂單確認信；重設密碼的驗證碼郵件被 Gmail 或 Yahoo 丟進垃圾郵件箱；更嚴重的是，有騙徒利用極為相似甚至偽造的電郵地址，冒充你的品牌向顧客發送虛假退款或釣魚連結，導致顧客蒙受損失並破壞品牌信譽。
許多店主誤以為只要在 Shopify、Shopline 或 WooCommerce 後台填妥聯絡電郵，系統就能自然順暢地代表品牌發信。然而，現代各大郵件服務商（包括 Google Workspace、Microsoft 365、Apple iCloud 及 Yahoo）對郵件發送者實施了極為嚴格的身分驗證機制。若你的自訂網域（Custom Domain）沒有在 DNS 底層正確配置防偽驗證協議，第三方電商平台或電子郵件營銷系統（EDM）代發的郵件，極容易被全球郵件伺服器判定為「未授權偽造郵件」並直接拒收或歸類為垃圾郵件。
三大電郵防偽基石：SPF、DKIM 與 DMARC 的運作原理
要讓各大電郵供應商確認「這封信確實代表你的網店發出」，你的網域 DNS 必須建立完整的信任鏈。這套防禦與驗證體系由三個互相協作的標準協議組成：
1. SPF（Sender Policy Framework，發件人策略架構）
SPF 就像是一份公開在 DNS 上的「合法發信名單」。你透過網域的 TXT 記錄，向全世界宣告哪些伺服器或 IP 地址有權代表你的域名發送電郵。當接收方伺服器收到一封自稱來自 [email protected] 的郵件時，會查詢該網域的 SPF 記錄，核對發信伺服器的 IP 是否名列其中。
2. DKIM（DomainKeys Identified Mail，網域名稱密鑰識別郵件）
如果說 SPF 是核對門牌，DKIM 就是數位簽名與封條。發信系統在寄出郵件時，會使用伺服器上的「私鑰」（Private Key）為郵件內容和標頭生成一組加密簽名；而網域擁有者則在 DNS 中發布對應的「公鑰」（Public Key，以 CNAME 或 TXT 記錄形式存在）。接收端伺服器利用公鑰解密驗證，確保郵件在傳輸過程中未被第三方篡改。
3. DMARC（Domain-based Message Authentication, Reporting, and Conformance）
DMARC 是架設在 SPF 與 DKIM 之上的指揮政策。它告訴接收端伺服器：如果一封自稱來自你網域的郵件，未能通過 SPF 或 DKIM 驗證時，應該如何處置？DMARC 提供了三種處置層級：
- p=none（純監控模式）：不攔截任何郵件，僅收集驗證失敗的報表，適合設定初期的測試與盤點。
- p=quarantine（隔離模式）：未通過驗證的郵件會被送入收件者的垃圾郵件箱。
- p=reject（拒收模式）：直接拒絕接收未通過驗證的郵件，全面封鎖偽冒信件，防護力最高。
電商多平台發信的典型衝突與設定盲點
電商營運環境通常比較複雜，一家網店往往同時使用多種發信來源：
- 電商核心平台：負責發送訂單確認、出貨通知（例如 Shopify、Shopline 等）。
- 自建商務電郵：日常客服對話、供應商溝通（例如專屬 Email Hosting 或 Microsoft 365）。
- 營銷自動化工具：負責促銷電郵、棄單挽回（例如 Klaviyo、Mailchimp 等）。
常見的技術錯誤在於：商戶在新增營銷工具時，重複建立了多條 SPF TXT 記錄，或直接覆蓋了原有的記錄。根據 RFC 官方規範，一個網域只能擁有一條 SPF 記錄。若 DNS 中出現多條 TXT SPF 記錄，接收方伺服器將直接視為驗證錯誤（SPF PermError），導致所有系統發出的郵件送達率全面崩潰。
實戰步驟：為電商網域建立完整的 DNS 防偽驗證
第一步：盤點所有發信服務來源
在修改 DNS 前，先列出所有代表你網域寄發電郵的端點，包括你的網頁寄存主機/電郵託管伺服器、電商平台及 EDM 系統。
第二步：合併並設定標準 SPF 記錄
將所有授權服務整合至單一 TXT 記錄中。例如，若你的網店同時使用自身的電郵託管系統與電商平台代發，SPF 記錄範例格式如下：
v=spf1 include:shops.shopify.com include:mailhost.kowloon.hk ~all註：結尾的 ~all 代表軟失敗（SoftFail），允許接收端在未完全匹配時進行彈性處理，待系統穩定後可評估收緊。
第三步：配置各平台的 DKIM 記錄
登入各大發信平台後台（如 Shopify 的網域設定或 Klaviyo 的 Sender Authentication），獲取系統生成的專屬 CNAME 或 TXT 記錄，並準確填入你的 DNS 管理面板。DKIM 允許多個發信端各自擁有獨立的 Selector 名稱，因此不同平台的 DKIM 記錄可以並存而互不衝突。
第四步：部署 DMARC 監控並逐步收緊政策
在 DNS 新增一條主機名稱為 _dmarc.yourdomain.hk 的 TXT 記錄。初期建議設定為監控模式，並指定接收分析報表的信箱：
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100;持續觀察 2 至 4 星期。確認所有合法管道（客服信箱、訂單通知、促銷信）皆能順利通過 SPF 及 DKIM 驗證後，再逐步將政策改為 p=quarantine 乃至最終的 p=reject，徹底杜絕外來偽冒攻擊。
維護品牌資產：將網域控制權掌握在自己手中
許多中小企在建站初期忽視了網域底層架構的獨立性，將域名、電郵與單一電商平台深度綁定，一旦未來面臨平台遷移或擴展，往往需要經歷痛苦的 DNS 割接與送達率重建過程。建立清晰、規範的 SPF、DKIM 與 DMARC 體系，不僅能立即改善顧客接收交易訊息的體驗，更是保障商業通訊安全與維護品牌信譽不可或缺的數碼基礎設施。
