確認產品及訊息路由
SharpSpring 現在是 Constant Contact Lead Gen 和 CRM。該提供者將其視為與持續聯絡電子郵件和數位行銷不同的產品。即使帳戶、整合或計費畫面仍帶有 SharpSpring 名稱，也請使用本指南的潛在客戶發掘和 CRM 說明。 SharpSpring 品牌更名通知、產品識別和差異.
確定郵件是透過平台發送的行銷郵件還是透過同步郵箱發送的智慧型郵件。提供者將自訂郵件同步記錄為透過使用者的SMTP帳戶發送智慧郵件。此路由需要由連接的郵件服務擁有的身份驗證，而不是假設行銷網域配置涵蓋它。 自訂提供者的郵件同步，了解自訂郵件同步.
清點實例、品牌、預期寄件者域、自動範本和個人郵件路由。分配帳戶管理員和DNS擁有者。本指南重點在於平台記錄的行銷網域身份驗證，並僅將同步郵件路由作為單獨的依賴項進行檢查。請勿僅僅因為公司名稱匹配而應用其他 Constant Contact 產品的說明。
圍繞預設域限制進行規劃
提供者記錄了一個經過身份驗證的網域的預設限制 DKIM 和 SPF 每個潛在客戶發掘和 CRM 實例。網域驗證是前面的步驟，並不證明簽章已準備就緒。驗證指示使用公司電子郵件設定和發送網域區域；他們提供了一封驗證電子郵件，並指出現有的工作站點追蹤配置可以在沒有該電子郵件的情況下建立驗證。 驗證網域、驗證工作流程和預設限制.
在新增第二個品牌或變更共用設定之前，請檢查現有的經過驗證的網域。記錄哪些活動和自動化依賴它。清單中的第二個可見網域不得被視為多個網域可以在帳戶權利下同時簽署的證據。對於超出記錄預設值的任何配置，請取得提供者的書面確認。
如果計劃進行網域更改，請讓企業所有者批准受影響的寄件者身分和啟動時間。當排隊的活動仍需要較早的網域時，請避免切換活動實例。保留相關DNS擁有者的基線接收訊息和變更前匯出，以便團隊可以區分新設定和歷史工作行為。
從實例中取得託管CNAME集
目前的身份驗證頁面描述了公司電子郵件設定、網域驗證和DNS設定工具；它還保留標籤DKIM和發送網域、設定DKIM和取得我的 CNAME 設定.使用目前帳戶畫面取得其發行值。記錄的身份驗證記錄是 em、s1 和 s2 CNAME條目，連結和所有者單獨處理以用於可選的連結品牌。返回工具以驗證發布。 潛在客戶發掘和 CRM 身份驗證、入門以及設定DKIM和SPF.
保存每個完整記錄所有者和目標，包括記錄類型、TTL 以及發布該記錄的帳戶或實例。請勿從其他組織的螢幕截圖中複製目標。如果介面呈現不同的安排，請保留該證據並要求提供者確認其適用性，然後再將其轉換為舊的記錄形式。
提供者的CNAME解釋描述了金鑰管理的委託和提供者管理的輪調。其名稱欄位標識DNS所有者；資料提供目標。目標主機名稱不是要貼上到TXT中的DKIM公鑰字串。保留已發布的CNAME關係，而不是將其扁平化為複製的下游密鑰。 了解CNAME記錄、 CNAME記錄.
在不破壞現有所有者的情況下發布
在進行更改之前詢問提議的所有者。 CNAME不能簡單地與同一所有者的衝突資料一起添加。如果主機名稱已服務於另一個平台，請停止並解決與兩個服務所有者的衝突。請勿刪除正在運行的網站、追蹤服務或金鑰以強制新記錄生效。
檢查DNS編輯器是否自動附加網域。將最終完全合格的所有者和目標與已發布的對進行比較。在DNS服務提供 Web 代理模式的情況下使用僅 DNS 記錄，否則會掩蓋別名，請遵循該DNS服務的文件。使用時間戳保存權威答案和外部解析器觀察結果。
提供者的CNAME指南也討論了拒絕底線的DNS主機，並建議透過DNS提供者或適當的受支援域安排來解決該問題。刪除下劃線不是有效的解決方法：它會更改驗證者尋找的擁有者。 了解CNAME記錄、 CNAME下劃線.
透過下發的信封相關別名和接收到的訊息檢查SPF身分。避免在頂點新增通用SendGrid或 Constant Contact 來取代此設定。提供者的底層交付服務並不能使每個通用設定配方都適合此實例。如果需要獨立的SPF編輯，請在評估的擁有者保留一項策略並評估嵌套的DNS查找。 RFC 7208 ，選擇記錄和DNS查找限制.
將追蹤連結視為單獨的更改
身份驗證文章警告說，在安全網站上添加和稍後刪除連結和所有者記錄可能會破壞真實訊息連結或跟踪，並且可能需要後端支援。在啟用可選品牌之前，請與網站所有者一起查看該警告。其 cal 記錄屬於 Meetings 自訂網域配置，而非核心驗證流程。 潛在客戶開發和 CRM 身份驗證、了解CNAME記錄和有關 Cal 記錄.
當不需要時，將可選品牌保留在最小身份驗證變更之外。如果需要，請記錄網站的 HTTPS 和 HSTS 行為、建議的追蹤所有者和提供者批准的配置。瀏覽器測試和測試電子郵件預覽不足以取代點擊受控真實行銷訊息中的無害連結。
不要刪除追蹤記錄作為快速身份驗證回滾。現有電子郵件可能仍包含依賴它們的連結。與提供者協調恢復順序並保持網站路由完好無損。與DNS驗證分開記錄連結功能接受情況 DMARC 結盟 因此，一個領域的成功並不能掩蓋另一個領域的失敗。
查看DMARC以及產生的說明
設定工具可以提供DMARC指導，但網域所有者必須使其與任何現有策略和報告安排保持一致。不要因為產品演練顯示了入門價值就更換已建立的組織範圍的政策。在決定通過測試需要什麼之前，記錄相關的寄件者域、對齊模式和策略來源。
DMARC評估可見寄件者與合格SPF或DKIM通行證之間的關係。品牌返迴路徑或簽名域仍必須在適用的寬鬆或嚴格比較下進行檢查。當寄件者使用不同的確切網域時，請勿聲明與信封子網域的嚴格SPF對齊。 RFC 9989 ，識別符對齊解釋和DMARC評估.
請勿從螢幕截圖中新增任意報告地址。報告目的地應由組織批准和運營，並檢查任何所需的外部授權。更強有力的政策是涵蓋所有合法寄件者的單獨推出決策，而不是對完成某個提供者的DNS篩選的獎勵。
全文發表後測試行銷路線
使用實際行銷工作流程和預期寄件者地址運行受控發送。包括無害的內容，以及一個安全的追蹤連結（如果相關）。單獨測試自動化範本是否可以提供不同的寄件者。保留帳戶或實例識別碼、活動識別碼、訊息 ID 和 UTC 時間。
擷取接收者的可信任身分驗證結果和原始標頭。記錄可見的寄件者、經過驗證的信封網域， Return-Path 每個DKIM d= 和 s= 值。這 選擇器 簽章域決定金鑰查找；在診斷關鍵問題時，請遵循已發佈的CNAME的驗證資料。 RFC 6376 ， DKIM-Signature標頭欄位和從訊息中提取簽名.
記錄哪個機制提供對齊的通道。提供者驗證、成功交付和明顯的簽名標籤都是有用的觀察結果，但沒有一個單獨證明完全接受條件。保留上下文截圖和原始接收者證據以得出技術結論。
如果智慧型郵件也在範圍內，請透過同步郵箱傳送單獨的受控訊息並識別該郵件服務的簽署者。請勿將其與行銷CNAME集進行比較，就好像它們是同一路由一樣。個人郵件的成功不能結束失敗的活動測試，反之亦然。
在輪換密鑰之前診斷故障層
如果網域所有權已驗證但DKIM尚未準備好，請檢查頒發的CNAME集及其公共解析。如果缺少預期的簽名，請檢查實際的寄件者網域和發送工作流程。如果簽章失敗，請在請求新金鑰之前調查觀察到的選擇器和下游訊息變更。
當自動化發送意外的寄件者時，請修正已核准的範本或寄件者選擇並重新測試。當連結中斷但身份驗證通過時，請在支援人員的幫助下調查連結品牌設置，而不是更改身份驗證記錄。當預設網域限制阻止所需配置時，請解決帳戶設計，而不是在沒有遷移計劃的情況下刪除工作域。
保持最少的支持證據：實例身份、受影響的域、發布的公共名稱和目標、定時DNS答案、訊息標識符和相關接收者結果。請勿傳送郵件信箱密碼、帳號 API 機密、聯絡人清單或不相關的客戶內容。
工作表和虛構路線混淆
使用 SharpSpring 和 Lead Gen CRM 工作表（使用此處描述的欄位建立單獨的審核記錄）來分離產品身分、權利、所有權驗證、 CNAME發布、可選連結和接收者測試。將個人郵件路由保留為具有自己的身份驗證擁有者的不同行。
虛構的書面案例 LG-01：假設來自alex@studio.example的智慧型郵件透過連接的郵箱發送，並傳遞d=studio.example.行銷活動旨在news@studio.example ，但其 em、s1 和 s2 發布/驗證不完整，活動驗證結果未知。行銷管理員必須完成實例頒發的CNAME檢查並收集單獨的受控行銷活動。銷售人員的結果無法關閉該路線。未存取或測試任何執行個體、郵件信箱、 DNS記錄或活動。
協調退休並僅關閉經過驗證的工作
在更改網域之前，決定如何暫停新的行銷活動並保留排隊的工作。在商定的過渡期內保留舊的選擇器和追蹤依賴項，並與提供者簽署行為和現有連結協調。網域切換、實例遷移、 DNS移動或郵件路由變更後重新測試。
文件設定可用，但尚未檢查客戶的實際帳戶權限、發布的記錄、即時DNS和接收訊息結果。獨立技術審查、目視審查和 SME 人工批准也仍在等待中。此未發布的草稿不證明收件匣放置或已完成的生產身份驗證部署。
將傳遞的訊息與執行準備分開
RFC 9989 第 7.4 節要求有效的DKIM才能進行網域發布 p=reject 並對間接郵件互通性提出警告。單一對齊的SPF結果本身並不能證明拒絕策略的推出是合理的。與此提供者設定分開審查所有合法路由和策略所有權。