「ip4:」メカニズムへの引数は、IPv4のネットワーク範囲です。プレフィックス長が指定されていない場合は、/32とみなされます（個々のホストアドレスを指定する場合）。プレフィックス長を/16より大きく指定するように注意してください。そうしない
と、一部の小規模な受信者への配信に影響が出る可能性があります。
SPFレコードの構文
SPF構文の理解
本ガイドは、SPFに関する理解を深めていただき、当アプリケーションによって指摘された問題の解決に役立てていただくために作成されました。有効かつ正確で、設定が整合したSPFレコードを維持することで、認証の適用範囲と配信率が向上し、ドメインに対して望ましいセキュリティレベルを確保するのに役立ちます。
dmarcianのアカウントをお持ちでない場合でも、当社のSPF調査ツールを使用して、SPFレコードの内容を確認することができます。
SPFに関する詳細情報は、このドキュメントの下部に掲載されている関連記事をご覧ください。SPFを初めてご利用になる方には、「SPFレコードの作成と追加方法」をご案内しています。
今すぐ無料アカウントを作成して、dmarcianにSPF、DKIM、DMARCレコードの監視を自動で行ってもらいましょう。dmarcianのSaaSプラットフォームを活用すれば、配信エラーやフィッシング、なりすまし攻撃の試みを即座に把握できます。
メカニズム
メカニズムは、ドメインの送信元メールサーバーとして指定されたホストの集合を表すために使用でき、4つの修飾子のいずれかを接頭辞として付けることができます：
+ Pass
~ SoftFail
- Fail
? Neutral
メカニズムによってヒットとなった場合、その修飾値が使用されます。デフォルトの修飾値は「+」、つまり「成功」です。メカニズムは順番に評価されます。一致するメカニズムや修飾子が存在しない場合、デフォルトの結果は「中立」となります。
「~」と「–」の違いに関するより詳しい情報は、こちらをご覧ください
ドメインにSPFレコードがまったく存在しない場合、結果は「None」となります。DNS処理中にドメインで一時的なエラーが発生した場合、結果は「TempError」（以前の草案では「error」と呼ばれていました）となります。構文エラーや評価エラーが発生した場合（例：ドメインが認識されないメカニズムを指定している場合など）、結果は「PermError」（以前は「unknown」）となります。
例：
v=spf1 -all
v=spf1 a -all
v=spf1 a mx -all
v=spf1 +a +mx -all
SPFレコードの評価では、以下のいずれかの結果が返される可能性があります：
| 結果 | 説明 | 意図された措置 |
|---|---|---|
| Pass | SPFレコードは、送信を許可されるホストを指定します | 許可する |
| Fail | SPFレコードにより、このホストからの送信は許可されていないと指定されています | 拒否する |
| SoftFail | SPFレコードでは、このホストは送信を許可されていないと指定されていますが、移行中です | 許可する（ただし、マークを付ける） |
| Neutral | SPFレコードは、有効性については何も断定できないことを明示的に規定している | 許可する |
| None | このドメインにはSPFレコードが存在しないか、SPFレコードの評価結果が得られていません | 許可する |
| PermError | 恒久的なエラーが発生しました（例：SPFレコードの形式が不正です） | 未指定 |
| 一時的なエラー | 一時的なエラーが発生しました | 拒否する |
「all」の仕組み
all
このメカニズムは常に一致します。SPFレコードの末尾に配置する必要があります。
例：
v=spf1 mx ~all
当該ドメインのMXレコードからのメール送信を許可し、それ以外の送信をすべて禁止する。
v=SPF1 -all
このドメインからはメールが一切送信されません。
v=spf1 +all
このドメインでは、インターネット上のすべてのIPアドレスからのメール送信を許可しています。この設定は強く推奨されません。
「ip4」メカニズム
ip4:<ip4-address>
ip4:<ip4-network>/<prefix-length>
例：
v=spf1 ip4:192.168.0.1/16 ~all
192.168.0.1 から 192.168.255.255 までのすべてのIP アドレスを許可します。
「ip6」メカニズム
ip6:<ip6-address>
ip6:<ip6-network>/<prefix-length>
「ip6:」メカニズムへの引数は、IPv6のネットワーク範囲です。プレフィックス長が指定されていない場合は、/128とみなされます（個々のホストアドレスを指定する場合）。
例：
v=spf1 ip6:1080::8:800:200C:417A/96 ~all
1080::8:800:0000:0000 から 1080::8:800:FFFF:FFFF までのすべてのIPv6 アドレスを許可します。
v=spf1 ip6:1080::8:800:68.0.3.1/96 ~all
1080::8:800:0000:0000 から 1080::8:800:FFFF:FFFF までのすべてのIPv6 アドレスを許可します。
「a」メカニズム
a
a/<prefix-length>
a:<domain>
a:<domain>/<prefix-length>
ドメインのすべてのAレコードがチェックされます。クライアントのIPアドレスがそれらのリストに含まれている場合、このメカニズムが一致します。IPv6経由で接続が行われる場合は、代わりにAAAAレコードの検索が行われます。
ドメインが指定されていない場合は、現在のドメインが使用されます。
Aレコードは、クライアントのIPアドレスと完全に一致している必要があります。ただし、プレフィックス長が指定されている場合は、Aレコードの検索によって返される各IPアドレスが対応するCIDRプレフィックスに展開され、そのサブネット内でクライアントのIPアドレスが検索されます。
例：
v=spf1 a ~all
現在のドメインが使用されます。
v=spf1 a:example.com ~all
現在のドメインが example.com の場合、これと同等です。
v=spf1 a:mailers.example.com ~all
おそらく、example.com は、mailers.example.com という特別な A レコードに、すべての送信メールサーバーを明示的に記載することを選択したのでしょう。
v=spf1 a/24 a:offsite.example.com/24 ~all
example.com が 192.0.2.1 に解決される場合、192.0.2.0/24 のクラス C ネットワーク全体がクライアント IP の検索対象となります。offsite.example.com についても同様です。複数の A レコードが返された場合、それぞれが CIDR サブネットに展開されます。
「mx」メカニズム
mx
mx/<prefix-length>
mx:<domain>
mx:<domain>/<prefix-length>
ドメインのすべてのMXレコードに対応するAレコードは、MXの優先順位に従って順次チェックされます。その中にクライアントのIPアドレスが含まれている場合、このメカニズムが一致します。
ドメインが指定されていない場合は、現在のドメインが使用されます。
Aレコードは、クライアントのIPアドレスと完全に一致している必要があります。ただし、プレフィックス長が指定されている場合は、Aレコードの検索によって返される各IPアドレスが対応するCIDRプレフィックスに展開され、そのサブネット内でクライアントのIPアドレスが検索されます。
例：
v=spf1 mx mx:deferrals.domain.com ~all
あるドメインが、MXサーバーに加えて、配信保留となったドメインへのメールを再送信する役割を担う別のサーバー群を経由してメールを送信している可能性があります。
v=spf1 mx/24 mx:offsite.domain.com/24 ~all
ドメインのMXサーバーは、あるIPアドレスでメールを受信し、別の（ただし近隣にある）IPアドレスでメールを送信している可能性があります。
「ptr」メカニズム
ptr
ptr:<domain>
クライアントのIPアドレスに対応するホスト名（1つまたは複数）は、PTRクエリを使用して検索されます。その後、ホスト名の有効性が検証されます。つまり、PTRホスト名に対応するAレコードのうち、少なくとも1つが元のクライアントIPアドレスと一致している必要があります。無効なホスト名は除外されます。有効なホスト名の末尾が「.domain」で終わる場合、このメカニズムは一致とみなされます。
ドメインが指定されていない場合は、現在のドメインが使用されます。
可能であれば、SPFレコードでこの仕組みを使用するのは避けるべきです。なぜなら、これにより、負荷の高いDNSルックアップが大量に発生してしまうからです。
例：
v=spf1 ptr ~all
（ダイヤルアップやブロードバンドのISPとは異なり）自社のすべてのマシンを直接管理しているドメインは、そのサーバーすべてからメールを送信することを許可しています。たとえば、hotmail.com や paypal.com などがこれに該当します。
v=spf1 ptr:otherdomain.com ~all
ホスト名が otherdomain.com で終わるすべてのサーバーが指定されます。
「exists」メカニズム
exists:<domain>
指定されたドメインに対してAレコードの照会を実行します。結果が見つかった場合、それは一致とみなされます。照会結果が何であるかは問いません。例えば、127.0.0.2であっても構いません。
この仕組みでマクロを使用すると、RBL形式の逆IP検索を実行したり、ユーザーごとの例外設定を行ったりすることができます。
例：
次の例では、クライアントのIPアドレスは1.2.3.4で、現在のドメインはexample.comです。
v=spf1 exists:example.com ~all
example.com が解決されない場合、結果は失敗となります。解決された場合、この仕組みにより一致が成立します。
「インクルード」の仕組み
include:<domain>
指定されたドメインに対して一致するものが検索されます。検索の結果、一致するものがなかったりエラーが発生したりした場合、処理は次のディレクティブに進みます。 警告: ドメインに有効なSPFレコードがない場合、結果は永続的なエラーとなります。一部のメール受信サーバーは、PermErrorに基づいてメールを拒否することがあります。
例：
次の例では、クライアントのIPアドレスは1.2.3.4で、現在のドメインはexample.comです。
v=spf1 include:example.com ~all
example.com に SPF レコードがない場合、結果は PermError となります。
example.com の SPF レコードがv=spf1 a ~all であると仮定します。
example.comのAレコードを検索します。1.2.3.4と一致する場合、Passを返します。
含まれるドメインの「~all」以外の一致がない場合、include全体として一致しないことになります。この例で設定された外側のディレクティブから、最終的な結果は依然としてFailとなります
信頼関係 –「include:」メカニズムは、管理境界を越えることを意図しています。 「include:」メカニズムが、ユーザー間なりすましによるメッセージに対してSPFの「Pass」判定を下すことでドメインを危険にさらすことがないよう、細心の注意が必要です。指定された他のドメインにおいてユーザー間なりすましを防止する技術的措置が講じられていない限り、「include:」メカニズムは「Pass」ではなく「Neutral」の判定を下すべきです。これを行うには、「include:」の前に「?」を追加します。
例：
v=spf1 ?include:example.com ~all
修飾子
修飾子は任意です。修飾子は、1つのレコードにつき1回のみ指定できます。未知の修飾子は無視されます。
「redirect」修飾子
redirect=<domain>
ドメインのSPFレコードは、現在のレコードに置き換えられます。また、それらの検索において、マクロ展開されたドメインも現在のドメインに置き換えられます。
「redirect」修飾子が使用される場合、SPFレコードには「all」メカニズムを含めないでください。両方が存在する場合、「redirect」修飾子は無視されます。最初の「redirect」修飾子以降のものはすべて無視されます。
例：
たとえば、example.com には次のような SPF レコードが公開されています：
v=spf1 redirect=example.com
example.com に SPF レコードがない場合、それはエラーとなります。結果は不明です。
example.com の SPF レコードが v=spf1 a ~all であると仮定します。
example.com の A レコードを検索します。1.2.3.4 と一致する場合、「Pass」を返します。
一致するレコードがない場合、exec は一致に失敗し、~all の値が使用されます。
「exp」修飾子
exp=<domain>
SMTP受信側がメッセージを拒否する場合、その理由を明記することがあります。SPF発行者は、送信者に表示される説明文を指定することができます。これにより、ISPは、基準を満たしていないユーザーに対し、SASLの設定方法に関する詳細な手順が記載されたWebページへ誘導することが可能になります。
ドメインが展開され、TXTルックアップが実行されます。その後、TXTクエリの結果がマクロ展開され、送信者に表示されます。その他のマクロを使用して、カスタマイズされた説明を表示することも可能です。
exp修飾子には、表示可能なASCII文字のみを含めることができます。
例：
たとえば、example.com には次のような SPF レコードが公開されています：
v=spf1 mx -all exp=explain._spf.%{d}
また、explain._spf.example.com には、次のような文字列を含む TXT レコードがあります：
example.com からのメールは、同ドメインのメールサーバーからのみ送信されなければなりません。
検索回数が多すぎませんか？
この10年間で、メールの送信はますます容易になりました。市場には数え切れないほどのサービスが登場し、それぞれがマーケター、開発者、中小企業といった現代のニーズに合わせて特化したツールセットを提供しています。こうしたサービスの拡大に伴い、メール認証、特にSPFの取り扱いは、ますます複雑化しています。
SPF RFC仕様（いわばインターネット上のルール）には、1つのSPFレコードに含まれる「DNSクエリメカニズム」の数に実用上の制限が設けられています。その上限は10です。この10件という上限は、ドメイン管理者（つまりあなたです！）が、Gmailやその他の受信者に対し、特定のIPアドレスがあなたに代わってメールを送信することを許可しているかどうかを確認するために、10回以上の連続したDNSクエリを実行させる必要がないことを意味します。
（メールインフラの外部委託化が進んだ結果、単一の組織が多数の異なるネットブロックを管理することが一般的になってきたため）最大10件という検索制限に対して、絶え間なく不必要な負荷がかかっているように見えます。しかし、この制限は依然として極めて実用的なものであり、タイムリーな配信と高い受信箱到達率を確保するためには遵守すべきです。 さらに、この制限を回避するための解決策は、GmailやYahoo!などの主要な受信プロバイダーが長年推奨してきた、他の一般的なメール運用上のベストプラクティスによって明確に示されています。
「ルックアップ回数超過」の問題を回避する最も実用的な解決策は、サブドメインを活用することです。個々のサブドメインにはそれぞれ10回のルックアップ上限が割り当てられるため、SPFは事実上無制限となります。 例：hello.comには10回のルックアップが許可され、sub.hello.comにも10回のルックアップが許可されます。つまり、異なるメールストリーム（例：トランザクション、社内、マーケティングなど）を個別のネームスペースに適切に分割していれば、ルックアップの上限である10回に達することは決してないはずです。
Gmailのポストマスターサイトの「配信のヒント」というこのサブセクションでは、以下のことが推奨されています。
- 別のメールアドレスを使用してください
- 異なるドメインやIPアドレスからメールを送信する
要約すると、ルックアップの最大数である10件に達することはないはずです。万が一達してしまった場合、その対処法について、いくつかの追加の対策やナレッジベースの資料をまとめています。
