SPFレコードの作り方:構文、例、よくあるエラー

要点まとめ

1. SPFレコードの役割 SPFはSender Policy Frameworkの略です。
2. 構文を1つずつ見る SPFレコードはすべてv=spf1で始まります。
3. ステップ1:すべての送信元を洗い出す ドメインを送信元としてメールを送信するすべてのシステムを書き出します。送信サービス、メールボックスプロバイダー、Webサイトやショップ、CRM、サポートデスク、請求や人事のツールなどです。
4. ステップ2:レコードを組み立てる v=spf1で始め、送信元ごとにincludeまたはip4を1つずつ追加し、最後に~allを置きます。
5. ステップ3:DNSに公開する ドメインのルートにTXTレコードを追加します。
6. ステップ4:テストする ルックアップでレコードが公開され、正しく解析されることを確認します。次に、自分が管理するメールボックスにテストメッセージを送信し、ヘッダーの認証結果を読みます。

SPFレコードの役割

SPFはSender Policy Frameworkの略です。ドメインのDNSに設定するTXTレコードで、そのドメインを使ってメールを送信してよいサーバーを一覧にしたものです。メッセージが届くと、受信サーバーは送信元ドメインのSPFレコードを調べ、接続元のIPアドレスがリストに含まれているかを確認します。

SPFが確認するのは、人が目にするFromアドレスではなく、Return-PathやMAIL FROMアドレスとも呼ばれるエンベロープ送信者です。この違いは、後でDMARCのアライメントを扱う際に重要になります。

構文を1つずつ見る

SPFレコードはすべてv=spf1で始まります。その後ろにメールの送信元を指定するメカニズムが並び、最後に、それ以外のすべてをどう扱うかを示すallメカニズムで終わります。ip4とip6はアドレスまたは範囲を記述します。includeは別のドメインのSPFレコードを取り込むもので、送信サービスを許可するときに使います。aとmxは、自社ドメインのWebサーバーやメールサーバーのアドレスを許可します。

v=spf1 ip4:203.0.113.10 include:YOUR_SPF_HOST ~all

各メカニズムの前には、修飾子を付けることができます。プラスはパスを意味し、デフォルトです。マイナスは失敗、チルダはソフトフェイル、疑問符はニュートラルを意味します。つまり、~allは、記載のないものは疑わしいが禁止はしないという意味で、-allは拒否すべきだという意味になります。

ステップ1:すべての送信元を洗い出す

ドメインを送信元としてメールを送信するすべてのシステムを書き出します。送信サービス、メールボックスプロバイダー、Webサイトやショップ、CRM、サポートデスク、請求や人事のツールなどです。SPFはこれらすべてを1つのレコードでカバーする必要があるため、リストに漏れがあると、忘れていた送信元が機能しなくなります。

各プロバイダーは、使用すべきinclude値を公開しています。MigoSMTPの場合は、推測せずに、ダッシュボードに表示されるSPF値をコピーしてください。

ステップ2:レコードを組み立てる

v=spf1で始め、送信元ごとにincludeまたはip4を1つずつ追加し、最後に~allを置きます。たとえば、メールボックスプロバイダーと送信サービスを使う企業であれば、includeが2つと、末尾が1つになります。

すべてを1つのTXTレコードにまとめてください。送信元ごとにレコードを作ってはいけません。それがSPF失敗の最も多い原因で、後ほど詳しく説明します。

ステップ3:DNSに公開する

ドメインのルートにTXTレコードを追加します。多くのDNS管理画面では、ホストは@か空欄です。値は組み立てたとおりに貼り付け、管理画面から求められない限り、余計な引用符は付けないでください。GoDaddy、BigRock、Hostingerなどインドのレジストラの管理画面や、CloudflareなどのDNSホスティングでも、すべて同じ手順です。

ルートにすでにレコードがある場合は、2つ目を追加せずに編集してください。変更の反映には、レコードのTTLに応じて、数分から数時間かかることがあります。

ステップ4:テストする

ルックアップでレコードが公開され、正しく解析されることを確認します。次に、自分が管理するメールボックスにテストメッセージを送信し、ヘッダーの認証結果を読みます。spf=passと表示されていることを確認してください。当社の無料チェッカーでは、SPF、DKIM、DMARCのレコードを1か所で確認でき、よくあるエラーも指摘されます。

1つのシステムだけでなく、メールを送信するすべてのシステムからテストしてください。送信サービスでパスしても、請求ツールについては何も保証されません。

ミス1:SPFレコードが複数ある

ドメインが公開するSPFレコードは、ちょうど1つでなければなりません。2つあるとSPFは恒久的なエラーを返し、受信側はそれを失敗として扱います。複数のチームがそれぞれ独自に追加した場合は、すべてのincludeを含む1つのレコードに統合してください。

新しいツールを導入するとき、その手順書に新しいTXTレコードを作成するよう書かれていると、このミスが起こりやすくなります。まず、すでにあるレコードを確認してください。

ミス2:DNSルックアップが多すぎる

SPFでは、レコードの評価中に行えるDNSルックアップは最大10回です。include、a、mxなどのメカニズムはそれぞれ数えられ、ネストされたincludeも含まれます。ip4とip6は数えられません。10回を超えるとSPFは恒久的なエラーを返し、各部分に問題がなくてもチェックが失敗します。

使っていない送信元を削除し、アドレスが安定している場合はaとmxのメカニズムを明示的なip4の範囲に置き換え、includeを何重にも重ねないようにしてください。includeをアドレスに置き換えるSPFフラットニングを提供するサービスもあります。有効な方法ですが、アドレスは時間とともに変わるため、常に最新の状態に保つ必要があります。

ミス3:-allを早く設定しすぎる

-allのハードフェイルは、リストにないものを拒否するよう受信側に指示します。リストに送信元の漏れがあると、その送信元のメールは拒否されます。多くのチームは~allで始め、数週間DMARCレポートを確認し、すべての送信元が記載されていると確信できてから厳しくします。

どちらを選んでも、SPFだけで受信トレイへの振り分けが決まるわけではありません。SPFは、DKIMやDMARCと連携して働く、シグナルの1つです。

転送されたメールでSPFが失敗する理由

誰かがメッセージを転送すると、転送元のサーバーから送信されることになります。そのサーバーはあなたのレコードに含まれていないため、最終的な宛先でSPFは失敗します。これは正常な動作であり、あなたの側のミスではありません。

これがDKIMが重要な理由です。DKIM署名は通常、転送されても維持され、DMARCはSPFとDKIMのどちらかがパスしてアライメントが取れていればパスします。両方を設定してください。

参考資料と出典

• RFC 7208: Sender Policy Framework (SPF)
• Google Workspace: Define your SPF record
• Microsoft: Set up SPF to help prevent spoofing

MigoSMTPで実践:ヘルプセンターの記事

• SPFのpermerrorと10回のルックアップ上限を解消する
• 送信ドメインを検証する:DNSレコードと反映
• MigoSMTPで送信ドメインを認証する:SPF、DKIM、DMARC

関連ガイドとツール

• SPFレコードチェッカー:レコードを検索し、DNSルックアップ数を数えます。
• SPFレコードジェネレーター:送信元からレコードを作成します。
• DKIM、SPF、DMARCの設定:ドメインを端から端まで認証します。