まとめ
- ひとつの FQDN に対して 複数の SPF レコードを設定する場合の書式に注意する
- ルックアップ回数の制限（10回）に注意し、必要に応じて Flattening を行う
SPF レコードとは
SPF (Sender Policy Framework)とは、 電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。 SPFの仕様は、 RFC4408で定められています。
メール配信に関する設定をおこなうさいにいじることになるやつです。
RFC 4408, 7208
RFC に定めがありますので、7208 を参照するのがよいです。
後述するルックアップ回数制限についても記述があります。
4.6.4. DNS Lookup Limits
SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS.
複数の SPF レコードを設定する場合
例えば、Firebase 用に SPF レコードを設定したあとに、別途 SendGrid 用の設定を行う必要がでてきた、、といった場合。
- 誤り : 複数の TXT, SPF レコードを設定する
TXT @ "v=spf1 include:_spf.google.com ~all"
TXT @ "v=spf1 include:_spf.firebasemail.com ~all"
- 正解 : 記述をマージして 1レコードとして設定する
TXT @ "v=spf1 include:_spf.google.com include:_spf.firebasemail.com ~all"
DNS 管理サービスの仕様によっては '誤り' のほうで設定できてしまうので注意する。
ルックアップ回数の制限について
前述の RFC 7208 に記載のある「4.6.4. DNS Lookup Limits」の件です。
次の記事が詳しかったのでシェア。
自前で頑張るほか、SPF の Flattening サービスを利用する選択肢もあります。
SPF レコードのチェック方法
Validation を行えるサービスがあるので利用します。
We did not find problems with your SPF record.
となればOK。
残された謎
よくある RFC 違反として、「複数レコードの設定時の書式間違い」「ルックアップ制限の超過」があると思います。ただし経験上、じっさいに運用されているルールはもう少し寛容なのではないかと感じています。
例えば上記2つの違反をしていたとしても、レコード自体が設定されている場合、Gmail クライアントで（わかりやすい形では）警告は表示されないと思います。とはいえサイレントで迷惑メール判定の確率をあげられてしまっている可能性はあるので、Validation の結果をできるだけグリーンにしておくことが推奨されます。
ということで、正しく SPF レコードを運用しましょう。
Discussion