DDEIにおける送信者ドメイン認証の概要及びその他の機能につきましては、こちらをご参照ください。
本KBでは、SPF認証機能についてご紹介します。
SPFの概要
SPFはRFC7208にインターネット標準として規定されています。以下、概要について簡単にご紹介します。検証するドメイン
SPF ではメッセージヘッダ (From ヘッダ) ではなく、エンベロープの送信者 (SMTP トランザクションにおける MAIL FROM のコマンドに指定されたメールアドレス) のドメインを検証します。
また、配信不能通知 (バウンスメール) など、一部のメッセージは MAIL FROM に null ("<>") を指定する決まりであるため、その場合、送信者のドメインとして、SMTP クライアント (配送元のメールサーバやメールクライアント) が HELO/EHLO コマンドに指定するホスト名が検証対象となります。
SPFレコード
ドメインが SPF に対応している場合、次のような SPF レコードが DNS の TXT レコードで登録されています。
v=spf1 +mx a:smtp.example.com ip4:192.168.1.100 ip4:192.168.2.100 -all
SPF レコードは左から右に順に評価され、修飾子 ("+" や "-" など) によって評価が決定します。
+: Pass (修飾子が指定されていない場合は + とみなされます)
-: Fail
~: Softfail
?: Neutral
したがって、前述の SPF レコードは以下の意味になります。
| +mx | MX レコードに指定されたホスト (そのホストに対する A レコードのIPアドレス) は評価を Pass とします |
| a:smtp.example.com | smtp.example.com の A レコードに登録されたIPアドレスは評価を Pass とします |
| ip4:192.168.1.100 | IPv4 のIPアドレス 192.168.1.100 は評価を Pass とします |
| ip4:192.168.2.100 | IPv4 のIPアドレス 192.168.2.100 は評価を Pass とします |
| -all | 上記に合致しない接続元IPアドレスは評価を Fail とします |
例えば gmail.com の場合、2019年4月現在、SPF レコードは次のようになっています。
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
"redirect" は _spf.google.com の SPF レコードにリダイレクトすることを意味しています。_spf.google.com の SPF レコードは次のようになっています。
_spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
"include" は _netblocks.google.com や _netblocks2.google.com, _netblocks3.google.com の SPF レコードを再帰的に評価することを意味しています。例えば _netblocks.google.com の SPF レコードには多くのIPアドレスの範囲が指定されています。
_netblocks.google.com. 3600 IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
したがって、gmail.com の SPF レコードは _spf.google.com にインクルードされた _netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com の各 SPF レコード の評価に依存します。
SPFの評価
SPF の検証では、次のいずれかの評価が返されます。
| 評価 | 説明 |
|---|---|
| None | ドメインに SPF レコードがない場合など。 |
| Neutral | 接続元IPアドレスが "?" と判定された場合。許可/拒否を示さない場合に使用。 |
| Pass | 接続元IPアドレスが "+" と判定された場合。明示的に許可する場合に使用。 |
| Fail | 接続元IPアドレスが "-" と判定された場合。明示的に拒否する場合に使用。 |
| Softfail | 接続元IPアドレスが "~" と判定された場合。弱い拒否を示す場合に使用。 |
| Temperror | DNS サーバに接続できないなど、一時的なエラーで評価できなかった場合 |
| Permerror | ドメインの SPF レコードの記述に問題があり、評価できなかった場合 |
SPFの設定
管理画面の[管理] > [送信者フィルタ/認証] > [SPF]から設定します。
1.SPF(Sender Policy Framework)を有効にする
SPF認証を有効にする場合にチェックを入れます。2.メールメッセージにX-Headerを挿入する
SPF認証の結果をメールにXヘッダとして付与する場合にチェックを入れます。有効な場合、X-TM-DDEI-Authentication-Resultsヘッダが付与され、ヘッダ値にSPF認証結果が記載されます。
後述いたしますが、コンテンツフィルタルールでSPF認証結果を条件として使用する場合は、本設定を有効にする必要があります。
3.HELO/EHLO ID
エンベロープ送信者が<>(空)のメールに対し、HELO/EHLOで指定されたドメイン名を使用してSPF認証を試みる場合にチェックを入れます。ただし、本機能は後述のエッジMTAリレーサーバの設定が空の場合にのみ有効となります。4.送信者ドメインの検証
SPF認証を実施する送信者ドメインを設定します。-すべて
全てのドメインに対しSPF認証を試みます。
全メールについてDNSのSPFレコードを参照することになるため、その分負荷が増大する可能性があります。
-送信者ドメインの指定
SPF認証を試みるドメインを個別に設定します。
サブドメインを登録する場合、"*.example.test"のようにワイルドカードでの指定が可能です。
5.検証結果に基づく処理
SPF認証結果毎に、実施する処理を設定します。処理は以下から選択します。
-バイパス
メールを受信し、後続のフィルタリング処理を継続します。
-一時的にブロック
SMTPクライアントにSMTP 4xx系応答を返却いたします。
-常にブロック
SMTPクライアントにSMTP 5xx系応答を返却いたします。
エッジMTAリレーサーバ設定について
DDEIの前段に別途内部MTAが存在する場合、DDEIの接続元IPアドレスが常に当該内部MTAになるため、デフォルトでSPF認証は期待通り動作いたしません。
その場合は、各内部MTAのIPアドレスを管理画面の[管理] > [メール設定] > [エッジMTAリレーサーバ]に登録してください。
エッジMTAリレーサーバにIPアドレスを登録すると、DDEIはこれらのIPアドレスを内部のメールサーバと認識します。
そして、メールのReceivedヘッダを確認し、内部にメールを送信したメールサーバのIPアドレスを"接続元IPアドレス"とみなしてSPF認証を試みます。
コンテンツフィルタルールでのSPF認証結果の使用
管理画面の[ポリシー] > [ポリシー管理]にて、各種ポリシールールを設定可能ですが、コンテンツフィルタルールの条件「送信者の認証結果」に"SPF"という条件が用意されております。
これにより、コンテンツフィルタルールでもSPF認証結果をルールの条件して使用することができます。
ただし、使用には以下が必要となります。
- [管理] > [送信者フィルタ/認証] > [SPF]にて、"メールメッセージにX-Headerを挿入する"の有効化が必要です。
- [管理] > [送信者フィルタ/認証] > [SPF]にて、"検証結果に基づく処理"でメールが"バイパス"されている必要があります。