破解 AWS SES 追蹤連結限制：從 HTTP 到 HTTPS 的送達率最佳化
郵件送達率的核心變數：追蹤連結的技術盲點
在電子報行銷與自動化工作流中，郵件送達率 (Deliverability) 決定了系統的有效性。多數技術人員將送達率的最佳化焦點放在 SPF、DKIM 與 DMARC 紀錄的設定。這些 DNS 層級的驗證確實能防範網域遭冒用，但在信件內容層級，一個經常被忽略的變數是「點擊追蹤連結 (Click Tracking Links)」。
郵件服務供應商 (ESP) 為了統計點擊率，會在信件寄出前將原始連結覆寫為專屬的追蹤網址。當收件人點擊時，流量會先導向 ESP 的伺服器進行紀錄，再以 301 或 302 狀態碼重定向至目標頁面。若此追蹤網址的網域與寄件網域不一致，或是採用未加密的 HTTP 協定，極易引起收件端防垃圾郵件系統 (如 SpamAssassin 或 Google Postmaster) 的警戒。
案例檢視：SendGrid 與 AWS SES 的 HTTP 追蹤陷阱
各大主流 ESP 雖提供自訂追蹤網域的功能，但在預設配置下，往往存在 SSL 憑證支援不足的技術缺陷。
SendGrid 自訂網域仍缺乏 HTTPS
觀察市場上知名電腦主機商的行銷郵件配置。圖一顯示該品牌使用 SendGrid 寄發行銷郵件，寄件人網域與官方網站一致。進一步檢查信件內部的連結結構 (圖二)，該品牌確實啟用了 SendGrid 的自訂追蹤網域 (Custom Tracking Domain) 功能，將追蹤連結的 Host 替換為其品牌網域的子網域。
開啟瀏覽器的開發者模式擷取完整網址 (圖三)，可以發現該追蹤連結的通訊協定為 http://。SendGrid 的預設自訂追蹤網域方案缺乏原生的 HTTPS 支援。若要為 SendGrid 的追蹤連結部署 SSL 憑證，使用者必須透過反向代理 (Reverse Proxy) 或是內容傳遞網路 (CDN) 自行設定憑證與路由規則。這項額外的工程門檻導致多數企業直接採用預設的 HTTP 配置，增加信件被各大郵件客戶端標記為「不安全」的風險。
AWS SES 的 awstrack 共用網域與 HTTP 限制
AWS SES (Amazon Simple Email Service) 是許多 SaaS 產品底層依賴的發信引擎。回顧 Quants Note 過去的架構，在使用 AWS SES 預設追蹤功能時，原始連結會被轉換為 awstrack.me 結尾的網域 (圖四)。
使用 awstrack.me 這類共用追蹤網域會帶來兩個問題。第一，寄件網域與連結網域不一致 (Domain Mismatch)，這在釣魚郵件的特徵比對中屬於扣分項。第二，該共用網域的信譽分數由所有 AWS SES 用戶共同承擔。若其他不良寄件者利用此網域發送垃圾郵件，將連帶拖累你的信件送達率。
即使在 AWS SES 中配置了自訂追蹤網域 (圖五)，預設狀態下產生的連結依然是 HTTP 格式。要在 AWS 基礎設施中實現 HTTPS 的自訂追蹤網域，必須串接 Amazon CloudFront 與 API Gateway，將請求透過 HTTPS 接收後再轉發至 SES 的追蹤節點。架構複雜度高，維護成本也隨之增加。
如果您尚未完成 AWS 基礎環境的建置，請先參考我們的 Amazon SES 申請與配置教學。
HTTP 追蹤連結觸發垃圾郵件過濾器的機制
未加密的 HTTP 連結在現代網路環境中已被視為高風險特徵。垃圾郵件過濾器在評分時，會將信件內的 URL 結構納入計算模型。
當過濾器掃描到 http:// 開頭的追蹤連結，會產生以下負面影響：
- 觸發網路釣魚警告：多數郵件客戶端 (如 Gmail、Outlook) 會對 HTTP 連結提出安全警告。若連結被隱藏在按鈕或不一致的錨點文字下，過濾器會將其判定為具備欺騙意圖。
- 混合內容問題 (Mixed Content)：若收件人在強制使用 HTTPS 的網頁版郵件客戶端中點擊 HTTP 連結，瀏覽器可能會阻擋該次跳轉，導致點擊數據遺失，並破壞使用者體驗。
- 信譽評級下降：ISP (網際網路服務供應商) 傾向信任全面採用加密傳輸的寄件者。信件內部充滿未加密連結，將直接降低網域整體的發信信譽 (Sender Reputation)。
SureContact 實戰：建構純淨的 HTTPS 自訂追蹤網域
為了解決 ESP 預設配置帶來的送達率瓶頸，Quants Note 導入了 SureContact 進行郵件自動化與會員管理。
SureContact 在系統設計上大幅簡化了自訂追蹤網域的部署門檻。根據後台配置要求 (圖六)，管理者只需在網域 DNS 託管商 (例如 Cloudflare) 新增一筆 CNAME 紀錄，將專屬的追蹤子網域 (如 link.quantsnote.com) 指向 SureContact 的伺服器節點。
圖七呈現了改用 SureContact 發送後的連結狀態。
在實務配置上需特別注意一個技術細節：若您的 DNS 是交由 Cloudflare 託管，設定 CNAME 紀錄時必須關閉 Proxy 代理功能 (保持「僅限 DNS / 灰色雲」狀態)。 若開啟 CDN 代理 (橘色雲)，Cloudflare 的邊緣節點會攔截流量，導致 SureContact 底層的自動化憑證簽發機制 (如 Let’s Encrypt 的 HTTP-01 驗證) 無法確認網域指向。在灰色雲狀態下，流量直達端點，SureContact 系統才能順利通過驗證，並在他們的伺服器上為該追蹤網域自動核發與配置 SSL 憑證。
(註：使用者若有開啟 Cloudflare 的憑證透明度監控，後續收到的憑證核發通知信，僅是 Cloudflare 針對公開日誌的「監測回報」，實際提供 HTTPS 加密連線的仍是 SureContact 端。)
完成這項一次性設定後，檢視系統實際輸出的連結結構，網址具備高度的品牌一致性，且通訊協定強制採用 https://。這種乾淨、加密且與寄件人網域完全對齊的追蹤連結，能順利通過 SpamAssassin 等防護系統的 URL 規則檢查。此架構有效避開了共用網域的信譽風險，同時消除了 HTTP 連結帶來的資安疑慮，從根本上提升了行銷郵件進入主要收件匣 (Primary Inbox) 的機率。
結論與系統配置建議
行銷郵件的技術架構不僅止於 DNS 紀錄的設定。信件內部的連結結構同樣受過濾器嚴格審查。AWS SES 與 SendGrid 在預設狀態下產生的 HTTP 追蹤連結，容易觸發釣魚防護機制並影響送達率。
確保網域信譽與送達率的最佳實踐，是強制所有點擊追蹤連結皆具備 HTTPS 加密，並使用專屬的自訂網域。這要求企業具備設定反向代理與自動展延 SSL 憑證的維運能力。若希望降低架構維護成本並直接獲得完整的 HTTPS 追蹤配置，採用原生支援此功能的郵件自動化系統會是較具效益的選擇。
若您正在尋找能妥善處理自訂網域與 HTTPS 追蹤連結的系統，建議可參考我們目前使用的解決方案：立即探索 SureContact 功能與配置
