HubSpot行銷電子郵件和銷售人員的連線信箱是不同的寄送排程。首先確定您正在配置的工作流程。驗證行銷發送網域並不會建立與 CRM 關聯的每個訊息的狀態。
本指南涉及用於HubSpot行銷電子郵件的電子郵件發送網域。在進行變更之前記錄相關帳戶、寄件者網域及其企業擁有者。
選擇適合工作流程的網域
選擇名稱之前，請閱讀目前的網域資格指南。 HubSpot目前的说明规定，电子邮件发送域不得已用于其他目的，例如托管内容。合適的子域可以使該路由保持獨特，但它仍然需要明確的所有者和經過測試的配置。
根據建議的發送網域連線檢查行銷寄件者地址中使用的確切網域。看起來與品牌相似的新名稱對於實際活動來說仍然可能是錯誤的名稱。
映射網域或子網域的其他用途：託管內容、接收郵件、重新導向、另一個HubSpot帳戶和外部服務。在接受產生的DNS更改之前解決衝突。
將產生的DNS請求作為更改集進行查看
使用目前的電子郵件傳送連線工作流程以及為帳戶產生的值。 HubSpot的指南涵盖MX 、 DKIM, SPF 和 DMARC，其詳細資訊必須在其指定的所有者名稱處進行檢查。
請勿移動機構正常信箱 MX記錄 只因為寄件者工作流程顯示MX要求。在產生的請求中確定確切的名稱和用途。特定於子域的變更和根域變更會產生不同的後果。
對於SPF ，檢查正在變更的確切名稱處的現有策略。如果已經存在，請將所需的授權調整到該策略中，而不是在那裡建立第二個SPF策略。將授權機制置於終止所有機制之前，並確保結果評估保持有效並在依賴 DNS 的查找限制內。
將DMARC視為網域所有者的策略決策。保留現有的合適策略和報告配置。行銷設定不應重置對不相關郵件的控制。
檢查DNS如何發布數值
辨識活躍的權威主機，而不是依賴註冊商的名稱。發布後比較完整的結果擁有者名稱和值。
HubSpot特別提到了Cloudflare代理和網域範圍的 CNAME 扁平化設定。遵循目前支援的身份驗證記錄要求，並單獨評估任何更廣泛的DNS變更。不要僅僅為了清除電子郵件設定警告而更改不相關的網站行為。
對於自動連接，請檢查變更並記錄實際寫入的內容。對於手動連接，請檢查後綴處理和記錄類型衝突。兩條路徑都需要可觀察到的公開答案。
驗證實際的行銷訊息
完成HubSpot的身份验证检查，然后通过预期路由发送适当的受控活动测试。保留原始收到的訊息、帳戶上下文和發送時間。
检查可见的发件人、信封身份、 DKIM签名域和可信接收者结果。記錄 結盟 支援DMARC路徑。傳遞不相關服務域的簽章本身是不夠的。
在綜合案例中， DNS團隊成功連接了行銷子網域，但活動仍然使用舊的根網域寄件者位址。配置和訊息描述不同的身份。修正預期的寄件者配置，然後重複活動路由測試，而不是在每個看似合理的名稱中新增記錄。
不要將一項測試推廣到每個連接的郵箱、事務路由或整合服務。測試與此變更範圍相關的工作流程。
保留有用的完成記錄
切换应识别帐户、选择的发送域、生成的记录、 DNS更改所有者和经过验证的消息。包括選擇該網域以及使用該網域的任何其他帳戶的原因。
當行銷活動所有權發生變更或引入新的子網域時，請檢查配置。保留舊的依賴項直到驗證停用為止，而不是在新活動成功後立即刪除它們。
使用寄件者庫存將行銷所有權與更廣泛的郵件計劃連結起來。身分驗證建立身分路徑；聯絡收件者的權限、清單品質和收件匣放置仍然是不同的事項。
將寄件者更正與策略變更分開
书面案例 HS-01 假设营销帐户已连接news.example.com ，而计划的营销活动发件人为updates@example.com 。假设的可信消息结果是DKIM传递，其中d=news.example.com, s=demo1.该签名可以在普通宽松的组织域对齐下对齐，但与adkim=s. SPF和所有其他签名仍然未知，因此不要报告整体严格模式DMARC故障。行銷負責人必須確認預期的寄件者和匹配的產品連接，然後取得授權的行銷活動樣本；更改網域範圍的策略不是此處建議的修復。 example.com上的普通员工邮箱MX仍然不受此更改的影响。未测试HubSpot帐户、邮箱或DNS 。
使用產生的記錄所有者和值，而不是將故障排除範例轉變為通用選擇器。 HubSpot目前会在存在策略时记录配对的DKIM CNAME 和SPF合并。它的狀態標籤描述了設定檢查；即使經過完全驗證的標籤也不能證明此計劃的活動選擇了正確的寄件者身份。
保留執行邊界
RFC 9989 第 7.4 節要求有效的DKIM ，而不僅僅是SPF來進行域發布 p=reject，並對間接郵件和郵件清單互通性發出警告。一次成功的直接訊息測試並不能證明每條合法路線都已準備好採取更強有力的政策。保留現有批准的保護，同時診斷實際差距；任何政策變化都需要自己的決定。