[ 寄送服務指南 ]

為您的活動使用的寄件者驗證 eSputnik

圍繞其配置方法、選定的寄件者和實際簽名條件規劃 eSputnik 域身份驗證,同時保護傳入的郵件。

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

[ 重點 ]

  • 將可見發送域與任何技術子域分開。
  • 在批准產生的DNS更改之前檢查現有郵箱路由。
  • 將網域驗證、寄件者確認和觀察到的訊息對齊視為單獨的證據。
在此頁面上

配置方法前選擇發送身份

eSputnik 身分驗證專案從讀者將看到的地址開始。主域時事通訊、促銷子網域和技術子網域可以屬於同一家企業,但服務於不同的目的。混淆這些目的可能會產生一個看似完整的DNS工作表,該工作表授權錯誤的發送路由。從指定的活動、其預期寄件者地址以及負責回覆和傳送失敗的人員開始審核。

本指南涵蓋了目前可存取的 eSputnik 文件中的電子郵件網域和寄件者工作流程。它沒有確定特定帳戶支援什麼或其訊息今天是如何簽署的。將每個產生的記錄、帳戶狀態和訊息結果視為仍有待取得的證據。成功的規劃審查是允許準備有限的變更,而不是變更已經發生的證據。

區分完整域、完整+域和子域

官方 網域配置指南 透過設定、網域驗證和新網域提供完整、完整+和子網域方法。完整包括退回地址轉送。 Full+ 使用未使用的技術子域。子網域支援專用的傳送子網域。選擇的方法決定了帳戶產生的記錄集;複製其名稱、類型和數據,而不是從不相關的範例中組裝值。

該指南將可見發送域與技術子域區分開來。驗證父域不會自動驗證「寄件者」子網域。每個發送域都需要有自己的入口,同一個網域的跨帳戶使用需要匹配配置,包括技術子域。這些是產品要求,獨立於 DMARC的協定定義 結盟.

在選擇方法之前,記下哪個名稱滿足每個目的以及另一個系統是否已經依賴它。請勿僅根據「行銷領域」標籤批准變更。此標籤可能表示可見的寄件者網域、追蹤主機或技術郵件處理名稱,每個名稱都有不同的後果。

準備DNS時保護傳入郵件

電子衛星公司 故障排除指南 關於更換普通郵箱提供者的警告 MX記錄 與平台的技術配置。它還將錯誤的記錄類型、重複的網域後綴以及放置在錯誤區域的記錄識別為驗證問題。在提議發布之前,將預期的完整DNS所有者與編輯的條目約定進行比較。

明確郵件路由審查。技術子網域可以適合平台處理,而主網域必須繼續在其他地方接收員工和客戶郵件。保留現有配置並確定受每個建議差異影響的業務流程。退回轉發安排也需要經過批准的收件者和資料共享範圍;這份手稿沒有提供創作目的或授權。

對於失敗的驗證,請將帳戶請求的值和觀察到的公開答案儲存為單獨的證據。在再次更改任何內容之前,確定差異是否為所有者名稱錯誤、缺失值或不完整的觀察結果。只有當已知已發布的更改正確時,等待才有用;它無法修復 一個記錄 提交到錯誤的區域。

確認訊息使用的寄件者

這 寄件者指南 描述了透過「設定」、「寄件者」、「電子郵件」新增現有公司地址並確認發送給該地址的電子郵件。這不會建立郵箱。所選寄件者屬於每封郵件,因此僅檢查帳戶清單不足以為活動做好準備。也要檢查預期的訊息配置。

動態寄件者的使用值得單獨審查,因為提供者要求新增並確認替換地址。對一個寄件者的成功測試無法為工作流程可能選擇的每個位址建立就緒狀態。記錄核准的寄件者群體,並在人員、網域或工作流程變更時指派專人維護。

評估預期發送條件下的簽名

這 身份驗證和聲譽常見問題解答 描述了一個 熱身 使用客戶簽署的訊息的限制 DKIM 領域。其他訊息可能使用平台簽章域,其行為取決於DMARC策略。因此,不應將經過驗證的網域徽章或一個簽名樣本推斷為大型活動中的每個訊息。取得目前帳戶限額並在釋放前查看預期交易量。

保持協議結論準確。 RFC 6376第 3.5 節 定義簽名字段,包括簽名域和 選擇器。有效簽名涵蓋其指定規則下的簽名材料;它不證明每個顯示的欄位或寄件者的商業可信度。 RFC 7208第 2.4 節 評估SMTP身份,而不是可見的寄件者地址本身。

RFC 9989第 4.4 節 透過對齊將身份驗證與作者網域連結。一種合格的對齊傳遞機制可以滿足DMARC要求。平台域簽章本身並不能建立客戶域一致性。記錄 SPF 首先確定每個DKIM結果,然後確定對齊方式,而不是將多個綠色指示器視為可互換的。

在批准發送之前定義證據

建議的接收記錄應標明帳戶、方式、確切的發送者、工作流程和相關發送條件。經過單獨授權的配置和測試後,它應該將權威的DNS觀察結果連結到透過實際 eSputnik 路由接收的受控訊息。擷取可見的寄件者網域、信封身分、每個DKIM網域和選擇器以及可信任接收者的結果。清楚標示不可用的觀察結果。

使用無害的測試內容和經批准的接收者。限制對原始標頭和訊息範例的訪問,並僅保留審閱者需要的內容。在驗收計畫中包含郵箱路由檢查,以便身分驗證工作不會悄悄中斷回覆。這份手稿既沒有進行檢查也沒有進行競選測試。

虛構評論和剩餘的門

在虛構零售商的計畫中,建議主 From 網域使用 Full+,但後來的促銷訊息使用不同的 From 子網域,沒有自己的驗證條目。審閱者發現了不匹配的地方並保留了計劃。沒有更改記錄,也沒有發送訊息;該範例展示了規劃決策,而不是觀察到的提供者失敗。

確切的要求仍然懸而未決:目前的 eSputnik 第一方設定證據以及來自確切產品和路線的接收訊息識別表。調試門是: 確認目前產品身分和提供者擁有的文件;測試真實的訊息或發布的記錄。誠實地說明不受支援的自訂網域功能。文獻研究支持了這個有限的草案;租戶適用性、原始測試、SME 審查、即時視覺審查、業主發布和發布批准仍然懸而未決。

[ 外帶 ]

驗證確切的發送域和訊息發送者,然後從預期路由和發送條件中收集證據。

[ 按角色 ]

這對您意味著什麼

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

活動所有者

識別工作流程可能選擇的每個寄件者

訊息等級選擇可能與首次通過設定審核的網域不同。

後續步驟

  1. 列出確切的寄件者域和動態寄件者群體。
  2. 將未經驗證的地址排除在建議的發布範圍之外。

郵件和DNS管理員

將技術路由與信箱傳送分開

狹義的身份驗證變更不應重定向不相關的商業郵件。

後續步驟

  1. 確定每個提議的DNS所有者的當前消費者。
  2. 需要定義的恢復條件和批准的轉送目的地(如果適用)。

認證審核員

記錄結論前的觀察結果

規劃期望無法建立所接收訊息所使用的身份。

後續步驟

  1. 記錄帳戶限制和每個授權樣本所代表的條件。
  2. 保持缺失的身份和接收者結果欄位明確不可用。

[ 常見問題解答 ]

常見問題

驗證主域是否涵蓋每個 From 子域?

不需要。 eSputnik 要求每個發送域都有自己的驗證條目。

同一網域可以在兩個帳戶中使用不同的技術子網域嗎?

記錄的跨帳戶安排需要匹配配置,包括技術子網域。

網域驗證警告是否應該觸發替換正常郵箱MX記錄?

否。在批准任何MX變更之前,請將技術路由與現有郵箱傳送分開。

新增寄件者會建立其郵箱嗎?

不需要。新增現有的公司地址並完成提供者的寄件者確認。

動態寄件者可以選擇從未確認過的地址嗎?

記錄的工作流程需要事先新增並確認替換的寄件者地址。

一個客戶簽名的樣本能否證明整個活動都會使用該簽名?

不會。記錄的預熱行為可能會因簽章限制和DMARC政策而異。

有效的平台簽章是否能夠單獨為企業建立DMARC一致性?

否。根據適用的對齊規則,將透過身份驗證的網域與作者網域進行比較。

如果目前帳戶與記錄的工作流程不同會發生什麼?

暫停受影響的步驟,保留差異並取得特定於目前帳戶的指導。請勿使用其他帳戶的值來填補空白。

[ 來源 ]

來源

  1. eSputnik:常見問題:電子郵件身份驗證和網域信譽
  2. eSputnik:新增/更改/刪除發送者
  3. eSputnik:設定電子郵件網域驗證
  4. eSputnik:網域驗證故障排除
  5. RFC6376 :網域金鑰識別郵件簽名
  6. RFC7208 :寄件者策略框架
  7. RFC9989 :基於網域的訊息驗證、報告和一致性

[ 詞彙表 ]

詞彙表

發送網域條目
寄件者地址所使用的確切網域的 eSputnik 驗證條目。
技術子域
用於平台郵件處理的名稱,不必是可見的寄件者網域。
已確認的寄件者
將現有地址新增至 eSputnik 並透過其地址驗證工作流程進行確認。
客戶域簽章限制
使用客戶DKIM網域記錄的訊息預熱限制與通用活動身份驗證保證不同。
驗收樣品範圍
由提議的受控訊息觀察表示的帳戶、寄件者、工作流程和發送條件。

企業出處

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

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

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

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

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

知識庫