[ 発送サービスのご案内 ]

共有ドメイン設定を使用して SendPulse Email とSMTPを認証する

SendPulse Email とSMTPでサポートされているドメイン認証を再利用し、ドメイン制限を考慮して、一方のサービスがもう一方のサービスを証明すると仮定するのではなく、各送信ワークフローをテストします。

EmailAuth研究チームによる · 8 分で読めます

【ポイント】

  • SendPulse Email とSMTPでサポートされているドメイン認証を再利用し、ドメイン制限を考慮して、一方のサービスがもう一方のサービスを証明すると仮定するのではなく、各送信ワークフローをテストします。
  • 共有レコードは、アプリケーション間で送信者の選択が一致することを保証しません。
このページでは

電子メールとSMTP共有設定の個別のテストとして扱う

SendPulse は、電子メールとSMTPの共有認証済みドメイン リストを文書化します。適用されるドメインの許容量は 2 つのプランの上限であり、各サブドメインは個別にカウントされます。追跡ドメインはその認証許可を消費しません。現在のガイドでは、2 つの共有エントリを許可する 1 つの電子メール ドメインと 2 つのSMTPドメインの無料プランの例が示されています。複数のブランドやサブドメインを計画する前に、ライブアカウントの許容量を確認してください。 SendPulse 電子メール認証、 DKIMおよびSPFレコードの生成.

共有設定によりDNS作業の重複が軽減されますが、すべてのアプリケーションが目的の From ドメインを選択することを証明するものではありません。 SMTPまたは API を介して送信されるマーケティング キャンペーン、自動化、およびアプリケーションの在庫管理。各ルートのアカウントと目的のドメイン、ビジネス所有者、アプリケーション所有者、 DNS管理者をキャプチャします。送信資格情報はこのワークシートの外に保管してください。

このガイドでは、プロバイダーのパブリック電子メールおよびSMTP認証ワークフローについて説明します。無制限のドメイン許可、独立して選択可能なカスタムを想定していません。 Return-Path または、すべての統合で最終的なアイデンティティが同一になります。ビジネス要件が厳密な要件に依存する場合 アライメント または特定のエンベロープ ドメインについては、コミットする前に SendPulse からサポートされているデザインを取得してください。

レコードを生成する前に既存のドメインを確認する

電子メールの場合、文書化されたエントリ ポイントは [設定] > [ドメイン設定] であり、続いて認証済みドメイン領域でアクティブ化します。 SMTPでは、 SMTP設定 > ドメイン設定および送信ドメイン領域を使用します。どちらのワークフローでも生成される SPF そして DKIM 入力されたドメインのレコード。 SMTPドキュメントには、サービスがレコード設定を共有するため、既存の電子メール認証には別のDKIMセットアップは必要ないと記載されています。 SendPulse SMTP DKIM 、共有レコード設定、および新しいドメインの追加.

既存のドメインがすでに存在する場合は、まず既存のドメインを開きます。現在の接続ステータスと公開値を記録します。新しいアプリケーションがSMTPを使用しているという理由だけで 2 番目の取り決めを生成しないでください。 2 つのアカウントまたはチームが同じドメインを主張している場合は、共有ドメインを変更する前に、現在のプロバイダー発行の指示を比較し、所有権を明確にしてください。 セレクタ.

個別に認証されたサブドメインを含め、ロールアウトに必要なドメインをカウントします。アカウントが許容範囲にある場合は、追加コントロールを公開するためだけに作業ドメインを削除しないでください。そのドメインを何に使用しているかを特定し、アカウント所有者と一緒にプランまたはドメイン戦略を選択します。商用ライセンスの決定は、 DNS障害とは別のものです。

SPF命令と既存のポリシーを調整する

SendPulse SPFガイドでは、既存の SPF をユーザーに説明しています。 SPFレコード 2 番目のレコードを作成するのではなく、そのレコードにプロバイダーの承認を追加します。引用されたガイド名には、既存のポリシーへの追加としてinclude:mxsspf.sendpulse.com 。現在のアカウントのドメイン設定に対する適用性を確認します。サンプルの a 項と mx 項は自動追加されません。サンプルの完全なポリシーを既存のポリシーの上にコピーしないでください。 SendPulse SMTP SPF 、 SPFレコードをコピーし、 DNSプロバイダー Web サイトにエントリを追加します.

編集する前に、正確な所有者の現在のTXT回答をエクスポートします。 SPFポリシーに依存する他のサービスをリストし、可能な場合はベースライン メッセージ内の実際のエンベロープ ID を特定します。企業の From ドメインと SPF 認証されたドメインは異なる場合があります。任意の頂点でインクルードを公開しても、他の場所で評価された障害を修復することはできません。

ネストされたインクルードを含むすべての DNS クエリSPF用語を 10 用語の評価制限と照らし合わせて確認します。編集者の長さの制約に適合するDNSレコードでも、プロトコルの評価制限を超える可能性があります。正当な承認と承認された終了修飾子を保持します。ドメイン所有者が許可内容を評価していない限り、サンプル a または mx メカニズムを使用して権限を拡大しないでください。 RFC 7208 、レコードの選択とDNSルックアップの制限.

プロバイダーの要求と組織の既存のポリシーを安全に調整できない場合は、公開する前に停止してください。メール所有者に、サポートされている送信サブドメインまたは別の適切な設計を評価するよう依頼してください。その決定が行われる間、既存の作業ルートを利用可能な状態に保ちます。

アカウントの公開キーを正しい所有者に公開します。

SendPulse の手順には、 DKIMが TXTレコード また、デモンストレーション公開キーとアカウント自体の値を明示的に区別します。ガイドには標識が示されています。 TXT所有者としての_domainkey 。イラストをすべてのアカウントの証拠として扱うのではなく、ドメイン設定から現在のフルネームと公開値を取得します。記事内で長いサンプル キーを再利用しないでください。 SendPulse SMTP DKIM 、既存のドメイン レコードのコピー.

提案されたセレクター所有者の既存のレコードを検査します。既存のキーは、別のアカウント、プロバイダー、または運用ルートをサポートする場合があります。黙って置き換えたり、サービスが使用しない新しいセレクターを作成したりするのではなく、サポートされている解像度を問い合わせてください。以前の公開記録のコピーを保持しておくと、レビュー担当者が回復を評価するのに役立ちますが、署名状態を調整せずに古いキーを復元することは許可されません。

必ずしもドメイン レジストラーではなく、権威あるDNSプロバイダーを使用してください。エディターが相対ホストまたは完全修飾名を予期しているかどうかを確認します。保存後、完全な所有者を照会し、完全な公開値をアカウントの出力と比較します。 TXT文字列はセグメントで表示される場合があります。フラグメント間にスペースを挿入するのではなく、結合されたコンテンツを比較します。

DNSまたは実装ワークシートには、公開された検証資料のみが含まれます。 DNSレビューには、秘密署名キー、 SMTPパスワード、および API シークレットは必要ありません。資格情報を送信せずに、影響を受けるドメインと公的記録の証拠をサポートします。

接続ステータスと送信者の選択を確認する

電子メールのドキュメントでは、 DNSレコードの確認を使用し、成功したエントリを接続済みに変更します。そのセットアップ手順では、認証されたドメインが送信者アドレスのドメインと一致することも必要です。 SendPulse 電子メール認証、 DKIMおよびSPFレコードの生成、エントリ ステータスの確認.

両方のサービス ビューで該当するステータスを確認し、タイムスタンプを記録します。一方のチームに異なるドメイン リストが表示される場合は、 DNSを変更する前に、両方のチームが意図したアカウントに属していることを確認してください。あるアカウントのステータスが別のアカウントの準備が整っていることを証明するとは考えないでください。

次に、マーケティング ワークフローおよび送信するすべてのアプリケーションで構成された送信者アドレスを検査します。移行後に古いドメインが保持される可能性がある自動テンプレートとアプリケーションのデフォルトを確認します。プレビュー画面で選択した送信者は、バックグラウンド ジョブで使用されるアドレスと異なる場合があります。テストされている本番環境に似たワークフローの実際の設定をキャプチャします。

追跡ドメインの構成を区別してください。ブランドの追跡ドメインはリンクには便利ですが、送信者が選択した認証済みドメインの代わりにはなりません。受け入れレコードでは、追跡ホスト名や明らかにブランド化されたメッセージからDKIMまたはSPFアラインメントを推測してはなりません。

電子メールとSMTPルートを個別に証明する

1 つの代表的なキャンペーンと 1 つの代表的なアプリケーションの送信を通じて、無害なメッセージを送信します。さまざまな From ドメイン、アプリケーション オーバーライド、またはルーティング配置のケースをさらに追加します。制御された外部受信者を使用し、元のヘッダー、メッセージ ID、送信時刻、およびワークフロー ID を保持します。

ケースごとに、表示される From、SPF 認証されたドメイン、 Return-Path 、およびすべてのDKIM d= および s= 値を記録します。 DKIM署名ドメインとセレクターは公開キー検索を識別します。 DNS内の有効なキーだけでは、実際のメッセージがそのキーを使用したことを証明することはできません。 RFC 6376 、 DKIM-Signatureヘッダー フィールドとメッセージからの署名の抽出.

信頼できる受信者の結果を使用して、暗号化パスと調整されたパスを区別します。 DMARC は、修飾されたSPFまたはDKIM結果を通過することができ、アラインメント モードはドメインの比較に影響します。 「認証に合格した」とだけ書くのではなく、どのメカニズムが結果を提供したかを記録します。 RFC 9989 、識別子のアライメントの説明とDMARC評価.

キャンペーンは合格したがアプリケーションは合格しなかった場合は、最初に実際の送信者、アカウント、ルートを比較してください。最初の応答として共有キーをローテーションしないでください。この変更は、アプリケーションの間違った送信元アドレスをそのままにしたまま、実際のマーケティング ストリームに影響を与える可能性があります。

両方のサービスを中断することなく、共有レコードの問題を診断します

DNS検証が失敗した場合は、公開された所有者、レコード タイプ、完全な値、および権限のあるプロバイダーを検査します。署名が欠落している場合は、テストで認証されたドメインと目的の SendPulse アカウントが使用されたことを確認します。署名が失敗した場合は、観察されたセレクターとキーを比較し、別のゲートウェイが署名されたコンテンツを変更したかどうかを確認します。

SPF合格したがDMARC失敗した場合は、認可を追加する前に ID を比較してください。 SMTP送信が配信前に拒否された場合は、送信エラーを受信者の認証結果とは別に保管してください。資格情報、クォータ、またはアプリケーション形式の問題は、 DNSチェックだけでは診断できません。シークレットをサポート バンドルにコピーせずに、正確なエラーを保持します。

カスタム エンベロープの要件が満たされていない場合は、正確なアカウントに対して SendPulse でサポートされているオプションを取得してください。レビューされた手順では、すべての顧客が希望のReturn-Pathドメインを割り当てられることは確立されていません。 MXや CNAME 未確認の特徴を近似するための配置。

ワークシートのリカバリと架空のテストの失敗

認証済みドメインごとに 1 つの行グループと、電子メールまたはSMTPルートごとに 1 つの証拠エントリを使用して、SendPulse 共有ドメイン ワークシートを完成させます (ここで説明するフィールドを含む別のレビュー レコードを作成します)。プランの許容量、既存のセレクターの依存関係、 DNS結果、送信者の構成、および受信メッセージの結果を記録します。不明なものを明示的にマークします。

架空の書かれたケース SP-01: キャンペーン From courses@example.orgがd=example.org,レッスン アプリケーションはDKIM / SPF結果が不明の From lessons@old.exampleに送信されます。 example.orgの接続ステータスは、 old.exampleの認証を確立しません。アプリケーション所有者は、承認された送信者を確認し、共有ドメイン インベントリを比較し、作業キーをローテーションせずにレッスン ルートをテストする必要があります。アカウントやメッセージにはアクセスされず、修正やテストは実行されませんでした。

変更を行う前に、影響を受ける各ストリームを一時停止し、最後に承認された送信者の構成を復元する方法を決定してください。キーの交換をすべてのサービスで共有して調整します。廃止時には、認証レコードを削除する前に、依存するすべてのアプリケーションとキャンペーンを停止します。計画の変更、アカウントの移行、 DNSホスティングの変更、または新しいアプリケーション ルートの後に再テストします。

テストされたスコープのみを閉じます

承認には、正しいドメイン資格、アカウントが発行したレコード、有効なパブリックDNS 、接続されたプロバイダーのステータス、意図された送信者の選択、および各重要なルートの信頼できる受信者の証拠が必要です。検証済みのキャンペーンは、テストされていないSMTP統合を終了しません。ライブ アカウント、 DNSおよびメッセージ チェック、独立した技術レビュー、ビジュアル レビュー、および SME による人間の承認は保留中です。このドラフトは未公開であり、展開が完了したとは主張しません。

通過メッセージを施行の準備から切り離す

RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。

[ 取り除く ]

共有レコードは、アプリケーション間で送信者の選択が一致することを保証しません。

【役割別】

これがあなたにとって何を意味するか

実際の次のステップに向けて、自分の役割を選択してください。

IT / メール管理者

設定の再利用とルートのテスト

共有レコードは、送信者の選択が異なる場合でも、両方のサービスをサポートできます。

次のステップ

  1. まず既存のドメイン設定を確認します。
  2. 編集する前にセレクターの衝突を解決してください。
  3. 実質的に異なるワークフローをそれぞれテストします。

CISO / SecOps

共有依存関係を保護する

キーまたはポリシーの変更は、マーケティング メールとトランザクション メールの両方に影響を与える可能性があります。

次のステップ

  1. すべての依存口座とアプリケーションを記録します。
  2. エンベロープ要件を前提条件から分離します。
  3. ロールバックとキーの廃止を調整します。

創業者 / 非技術系

ドメイン インベントリの予算

電子メールとSMTP計画された認証済みドメインをカバーする必要がある許容量を共有します。

次のステップ

  1. リリース前にブランドとサブドメインをカウントします。
  2. スロットを解放するために動作中のドメインを廃止することは避けてください。
  3. キャンペーンとアプリケーションの個別のテストを承認します。

[ よくある質問 ]

よくある質問

電子メールとSMTPでは、同じ認証済みドメインに対して個別のDKIMレコードが必要ですか?

SendPulse は共有レコード設定を文書化します。新しいものを作成する前に、既存のドメインと接続状態を検査します。

電子メールとSMTPプランが異なる場合、どのドメイン制限が適用されますか?

レビューされたガイドでは、2 つの制限のうち高い方を適用します。追加のドメインを計画する前に、ライブ アカウントの許容量を確認してください。

サブドメインはその制限にカウントされますか?

はい。現在のガイドでは、認証された各サブドメインを個別にカウントし、追跡ドメインを認証許可から除外しています。

ヘルプ記事に記載されている公開キーを公開できますか?

いいえ、記事ではこれを一例として挙げています。アカウントで発行された公開値を使用します。

要求された所有者の既存のDKIMレコードを置き換える必要がありますか?

依存関係とプロバイダーの署名状態を解決する必要があります。共有セレクターは、他のアクティブなルートをサポートする場合があります。

Connected は、アプリケーションが正しい From ドメインで送信していることを証明しますか?

いいえ。アプリケーションの送信側構成と、そのルートからの制御されたメッセージを検査します。

SendPulse は、これらの命令で任意のカスタムReturn-Path約束しますか?

いいえ。サポートされているものとして扱う前に、必要なカスタム エンベロープ ID の確認を取得してください。

このガイドが検証済みの実装として受け入れられるまでに何が残っているのでしょうか?

スコープ内のすべてのルートに対するライブ アカウント設定、 DNS 、および受信メッセージ テストが行​​われ、その後、技術的および人間によるレビューが行われます。

[ 情報源 ]

情報源

  1. 電子メール認証用にSPFとDKIMを構成する

    セクション DKIMとSPFレコードを生成する · SPFレコードを追加する · DKIMレコードを追加する · エントリ ステータスを確認する

  2. DKIM署名を設定する

    セクション 共有レコードの設定 ・新規ドメインの追加 ・既存のドメインレコードのコピー ・エントリー状況の確認

  3. SPFレコードを設定する

    セクション SPFレコードをコピーする · DNSプロバイダー Web サイトにエントリを追加する · エントリのステータスを確認する

  4. RFC 7208送信者ポリシー フレームワーク

    セクション §4.5 レコードの選択 · §4.6.4 DNSルックアップ制限

  5. RFC 6376 DomainKeys によるメールの識別

    セクション §3.5 · §3.6.1 · §6.1

  6. RFC 9989ドメインベースのメッセージ認証のレポートと適合性

    セクション §4.4 · §5.3.5 · §7.4

[ 用語集 ]

用語集

共有ドメインリスト
SendPulse 認証済みドメインは、電子メールおよびSMTPサービス全体で利用できます。
ドメイン許可
認証できるドメインの数を制御するアカウント プランの制限。
セレクターの衝突
既存のDKIM所有者を置き換えると、別の送信依存関係に影響を与える可能性があります。
提出ルート
メッセージを送信側サービスに渡すアプリケーションまたはワークフロー。

企業の来歴

一流の金融機関と政府が選ばれる理由 電子メール セキュリティ ダッシュボードを廃止しました。

従来の電子メール認証プラットフォームはダッシュボードを販売し、エンジニアに作業を依頼します。一か八かの環境では、手動による監視は適用の遅れ、構成のドリフト、および監視されていないシャドウ ドメインを意味します。

EmailAuthは、エージェントの電子メール来歴プラットフォームです。 当社のエージェントが執行します p=reject、サードパーティの送信者を調整し、ドメインを完全に移動します。 RFC 9989 新しいDMARC標準に準拠し、人間による監査機能を備えています。

政府 大企業 ティア1金融機関

SaaS · 専用テナント · エアギャップオンプレミス · BYOK 暗号化

ナレッジベース