テスト SPF DNSが公開するものと、特定のメッセージに対して受信者が評価したものという 2 種類の証拠が必要です。 Dig と nslookup は最初の検査に役立ちます。信頼できる Authentication-Results フィールドまたは受信側のトレースは、2 番目の検査に役立ちます。これらの観測は、同じエンベロープ ドメイン、送信ルート、および時間枠によって接続されたままにします。
適切なドメインから始める
調査しているアプリケーションを通じて代表的なメッセージを送信し、元のヘッダーを保存します。次を使用して、信頼できる受信者の証拠からエンベロープ ID を特定します。 Return-Path 表示されている From アドレスと混同するのではなく、手がかりとして使用できます。空のリバース パスの場合、 SPFの ID 処理には次のことが含まれます。 HELO;通常のメッセージ入力がそのケースをカバーするとは想定しないでください。 RFC 7208 §2.3 そして RFC 7208 §2.4 アイデンティティを説明します。
受信者が観測した送信 IP、エンベロープ ID、受信者システム、メッセージ時刻を書き留めます。色付きの結果を取得するためだけに、完全なプライベート ヘッダーを馴染みのないパブリック チェッカーにアップロードしないでください。最小限の制御されたフィクスチャは、多くの場合、無関係なメッセージ データを開示することなく、技術的な質問に答えることができます。
公開されたTXT応答を検査する
これらは読み取り専用コマンドの例です。例の名前を評価対象のドメインに置き換えます。それらは、すでに実行されたテストの証拠ではありません。
TXT bounce.example.comを掘ります。 nslookup - type=TXT bounce.example.com 。の BINDディグマニュアル クエリユーティリティの文書化、および Microsoft の nslookup リファレンス クエリ オプションについて説明します。絶対クエリ名の末尾のドットを使用して、意図しない検索サフィックスの拡張を回避します。トラブルシューティングの際は、リゾルバー、ステータス、回答、TTL が表示されている場合は、完全な応答を保存してください。短縮された回答は読みやすいですが、診断のコンテキストが省略されます。
実際の所有者名を調べ、無関係な名前からSPF値を選択します。 TXTレコード。引用符で囲まれた複数の文字列が 1 つのTXTレコードに属することができます。 SPF 、これらの文字列をスペースを挿入せずに連結したものとして扱います。 2 つの個別に適用可能 SPFレコード は別の問題です。 RFC 7208 §3.2 そして RFC 7208 §3.3 その区別を定義します。
ペアになった合成結果を読み取る
以下は完全に合成された備品であり、観察されたメールや制作記録ではありません。受信者がドキュメント アドレス192.0.2.10からの直接接続を認識したと仮定します。 メール送信元 invoices@bounce.example.comおよび From invoices@example.comから表示されます。そのDNS応答には、1 つのTXTリソース レコードが含まれています。
bounce.example.com 。 300 IN TXT " v=spf1 ip4:192.0.2.10 " " -all "1 つのレコード内の 2 つの文字列が結合されます。 v=spf1 ip4:192.0.2.10 -all。最初の文字列の末尾のスペースはメカニズムを区切ります。指定された接続では、アドレス メカニズムが一致し、予想されるSPF結果が合格です。対応する受信機の結果例は次のとおりです。
Authentication-Results : mx.receiver.example ; spf=pass smtp.mailfrom= bounce.example.commx.receiver.exampleが宛先の信頼できる認証サービスであるという明示的なフィクスチャの仮定の下でのみ、これを信頼できるものとして扱います。そうしないと、送信者が同様のテキストを挿入する可能性があります。この例では、 SPF証拠のみを示します。それは主張しません DKIM, DMARC または納品結果。
これを、同じ名前で 2 つの個別の該当するレコードが含まれている、次の別の合成DNS回答と比較してください。
bounce.example.com 。 300 IN TXT " v=spf1 ip4:192.0.2.10 -all " bounce.example.com 。 300 IN TXT " v=spf1 ip4:192.0.2.20 -all "レコードの選択が戻るようになりました permerror 権限を組み合わせるのではなく。引用符だけを数えて状況を診断しないでください。 DNSリソースとレコードの境界を保持します。
パブリケーションに異議がある場合のリゾルバーの比較
DNSエディターと再帰的クエリーが一致しない場合は、権限のあるクエリーを特定します。 ネームサーバー 検証された権限のあるサーバーに直接クエリを実行します。 Dig はフォームをサポートします dig@サーバー名TXT;実際に検証されたサーバー名とターゲット名を置き換えます。答えとタイムスタンプを再帰的な結果と比較します。編集中のDNSアカウントが委任ゾーンをホストしていると想定しないでください。
現在の信頼できる回答と古い再帰的回答は、キャッシュを示している可能性があります。タイムアウト、 SERVFAIL 、および該当するレコードがない正常な応答は、別の観察です。原因を特定する前に、正確な応答を保存してください。 1 つの観測が古いという理由だけで、正しいレコードを繰り返し編集することは避けてください。
構文だけでなくメッセージを評価する
TXTルックアップではSPFは実行されません。標準対応の評価者には、接続 IP と関連するSMTP ID に加えて、解決されるDNS状態が必要です。トレースを調べて、一致するメカニズム、依存関係、エラーを調べます。静的レコード検証ツールは、実際の送信者が合格したかどうかには答えずに、構造的に許容可能なポリシーを報告する場合があります。
宛先では、以前の任意のコピーではなく、信頼できる受信者によって挿入されたAuthentication-Resultsを読み取ります。 RFC 8601 信頼境界が重要になります。 SPF結果と ID を、互換性のあるものとして扱うことなく、 DKIMおよびDMARC結果と一緒に記録します。
再現可能なテスト記録を保管する
コマンド、クエリ時間、 DNS応答、評価者の入力、編集された受信メッセージの証拠を保存します。使用されている実質的に異なるアプリケーション ルートとアドレス ファミリをそれぞれテストします。合成器具には観察結果とは別にラベルを付けます。 DNSビューが正しいように見えても受信者が同意しない場合は、次の手順に進みます。 ツールのパスと受信者の失敗 受信者が間違っているに違いないと宣言するのではなく。
DNS背景: RFC 1035セクション 3.2.1 リソース レコード TTL を定義します。 RFC 2308 §5 ネガティブ キャッシュについて説明します。 RFC 8767 §4 TTL セマンティクスを更新し、権限のあるリフレッシュが失敗した場合に古い使用を許可します。これらはDNS動作を説明するものであり、変更の普遍的な完了時間を示すものではありません。
次の決定を記録する
単一レコードのフィクスチャの場合は、1 つのレコード内の 2 つの文字列と結合スペースを示す境界を維持します。期待されるSPFは192.0.2.10に合格します。 2 レコードのフィクスチャの場合、メカニズムが評価される前に選択がpermerrorで失敗します。信頼できる結果の仮定を個別に保存します。印刷されたAuthentication-Resultsテキストは、単独では信頼できません。ここではコマンドやメール検証は実行されませんでした。