SPFレコード

SPFレコードとは？

SPFレコードとは、ドメイン上に置く1行のテキストで、そのドメインのメールを送ってよいサーバーを一覧にしたものです。SPFはSender Policy Frameworkの略です。RFC 7208で定められています。

最初にいくつかの言葉を説明します。ドメインとは、メールアドレスの @ より後ろの名前で、example.comなどです。サーバーとは、メールを送ったり受け取ったりするコンピューターです。DNSとは、ドメインが自分の設定を公開する、インターネット上の公開ディレクトリです。それぞれの設定をレコードと呼びます。SPFレコードはDNS TXTレコード、つまりテキストを保存するDNSレコードです。

シンプルなSPFレコードは次のような形です。

v=spf1 include:_spf.google.com -all

それぞれの部分に意味があります。

• v=spf1 は、これがSPFレコードであることを示します。
• include:_spf.google.com は、Googleが一覧にしているすべてのサーバーが、このドメインのメールを送ってよいことを示します。
• -all は、ほかのすべてのサーバーからのメールを拒否するよう求めます。
• ~all は、より緩やかな終わり方です。ほかのサーバーからのメールを疑わしいものとして扱い、拒否はしないよう求めます。

簡単な例

1つのSPFレコードが小さな会社をどう守るかを見てみます。

1. パン屋がGoogle Workspaceを使っています。Rosa's Bakeryは、Google Workspaceを通じてrosa@bakery.exampleからメールを送っています。
2. SPFレコードを公開します。レコードは v=spf1 include:_spf.google.com -all です。これは、bakery.exampleのメールを送ってよいのはGoogleのサーバーだけ、という意味です。
3. ローザが顧客にメールを送ります。メールはGoogleのサーバーの1つから送られます。
4. 顧客側のサーバーが確認します。bakery.exampleのSPFレコードを調べます。Googleのサーバーは許可されているので、結果はpass（合格）です。
5. 誰かが偽のメールを送ります。詐欺師が、bakery.exampleから送られたと名乗るメールを送ります。そのメールは、レコードにないサーバーから送られています。
6. チェックが失敗します。レコードの最後が -all なので、顧客側のサーバーは偽のメールを拒否できます。

受信側のサーバーが確認する方法

メールが届くと、受信側のサーバーはReturn-Pathのドメインを読みます。Return-Pathとは、バウンスが送られる先のアドレスです。バウンスとは、メールが届かなかったことを送信者に知らせる自動のメッセージです。

サーバーは、そのドメインのSPFレコードを取得します。次に、メールを届けたIPアドレスがレコードに含まれているかを確認します。IPアドレスとは、インターネット上のサーバーを識別する番号です。よくある結果は3つです。

• Pass（合格）。IPアドレスがレコードに含まれています。メールは許可されたサーバーから送られました。
• Fail（失敗）。IPアドレスがレコードになく、レコードの最後が -all です。サーバーはメールを拒否することがあります。
• Softfail（ソフトフェイル）。IPアドレスがレコードになく、レコードの最後が ~all です。サーバーはメールを受け付けますが、疑わしいものとして印を付けます。

Microsoft Exchange Onlineは、チェックに失敗したメールを 5.7.23 The message was rejected because of Sender Policy Framework violation で拒否します。Gmailは、認証がまったくないメールに 550 5.7.26 を返します。どちらのコードも5で始まります。アドレスに問題はなくても、配信ツールはこれらをハードバウンスとして記録します。

SPFレコードが必要な送信者

大量のメールを送るすべての送信者に必要です。Googleの送信者ガイドラインは、Gmailあてに1日5,000通以上を送る送信者にSPFとDKIMを求めています。DMARCも求めています。Microsoftも、Outlook.com、Hotmail、Liveあてに1日5,000通を超えて送るドメインに、同じ3つのレコードを求めています。Microsoftは2025年5月5日からこのルールの適用を始めました。

送信数がそれより少なくても、これらのレコードは重要です。レコードがないと、メールが迷惑メールフォルダに入りやすくなります。

DNSルックアップ10回の上限

RFC 7208は、1回のSPFチェックで行えるDNSルックアップを10回までに制限しています。ルックアップとは、受信側のサーバーがDNSに1回問い合わせることです。レコード内の include:、a、mx、redirect は、それぞれ1回のルックアップとして数えます。includeしたレコードの中のルックアップも数えます。合計が10回を超えると、チェックは恒久的なエラーを返します。ほとんどの受信側サーバーは、このエラーをfail（失敗）として扱います。

これが、SPFレコードが壊れる最も多い原因です。会社がメールツールを1つずつレコードに追加していきます。11回目のルックアップが加わった時点で、レコード全体が機能しなくなります。SPFチェッカーは、各includeの中のものも含めて、レコードのルックアップ数を数えます。

例：ある会社のSPFレコードには、社内のメール、ニュースレターツール、ヘルプデスクツール、請求書ツールがincludeされています。その中には、さらに別のレコードを含むものがあります。合わせると11回のルックアップが必要です。その日から、自社のオフィスから送ったメールも含めて、会社のメールはSPFチェックに失敗します。

SPFは3つのレコードの1つ

• SPFは、どのサーバーがメールを送ったかを確認します。
• DKIMは、送信後にメールが変更されていないかを確認します。
• DMARCは、両方のチェックを、読み手に見えるFromアドレスと結び付けます。チェックに失敗したときにどうするかも、受信側のサーバーに伝えます。

ドメインには3つすべてが必要です。ハードバウンスとソフトバウンスの違いのガイドでは、失敗したときのコードがバウンスレポートでどう見えるかを紹介しています。

SPFレコードとメールアドレス検証

SPFレコードは、どのサーバーがドメインのメールを送ってよいかを証明します。受信者のアドレスが存在することは証明しません。正しく認証されたメールでも、使われていないアドレスに送ればバウンスします。メールアドレスチェッカーは、送信前に、メールボックスが存在するかを受信側のサーバーに確認します。メールアドレスの一括検証ツールは、同じことをリスト全体に対して行います。正しいSPFレコードは 5.7.23 のような認証によるバウンスを防ぐのに役立ち、メールアドレス検証は 5.1.1 のようなコードでバウンスするアドレスを見つけます。