SPF の1行の読み方（include・ip4・mx・all）、受け取る側がどのドメインの何を照らし合わせるのか、なぜ「相手の番号」なら信じてよいのか、7種類の結果、そして SPF の2つの穴（画面の From を見ない・転送で壊れる）と、1行だけ・10回まで、という落とし穴までを説明します。
4本目で、メールの身元確認は「持ち主が DNS に宣言を書き、受け取る側が照らし合わせる」形で後から足された、と説明しました。この作品では、その1つ目である SPF（Sender Policy Framework）を詳しく見ます。
SPF の考え方は単純です。ドメインの持ち主が、DNS に次のような宣言を書いておきます。
「うちのドメインのメールを送ってよいのは、このサーバーたちだけです」
図の下の掲示板にある1行がそれです。
send.mail.animemo.app TXT "v=spf1 include:amazonses.com ~all"受け取る側は、メールを送ってきた相手がこの一覧に入っているかを確かめます。入っていれ ば、「このドメインの持ち主が許可したサーバーから来た」と言えます。
この作品では、この1行の読み方から始めて、受け取る側が実際に何を照らし合わせているのか、そして SPF だけでは防げない穴まで見ていきます。
SPF の宣言は、空白で区切られた部品の並びです。
| 部品 | 意味 |
|---|---|
v=spf1 | これは SPF の宣言です（必ず先頭に書く） |
include:amazonses.com | amazonses.com が公開している SPF の一覧を、そのまま含める |
ip4:203.0.113.0/24 | この IPv4 アドレスの範囲を許可する（ip6: もある） |
a | このドメインの A レコード の機械を許可する |
mx | このドメインの MX の機械を許可する |
~all | 上のどれにも当てはまらない送信元の扱い（次のページ） |
左から順に調べて、最初に当てはまったもので結果が決まります。
いちばんよく使うのは `include:` です。Resend（中身は Amazon SES）のような送信サービスは、自分たちの送信サーバーの番号を自分のドメインの SPF で公開しています。include:amazonses.com と書けば、Amazon SES の番号が増えたり変わったりしても、こちらの宣言を書き換えずに済みます。
/24 は番号の範囲の書き方で、203.0.113.0 から 203.0.113.255 までの256個をまとめて指します。
SPF の最後には、all の前に記号を付けて、一覧に無い送信元から来たメールをどう扱ってほしいかを書きます。
| 書き方 | 結果の名前 | 意味 |
|---|---|---|
-all | fail | 偽物と断定してよい |
~all | softfail | たぶん偽物（疑わしい） |
?all | neutral | 何とも言わない |
+all | pass | 何でも許可（使ってはいけない） |
Resend の画面に出てくる値は ~all です。-all のほうが厳しくて安全に見えますが、自分でも忘れていた正規の送信元が一覧から漏れていたとき、そのメールが偽物扱いされてしまいます。まずは ~all で運用するのが普通です。
また、SPF が fail になっても、実際にメールをどう扱うか（受信トレイか、迷惑メールか、拒否か）は、最終的には受け取る側が決めます。今は、7本目の DMARC の宣言と合わせて判断されることが多くなっています。
+all は「誰が送ってもよい」という意味なので、SPF を書く意味がなくなります。書いてはいけません。
では、受け取る側（Gmail）が SPF をどう確かめるのかを、順に見ていきます。
最初に、どのドメインの SPF を読むかを決めます。見るのは、3本目で出てきた封筒の差出人（SMTP の MAIL FROM）のドメインです。図の例では send.mail.animemo.app です。
ここが大事なところです。画面に出る手紙の `From:` ではありません。 SPF は、SMTP の会話の中で名乗られた封筒の差出人について確かめる仕組みです。
Gmail は send.mail.animemo.app の掲示板から TXT を読み、v=spf1 で始まる行を探します。そこに「送ってよいのは Amazon SES」と書いてあります。
※届かなかった知らせ（バウンス）のように封筒の差出人が空のメールでは、代わりに EHLO で名乗った機械の名前を使って SPF を確かめます。
次に Gmail は、いま自分と SMTP の会話をしている相手の IP アドレスを見ます。
その番号が、読んできた一覧（include:amazonses.com の中身）に入っていれば、SPF は pass（合格） です。図では、送ってきたのが Amazon SES のサーバーで、一覧にも Amazon SES が入っているので合格しています。
まとめると、SPF は次の2つを組み合わせています。
| 材料 | なぜ信じてよいか |
|---|---|
| 掲示板に書かれた一覧 | 持ち主しか書けないから（2本目） |
| 相手の番号 | 嘘の番号では会話が続かないから（次のページ） |
この2つがそろうことで、「このドメインの持ち主が許可したサーバーから来た」と言えるようになります。
SPF は「相手の番号」を信じる前提に立っています。メールの From: は自由に書けるのに、番号は信じてよいのはなぜでしょうか。
1本目で、通信の小包には差出人の番号が書かれている、と説明しました。この番号を偽ることはできます。ところが、偽の番号を書くと、受け取った側の返事は、その偽の番号あてに送られます。本当の送り手には返事が届きません。
SMTP は、送る側が1行言い、受ける側が返事をする、という会話を何往復も続けます。返事が届かなければ、次に何を言えばいいか分からず、会話が進みません。当然、メールを最後まで渡すこともできません。
つまり、SMTP の会話が最後まで成り立った相手の番号は、本物とみなしてよいのです。SPF はこの性質を利用しています。
SPF を確かめた結果には、名前が付いています。
| 結果 | 意味 |
|---|---|
| pass | 一覧に入っている |
| fail | 一覧に無い（-all） |
| softfail | 一覧に無い（~all） |
| neutral | 何とも言っていない（?all） |
| none | そもそも SPF の宣言が無い |
| permerror | 宣言が壊れていて読めない（書き方の間違い） |
| temperror | DNS が一時的に引けなかった |
ふだん気にするのは、pass・fail・softfail の3つです。
もう1つ覚えておきたいのが permerror です。これは「設定した側の書き方が間違っている」ことを表します。permerror になると、せっかく書いた SPF が無いのと同じ扱いになり、正規 のメールまで身元が確かめられなくなります。この作品の後半で、permerror になる典型的な間違いを2つ見ます。
ここからは、SPF だけでは防げない穴を見ます。
1つ目の穴は、SPF が確かめるのが封筒の差出人だけだということです。受信者の画面に出る手紙の `From:` は見ていません。
図では、なりすましの送り手が、封筒の差出人を自分のドメイン evil.example にしています。自分のドメインなので、SPF の宣言も自分で書けます。送ってくるのも自分のサーバーなので、SPF は合格します。
一方で、手紙の From: には 〇〇銀行 <[email protected]> と書いてあります。受信者の画面に出るのはこちらです。
SPF は「封 筒の差出人は本物」と言っているだけで、「画面の差出人は本物」とは言っていません。利用者が目にするのは画面の差出人なので、これはなりすましを防ぐうえで致命的な穴です。この穴は、7本目の DMARC が塞ぎます。
2つ目の穴は転送です。
太郎さんが、大学のメールアドレスに届いたメールを、Gmail へ自動転送する設定にしていたとします。すると、メールは Resend → 大学のサーバー → Gmail と運ばれます。
Gmail から見ると、SMTP の会話をしている相手は大学のサーバーです。封筒の差出人は send.mail.animemo.app のままなので、その SPF の一覧を見ますが、大学のサーバーは載っていません。SPF は不合格になります。
メールは正規のものなのに、転 送されただけで落ちてしまいます。SPF は「どの番号から来たか」を見る仕組みなので、途中で経路が変わると必ず壊れます。これは SPF の設定をどう工夫しても避けられません。
この穴は、6本目の DKIM が埋めます。DKIM は経路ではなく、メールそのものに印を付ける方式だからです。
ここからは、SPF を設定するときの落とし穴です。
Google Workspace を使っているドメインに、あとから別のサービスの SPF を足すとき、もう1行増やしてしまうのは典型的な失敗です。
SPF の宣言は、1つの名前につき1行だけと決まっています。v=spf1 で始まる行が2つあると、受け取る側はどちらを信じればよいか分からず、permerror（宣言が壊れている）として扱います。善意で足した1行のせいで、それまで合格していたメールまで落ちます。
正しくは、include: を並べて1行にまとめます。
v=spf1 include:_spf.google.com include:amazonses.com ~allなお、v=spf1 で始まらない TXT（ほかのサービスの確認用の文字列など）は、同じ名前に何行あっても構いません。問題になるのは SPF の行だけです。
もう1つの落とし穴は、DNS を引く回数の上限です。
受け取る側は SPF を確かめるとき、include: の先の一覧を DNS で引きに行きます。その先にさらに include: があれば、それも引きます。この「DNS を引く部品」（include・a・mx など）の数は、合計で10回までと決まっています。ip4: や ip6: は DNS を引かないので数えません。
上限がある理由は、受け取る側を守るためです。1通のメールのたびに何十回も DNS を引かされると、受信サーバーが重くなり、悪用もされやすくなります。
使っているサービスを次々に include: で足していくと、自分では数回のつもりでも、各サービスの一覧の中の include: まで数えて10回を超えてしまうことがあります。超えると permerror です。
対策として有効なのが、送信用のサブドメインを分けることです。Resend のように send.mail.animemo.app という別の名前に SPF を置けば、ほかのサービスの一覧と混ざらず、回数も数えやすくなります。
10本目で Resend の設定をすると、SPF の行を send.mail.animemo.app（管理画面では send.mail）という名前に入れるよう指示されます。mail.animemo.app そのものではないのはなぜでしょうか。
理由は、この作品の前半で見た「SPF は封筒の差出人のドメインで読まれる」ことにあります。Resend は、封筒の差出人を …@send.mail.animemo.app にしてメールを送ります。だから SPF も、その send.mail.animemo.app の掲示板に置く必要があるのです。
封筒の差出人を専用の名前にしているのには、ほかにも理由があります。
| 理由 | 中身 |
|---|---|
| 戻りの受け口を作る | 届かなかった知らせを Resend が受け取れるように、同じ名前に MX も置く（10本目） |
| 普段の設定とぶつけない | mail.animemo.app や animemo.app の SPF とは別の行になる |
| 回数を数えやすくする | 前のページの10回の上限に引っかかりにくい |
画面に出る From: は [email protected] のままで、封筒だけが send.mail… になります。この2つが別のドメインでも問題ないことは、7本目の DMARC で確かめます。
この作品で見たことをまとめます。
| 項目 | 内容 |
|---|---|
| 何を宣言するか | このドメインのメールを送ってよい送信元の一覧 |
| どこに書くか | 封筒の差出人のドメインの TXT。1つの名前に1行だけ |
| 受け取る側は何を見るか | その一覧と、SMTP の会話の相手の番号 |
| なぜ番号を信じてよいか | 嘘の番号では会話が続かないから |
| 最後の all | ~all（たぶん偽物）から始める |
| 穴① | 画面の From: を見ていない → 7本目の DMARC が塞ぐ |
| 穴② | 転送で壊れる → 6本目の DKIM が補う |
| 落とし穴 | 2行書くと permerror。DNS を引く回数は10回まで |
次の作品では、経路ではなくメールそのものに印を付ける DKIM を見ていきます。
ログインするとコメントできます。
読み込み中…
権利侵害・不適切な内容の連絡: [email protected]