レコードを選択する前に Combell メール製品を選択してください
Combell は単一の認証構成ではありません。その SPF 手順では、基本電子メール、Exchange 電子メール、およびMicrosoft 365を区別します。それは別です DMARC 記事には次のように書かれています DKIM 標準のメールボックスでは利用できず、Combell Mailserver にサポートがインストールされた代替手段について説明しています。これらの違いにより、責任ある構成計画が何を約束できるかが決まります。このガイドでは、文書化された製品の選択とDNS準備について説明しますが、検証済みのテナント実装やユニバーサルDKIMレシピについては説明しません。 SPF記事は 2025 年 4 月 1 日に更新されました。 DMARC記事は 2026 年 9 月 2 日に更新されました。変更を加える前に、実際のサブスクリプションへの適用性を確認してください。 Combell SPFガイダンス Combell DMARCガイダンス
請求書に単にベンダー名を記載するのではなく、製品の名前を記載した在庫から始めます。どのシステムがスタッフの通信を送信するか、どのシステムが Web サイト通知を送信するか、どのシステムがキャンペーンを送信するか、どのシステムが返信を受信するかを記録します。 Combell でホストされている Web サイトでは、すべてのメッセージがその基本的な電子メール インフラストラクチャを使用していることは確立されていません。同様に、Exchange サブスクリプションとMicrosoft 365ルートは、 DNSが同じポータルを通じて管理されているという理由だけで、基本的な電子メール認証を受け取るべきではありません。この目録は提案された作品です。この原稿に関してはアカウント、ドメイン、メッセージは検査されていません。
SPFと実際の送信ルートを調整する
プロバイダーは、3 つの名前付き製品に対して個別のSPFサンプルを公開しています。これらは、互換性のある追加機能としてではなく、適用性チェックが必要な製品固有の指示として扱ってください。現在承認されているルート情報を取得し、承認されたプロセスを通じて既存の完全なSPFポリシーを取得し、結果のレコードを提案する前に他の正当な送信者を特定します。マルチ送信者ポリシーを短い例に置き換えたり、2 番目のSPFポリシーを一緒に公開したりしないでください。 Combell SPFガイダンス
SPFはSMTPに対して評価されます メール送信元 アイデンティティ、あるいは HELOアイデンティティ 関連する場合。表示されている作成者のアドレスを直接認証するわけではありません。したがって、メッセージにDMARCが存在しない場合でも、アウトバウンド サービスを許可するポリシーは正しい可能性があります。 アライメント。エンベロープ ドメイン、表示される送信元ドメイン、および監視される送信ルートを別のフィールドとして保持します。正しい記述を避ける SPFレコード 組織の表示名を含むすべてのメールが本物であることの証明として。 RFC 7208 、セクション 2.3 ～ 2.4
すでに存在するサービスを含む、拡張されたSPF依存関係パスを確認します。プロトコル制限は、DNS クエリ用語を評価します。これは、単にテキストのインクルード エントリ、パケット、またはキャッシュされた回答の数ではありません。追加の承認は、正当な送信者をサイレントに削除せずに、評価ルール内に残す必要があります。最後の all メカニズムはポリシーの結果を表しますが、受信者の処理は別個の決定のままです。ハード障害もプロバイダーの配信指向の文言も、特定の受信トレイまたは拒否の結果を保証するものではありません。 RFC 7208 、セクション 4.6.4 および 8
権威DNSコンテキストで公開する
文書化されたDNSインターフェイスで管理されているドメインの場合、Combell は、My 製品、 DNSおよび転送管理、ドメインの横での管理、および TXTレコード。そのSPF命令では、ドメイン自体に空のホスト名を使用します。その動作は、文書化されたエディターと対象のゾーンにのみ適用してください。別の場所で管理されるDNSゾーンには、そのプロバイダー独自の名前入力セマンティクスが必要です。 Combell の命令は、別のエディタが空白の名前やサフィックスを同様に処理することを証明するものではありません。 Combell SPFガイダンス
公開する前に、目的の完全修飾所有者名、レコード タイプ、完全なコンテンツ、TTL、およびロールバック値を記録します。対象の所有者をエディターのプレビューと比較します。承認された変更後、保存されたコントロール パネルのビューを、承認された回答やリゾルバーの観察結果と区別します。 TXTプレゼンテーションには引用符または複数の文字列を含めることができます。これらの表示の詳細を、いくつかの独立したSPFポリシーと間違えないでください。オペレーターは、意図した論理値とレコード境界を保存する必要があります。 RFC 1035 、セクション 3.3.14 および 5.1 RFC 7208 、セクション 3.1 ～ 3.3
Combell 氏が述べた 1 ～ 4 時間の間隔は運用上の指針であり、特定の瞬間にすべてのキャッシュが更新されたことを証明するものではありません。ワークシートは観察時間を保持し、以前にキャッシュされた回答を現在の信頼できる状態から区別する必要があります。 1 つのリゾルバーがまだ以前の応答を返しているという理由だけで、正しいレコードを繰り返し書き換えないでください。逆に、間違った所有者名や誤って複製されたポリシーは、時間が経過しても修復できません。
標準メールボックスのDKIM制限を尊重する
Combell DMARCページには、 DKIMは標準メールボックスでは利用できないと明示的に記載されています。これは、サポートがDKIMインストールできる別のオプションとして Combell Mailserver を識別し、別個のマーケティング製品として Flexmail を識別します。これらの代替案は、標準メールボックスがDKIMスイッチを取得していることを確立するものではなく、ユニバーサル スイッチを提供するものでもありません。 セレクタ または公開鍵。調整されたDKIMを必要とするプロジェクトでは、経常収支の適用性は未解決のまま、これを製品適合性の決定として保持する必要があります。 Combell DMARCガイダンス
チェックリストが完全であるように見せるために、作成されたDKIMレコードを公開しないでください。 DNS公開だけでは、署名されていないルートにメッセージに署名させることはできません。署名者は対応する秘密キーを所有し、適切な署名を適用する必要がありますが、受信者は署名のセレクターと署名ドメインを通じて公開検証マテリアルを取得します。サポート付きインストールには、独自の承認された範囲、現在の手順、およびその後のメッセージの証拠が必要です。ここではサポートへの問い合わせやインストールは行われていません。 RFC 6376 、セクション 3.5 および3.6.2.2
サンプルとは別にDMARCポリシーを決定する
Combell は、 _dmarcでDMARC TXTレコードとして追加する方法について説明し、特定の強制ポリシーを必要としないユーザー向けの監視ポリシーの例を示しています。その例は、既存の隔離ポリシーや拒否ポリシーを置き換える許可ではありません。ポリシーを変更する前に、組織の完全な送信者インベントリと承認されたレポートの取り決めを確認してください。ジェネレーターは決定をフォーマット化できます。認証されていないメールに対する組織の許容範囲を決定することはできません。 Combell DMARCガイダンス
DMARC 、適格な調整されたSPF結果または適格な調整されたDKIM結果をパススルーできます。したがって、標準メールボックスのDKIM制限だけでは、すべてのメッセージがDMARC失敗することを証明するわけではありません。また、公開されたSPFポリシーが実際のエンベロープ ID が一致していることを確立するわけでもありません。証拠が入手可能な場合は、承認されたルートに対する受信者の結果を記録します。認証は、評判、コンテンツ評価、受信者の好み、最終的な配信とは区別されます。 RFC 9989 、セクション 2.4 および 4.4
架空の診断: 間違った製品の仮定
Cedar Workshop という架空の組織について考えてみましょう。この組織の管理者は、 DNS請求書の Combell を確認し、基本的な電子メールの例を選択します。金融関連の通信では実際には別の購読メール製品が使用されており、Web サイトでは別の送信サービスが使用されています。次に、同僚が、内部チェックリストを満たすための推測されたDKIMセレクターを提案します。このシナリオには、測定されたインシデントや実行されたテストは含まれません。
提案された診断は、製品在庫を修正することから始まります。チームは、各正当な送信者を既存のSPFポリシーと照合し、どのルートが整合された ID を提供できるかを記録します。 DKIM発明するのではなく、標準メールボックスに対して未解決のままにしておきます。 記録。企業がそのルートにDKIM必要とする場合、所有者はサポートされている代替製品を評価し、該当する指示を取得します。成功した結果は明確な決定と証拠の計画であり、 DNS変更によって配信がすでに修正されているという主張ではありません。
空白の承認ワークシート
- サブスクリプションと製品: ____;責任のあるアカウント所有者: ____。
- 送信アプリケーション、エンベロープ ドメイン、および表示される From ドメイン: ____。
- 権威あるDNSオペレーターと意図された完全な所有者名: ____。
- 既存のSPFポリシーと正当な送信者は保持されます: ____。
- 製品固有の認可は日付____に確認されました。
- SPF評価レビューの拡張と未解決の依存関係: ____。
- この正確な製品に対するDKIM可用性と設置責任: ____。
- 現在のDMARCポリシー、承認された報告先、および変更の根拠: ____。
- 承認されたDNS観察と実際に受信したメッセージの証拠: ____。
- 残りの製品適合性の決定、ロールバック所有者およびリリース承認者: ____。
すべてのフィールドは意図的に空白になっています。カタログの実装要件、人間によるレビュー、現在のソースの適用性、生産ルート、ビジュアル/アクセシビリティのレビュー、および所有者のリリースは未解決のままです。このドラフトは運用上の受諾ではなく、納品を保証するものではありません。