+a管理者が SPF レコードでalongを使用することが多いのはなぜでしょうか+mx? 次に例を示します。
@ 10800 IN TXT "v=spf1 +a +mx -all"
パラメータのみを使用するだけでは十分ではないでしょうか+mx:
@ 10800 IN TXT "v=spf1 +mx -all"
MX レコードの役割は電子メールの送信であり、A レコードの役割ではないと思っていました。なぜ+aそれを使用するのか、そのシナリオを説明していただけますか?
答え1
a率直に言って、SPFの基本原理を知らずに、チュートリアルやサンプル設定から設定をコピーしたからです。たとえば、受信側と受信側のWebサーバーの両方がメール交換 mxメールの送信にも使用されますが、常に使用されるわけではありません。
追加のDNSクエリが少ないメカニズムを優先する方が良いでしょう: ip4/ip6何度aもa繰り返しmx(RFC 7208、10.1.1）そして、管理を容易にするために（10.1.2）、メカニズムが選択される場合、必ずしもまたはではaなく、例えば となります。a mxaa:relay.example.com
答え2
記録に載っているホストの任務MXは受け取る電子メール、必ずしも届ける電子メール。
受信メールと送信メールを処理するホストが同じではない非対称設定を持つことは、まったく問題ありません (特に大規模な運用では、かなり一般的です)。
つまり、 SPFのmx（別名+mx）またはa（別名+a）のいずれかが、どのホストが届ける電子メール。
たとえば、独自のメール サーバーを実行していない場合は、次のようなものがv=spf1 include:spf.majoremailserviceprovider.example -allより適切かもしれません。
なぜこの組み合わせが特に SPF レコードで過剰に表現されているように見えるのかという質問に直接答えるとa mx、この状況は、SPF の概念を十分に理解せず、ポリシーに何を入れるべきかを判断せずに SPF レコードを追加している管理者が多すぎるためであり、代わりに恣意的に作成された例をコピーして貼り付けているだけであると私は推測します。
答え3
+a +mxおそらくカーゴカルトの反慣用句である他の回答に同意します。
いつ使用するかについては+a、RFC文書で次のように答えています。セクション10.1.2:
個々のホストの SPF レコードを公開することもベスト プラクティスです。ホスト名は通常、5321.HELO/.EHLO コマンドで使用される ID です。5321.MailFrom が null のメッセージの場合、これは 5321.MailFrom SPF チェックのドメインとして使用され、さらに 5321.HELO/.EHLO ベースの SPF チェックでも使用されます。メール処理に関係する個々のホストの標準 SPF レコードは次のとおりです。
relay.example.com. IN TXT "v=spf1 a -all"
たとえば、私は、mail.mydomain.org最初に HELO ID を検証する検証者のために、自分のメール サーバーにそのようなレコードを公開しています。(もちろん、v=spf1 mx -allメール ドメインmydomain.org自体でも慣例的なレコードを公開しています。)
答え4
長さの利点があるかもしれないが、これが本当の動機である可能性は非常に低い。
TXT レコードのサイズが大きくなり、単一の UDP パケットでは小さすぎる可能性があることを考慮してください。そのため、要求は TCP で再度送信され、応答は複数の TCP パケットと関連するハンドシェイク セットアップ時間になります。
A および MX 要求を慎重に使用することで、SPF レコードに対して 2 つの約 1500 バイトの UDP 応答 (1 つは A 用、もう 1 つは MX 用) と、すべての TXT レコードに対して残りの約 1400 バイトを取得できます。
これは、SPF レコードに 3000 バイトを超える十分な承認済みの「もの」があることを前提としています。インクルードは長さの制限を回避することもできますが、それぞれが個別の UDP 要求になるのか、単一の TCP 要求セッションになるのかは不明です。