SPFの設定は、自社のメールを送ってよいサーバーを書いたTXTレコードを、ドメインのDNSに1本置く作業です。
今日やることは、自社のドメインを差出人にしてメールを送っているものを全部書き出すことです。Microsoft 365やGoogle Workspaceだけでなく、メール配信サービス、問い合わせフォーム、業務システムの通知も入れます。ここで漏れると、そのメールがSPFの認証に失敗します。
SPFレコードの基本の書き方は？
SPFレコードは、Googleの設定手順の言葉では「ドメインに追加する1行のテキスト」です。その1行に、ドメインに代わってメールを送るサーバーをすべて書きます。形は次のとおりです。
v=spf1 送信元 送信元 … 認証に通らない時の扱い
使う語はそれほど多くありません。
| 書くもの |
意味 |
例 |
| v=spf1 |
SPFレコードの宣言。必ず先頭 |
v=spf1 |
| include: |
別のドメインの送信元を取り込む |
include:_spf.google.com |
| ip4: / ip6: |
IPアドレスを直接書く |
ip4:192.0.2.10 |
| ~all / -all |
書いていない送信元の扱い |
~all |
自社で使うメールサービスごとの書き方は、公式の文書に出ています。
Google Workspaceだけの場合
v=spf1 include:_spf.google.com ~all
Microsoft 365だけの場合
v=spf1 include:spf.protection.outlook.com -all
上はGoogleの手順、下はMicrosoftの手順にある形です。末尾の違いは、後の節で説明します。
どこに、どんな順番で設定する？
SPFはメールの管理画面ではなく、ドメインのDNSに設定します。Googleは管理コンソールで特に何もする必要はないと案内し、Microsoftも管理ポータルでは扱わず、レジストラーかDNSホスティング事業者の側で作ると案内しています。作業の順番は次のとおりです。
- 自社ドメインでメールを送っているものを書き出す
- 各サービスの公式文書で、指定のincludeかIPアドレスを確かめる
- DNSの管理画面で今のTXTレコードを見て、
v=spf1 で始まる行があるか確かめる
- 無ければ新しく1本作り、あれば既存の1本を編集する
- 実際に送ったメールで、認証の結果を確かめる
DNSの管理者が社外の制作会社やプロバイダということもよくあります。その場合は依頼先を確かめて、書きたい1行を渡すと話が早く進みます。Googleの手順によれば、SPF認証が機能し始めるまでに最長で48時間ほどかかることがあります。確認の手順はSPF・DKIM・DMARCの設定状態を調べる方法にまとめました。
サブドメインにも注意が要ります。Microsoftの文書のとおり、contoso.com のSPFレコードは marketing.contoso.com をカバーしません。サブドメインから送るなら、そのサブドメインのレコードを別に作ります。
~allと-allはどちらにする？
どちらも「書いていない送信元」への指示で、強さが違います。-all は拒否すべきという指示です。~all は受け入れたうえで目印を付けるべきという指示です。実際にどう扱うかは、受信側のメールシステムが決めます。
各社の案内は分かれています。Googleは~allを勧め、Microsoftは、DKIMとDMARCも使うことを前提に-allを勧めています。Microsoftの文書には、DKIM署名のないメールでは、~all の失敗だとDMARCポリシーが実質的に無視されるとの記載もあります。
私たちの考えはこうです。送信元の洗い出しが済んでいない間は ~all にします。全経路の認証を確かめ、DKIMも揃ってから -all にするかを決めます。書き漏らした経路があるまま -all にすると、正規のメールが拒否されるおそれがあるためです。
複数のサービスを使うときはどう書く？
レコードを増やさず、1本の中に足します。同じドメインにSPFレコードが2本あると、受信側はどちらで判定するか決められません。仕様のRFC 7208は複数持つことを禁じていて、Microsoftの文書でも結果はpermerrorになると説明されています。
次の上の形は、配信サービスの導入時に起きやすい間違いです。
誤り（2本に分かれている）
v=spf1 include:_spf.google.com ~all
v=spf1 include:amazonses.com ~all
正しい（1本にまとめる）
v=spf1 include:_spf.google.com include:amazonses.com ~all
正しい形は、Googleの手順にある組み合わせの例です。配信サービスの案内には、単体で使うときのSPFレコードが1行で載っていることがあります。そのまま新しい行として登録せず、includeの部分だけを既存の行へ移します。
たとえば、社内のメールはMicrosoft 365で送り、受発注システムの注文確認と、展示会の案内の配信を別のサービスから同じドメインで送る製造業の場合です。includeが3つ必要で、受発注のIPアドレスが固定なら ip4: で足します。担当部署が分かれていると、導入のたびに別々の人がレコードを触るので、DNSの変更は1つの窓口に集めておくと事故が減ります。
10回の制限は何を数える？
SPFには、判定の間に行うDNS参照の上限があります。RFC 7208の4.6.4節は、include、a、mx、ptr、exists、redirectの合計を10までに制限し、超えた場合はpermerrorを返すよう定めています。ip4、ip6、allは数えません。
間違えやすいのは、見た目のinclude数と参照の数が別物である点です。Microsoftの文書の例では、さらに3つのincludeを持つレコードを指すincludeは、それだけで4回と数えます。Googleの手順には「includeは最大10個」とありますが、中の入れ子まで入れた合計で10回に収める必要があります。
失敗が気づかれにくい点も厄介です。判定は左から順に進み、送信元が一致した時点で止まります。そのため、右のほうの経路だけが上限に届き、特定のメールだけが失敗することがあります。社内のメールは届くのに展示会の案内だけ迷惑メールに入る、という形で表に出る場合もあるわけです。
10回を超えたときの減らし方
- 使っていないサービスのincludeを消す
- 送信元のIPアドレスが安定し、文書化されているサービスは、ip4 / ip6 に置き換える。変更の監視は自社で行う
- 配信サービスをサブドメインへ移す。サブドメインごとに別枠の10回になる
- 送信に使うサービスの数を減らす
2つ目以降はMicrosoftの文書にある方法で、配信サービスをサブドメインに分けると、本体のドメインの評判を守れるとも説明されています。解約したサービスのincludeを残すのも避けます。同じ文書によれば、include先が解決できないとpermerrorになり、メールが拒否される可能性があります。
文字数の制限はどう考える？
2つの数字を分けて覚えます。
- 255バイト：TXTレコードの中の1つの文字列の上限。超えるときは複数の文字列に分ける
- 512バイト：DNSの応答がこの大きさに収まるよう、レコードを小さく保つとされている値
どちらもRFC 7208の3.3節と3.4節に書かれています。分割した文字列は、受信側で空白を入れずにつなげて読まれます。分けるときは、語の区切りの空白を文字列の中に残します。
"v=spf1 include:example.com " "include:example.net ~all"
1行目の文字列の末尾に空白があるのがポイントです。長いレコードの扱いはDNS事業者の管理画面ごとに違うので、事業者の案内を確かめてください。文字数が問題になるほどIPアドレスを並べているなら、先に送信元の整理を検討します。
SPFを設定すれば、なりすましは防げる？
SPFだけでは足りません。Microsoftの文書も、最適な保護にはDKIMとDMARCの構成も必要だとしています。Gmailの送信者ガイドラインでは、すべての送信者にSPFかDKIMを求め、1日5,000件以上の送信者にはSPF、DKIM、DMARCのすべてを求めています。
メールに使っていない予備のドメインを持っている会社は、そちらも見ておきます。Microsoftの文書は、送信に使わないドメインには v=spf1 -all を置いて、そのドメインからのメールが無いことを示す方法を挙げています。
DMARCの支援サービスは、送信元の洗い出しを自社で続けにくい会社に向きます。内容はDMARC導入・運用支援サービスの比較で確かめられます。メール全体の守りをどこまで揃えるかはメールのセキュリティ対策とメールセキュリティ製品の比較を見てください。製品を比べる前に標準機能の範囲を確かめたい場合は、メールセキュリティ製品の比較の見方が参考になります。
