SPFレコードの文字数制限とサービス別のSPFの設定の比較


* [間違いから学ぶSPFレコードの正しい書き方](http://salt.iajapan.org/wpmu/anti_spam/admin/operation/information/spf_i01/)

上記サイトからの抜粋だけど、毎回忘れるのでメモまでに。

送信メールが送り先のメールサーバになりすましメールと判定されずに正しいメールとして判断してもらうためにはSPFレコードをDNSサーバに設定する必要がある。

サーバ台数が増えてくると、SPFレコードが長くなってしまうが、1つの文字列の最長は255文字制限がある。
文字列の連結によりこの制限を超えることができる。ただし連結部分に空白を入れること

```

【誤】 /２４と"の間、もしくは”と+ip4の間に空白を入れること　
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24" "+ip4:10.0.0.0/24 ~all"

【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 " "+ip4:10.0.0.0/24 ~all"
【正】 
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24" " +ip4:10.0.0.0/24 ~all"


【正】 
example.jp.   IN TXT ( "v=spf1"
                          " +ip4:192.168.100.0/24"
                          " +ip4:10.0.0.0/24"
                          " ~all" )

```

連結したレコードの長さは450文字以上になるようであれば、includeを使って分割

```

【正】 
example.jp.   IN TXT "v=spf1 include:_a.example.jp include:_b.example.jp ~all"
_a.example.jp IN TXT "v=spf1 +ip4:192.168.100.0/24 ~all"
_b.example.jp IN TXT "v=spf1 +ip4:10.0.0.0/24 ~all"

```


## 他のサービスの状況

実際に他のサービスではどのように設定しているか調べて見た。
調べるのには[MXToolBox](https://mxtoolbox.com/SuperTool.aspx#)のサイトを使った。
digコマンドを使っても良い。

前提知識としてSPFの主な設定パターンは次の通り。
詳細については[IAJapan 10. SPFレコードの記述例](https://salt.iajapan.org/wpmu/anti_spam/admin/tech/explanation/spf/#100)や[SendGrid 送信ドメインを認証するためのSPFレコードに詳しくなろう](送信ドメインを認証するためのSPFレコードに詳しくなろう)を参考

```
# ホストのIPアドレスで記述
example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 -all"
# ホスト名で記述
example.org. IN TXT "v=spf1 a:mx01.example.org a:mx02.exmaple.org a:ns.example.org -all"
# ネットワークでの指定
example.org. IN TXT "v=spf1 ip4:192.0.2.0/28 -all"
# サブドメインに個別のSPFレコードを定義する
example.org. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.2 ip4:192.0.2.3 -all"
announce.example.org. IN TXT "v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 -all"
campaign.example.org. IN TXT "v=spf1 include:advertise.example.com -all"

```

Googleの場合

```
# gmail.com
v=spf1 redirect=_spf.google.com

# google.com
v=spf1 include:_spf.google.com ~all

# _spf.google.com
v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all

# _netblocks.google.com
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の場合、_spf.google.comにredirectされる。 
[Gsuiteなどを他のサービス経由でgoogleのメールサービスを使う場合](https://support.google.com/a/answer/33786?hl=ja)は_spf.google.comをincludeなどで指定しているようだ。
最初にincludeではなく、redirectしているのは多分、単に同じサービスの別エイリアスだからだとか、includeに使用回数制限があるからだからとかなのか。
includeを辿っていくとip4指定までたどり着く。あまりaレコード指定を使っているspfの例がないのは名前解決のコストを減らすため？



Slackの場合

```
# slack.com
v=spf1 include:amazonses.com include:mailgun.org include:u931175.wl176.sendgrid.net include:_spf.qualtrics.com -all

```
Slackの場合はip4の指定がなく、全て外部サービスのincludeのみ、自社のsmtpサーバはなくて、amazonsesやmailgun、sendgridを使って配信しているみたいだ。ちなみにqualtricsはアンケートサービス


Yahoo(米国）の場合

```
# yahoo.com
v=spf1 redirect=_spf.mail.yahoo.com
# _spf.mail.yahoo.com
v=spf1 ptr:yahoo.com ptr:yahoo.net ?all

```
Yahooの場合は、ちょっとあまり見かけない書き方をしている。
ptrは送信元ホストの逆引きと正引きが一致していたら認証OKとするやり方。負荷がかかるので一般的には推奨されていない。
「？all」は「Neutral」となっている。softfailはfailとneutralの間とのことなので送信元ホスト以外から送られてきたメールのなりすまし判断は行わない。


salesforce.comの場合

```
# salesforce.com
v=spf1 include:_spf.google.com include:_spf.salesforce.com  include:spf.mandrillapp.com exists:%{i}._spf.corp.salesforce.com ~all

# _spf.salesforce.com
v=spf1 exists:%{i}._spf.mta.salesforce.com -all

```

Salesforce.comの場合も珍しく、existsが指定されている。
existsは
>引数であるドメイン名に指定された表記でAレコードルックアップを実施し、該当のAレコードが存在すればマッチする。SPFのマクロ機能とあわせての利用を想定している

ということなので、＊＊＊._spf.mta.salesforce.comというサブドメインがあるのか。


大体のサービスがSlack方式で外部サービスのspfレコードがincludeされている場合が多かった。
自前でsmtpサーバを立てるのではなく、amazonsesやsendgrid、mailgunなどのサービスを利用するパターンが増えてきているようだ。






## 参考

あと、[「アプリケーションエンジニアが知るべきDNSの基本」](
https://speakerdeck.com/mamy1326/basics-of-dns-that-application-engineers-should-know-1?slide=105)のスライドも為になる。

```
example.jp.   IN TXT "v=spf1 +ip4:192.168.100.0/24 +ip4:10.0.0.0/24 ~all"
```

の「~all」は非推奨で、「-all」が良いとのこと。
TTL値は最近のDNSサーバのスペックは優れているので、通常「300」で、切り替え時「60」ぐらいに短くしても問題は起きにくいとのこと。