上記サイトからの抜粋だけど、毎回忘れるのでメモまでに。
送信メールが送り先のメールサーバになりすましメールと判定されずに正しいメールとして判断してもらうためには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のサイトを使った。
digコマンドを使っても良い。
前提知識としてSPFの主な設定パターンは次の通り。
詳細についてはIAJapan 10. SPFレコードの記述例やSendGrid 送信ドメインを認証するための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のメールサービスを使う場合は_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の基本」のスライドも為になる。
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」ぐらいに短くしても問題は起きにくいとのこと。