[ 寄送服務指南 ]

驗證透過 Campaign Monitor 發送的電子郵件:設定和驗證

驗證確切的行銷活動監控發送網域,保留目前策略,並將DKIM對齊與可選的SPF授權區分開來。

由EmailAuth研究團隊提供 · 4 分鐘閱讀

[ 重點 ]

  • 驗證確切的行銷活動監控發送網域,保留目前策略,並將DKIM對齊與可選的SPF授權區分開來。
  • 產品中未配置的子網域不會自動導致協定對齊失敗。
在此頁面上

Campaign Monitor 透過帳戶設定、公用DNS和驗證檢查來驗證傳送網域。使用將出現在寄件者位址中的確切網域,包括其子網域。這是特定於寄件者的配置:對 Campaign Monitor 進行身份驗證不會對碰巧使用相同品牌網域的其他服務進行身份驗證。

建立身分並更改所有者

確認組織控制目標域並且DNS運營商可以更改其權威區域。保存現有的 選擇器, SPF 和 DMARC記錄。在接受任何建議的策略替換之前,先確定其他合法寄件者。讓配置活動的人員和發布DNS的人員在整個網域上保持一致,而不僅僅是郵件等簡短標籤。

這 發送網域指南 說驗證二級域不會驗證其在平台中的子域。如果行銷活動使用news.example.com ,請新增該確切的網域,而不是假設example.com涵蓋帳戶設定。

配置域和產生的金鑰

開啟設定檔選單、帳戶設置,然後開啟發送網域。選擇設定發送域或新增網域,輸入完整域並繼續。使用編輯器的正確全名或相對名稱約定,在權威DNS上發布產生的TXT名稱和值。返回行銷活動監視器並選擇我已新增記錄,或如果稍後返回則重新檢查記錄。

為此設定使用新產生的金鑰,而不是為了方便而匯入現有的私鑰。將私人簽名材料保留在DNS 、票證和共享工作表之外。如果產生的選擇器與另一個活動記錄發生衝突,請在替換之前解決衝突。公開範例不是您帳戶的金鑰。

保留DMARC並仔細調和SPF

記錄的工作流程接受現有的有效 DMARC 配置。保留其執行政策和報告目標,除非網域擁有者批准單獨的變更。如果沒有適用的政策,請在正確的所有者處制定政策。一個 p=none 例如,這是一個監控請求,而不是強制執行,也不是削弱從父級繼承的策略的理由。

Campaign Monitor 建議使用include:_spf.createsend.com.進行可選的SPF授權。如果該授權適合您的配置,請將其合併到單一現有SPF原則中,而不是新增第二個政策。保留其他合法寄件者並根據SPF的查找限制檢查評估的依賴路徑。提供者的 電子郵件身份驗證概述 提供上下文,但接收到的信封決定接收器實際檢查的域。

服務自有信封的SPF通行證不一定與您可見的寄件者一致。一個傳球對齊 DKIM簽名 即使SPF路徑未對齊,也可以滿足DMARC 。不承諾嚴格的SPF 結盟 僅僅因為包含被添加到 From 域的 TXT記錄.

活動測試前驗證記錄

在每個權威伺服器上查詢產生的選擇器,然後檢查適用的DMARC和SPF答案。記錄完整的擁有者、類型、值和時間戳記。 DNS編輯器可以將長TXT值拆分為一筆記錄中的字串;與發布多個不同 DKIM 記錄。依照DNS提供者的處理方式,比較重建後的值。

如果 Campaign Monitor 無法驗證,請檢查是否存在重複的網域後綴、錯誤的記錄類型、遺漏的關鍵字元以及權威伺服器不一致。 TTL 是一種快取控制,而不是每個驗證器更新的保證時間。快取的否定答案可以比建立新記錄的那一刻更持久。

確認真正的行銷活動使用預期的網域

使用新驗證的寄件者地址發送受控測試活動。保留值得信賴的 Authentication-Results, 從, Return-Path 以及所有DKIM d=/s=對。確認傳遞的簽章與設定模式下的 From 域一致。如果測試通過,但後續活動失敗,請在修改DNS之前比較寄件者地址和路由。

說明性案例: example.com已配置,但行銷活動使用news.example.com ,但從未將其新增至帳戶。修正實際活動身分的網域設定;不要取代有效的父域金鑰來解決不同身分的設定。

在可行的情況下,保留先前的工作寄件者直至接受。在帳戶變更、新的傳送子網域、 DNS遷移或金鑰輪替後重新檢查。在停用之前,停止計劃的活動並確認不再使用依賴項。本文是一份文件指南和擬議的驗證計劃,而不是即時 Campaign Monitor 測試或保證交付的證據。

不要將產品範圍差距與嚴格一致性混為一談

書面案例 CM-01 假設產品已配置example.com ,但行銷活動 From 為news@news.example.com 。單獨規定一個可信傳遞的DKIM簽章d=example.com, s=demo1.透過普通的寬鬆組織域對齊,該簽章可以與news.example.com對齊;與adkim=s不完全匹配。 SPF和其他簽名未知,因此嚴格模式的總體結論尚未解決,而不是既定的DMARC故障。這兩個前提都不能證明 Campaign Monitor 已配置預期的子域。活動擁有者應完成精確域設定並在發布之前檢查產生的受控活動。這些都是虛構的輸入,不是捕捉的交付或放鬆政策的理由。

保留執行邊界

RFC 9989 對於發布p=reject,第 7.4 節要求有效的DKIM而不僅僅是SPF ,並就間接郵件和郵件清單互通性發出警告。一次成功的直接訊息測試並不能證明每條合法路線都已準備好採取更強有力的政策。保留現有批准的保護,同時診斷實際差距;任何政策變化都需要自己的決定。

[ 外帶 ]

產品中未配置的子網域不會自動導致協定對齊失敗。

[ 按角色 ]

這對您意味著什麼

選擇您的角色以執行後續實際步驟。

IT/郵件管理員

驗證實際路線

比較產生的TXT 、帳戶狀態和真實簽名身份,而不僅僅是DNS存在。

後續步驟

  1. 單獨配置每個預期的子網域。
  2. 檢查產生的TXT和真實的DKIM d=身份。
  3. 發送網域或 DNS 提供者變更後重新測試。

CISO / SecOps

控制授權邊界

避免不必要的私鑰匯入並保持網域範圍內的授權變更可審核。

後續步驟

  1. 優先選擇新密鑰而不是不必要的私鑰導入。
  2. 審核其他寄件者的SPF變更並尋找依賴關係。
  3. 保留批准的恢復和供應商退役決定。

創辦人/非技術人員

擁有發送決定權

在安排主要版本之前,需要使用來自網域的確切活動進行測試。

後續步驟

  1. 批准來自網域的確切行銷活動。
  2. 保留先前的工作發送者,直到新路由通過接受。
  3. 啟動前需要受控訊息接受記錄。

[ 常見問題解答 ]

常見問題

example.com進行身份驗證是否會在 Campaign Monitor 中配置news.example.com ?

不可以。產品指南需要準確的發送網域,包括每個預期的子網域。

設定螢幕在哪裡?

開啟設定檔選單、帳戶設置,然後開啟發送網域。

我可以重複使用舊的私鑰嗎?

該產品提供現有詳細資訊路徑,但產生新金鑰可以避免不必要的私鑰處理和共享金鑰相依性。

我應該涵蓋有效的DMARC策略嗎?

否。保留它,除非網域擁有者批准單獨的策略變更。

Campaign Monitor 記錄了哪些SPF授權?

建議include:_spf.createsend.com.僅在檢查其他寄件者和尋找依賴關係後將其新增至適當的單一策略。

這包括保證SPF一致性嗎?

不可以。評估的包絡域必須與可見的 From 對齊;僅DNS授權不會選擇該身分。

複查記錄證明什麼?

這是配置檢查。仍需要受控接收的訊息來驗證實際的活動路線。

為什麼要讓之前的寄件者保持可用狀態?

如果新配置失敗,它會提供受控復原選項,而無需變更不相關的網域策略。

[ 來源 ]

來源

  1. Campaign Monitor 傳送網域身份驗證

    部分 必要:設定發送域 · 必要:新增DMARC記錄 · 建議:新增SPF記錄

  2. 活動監控電子郵件身份驗證

    部分 SPF · DKIM · DMARC

  3. RFC 7208 SPF

    部分 §2.4 · §2.6.5 · §3.2 · §3.3 · §4.6.4

  4. RFC 6376 DKIM

    部分 §3.4 · §3.5 · §3.6 · §3.7 · §6.1 · §6.3

  5. RFC 9989 DMARC

    部分 §4.4 · §5.3.5 · §5.4 · §7.4 · §8

  6. RFC 2308 DNS負緩存

    部分 §5 快取否定答案

[ 詞彙表 ]

詞彙表

結盟
傳遞身分驗證網域與DMARC的可見寄件人域之間所需的關係。
選擇器
與簽章域一起使用的DKIM標籤在DNS中尋找其公鑰。
權威DNS
負責發布相關區域記錄的名稱伺服器服務。
Return-Path
SMTP反向路徑的接收訊息追蹤在調查信封身分時很有用。

企業出處

為什麼頂級金融機構和政府 退役了他們的電子郵件安全儀表板。

傳統的電子郵件驗證平台會向您出售儀表板並要求您的工程師來完成這項工作。在高風險環境中,手動監督意味著延遲執行、配置漂移和不受監控的影子域。

EmailAuth是代理電子郵件來源平台。 我們的代理人強制執行 p=reject,保持第三方寄件者一致並將您的網域移至完整狀態 RFC 9989 合規性、新的DMARC標準,以及人機互動審核能力。

政府 大型企業 一級金融機構

SaaS · 專用租賃 · 氣隙本地部署 · BYOK 加密

知識庫