範囲と前提条件
DNS変更する前に、作成者のアクティブな送信チャネルを特定します。スーパー管理者はチャネルを管理します。ドメイン認証には有料プランが必要です。
文書化されたルートを構成する
- ステップ 1. 組み込み配信の場合は、送信者のアドレスを確認します。操作、電子メール管理、送信電子メール チャネルを開き、組み込み電子メールのドメインを管理します。
- ステップ 2. ドメインを検証し、そのドメインをコピーします SPF そして DKIM 指示に従ってレコードを公開し、再度検証してください。完了には、認証ステータスが完了済みおよびステータスがアクティブである必要があります。
- ステップ 3. ZeptoMail に切り替える前に、そのドメインを個別に検証し、必要な送信者をすべてテストします。
- ステップ 4. 1 つのチャネルだけがアクティブです。アクティブな削除可能な外部チャネル構成を削除すると、組み込みの配信がアクティブになります。組み込みの電子メールと ZeptoMail は削除できません。代わりに、ZeptoMail の関連付けを解除する必要があります。何かを変更する前に、該当する回復操作とフォールバックを確認してください。
製品固有のリスク
認証は、アプリケーション名だけでなく、配信チャネルに従う必要があります。ワークフロー通知、スケジュールされたメッセージ、およびユーザーがトリガーしたアクションのテスト インベントリを、それぞれが選択した送信者とともに作成します。 Creator でアクションが成功してもメールが到着しない場合は、アプリケーションの実行をSMTP受け入れおよび受信者の配信から分離します。チャネルの移行により、認証情報やクォータなどの運用上の依存関係も変更されます。証拠チケットに秘密を記録することなく、所有者に明確なロールバック決定を与えます。
受信側でルートを証明する
承認された外部メールボックスを使用し、完全な生メッセージをタイムスタンプとメッセージ ID とともに保存します。このガイドでは、ライブ テナント テストは主張されていません。以下は、実装中に完了する必要がある受け入れワークシートです。 記録 観察結果の。
- 証拠フィールド: 可視範囲;記録する内容: 実際のアドレスとドメイン。承認の質問: これは意図された送信者の ID ですか?
- 証拠フィールド: 封筒。記録する内容: Return-Path 受信者から報告されたSPFドメイン。承認の質問: SPF実際に認証したのはどのドメインですか?
- 証拠フィールド: SPF ;記録する内容: 信頼された受信者の結果と評価された ID。承認の質問: 合格しましたか?そのアイデンティティは一致していますか?
- 証拠フィールド: DKIM ;記録する内容: すべての d= ドメイン、s= セレクタ そして受信機の結果。承認の質問: 少なくとも 1 つの合格署名は一致していますか?
- 証拠フィールド: DMARC;記録する内容: 受信者の結果と適用されるポリシー。受け入れの質問: 整列した通過パスは存在しますか?
- 証拠フィールド: ルート。記録する内容: 製品、アカウント、メッセージの種類。承認の質問: テストでは実稼働パスが使用されましたか?
DMARC 、 SPFまたはDKIMパスを通過する、調整されたパスが少なくとも 1 つ必要です。無関係なサービス ドメインからの署名を渡すだけでは十分ではありません。厳しい アライメント ドメインが正確に等しいことが必要です。緩和された調整では、該当する組織とドメインの関係が使用されます。成功を宣言する前に、ドメインの実際の配置設定を確認してください。サブドメインは自動的に完全に一致するわけではありません。 SPF 、表示名や返信先ではなく、 SMTP ID を使用します。に相談してください。 アライメント用語集 決定を記録するとき。
使用 Authentication-Results 任意の送信者によって提供されたヘッダーではなく、信頼する受信システムからのものです。最初の失敗で停止するのではなく、すべての署名を取得します。転送されたメールについては、直接テストと転送されたコピーを比較します。転送によりSPF評価が変更されたり、署名されたコンテンツが変更されたりする可能性があります。プロバイダーの承認にフォワーダーのアドレスを追加して、これらの影響を診断しないでください。
アクセスを拡大せずに障害を診断する
まず権威DNS正確に構成されたレコード名と比較し、次に再帰的な可視性とサービスの検証をチェックします。名前が間違っている、キーが切り詰められている、または競合している CNAME キャッシュを待っても修正されません。所有者にSPFポリシーを 1 つだけ保持し、別の送信者をマージする前に、評価されたインクルードとリダイレクト全体で 10 個の DNS ルックアップ期間の制限を確認します。 DKIMセレクターは個々の署名構成に属します。検証結果を強制するために別のアプリケーションのレコードを上書きしないでください。
認証は成功したが配信が不十分な場合は、受信者の応答、レピュテーション、コンテンツ、および送信権限を個別に検査します。 DMARCパスは、承認または受信箱への配置を約束するものではありません。どちらのパスも一致しない場合は、拡張を停止し、実際の送信側構成を修正します。単一の製品の障害を隠すためにドメイン全体のDMARCポリシーを弱めないでください。
引き継ぎと回収
承認されたDNS差分、パブリック ルックアップ結果、サービス ステータス、および編集された受信メッセージ ワークシートを所有者を指定して保存します。資格情報や秘密キーをチケットに含めないでください。失敗した場合は、影響を受ける送信ジョブを一時停止するか、サービス所有者の制御下で以前にテストされたルートを使用します。この統合に属する変更されたレコードのみを復元します。インフライトメッセージに必要な公開キーを保持します。ロールバック、キーのローテーション、ドメインの移行、または送信リレーの変更後に再テストします。製品所有者とメール管理者が観察されたアイデンティティ チェーンを説明できる場合にのみ、変更を閉じます。
プロバイダー境界を確認する
現在のページには、 Microsoft 365 、個人用Outlook 、 Gmail 、およびカスタムSMTPチャネルについても記載されています。この記事では、組み込みの認証とチャネル変更の受け入れについて説明しますが、これらのサービスに対する完全な資格情報のプロビジョニングについては説明しません。現在の承認済みアカウント設定、送信者のエイリアス、およびセキュリティ制御を個別に使用します。構成を作成してもアクティブ化されません。アドレス検証後の組み込み検証ステータス「完了」は、 DNS検証後の「認証ステータス完了」および「アクティブ」ステータスとは異なります。
架空の診断ケースに取り組む
架空のケースのみ: CR-01 は、アクティブなカスタムSMTPチャネル構成を削除すると、有料クリエイター アカウントが意図したalerts@shop.exampleではなくnotifications@mailer.zohocreatormail.comを使用することを想定しています。認証結果は不明です。スーパー管理者は、アクティブなフォールバック、組み込みのドメイン認証、および必要なワークフローを再開する前に確認する必要があります。以前に通過した外部チャネルのサンプルは、変更されたルートを閉じることができません。このケースでは、テナント、 DNS 、サーバーのコマンドまたはメッセージは実行されませんでした。
アクティブなチャネルを変更する前にフォールバックを計画する
文書化された組み込みの共有差出人 ID は、有料ユーザーの場合はnotifications@mailer.zohocreatormail.com 、カスタム認証がない場合のトライアルの場合はnotifications@trial.zohocreatormail.comです。そこで ZeptoMail ドメインを再度検証する必要があります。この統合により、Creator Default メール エージェントが作成され、クレジット ベースのシステムへの送信が変更されます。関連付けを解除すると、プランベースの 1 日あたりの制限が復元され、統合の追跡、バウンス、ログ機能へのアクセスが削除されます。再検証が必要です。アクティブなチャネルの承認を取り消すと、再承認されるまで配信が停止しますが、アクティブで削除可能な外部チャネル構成を削除すると、組み込みの配信がアクティブになります。内蔵メールとZeptoMailは削除できません。 ZeptoMail は代わりに関連付け解除を使用します。その操作をチャンネルの削除として扱わないでください。意図した回復アクションを明示的に選択し、何かを変更する前に必要な送信者をすべてキャプチャします。
通過メッセージを施行の準備から切り離す
RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。