適用可能なポリシーと完了した評価により、 SPF そして DKIM 両方とも通過できます DMARC 以下で失敗します RFC 9989 §5.3.5。これは、これらのメカニズムが認証したドメインが、From アドレスに表示されるドメインと一致しない場合に発生します。
各メカニズムは異なる質問に答えます。 SPF 、接続元が評価されたエンベロープ ID に対して許可されているかどうかをチェックします。 DKIM署名ドメインに関連付けられた署名を検証します。次に、 DMARC 、渡された ID が、表示されている From ドメインと必要な関係を持っているかどうかを確認します。この問題を診断する方法は、グリーン パスのラベルを数えるのではなく、これらの ID を比較することです。
受信したメッセージから ID を収集する
受信側システムから、信頼できる認証結果を含む元のメッセージを取得します。パスを示す任意のヘッダーは、信頼できない送信者によって提供される可能性があります。証拠を生成した受信境界を特定する RFC 8601 §7.1.
次のフィールドを記録します。
- 証拠: ドメインから表示可能。確立するもの: 作成者ドメイン (表示されている From アドレス内のドメインを意味します)
- 証拠: SPF結果と評価 メール送信元 身元;確立する内容: 接続元がそのエンベロープ ID に対して承認されているかどうか
- 証拠: 各DKIM結果とその d= ドメイン。確立する内容: どのドメインの署名が検証されたか
- 証拠: 適用可能な aspf および adkim モード。確立するもの: 正確なドメイン関係が必要か、それとも緩和されたドメイン関係が必要か
- 証拠: 信頼できるDMARC結果と診断コンテキスト。確立するもの: 受信者の観察された評価
下 RFC 5321 §4.4、通常のメッセージの場合、配信される Return-Path 封筒の返送者の身元を特定するのに役立ちます。表示フィールドがSMTPストーリー全体を伝えていると仮定するのではなく、信頼できるSPF結果と関連付けて証拠をルーティングします。
うまくいった例: 2 つのパス、整合された ID なし
これは、キャプチャされた顧客メッセージではなく、適用可能な有効なポリシーと完了したチェックを想定した合成図です。
- フィールド: 差出人;観察された値: accounts@example.com
- フィールド: SPF ;観測された値: bounce.example.netに合格
- フィールド: DKIM ;観察された値: d=example.orgで渡す
- フィールド: DMARC アライメント;観察された値: 渡されたドメインはどちらもexample.comと一致しません
どちらのメカニズムもそれぞれの仕事で成功しました。どちらとも必要な関係を確立していません example.com, そのため、表示されている From ドメインに対してDMARCパス パスは提供されません。
サポートされている修正により、顧客ドメインが構成される可能性があります DKIM署名。もう 1 つの可能性は、パス調整されたSPFパスを生成するサポートされているカスタム エンベロープ ドメインです。どのオプションが利用できるかは、実際の発送商品とルートによって異なります。
DNS値を発明しないでください。サポートされている構成をサービスから取得し、正しい所有者名で公開し、関連する送信機能を有効にして、同じアプリケーション ワークフローを通じて新しいテストを送信します。
厳格なアライメントと緩和されたアライメントを正しく適用する
厳密な位置合わせでは、関連するドメインが以下で正確に一致する必要があります。 RFC 9989 §3.2.10.2、どちらのメカニズムでも。関連するDKIMおよびSPF識別子は、次のように指定されます。 RFC 9989 §4.4.1 そして RFC 9989 §4.4.2、 それぞれ。緩和された調整により、 DMARC適用可能な組織ドメイン関係と検出ルールを使用します。 RFC 9989 §4.10.2.
単純な例では、エンベロープ ID を次のように渡します。 bounce.example.com From ドメインと一致させることができます example.com リラックスしたSPFアライメントの下で。 2 つの名前が異なるため、厳密なSPFアライメントを満たしていません。
組織ドメインの検出を、常に最後の 2 つのラベルを取得するルールに一般化しないでください。ドメイン境界と現在のDMARC検出ルールが重要です。より複雑なドメイン構造については、実際のポリシーと実装を確認してください。
複数のDKIM署名が存在する場合は、関連するすべての署名を検査します。 1 つの非整列パッシング署名は、別の整列されたパッシング署名を無効にしません。逆に、失敗した署名にドメインが存在してもパス パスは作成されません。
送信サービスでサポートされている ID 設定を見つける
これは多くの場合、チームが CRM、請求ツール、またはキャンペーン サービスの使用を開始した後に発生します。ベンダーは認証が有効になっていると言っていますが、一部の受信者がメッセージを拒否しています。ビジネスがあなたのドメインを表示している間にプラットフォームが独自のドメインを認証する場合、両方のステートメントが真になります。
オペレータに、影響を受けるメッセージを 1 つ表示し、表示されている送信者、エンベロープ送信者、および署名ドメインについて説明するよう依頼します。有用な解決策は、実際のビジネス ワークフローがサポートされている調整された ID を介して送信していることを示しています。 2 つの緑色のチェックが表示されたスクリーンショットでは不十分です。
アプリケーション所有者を常に関与させてください。適切な修正とは、従業員メール プラットフォームの変更ではなく、そのサービスの設定またはプラン固有の機能である可能性があります。
元のルートで修正をテストする
影響を受けるサービスを通じて、制御された置換メッセージを送信します。 From ドメイン、エンベロープ ID、および関連するすべてのDKIM署名を前のサンプルと比較します。信頼できる受信者の結果と構成の変更を一緒に保管します。
単純な直接テストに合格してもビジネス ルートが引き続き失敗する場合は、転送、ゲートウェイ、およびメッセージの変更を検査します。どの認証パスが存続するかを変更することができます。また、 DMARCパスと受信ボックスの配置を区別します。受信機は追加のフィルタリングを適用できます。 RFC 9989 §5.4.
を使用します。 Microsoft 365ガイド または Google Workspaceガイド これらのシステムが実際の送信者です。メッセージが別のアプリケーションを使用している場合は、そのアプリケーション自体のルートを調査します。使用 集計レポート 観察されたトラフィック全体で同じパターンを探します。
失敗が何を物語るかを決める
アライメントの失敗により、技術的な結果が確定します。それ自体では、メッセージが正当なものであったのか、不正なサービスであったのか、転送による被害者であったのか、なりすましの試みであったのかを証明するものではありません。
新しい信頼を承認する前に、送信者の所有者とビジネス目的を要求します。共有インフラストラクチャと認識可能なプロバイダー名は有用な手がかりですが、組織がアカウントまたはワークフローを承認したことを証明するものではありません。
受け入れられた修正の範囲を記録します。調整された署名 ID は、後でアカウントが侵害されたり、アプリケーションが安全でないコンテンツを生成したりしても、 DMARC満たすことができます。アカウント管理、アプリケーションの検証、機密取引の独立した承認を継続します。
実践的なポイント
影響を受けるワークフローが、信頼できる受け渡しの調整結果を含む新しいメッセージを生成したら、問題を解決します。 ID の比較と構成の変更をまとめて保存します。これにより、元のメッセージが失敗した理由と、修正が機能した理由の両方が説明されます。
次の決定を明確にする
2パスフィクスチャの場合は、「 SPFが壊れている」ではなく「パスパスが揃っていない」と記録します。修復するサービス サポート ID を選択し、新しい同一ワークフロー メッセージが検証されるまで変更を保留のままにします。ポリシー検出またはDNS処理が不完全な場合は、観察を強制的に合格/失敗ラベルに設定しないでください。 RFC 9989 §5.3.6 必要なDNSエラーを個別に処理します。顧客による構成や納品テストは行われませんでした。