將 Concep SEND 域選擇與簽章啟動分開
康塞普官方 網域選擇指南，於 2020 年 9 月 18 日更新，區分公司發送網域和子網域。它是 使用DKIM指南簽名，於 2020 年 7 月 2 日更新，描述了支援輔助金鑰和啟動工作流程。這些過時的說明提供了具體的起點，但當前產品的適用性仍然開放。本文並不聲稱當今的每個 Concep SEND 帳戶都使用相同的基礎設施或控制項。
第一個決定是活動將在其寄件者地址中使用哪個網域，以及託管連結是否需要單獨的品牌名稱。網域指南稱，公司網域和子網域都可以用於發送，而只有子網域可以在其記錄的安排中託管活動連結。如果沒有該子網域選擇，連結將託管在emailcc.com上。不要將成功的品牌連結視為寄件者網域已通過身份驗證的證據。
準備一份包含預期發送網域、連結網域、帳戶和負責的DNS管理員的清單。在提交之前確定提議的名稱的現有用途。與員工郵件或其他行銷系統共用的網域需要協調；不應僅僅因為活動擁有者可以編輯寄件者地址而重新配置它。本稿件未存取任何帳戶或DNS設定。
查看歷史子網域和公司網域說明
對於子網域的安排，2020 年指南指定了 CNAME 指向emailcc.com 。對於公司發送域，它指定 SPF 使用include:emailcc.com.保留區別，而不是將子域別名放置在組織的區域頂點或假設相同的記錄用於這兩個目的。在進行生產變更之前確認目前提供者發布的配置。 Conceptp 網域選擇指南
該指南有關附加完整SPF範例的措詞不應從字面上理解為連接兩個v=spf1策略的指示。在下面 RFC 7208 ，第 3.2 節，一個網域不得發布導致選擇多個SPF策略的多筆記錄。將核准的授權合併到現有策略中並保留其他合法寄件者。請勿插入第二個版本標記或默默地替換終端限定符。
CNAME所有者還需要進行衝突審查。建議的記錄不允許覆蓋現有的郵件、網站或驗證相依性。記錄完整的擁有者和目標，並將它們與DNS編輯器的命名約定進行比較。如果在不檢查其解釋的情況下複製輸入，則附加區域名稱的編輯器可能會產生意外的重複後綴。
請求DKIM之前確認發送域
這 DKIM 指南指出，在DKIM請求之前，必須已使用 Concep 設定子網域或公司網域。然後，支援人員與 IT 部門協調產生金鑰，客戶的DNS團隊將其作為金鑰發布 TXT記錄。該文章不提供可重複使用的 選擇器 或所有客戶的公鑰。使用預期網域的實際提供的擁有者和值，並將請求引用附加到該變更。 Concep 與DKIM簽約
明智的建議切換會識別發送網域、帳戶範圍、 DNS運營商和預期完成證據。它不需要包括活動收件人、機密內容或憑證。發送支援請求是一種外部通信，需要經過授權的操作員；本指南既不建立票證也不暗示已提交票證。在得到確認之前，網域目前是否符合記錄流程的資格仍懸而未決。
在發布之前查看請求的選擇器中的現有資料。較舊的金鑰可能仍可服務於活躍流量，更換可能需要協調。公用DNS金鑰不是對提供者私有簽章金鑰的請求。保持明確的區別，以便支援移交不會成為不必要的憑證共享或簽名責任中未經審查的變更。
保留提供者端啟動步驟
儲存TXT記錄時，歷史DKIM工作流程不會結束。它說客戶在發布後通知支援人員； Concep 驗證傳播並將相關帳戶切換到其專用的DKIM郵件伺服器安排。然後它描述了來自帳戶的提供者測試訊息以及dkim=pass.將此視為記錄的序列，而不是任何當前帳戶已完成這些操作的證據。 Concep 與DKIM簽約
記錄提供者完成確認與DNS發布分開。這種區別很重要，因為正確發布的金鑰不能導致不相關的發送系統用它進行簽署。如果提供者表示目前的工作流程有所不同，請根據該帳戶特定的證據更新實施計劃，而不是將歷史順序強加到新的產品版本上。不要發明引用的工作流程未記錄的啟用簽署控制項。
提供者的測試描述建立了有用的DKIM檢查點，但單獨dkim=pass並不能證明 結盟 與活動的可見作者域。 RFC 6376 ，第 3.5 節 標識簽名的 d= 簽名域和 s= 選擇器。透過授權證據流程捕獲這些值並將它們與批准的配置相關聯。屬於另一個服務身分的成功簽名是不同的結果。
檢查實際路由上的SPF和DMARC
SPF評估SMTP身份，而不僅僅是活動編輯器顯示的位址。 RFC 7208 ，第 2.4 節 描述了 郵件來自 身份，而第 4.6.4 節對評估的 DNS 相關術語設定了限制。查看實際的信封域和完整的策略，包括巢狀依賴項。可見的包含字串既不能證明接收者使用該策略，也不能證明完整的評估預算評估。
RFC 9989 ，第 4.4 節 新增作者網域和傳遞的經過身份驗證的身份之間的對齊。透過對齊的SPF或透過對齊的DKIM可以滿足該身份驗證條件。不要聲稱 Concep 的歷史提供者測試會關閉所有 DMARC 要求或多品牌帳戶中的所有網域共享相同的結果。每個預期身分都需要自己的證據邊界。
來源對非垃圾郵件傳遞的廣泛保證並不能保證。身份驗證、 SMTP接受、資料夾放置和參與是不同的觀察結果。因此，沒有記錄觀看次數的活動並未被證明未經驗證或被阻止。使用實際的診斷證據並避免廣泛的收件人允許清單請求作為識別故障的替代方法。這裡沒有提出這樣的請求或測試。
虛構的診斷：已發布密鑰，未完成的提供者過渡
一個虛構的專業協會 Alder Council 從支援部門收到DKIM值，並要求其DNS團隊發布該值。變更單關閉後，活動所有者立即將項目標記為完成。後來的準備審查並沒有發現提供者端帳戶轉換或所描述的測試已經發生的確認。因此，該團隊將DNS發布記錄為虛構案例中的完整證據，但未解決發送準備問題。
建議的下一步是獲得授權提供者的確認，然後檢查無害的訊息證據以了解預期的發送者身分。並不是重複更換金鑰或假設單獨等待就會啟動簽名。此範例是虛構的：它不代表真實的票證、 DNS觀察、帳戶遷移或收到的訊息。
空白驗收工作表和發布邊界
- 註明日期的指南的當前帳戶、產品路線和適用性：______
- 發送網域與連結託管網域以及現有相依性：______
- 已批准的SPF授權合併為一項一致的政策：______
- 支援請求參考和網域設定先決條件：______
- 已頒發DKIM所有者、公共價值和DNS發布證據：______
- 提供者啟動或轉換確認：______
- 授權訊息d=, s=,信封網域和可信任結果：______
- DMARC一致性評估、剩餘例外情況和所有者決定：______
該目錄的原始實施證據、人工審查、來源適用性、生產路線、視覺可訪問性和所有者發布仍然開放。歷史公共工作流程支援該文件草案；它不建立當前租戶執行或授權發布、支援外展或DNS更改。