如果您的支援回覆落在 Gmail 的「促銷」分頁或 Outlook 的「垃圾郵件」資料夾中，罪魁禍首幾乎總是 DNS，而非您的服務台。三筆記錄 — SPF、DKIM 和 DMARC — 必須按特定順序設定，DKIM 必須正確委派給您的服務台，以便外寄郵件以您的品牌網域簽署。順序正確的話，大多數可遞送性問題會在 48 小時內消失。

重點摘要

• Gmail 和 Yahoo 在 2024 年 2 月的大量寄件者規則使 DKIM、SPF 和已發佈的 DMARC 記錄對於每天發送超過 5,000 封郵件的任何人都成為強制性的 — 他們也提高了其他所有人的標準。
• DKIM 是重頭戲：它必須以 d=yourdomain.com（而非服務台的網域）簽署，以符合 DMARC，這通常意味著 CNAME 委派兩個選擇器給您的服務台廠商。
• SPF 必須透過 include: 機制包含您的服務台寄件 IP，整個記錄必須保持在 10 個 DNS 查詢以下。
• DMARC 應從 p=none 開始進行監控，然後在您的彙總報告顯示兩週內 100% 對齐後，移至 quarantine，最後移至 reject。
• 透過向 Gmail 地址發送測試郵件並檢查原始標頭中的 dkim=pass、spf=pass 和 dmarc=pass — 全部三個 — 來驗證鏈。

為什麼支援電郵可遞送性在 2024-2025 年變得更困難

2024 年 2 月，Google 和 Yahoo 推出了相符的大量寄件者要求：SPF 和 DKIM 驗證、至少 p=none 的 DMARC 原則、行銷郵件的一鍵取消訂閱，以及垃圾郵件投訴率低於 0.3%。Microsoft 在 2025 年對 Outlook.com 和消費者 Hotmail 提供了類似指導。

觸發「大量」處理的閾值是每天向 Gmail 地址發送 5,000 封郵件，但基礎信號 — 對齐失敗、缺少 DMARC、軟 SPF — 會降低任何數量寄件者的信譽。一個 12 人代理的 SaaS 支援團隊每天發送 800 封回覆不會被速率限制，但當驗證不完整時，他們的郵件會被評分更嚴格。

修復方法不是切換服務台或支付可遞送性顧問費用。它是三筆 DNS 記錄，按順序設定，DKIM 進行實際的密碼學工作。

DKIM、SPF 和 DMARC 實際上做什麼

這三個協議解決不同的問題，DMARC 將前兩個結合在一起。

SPF（寄件者原則框架） 發佈授權從您的網域發送郵件的 IP 地址列表。接收伺服器根據此列表檢查 SMTP 信封寄件者的網域。通過意味著「此 IP 被允許為此網域發送」。

DKIM（DomainKeys 識別郵件） 使用私鑰對每封外寄郵件進行密碼學簽署。接收者從您的 DNS 獲取匹配的公鑰並驗證簽名。通過意味著「此郵件未被篡改，並由持有您私鑰的東西簽署」。

DMARC（基於網域的郵件驗證、報告和一致性） 將 SPF 和 DKIM 綁定到可見的 From: 標頭 — 用戶實際看到的。DMARC 要求 SPF 或 DKIM 中至少一個與該 From 網域 對齐。沒有 DMARC，垃圾郵件發送者可以在 mailer.spammer.com 上通過 SPF，同時在 From 行中偽造您的品牌。

對於服務台特別是，DKIM 對齐是您可以控制的槓桿。SPF 經常因對齐失敗，因為信封寄件者是您廠商的退回處理網域。DKIM，當以 d=yourbrand.com 簽署時，對齐乾淨。

分步：按順序設定三筆記錄

按順序執行此操作。在 SPF 和 DKIM 通過之前不要跳過 DMARC — 您會退回合法郵件。

1. 發佈您的 SPF 記錄。 在您的寄件網域根目錄添加單個 TXT 記錄。例如，如果您的服務台使用 Amazon SES，記錄可能是 v=spf1 include:amazonses.com -all。如果您還透過另一個提供者發送交易郵件，透過第三個發送行銷郵件，請組合它們：v=spf1 include:amazonses.com include:_spf.google.com include:mailgun.org -all。將總 DNS 查詢上限設為 10，否則 SPF 完全失敗。

2. 透過 CNAME 委派設定 DKIM。 您的服務台應該給您兩個或三個看起來像 selector1._domainkey.yourbrand.com → selector1.yourbrand.dkim.helpdeskvendor.com 的 CNAME 記錄。發佈這些。DNS 傳播後，廠商為您輪換和管理簽署金鑰 — 無需手動複製金鑰，金鑰輪換時無需重新簽署。

3. 等待 24-48 小時並驗證。 從您的服務台向您控制的 Gmail 地址發送測試回覆。打開郵件，點擊三點菜單，然後選擇「顯示原始內容」。查找三行：SPF: PASS、DKIM: 'PASS' with domain yourbrand.com 和 DMARC: 'PASS'（最後一行在第 4 步之前會缺失）。DKIM 網域必須與您的品牌網域匹配，而非廠商的。

4. 在 p=none 發佈 DMARC。 在 _dmarc.yourbrand.com 添加值為 v=DMARC1; p=none; rua=mailto:[email protected]; pct=100 的 TXT 記錄。p=none 原則意味著「暫時不拒絕任何東西，只報告」。rua 地址接收每日 XML 彙總報告。

5. 監控兩週。 使用 DMARC 報告解析器（dmarcian、Postmark 的免費工具或 Valimail）讀取這些 XML 報告。確認您所有合法來源 — 服務台、行銷平台、交易郵件、日曆邀請 — 都通過 DMARC 對齐。

6. 收緊至 p=quarantine，然後 p=reject。 一旦彙總報告在兩週內乾淨，將 p=none 更改為 p=quarantine。再等兩週，然後移至 p=reject。這是實際防止欺騙的原則 — Gmail 的大量寄件者規則對拒絕原則寄件者更有利。

為什麼 CNAME 委派 DKIM 比其他兩個更重要

SPF 和 DMARC 是您發佈一次的靜態記錄。DKIM 是大多數可遞送性問題隱藏的地方，因為金鑰需要定期輪換（NIST 建議每六到十二個月），簽署必須在發送時進行。

錯誤的方式：您的服務台以 d=helpdeskvendor.com 簽署外寄郵件。SPF 可能在廠商的網域上通過，但 DMARC 對齐失敗，因為 From 標頭說 [email protected]。結果：任何比 none 更嚴格的 DMARC 原則都會拒絕您自己的回覆。

正確的方式：CNAME 委派。您發佈指向廠商 DNS 的 CNAME，廠商在他們的一側管理私鑰，外寄郵件以 d=yourbrand.com 簽署。DMARC 看到 From 網域和 DKIM d= 網域匹配 — 對齐通過。

這就是為什麼在評估工具時服務台的 DKIM 設定模型很重要。要求您將長 DKIM 公鑰粘貼到 TXT 記錄中的廠商迫使您手動管理輪換。給您兩個 CNAME 的廠商隱藏了所有複雜性。

在您將 DMARC 翻轉至拒絕之前的驗證檢查清單

如果任何行失敗，請勿進行至 p=reject。配置錯誤的拒絕原則將阻止您自己的支援回覆和密碼重設電郵。

常見故障模式及其調試方法

症狀：回覆落在 Gmail 的垃圾郵件資料夾中，而非促銷。 幾乎總是 DKIM 對齐失敗。檢查原始標頭 — DKIM-Signature 中的 d= 值應與您的 From 網域匹配。

症狀：回覆通過 DKIM 但 DMARC 仍失敗。 SPF 失敗 且 DKIM 以錯誤的網域簽署。要麼修復 DKIM 對齐（首選），要麼將您的服務台退回處理網域添加到您的 SPF。

症狀：回覆適用於 Gmail 但對 Outlook 失敗。 Microsoft 對 SPF 和 PTR 記錄更嚴格。檢查您的服務台寄件 IP 是否具有有效的反向 DNS — 您的廠商處理此問題，但使用測試驗證。

症狀：DMARC 報告顯示神秘寄件者對齐失敗。 通常是被遺忘的行銷工具、日曆邀請轉發器或影子 IT 排程軟體。要麼將其添加到 SPF/DKIM，要麼停止透過它發送。

Helptal 如何適配

Helptal 完全透過 CNAME 委派處理 DKIM 部分。當您在支援工單中連接寄件網域時，我們生成三個 CNAME 供您粘貼到您的 DNS — 無需複製公鑰，無需記住輪換。UI 追蹤驗證狀態（待定 / 已驗證 / 失敗），以便您可以確切看到 DNS 傳播何時完成，外寄郵件從第一次發送起以 d=yourbrand.com 簽署。結合原生退回和投訴抑制，這使大多數 SMB 支援團隊無需可遞送性顧問即可達到收件匣放置。

常見問題

如果 DKIM 設定正確，我還需要 SPF 嗎？

是的。DMARC 要求 SPF 或 DKIM 中至少一個對齐，但 Gmail 和 Outlook 對同時通過兩者的寄件者比只有一個通過的寄件者更有利。SPF 在某些邊界情況下也有助於轉發郵件。發佈 SPF 需要五分鐘，沒有缺點。

DKIM CNAME 的 DNS 傳播需要多長時間？

大多數提供者（Cloudflare、Route 53、Google Cloud DNS）在幾分鐘內傳播。較慢的註冊商和 ISP 可能需要長達 48 小時。在您的服務台 UI 將寄件網域顯示為完全驗證之前，不要從 p=none 切換您的 DMARC 原則，這通常意味著在您發佈記錄後 4-24 小時。

如果我在不監控的情況下直接跳至 DMARC p=reject 會發生什麼？

您冒著阻止自己合法郵件的風險。任何對齐失敗的寄件來源 — 行銷工具、CRM、被遺忘的交易寄件者 — 將被直接拒絕。在收緊原則之前，始終在 p=none 運行兩週並啟用彙總報告。

如果我的 DKIM 和 SPF 通過，服務台的 IP 信譽重要嗎？

它的重要性不如以前，但是的。信譽良好的服務台廠商上的共享寄件 IP 通常具有強大的信譽。今天更大的風險是對齁失敗、高投訴率和不一致的寄件量 — 所有這些都由您的網域配置和內容控制，而非 IP。

我可以為行銷電郵和支援電郵使用相同的 DKIM 金鑰嗎？

技術上是的，但這是個壞主意。使用單獨的 DKIM 選擇器（例如 support 用於服務台，marketing 用於您的 ESP）。這隔離了信譽 — 觸發投訴的行銷活動不會將您的支援可遞送性拖累下去。

本週開始使用 SPF。在您的網域根目錄發佈單個 TXT 記錄，然後預訂 30 分鐘的時間窗口以添加您的服務台提供的 DKIM CNAME 和 p=none 的 DMARC 記錄。兩週的監控，隔離兩週，您將擁有一個通過 Gmail 大量寄件者標準的拒絕原則網域。如果您特別為可遞送性審計服務台工具，Helptal 的免費試用在每個計畫上都包括 CNAME 委派 DKIM 和驗證狀態追蹤。