[ SPF ]

ホスト型、動的、手動管理のSPF : 運用責任の比較

手動、ホスト、および動的SPFラベルは、異なるプロトコルではなく、異なる責任を説明します。承認の所有者、 DNS可用性、変更のレビューと回復を比較します。

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

【ポイント】

  • 実際の受信時ルックアップおよびバックグラウンド更新パスをマッピングします。
  • マネージドSPF引き続きプロトコル制限の影響を受けます。
  • 選択する前に、インシデント、公開、終了の責任を割り当てます。
このページでは

を選択する SPF 運用モデルは、誰が送信権限を維持するかについての決定です。 「ホスト型」と「動的」は、アーキテクチャ図の代わりにはなりません。コストを比較する前に、 DNSに何が残っているのか、他の組織が何を変更できるのか、更新の失敗や利用できない依存関係がメールにどのような影響を与えるのかを検討してください。

モデルを具体的に説明する

手動管理モデルでは、チームがポリシーを編集し、依存関係を確認します。プロバイダーが制御するインクルードに依存する場合もあるため、手動で編集してもすべての入力が制御下にあるわけではありません。ホストされたモデルでは、別のサービスが参照ポリシーを管理したり、提案されたレコードを生成したり、統合を通じて変更を公開したりできます。これらの取り決めにより、さまざまな権限が付与されます。

「動的SPF 」は、自動更新または管理ポリシー サービスを表すことができます。これは、個別のバージョン マーカーや鮮度を保証するものではありません。サプライヤーに、 DNSゾーン、編集者アカウント、関連する監視システムの名前を指定して、正確な検索パスと更新パスを作成するよう依頼してください。マーケティング カテゴリに表示されるという理由だけでその機能を想定することは避けてください。

プロトコル ルールをサービス プロミスから分離する

RFC 7208 管理モデルに関係なくSPF評価を決定します。マネージド サービスでは、より大きな評価期間の予算は付与されません。生成またはホストされた出力は、送信側 ID に対して正しく動作する必要があります。

ダッシュボードのスコアだけでなく、候補者の記録に関する証拠を求めます。代表的な肯定的評価と否定的評価、依存関係ツリー、サポートされているポリシー構成、および失敗したアップストリーム読み取りの処理が必要です。平坦化された出力の場合は、 平坦化評価 意味論と鮮度を調べるため。

責任の比較を構築する

オプションごとに、送信者の承認、そのアドレス スコープの維持、 DNSの公開、更新の失敗の通知、サービスの復元を担当する担当者またはサプライヤーの名前を指定します。どちらの側にも責任がない場合は、その責任を未解決としてマークします。一見安価なオプションは、管理者が予算のない日々の作業を行うことに依存している可能性があります。

この比較演習を使用してください。給与計算サービスには新しいエンベロープ ドメインが必要です。ある提案では、サプライヤーが電子メールで指示を送信し、 DNSチームがそれを実装します。別の方法では、管理サービスは、別のローカル編集を行わずに、参照された承認を変更できます。どちらのモデルも本質的に勝者ではありません。 2 つ目は、サプライヤーの変更管理に対するより強い注意を必要とします。 1 つ目は、信頼できる内部応答プロセスが必要です。

去ったベンダーを誰が削除できるのか、また削除が行われたことをどのように証明するのかを尋ねます。オンボーディングを簡素化するものの、廃止が不明確なままになるシステムは不完全です。

可用性を評価し、可視性を変更する

受信者が到達する必要がある依存関係と、バックグラウンド アップデーターによってのみ使用される依存関係をリストします。ライブ ポリシーの依存関係は、利用できない場合に評価に影響を与える可能性があります。バックグラウンド アップデーターが失敗すると、代わりに古い公開ポリシーがそのまま残される可能性があります。どちらも重要ですが、症状と回復手順が異なります。

アクティブな構成、変更履歴、および元のプロバイダー マッピングのエクスポートを要求します。サブスクリプションの有効期限が切れたとき、資格情報が機能しなくなったとき、または範囲の大幅な変更が発生したときに、アラートが監視対象の宛先に届くかどうかを確認します。アクセス制御は利便性とは別に評価してください。サポートされているより狭い統合で十分な場合は、広範なDNSアクセスを許可することは避けてください。

コミットする前に終了のリハーサルを行う

マネージド依存関係を置き換える方法、権限のあるゾーンを編集できる人、および置き換えを検証する送信テストを書き留めます。購入時に契約およびキャンセルの詳細を直接確認します。このガイドはサプライヤーの条件を主張するものではありません。最後に動作していた構成を保存しますが、サービスを終了した後もその構成が無期限に最新のままであると想定しないでください。

継続的な作業、サポートされているセマンティクス、観察可能な更新、インシデント対応、および出口の準備状況を使用して意思決定を行います。保管してください 送信者の在庫 特定のベンダーのダッシュボードの外にあるため、担当者やサプライヤーが変わった後も責任は理解できるままです。

決定を書面に残す

仮想の管理オプションについては、 DNSを編集するか、インクルード ターゲットを制御するか、提案のみを生成するかを記録します。送信者の承認者、発行者、上流の変更モニター、および回復の所有者を割り当てます。サプライヤーがライブターゲットを所有しているが、停止エスカレーションを所有している人がいない場合、オペレーティングモデルにはギャップがあります。テキストのみを生成する場合でも、 DNS公開と古い出力の処理には所有者が必要です。サプライヤーの能力や価格設定は想定されていません。

[ 取り除く ]

実際の受信時ルックアップおよびバックグラウンド更新パスをマッピングします。マネージドSPF引き続きプロトコル制限の影響を受けます。選択する前に、インシデント、公開、終了の責任を割り当てます。

【役割別】

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

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

IT / メール管理者

マップの検索および更新パス。

受信側の依存関係をバックグラウンド生成やDNS公開から区別します。

次のステップ

  1. それぞれの外部依存関係を文書化します。
  2. サポートされているポリシー構成をテストします。
  3. エクスポートと交換の手順を最新の状態に保ってください。

CISO / SecOps

付与されている権限を確認してください。

管理統合は、どのシステムがユーザーの ID で送信するかに影響を与える可能性があります。

次のステップ

  1. 公開権限を確認してください。
  2. 追跡可能な承認の変更が必要です。
  3. ベンダーの削除とアクセスの取り消し手順を確認します。

創業者 / 非技術系

ラベルではなく、運用コストを比較してください。

サービス料金によって、重要なメールに対する責任が免除されることなく、業務が変更される可能性があります。

次のステップ

  1. 内部サービス所有者に名前を付けます。
  2. 比較にはインシデントと出口の作業を含めます。
  3. モデルを選択する前に証拠が必要です。

[ よくある質問 ]

よくある質問

ダイナミックSPFは新しいプロトコルですか?

いいえ。それをサービスまたは管理ラベルとして扱い、実際のSPFレコードとその背後にあるプロセスを検査してください。

ホストされたSPFルックアップ制限を削除しますか?

いいえ、結果の評価には依然としてSPF制限が適用されます。

RFC 7208 §4.6.4

手動SPFは引き続き外部プロバイダーに依存できますか?

はい。ローカルで編集されたポリシーは、プロバイダー管理のインクルードやその他のDNS依存関係を参照できます。

RFC 7208 §5.2 RFC 7208 §6.1

どのモデルが一番安いですか?

進行中のスタッフの時間、インシデント処理、退出作業を料金と比較します。このガイドでは、サポートされていないサプライヤーの価格比較は行っていません。

サプライヤーは何を証明する必要がありますか?

実際の管理アーキテクチャ、テスト出力、サポートされているポリシー セマンティクス、変更の可視性、および回復プロセスについて尋ねます。

完全なDNSアクセスを許可する必要がありますか?

許可されたタスクを満たす、サポートされている最も狭いアクセスを使用します。公開統合を有効にする前に、正確な権限を確認してください。

ロックインを回避するにはどうすればよいですか?

独立した送信者インベントリ、構成のエクスポート、プロバイダーのマッピング、およびリハーサルされた交換手順を維持します。

最低限の受け入れテストは何ですか?

構成されたエンベロープ ドメイン、代表的な承認済みおよび未承認の入力、実際に受信したメッセージ、および回復の所有権を確認します。

[ 情報源 ]

情報源

  1. RFC 7208

    セクション §2.4 · §4.5 · §4.6.4 · §5.2 · §6.1 · §5.1

[ 用語集 ]

用語集

SPF
接続 IP および関連するSMTP ID の認可評価。

RFC 7208 §2.4

SPFを含む
パスがインクルードと一致する再帰的評価。 include 修飾子によって外側の結果が決まります。

RFC 7208 §5.2

SPFリダイレクト
ローカルメカニズムが一致しない場合に評価を委任する修飾子。すべてのメカニズムがその使用を妨げます。

RFC 7208 §5.1 RFC 7208 §6.1

企業の来歴

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

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

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

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

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

ナレッジベース