[ SPF ]

カスタム MAIL FROM ドメイン: SPFとDMARC整合性を一緒に検証する

成功したDNSセットアップ画面だけでなく、受信したメッセージを使用してカスタム エンベロープ ドメインを検証します。

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

【ポイント】

  • 正確なエンベロープ ドメインに対してアカウント固有のプロバイダー設定を使用します。
  • バウンス サブドメインは、親との厳密な調整を満たしていません。
  • 送信、フォールバック、サポートされているバウンス処理を個別にテストします。
このページでは

カスタム メール送信元 ドメインでは、表示されている From ドメインに関連するエンベロープ ID をサービスで認証できるようになります。有益な結果は、プロバイダーのコンソールに緑色のDNSインジケーターが表示されるだけでなく、正常に機能し調整されたメール パスになります。生成されたDNS設定、実際のSMTP ID、 SPF 結果と DMARC アライメント 別のステップとして。

ドメインは慎重に選択してください

表示される差出人アドレスで使用される作成者ドメインと、プロバイダーがサポートするカスタム エンベロープ設計をインベントリします。バウンス サブドメインは運用上便利かもしれませんが、厳密なSPF調整には作成者ドメインと完全に一致する必要があります。リラックスした調整の下では、組織とドメインの関係は次のように決定されます。 RFC 9989 §4.10.2 サブドメインを調整できるようになります。ブランド名や返信先フィールドから属性を推測しないでください。 RFC 9989 §3.2.4, RFC 9989 §4.4.

サービスによって提供される現在のアカウント固有のDNS値を使用します。プロバイダーは、 SPFだけでなくバウンス処理用の追加レコードを必要とする場合があります。これらの要件はサービス固有です。このガイドでは、ターゲットまたはクリック シーケンスを含め、ユニバーサルMXホスト名を意図的に示していません。ドメインが専用であること、または変更が既存のメール フローと競合しないことを確認してください。

ポリシーの整合性を失わずに公開する

正確なSPFアイデンティティ ドメインで、1 つを維持します。 SPFレコード 既存のポリシーの横に 2 番目のv=spf1レコードを追加するのではなく、ドメインに複数の正当な送信者がいる場合は、完全に組み合わされた要件を検証します。親ポリシーは自動的に子をカバーしません。ネストされた依存関係と、DNS クエリの原因となる用語の制限についての代表的な評価パスを検査します。 RFC 7208 §4.5, RFC 7208 §4.6.4.

カットオーバーの前に、古いDNS値と安全なロールバック計画を記録します。信頼できる出版物と関連する再帰的回答を確認し、サービスでカスタム エンベロープを有効にするか確認します。検証されたDNSレコードだけでは、メッセージがそのレコードを使用し始めたことを示すことはできません。

受信したメールで関係を証明する

適用可能なDMARCポリシーを想定した例: メッセージは From receipts@example.comと MAIL FROM return.bounce.example.comを使用します。そのエンベロープ ドメインが SPF 承認されており、該当する 組織ドメイン example.com 、リラックスモードで整列できます。完全なドメイン名が異なるため、厳密モードでは調整されません。代わりにプロバイダーが黙ってbounce.provider.example.netにフォールバックすると、 SPFアライメントが失われているにもかかわらず生のSPFが通過する可能性があります。

サポートされている場合はフェイルオーバーを含む、実質的に異なるすべてのルートを通じてテスト メッセージを送信します。実際の MAIL FROM、接続 IP、信頼できる受信者のSPF結果、調整されたSPF結果、および DKIM 署名ドメイン。 DMARC 、エンベロープが整列されていない場合でも、整列されたDKIMを使用して通過できます。カスタム MAIL FROM が機能したと主張するのではなく、正直に報告してください。 RFC 9989 §4.4.

運用面の検証

プロバイダーがサポートするバウンス処理をテストし、期待されるアプリケーションが配信ステータス情報を受信することを確認します。システムが null リバース パスを使用してメッセージを発信する場合、 SPF定義された postmaster-plus-HELO ID 構造を使用するため、別のケースとしてテストします。ループを生成するバウンス テストを運用環境に送信しないでください。 RFC 7208 §2.4, RFC 7208 §10.1.3.

送信、認証、位置合わせ、およびバウンス処理に証拠がある場合にのみ、変更を完了してください。 Runbook でプロバイダーのフォールバック動作と所有権を保持し、ルーティングまたはアカウントの変更後にテストを繰り返します。

具体的な意思決定記録を使用する

2 つの仮定の受け入れ行を使用します。通常のルートはreturn.bounce.example.comとSPFパスを発行します。フォールバックは無関係のプロバイダー ドメインを発行し、 SPFはパスします。 From= example.comの場合、最初のものは条件を満たす緩和された関係の下でのみ整列できますが、2 つ目は整列できません。 DKIM全体的なDMARCパスを提供する場合でも、カスタム MAIL FROM フォールバックを要求された ID を満たさないものとしてマークします。バウンス処理の証拠を独立して保持します。プロバイダーの構成やテストメールは実行されませんでした。

[ 取り除く ]

正確なエンベロープ ドメインに対してアカウント固有のプロバイダー設定を使用します。バウンス サブドメインは、親との厳密な調整を満たしていません。送信、フォールバック、サポートされているバウンス処理を個別にテストします。

【役割別】

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

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

IT / メール管理者

アカウントによって生成されたDNS値を使用します。

プロバイダーが生成した値、実際のSMTP ID、および受信者の結果を変更レコードに保持します。停止によってアライメントがサイレントに変更されないように、フォールバック動作をテストします。

次のステップ

  1. アカウントによって生成されたDNS値を使用します。
  2. 通常のエンベロープ ID とフォールバック エンベロープ ID をテストします。
  3. バウンス処理と位置合わせを個別に検証します。

CISO / SecOps

ID を制御するサービス アカウントを確認します。

どのサービスがエンベロープ ドメインを使用する可能性があるか、またそのアカウント制御が適切かどうかを確認します。緩和された調整または厳密な調整は、 DNS偶発的な結果ではなく、意図的な設計上の選択として扱います。

次のステップ

  1. ID を制御するサービス アカウントを確認します。
  2. 厳密または緩和された位置合わせの選択を文書化します。
  3. 所有権と回復条件を保持します。

創業者 / 非技術系

カスタム ドメインを使用してメッセージ ストリームを識別します。

実際のメッセージが新しいドメインを使用していること、および配信エラーが依然として適切なチームに届いていることの証拠を求めてください。完了したセットアップ ウィザードは 1 つのマイルストーンにすぎません。

次のステップ

  1. カスタム ドメインを使用してメッセージ ストリームを識別します。
  2. 受信メッセージの証明を要求します。
  3. 配送エラーが引き続きビジネス オーナーに届くことを確認します。

[ よくある質問 ]

よくある質問

MAIL FROM は顧客に表示されるアドレスですか?

通常はそうではありません。通常、顧客にはRFC5322 .From ヘッダーが表示されます。 MAIL FROM は、配信エラー処理とSPFに使用されるSMTPエンベロープ ID です。

RFC 7208 §2.4 RFC 9989 §3.2.2

カスタム ドメインはSPF調整を保証しますか?

いいえ。実際に使用し、 SPFに合格し、該当する位置合わせ関係を満たしている必要があります。

RFC 9989 §4.4.2

バウンス サブドメインは厳密モードで調整されますか?

作成者のドメインと完全に一致する場合のみ。同じ組織ドメインを共有するだけでは、厳密な調整には不十分です。

RFC 9989 §3.2.10.2

別の顧客のDNS値をコピーする必要がありますか?

いいえ。独自のプロバイダー アカウントとドメインに対して生成された現在の値を使用します。

2 番目のSPF TXTレコードを追加できますか?

同じ所有者名で複数のSPFレコードを公開しないでください。正当な送信者の要件を 1 つの有効なポリシーに調整します。

RFC 7208 §4.5

カスタム MAIL FROM が壊れているのにDMARCが通過するのはなぜですか?

整合されたDKIM署名を渡すと、独立してDMARC満たすことができます。 SPFアイデンティティと結果を直接検査します。

RFC 9989 §5.3.5

すべてのプロバイダーは同じバウンス レコードを必要としますか?

いいえ。バウンス ルーティングと検証の要件はプロバイダーによって異なります。現在のファーストパーティアカウントの指示に従ってください。

受け入れテストには何が含まれますか?

通常およびフォールバックの送信アイデンティティ、 SPF 、アライメント、 DKIM 、全体的なDMARC 、監視された配信、およびサポートされているバウンス処理。

[ 情報源 ]

情報源

  1. RFC 7208

    セクション §2.4 · §4.1 · §4.5 · §4.6.4 · §10.1.3

  2. RFC 9989

    セクション §3.2.2 · §3.2.4 · §3.2.10.2 · §4.4 · §4.4.2 · §4.10.2 · §5.3.5

[ 用語集 ]

用語集

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

RFC 7208 §2.4

ID からのメール
リバース パスが null の場合に、定義された postmaster/ HELO構造を使用してSPFによって使用されるSMTPエンベロープ ID。

RFC 7208 §2.4

DMARCアラインメント
認証された識別子と作成者ドメインの間に必要な関係。

RFC 9989 §4.4

企業の来歴

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

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

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

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

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

ナレッジベース