HubSpotマーケティング電子メールと営業担当者の接続されたメールボックスは、送信方法が異なります。まず、構成しているワークフローを特定することから始めます。マーケティング送信ドメインを認証しても、CRM に関連付けられたすべてのメッセージの状態が確立されるわけではありません。
このガイドは、 HubSpotマーケティング電子メールに使用される電子メール送信ドメインに関するものです。変更を加える前に、関連するアカウント、From ドメイン、およびそのビジネス所有者を記録します。
ワークフローに合ったドメインを選択してください
名前を選択する前に、現在のドメイン資格に関するガイダンスをお読みください。 HubSpotの現在の指示では、電子メール送信ドメインがコンテンツのホスティングなどの別の目的ですでに使用されていてはいけないとされています。適切なサブドメインはこのルートを明確に保つことができますが、それでも明示的な所有者とテスト済みの構成が必要です。
提案された送信ドメイン接続に対して、マーケティングの差出人アドレスで使用されている正確なドメインを確認してください。ブランドに似た新しい名前でも、実際のキャンペーンでは間違った名前になる可能性があります。
ドメインまたはサブドメインのその他の用途 (ホストされたコンテンツ、メールの受信、リダイレクト、別のHubSpotアカウント、外部サービス) をマッピングします。生成されたDNS変更を受け入れる前に競合を解決してください。
生成されたDNSリクエストを変更セットとして確認します。
現在の電子メール送信接続ワークフローと、アカウントに対して生成された値を使用します。 HubSpotのガイダンスはMXをカバーしています。 DKIM, SPF そして DMARC、指定された所有者名で確認する必要がある詳細が含まれています。
組織の通常のメールボックスを移動しないでください MXレコード 単に送信者のワークフローにMX要件が表示されるからです。生成されたリクエストで正確な名前と目的を確立します。サブドメイン固有の変更とルートドメインの変更では、異なる結果が生じます。
SPFの場合は、変更される正確な名前で既存のポリシーを検査します。すでに存在する場合は、そこに 2 番目のSPFポリシーを作成するのではなく、必要な承認をそのポリシーに調整します。すべてのメカニズムを終了する前に承認メカニズムを配置し、結果の評価が有効であり、DNS に依存する参照制限内にあることを確認します。
DMARCドメイン所有者のポリシー決定として扱います。既存の適切なポリシーとレポート構成を保持します。マーケティング設定では、無関係なメールの制御をリセットしないでください。
DNS値を公開する方法を確認する
レジストラの名前に依存するのではなく、アクティブな権限のあるホストを特定します。公開後に、結果として得られる完全な所有者名と値を比較します。
HubSpot 、特にCloudflareプロキシとドメイン全体の CNAME フラット化設定を呼び出します。認証レコードに関して現在サポートされている要件に従い、より広範なDNS変更を個別に評価します。電子メール設定の警告を消すためだけに、無関係な Web サイトの動作を変更しないでください。
自動接続の場合は、変更を確認し、実際に書き込まれた内容を記録します。手動接続の場合は、サフィックスの処理とレコード タイプの競合を確認してください。どちらの道にも、観察可能な公開の回答が必要です。
実際のマーケティングメッセージを確認する
HubSpotの認証チェックを完了し、目的のルートを通じて適切に制御されたキャンペーン テストを送信します。元の受信メッセージ、アカウントのコンテキスト、送信時刻を保持します。
表示される From、エンベロープ ID、 DKIM署名ドメイン、および信頼できる受信者の結果を検査します。記録する アライメント DMARCをサポートするパス。無関係なサービス ドメインの署名を渡すだけでは十分ではありません。
合成の場合、 DNSチームはマーケティング サブドメインへの接続に成功しましたが、キャンペーンでは依然として古いルートドメインの From アドレスが使用されています。設定とメッセージは異なる ID を表します。意図した送信者の構成を修正してから、考えられるすべての名前にレコードを追加するのではなく、キャンペーン ルート テストを繰り返します。
接続されているすべてのメールボックス、トランザクション ルート、または統合サービスに対して 1 つのテストを一般化しないでください。この変更の範囲に重要なワークフローをテストします。
有用な完了記録を保存する
ハンドオーバーでは、アカウント、選択された送信ドメイン、生成されたレコード、 DNS変更所有者、および検証されたメッセージを識別する必要があります。ドメインとそれを使用している他のアカウントを選択した理由を含めます。
キャンペーンの所有権が変更された場合、または新しいサブドメインが導入された場合は、設定を確認してください。新しいキャンペーンが成功したらすぐに古い依存関係を削除するのではなく、廃止が確認されるまで古い依存関係を保持してください。
送信者インベントリを使用して、マーケティングの所有権をより広範なメール プログラムに結び付けます。認証によりアイデンティティ パスが確立されます。受信者に連絡する許可、リストの品質、受信箱の配置は別の問題のままです。
送信者の修正をポリシーの変更から分離する
文書化されたケース HS-01 では、マーケティング アカウントにnews.example.comが接続されており、計画されたキャンペーン From はupdates@example.comであると想定しています。仮想の信頼できるメッセージの結果は、 d=news.example.com, s=demo1.のDKIMパスです。この署名は、通常の緩和された組織ドメインの調整の下で調整できますが、 adkim=s. SPFおよびその他すべての署名は不明なままであるため、厳密モードのDMARC全体的な障害は報告しないでください。マーケティング所有者は、意図した From と一致する製品の接続を確認し、承認されたキャンペーン サンプルを入手する必要があります。ドメイン全体のポリシーを変更することは、ここで提案されている修復ではありません。 example.comの通常のスタッフ メールボックスMXこの変更の対象外のままです。 HubSpotアカウント、メールボックス、 DNSはテストされませんでした。
トラブルシューティングの例をユニバーサル セレクターに変換するのではなく、生成されたレコードの所有者と値を使用します。 HubSpot現在、ポリシーが存在する場合、ペアになったDKIM CNAME とSPFマージを文書化しています。そのステータス ラベルはセットアップ チェックを説明します。完全に認証されたラベルであっても、この計画されたキャンペーンが正しい From ID を選択したことを証明するものではありません。
施行境界を維持する
RFC 9989 セクション 7.4 では、ドメイン公開にはSPFのみではなく有効なDKIMが必要です p=reject、間接メールとメーリングリストの相互運用性について警告します。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。