SPF

自社ドメインのメールアドレスで送信可能な正当なメールサーバの登録

SPFエスピーエフ(Sender Policy Framework)は、ドメイン管理者が自分のドメイン名のアドレスでメール送信が許可されたMTA（メール転送エージェント）をDNSレコードに登録することにより、受信側のMTAに正規の送信元であることを確認できるメール認証システムです。
SPFの仕様は、2006年に公開されたRFC4408に記載されています。

動作の例

SPF（Sender Policy Framework）の動作について、下の図を使って説明します。
例として、example.comの正しいメールサーバのIPアドレスは113.149.170.222だとします。
このIPアドレスをDNSのTXTレコードに登録しておくことで、SPFが機能します。

もし誰かが悪意を持って、support@example.comというアドレスで偽装メールを送ろうとし、自分で用意した別のIPアドレス（例：122.197.157.64）のメールサーバを使った場合、メールを受信する側のサーバは、example.comのDNSに登録されているSPFのTXTレコードを調べます。
IPアドレスが一致しないため、正しいメールサーバから送信されていないと判断されます。

受信側メールサーバが処理を決める

SPFレコードを設定すると、受信側のメールサーバは、メールが正当なサーバから送信されたかどうか判断できます。
正当でないサーバから送られたメールの処理は、受信側のメールサーバに任されます。
多くのメールサーバでは、迷惑メールフォルダに入れる設定になっています。

SPFが必要な理由とMXとの違い

メールサーバのDNS登録には、MX（Mail Exchange）レコードが存在します。
このため、「メールサーバの正当性はMXレコードで確認できるのでは？」と疑問に思うかもしれません。

しかし、現在は、一括メール配信サービスやMA、SFA、会計システムなどのSaaSを利用して、自社ドメイン名のメールアドレスで配信することが一般的です。
この場合、それらのメールサーバのドメイン名は、自社のドメイン名とは異なります。
MXレコードに他社のメールサービスのメールサーバを登録すると、自社宛てのメールもそのサーバに届いてしまう問題があります。

SPFレコードの役割は、このような状況を踏まえて、MXとは別に、正当な送信メールサーバのIPアドレスやホスト名を登録することです。
これにより、各種SaaSを使用して他社のドメインのメールサーバから送信されたメールも、正当性を確認できます。

FCrDNSとの違い

FCrDNS(Forward-confirmed reverse DNS)は、メールの認証ステータスに関するメッセージヘッダフィールドを定義したRFC8601(Message Header Field for Indicating Message Authentication Status)の「2.7.3 "iprev"」というヘッダフィールドで定義されています。

FCrDNSは、IPアドレスからホスト名への逆引きDNSができるか、且つそのホスト名から元のIPアドレスへの正引きDNSができるかを確認する手法です。
この一連の処理が成功すれば、そのIPアドレスとホスト名が正確に関連付けられていると判断できます。
しかし、FCrDNSは、スパム対策として有用である一方で、制限もあり、クラウドコンピューティングの普及と共に限界を迎えました。

設定ミスや管理の問題

FCrDNSはドメイン名とIPアドレスが正しく関連付けられていることを必要とします。
しかし、この設定が正しくない場合、誤って合法的なメールをスパムとして認識する可能性があります。
また、IPアドレスが変わった場合でも、DNS設定を迅速に更新する必要があります。

偽造可能性

スパマーは自身のIPアドレスに対して逆引き可能なDNSエントリを設定できます。
これによりFCrDNSの検証を突破し、スパムメールの送信源としてそのIPアドレスを利用することが可能です。

認証レベル

FCrDNSはIPアドレスレベルでの認証を行いますが、これは送信元のメールアドレスやドメインを特定するものではありません。
したがって、特定のドメインからのメール送信を許可するというより細かい制御はできません。

レガシーなシステムとの互換性

一部の古いシステムや設定では、逆引きDNSが正しく機能しない場合があります。
これにより、誤って正規のメールがブロックされる可能性があります。

クラウドコンピューティングの普及

クラウドコンピューティングの普及により、IPアドレスの扱いが従来と大きく変わりました。
従来のホスティング環境では、企業は固定的なIPアドレスを持つことが一般的で、そのIPアドレスを逆引き可能なDNSエントリと関連付けることが可能でした。
しかし、クラウドコンピューティングでは、仮想マシンやコンテナが動的に生成・消滅するとともに、それに伴いIPアドレスも動的に割り当てられます。
その結果、固定のIPアドレスに依存したシステム、例えばFCrDNSのようなものは対応が困難となります。
さらに、多くのクラウドサービスプロバイダーは、逆DNSのエントリをカスタマイズできない設定としています。
そのため、企業が自身のIPアドレスに対する逆引きエントリを管理することができない場合があります。

これらの制限により、FCrDNSだけを用いた送信元担保の手法には限界があります。
そこで、送信元のIPアドレスの担保の手法として、SPFはFCrDNSに代わって広く使われるようになりました。

SPFの構文

以下は、SPFレコードの基本構造です：

v=spf1 [mechanisms] [qualifiers]

ここで、v=spf1はSPFプロトコルのバージョンを示し、その後に続く[mechanisms]と[qualifiers]は、送信元の評価と許可状況を示すために使用されます。

メカニズム

メカニズムは、送信元のIPアドレスやホスト名を指定するためのパターンです。
以下は、よく使われるメカニズムの例です。

all

すべての送信元

a

ドメインのAレコードにマッチする送信元

mx

ドメインのMXレコードにマッチする送信元

ip4

IPv4アドレスにマッチする送信元

ip6

IPv6アドレスにマッチする送信元

include

他のドメインのSPFレコードにマッチする送信元

修飾子

修飾子は、メカニズムに対して評価結果を指定するために使用されます。以下は、一般的な修飾子です：

+

Pass（通過）

-

Fail（失敗）

~

SoftFail（ソフト失敗）。SPF認証に失敗していることが記録はされるが、受信しても良いという意味。

?

Neutral（中立）。ドメイン所有者はSPFでは正当かどうかの判断を明示的に行わない旨を示し、DKIMやDMARCを使って正当性確認を行う必要があることを示す。

これらの要素を組み合わせることで、ドメイン管理者は自分のドメイン名のアドレスから送信が許可されたMTAをDNSレコードに登録し、受信側のMTAが正規の送信元であることを確認できるようになります。
以下は、一般的なSPFレコードの例です：

v=spf1 a mx ip4:192.168.0.0/16 ip6:2001:db8::/48 include:example.com -all

このSPFレコードでは、次のルールが適用されます：

• ドメインのAレコードにマッチする送信元（a）
• ドメインのMXレコードにマッチする送信元（mx）
• 指定されたIPv4アドレス範囲（ip4:192.168.0.0/16）にマッチする送信元
• 指定されたIPv6アドレス範囲（ip6:2001:db8::/48）にマッチする送信元
• example.comドメインのSPFレコードにマッチする送信元（include:example.com）
• これらのルールにマッチしない送信元はFail（-all）と評価されます。

SPFレコードはサブドメインに自動継承されない

SPFレコードは、APEXドメインにしか適用されず、サブドメインに自動的に設定が適用されることはありません。
つまり、各サブドメインには独自のSPFレコードを設定する必要があります。

例えば、example.comのSPFレコードを以下のように設定した場合、example.comのみに適用され、subdomain.example.comには自動的に継承されません。

v=spf1 mx -all

したがって、subdomain.example.comにも独自のSPFレコードを設定する必要があります。
この場合、subdomain.example.comのSPFレコードを以下のように設定できます。

v=spf1 mx include:example.com -all

このようにすることで、subdomain.example.comでのメール送信が、example.comのSPFレコードに基づいて許可されるかどうかを確認できます。

SPFマクロ

SPFマクロの利点

SPFマクロは、以下のような利点があります。

柔軟性

SPFマクロを使用することで、送信者ドメインの異なる部分に対して異なるポリシーを適用できます。

効率性

マクロを使用することで、複雑な状況でも簡単にSPFレコードを作成・管理できます。

節約

SPFマクロを使用することで、IPアドレスやCIDR範囲の数を減らし、SPFレコードの肥大化を防ぐことができます。

SPFマクロの基本構文

SPFマクロは、次のような基本構文で構成されています。

%{変数}

メールサーバーから送られる情報に基づいて、変数を展開します。

%{変数|変換}

変換オプションを使用して、変数を展開します。

%{変数|変換|デリミタ}

変換とデリミタを使用して、変数を展開します。

SPFマクロの主要な変数

以下は、SPFマクロで使用される主要な変数です。

%{s}

送信者のドメイン。

%{l}

送信者のローカル部分（メールアドレスの@マークより前の部分）。

%{o}

送信者のドメインの組織部分（メールアドレスの@マークより後ろの部分）。

%{d}

評価中のSPFドメイン。

%{i}

送信者IPアドレス。

%{p}

検証されたドメイン名。

%{v}

IPアドレスのバージョン（IPv4またはIPv6）。

%{h}

送信メールのHELO/EHLOドメイン。

SPFマクロの変換オプション

SPFマクロでは、変換オプションを使用して、変数をさらにカスタマイズできます。
以下は、いくつかの一般的な変換オプションです。

r

ドメイン名を逆順にする。

l

文字列の長さを制限する。

t

文字列の一部をトリムする。

s

文字列をサブドメインに分割する。

SPFマクロの使用例

以下は、SPFマクロを使用したSPFレコードの例です。

a. v=spf1 include:%{i}._ip.%{h}._ehlo.%{d}._spf.example.com -all

このレコードは、送信者IPアドレス（%{i}）、HELO/EHLOドメイン（%{h}）、および評価中のSPFドメイン（%{d}）に基づいて、_spf.example.comサブドメイン内のSPFレコードを参照します。
これにより、送信者情報に基づいた柔軟なSPFポリシーの実装が可能になります。

v=spf1 mx include:%{d|lower}._spf.example.com -all

このSPFレコードは、ドメイン名を小文字に変換し（%{d|lower}）、それに基づいて _spf.example.com サブドメイン内のSPFレコードを参照します。
この設定は、異なるケース表記を統一し、レコード管理を容易にするのに役立ちます。

v=spf1 a ip4:%{i|reverse}.%{d}.in-addr.arpa -all

このSPFレコードは、送信者のIPアドレス（%{i}）を逆順に変換し（%{i|reverse}）、それに基づいて in-addr.arpa ドメイン内のPTRレコードを参照します。
この設定は、IPアドレスとドメインの逆引きDNS（Reverse DNS）を使用して、送信者のドメインが正当であることを確認するのに役立ちます。

v=spf1 ptr include:%{l|trim=1}._%{h}._spf.example.com -all

このSPFレコードは、送信者のローカル部分（%{l}）の最初の1文字をトリムし（%{l|trim=1}）、それに基づいて _spf.example.com サブドメイン内のSPFレコードを参照します。 これにより、送信者のメールアドレスに応じて異なるSPFポリシーを適用することができます。

メール送信しないドメインでのSPF設定

企業は、キャンペーン用のサイトに使用するドメインや、なりすましのWebサイト防止のために取得した類似のドメイン名を持つことがあります。
また、国内向けに「.jp」、国際展開のために「.com」といった複数のドメインを取得している場合もあります。
これらのドメインからメールを送信しないことが一般的です。

しかし、このようなドメインでもSPF設定が必要です。

Defensive(防御用) SPFレコードの設定

以下のようにSPFを設定すると、-allで全否定となり、そのドメインからメールを送信する正当なメールサーバは存在しないという意味になります。

Type: TXT
Host: @
Value: v=spf1 -all 

Defensive(防御用) MXレコードの設定

SPFだけでなく、MXレコードも以下のように設定しましょう。
この設定により、そのドメイン宛てのメールはルートドメイン(.)行きとなり、エラーが発生します。
これにより、メール受信をしないことを明示的に指定できます。

Type: MX 
Preference: 0  
Host: @
Value: .

これは、Null MXと呼ばれるもので、2015年にRFC7505（"A "Null MX" No Service Resource Record for Domains That Accept No Mail"）で定義されました。

SPFの制限事項

文字数制限

SPFレコードには明確な文字数制限は存在しませんが、DNS内の各TXTレコードには最大255文字までの制限があります。
もしSPFレコードが255文字を超える場合、includeを使用して複数のTXTレコードに分割して設定することができます。

DNSルックアップ数制限

多くのメール配信プラットフォームから「このincludeを設定してください」と指示があり、SPFレコードに記載されることが一般的です。SPFレコードは、DDoS攻撃を防ぐ目的で、SPF内に記載されているドメインのDNSルックアップ数に10回までの制限が設けられています。この制限を超えると、SPF permanent errorが発生し、DNSのSPFレコードを正しく解釈できなくなります。

この場合、SMTPは550番エラーを返すことが定められており、「550, "5.7.1" Unauthenticated email is not accepted from this domain.」（このドメインからの認証されていないメールは受け取れません）というエラーメッセージが表示されます。

PowerDMARCでは、この制限を超えられるようにするPowerSPFという機能を提供しています。

SPFの限界

「SPFレコードがあれば十分ではないか？」と考えるかもしれませんが、SPFにはいくつかの限界が存在します。

メール配信プラットフォームを使っている場合

近年、自社でメールサーバを構築・運用する企業は減少傾向にあります。代わりに、Google WorkspaceのGmail、Microsoft365のOutlookなどのSaaSを利用して自社のメールを運用する企業が増えています。また、Amazon SESやSendGrid、MailChimp、SalesForce、Zohoなど、様々なメール配信サービスやSaaSを使ってメールを送信している企業も多く存在します。

例えば、Gmailは誰でも登録して使えるサービスであり、そのため悪意のある人がGmailで捨てアカウントを作成し、なりすましメールを送ることができます。これは、_spf.google.comが、Googleを利用しているアカウントで共通のSPFレコードになるためです。

転送メール

メール転送時に、転送元のメールサーバと異なる送信メールサーバが使用されると、SPF検証でエラーが発生します。
メール認証システムについて、SPFだけを設定して運用していると、転送メールが正常に届かない問題が発生することがあります。

SPFの限界を超えるためのDKIM

以上のように、SPFだけの設定では、メールセキュリティの限界があります。
そこでDKIMが登場します。