SPFレコードとは？ — 書き方と確認方法をやさしく解説
最終更新: 2026-08-07
SPF（Sender Policy Framework）は、「うちのドメインのメールは、このサーバーから送ります」とあらかじめ世界に宣言しておく仕組みです。郵便にたとえると「住所の登録」。登録がないと、受信側はそのメールが本物の差出人から来たのか判断する手がかりがありません。送信ドメイン認証の3大必須設定（SPF・DKIM・DMARC）の1つ目です。
しくみ — 受信側は「送信元のIPアドレス」を照合している
メールを受け取ったサーバー（Gmailなど）は、送信元サーバーのIPアドレスを見て、差出人ドメインのDNSに公開されているSPFレコードと照合します。「宣言されたサーバーからのメールならOK（pass）、宣言にないサーバーからならあやしい」という判定です。
SPFレコードは、ドメインのTXTレコードとして1本だけ公開します。特別なサーバーやソフトは不要で、DNSに1行追加するだけです。
レコードを1語ずつ分解して読む
よくあるSPFレコードを分解してみます。
v=spf1 include:_spf.google.com ip4:203.0.113.10 ~all| 部品 | 意味 |
|---|---|
v=spf1 | 「これはSPFレコードです」という宣言。必ず先頭に置く |
include:_spf.google.com | 「Googleが公開しているサーバー一覧も、うちの送信元として認める」。Google WorkspaceやM365など、サービス利用時はこの形が基本 |
ip4:203.0.113.10 | このIPアドレスからの送信を認める（自社サーバーがある場合など） |
~all | 「上記以外からのメールは、あやしい扱いにしてよい」。レコードの締めくくり |
末尾の「all」の記号は4種類
| 書き方 | 意味 | 推奨度 |
|---|---|---|
-all | 上記以外は不合格（最も厳格） | ◎ 送信元を完全に把握できているなら |
~all | 上記以外はあやしい扱い（ソフトフェイル） | ◎ 一般的な推奨 |
?all | 中立（判定に使わない） | △ 実質意味がないため非推奨 |
+all | 誰でも送ってよい | ✕ 危険。SPFが実質無効になります |
書き方の実例
お使いのメールサービスが「include の値」を公式に指定しています。代表例：
| サービス | SPFレコード |
|---|---|
| Google Workspace（Gmail） | v=spf1 include:_spf.google.com ~all |
| Microsoft 365 | v=spf1 include:spf.protection.outlook.com -all |
| 複数サービスの併用 | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all（1本にまとめる） |
よくある失敗
- SPFレコードを2本登録してしまう — ルール違反（RFC 7208）で、かえって認証エラー（permerror）になります。新しいサービスを足すときは、レコードを増やすのではなく、既存の1本に include を追記します。
- include を足しすぎる — SPFの検証で発生するDNS参照は10回までという上限があります（include の中の include も数えます）。超えると permerror です。本サイトの診断は include を再帰的にたどって参照回数をカウントします（→10回制限の詳しい解説と減らし方）。
- 「+all」で締めてしまう — 誰でもあなたのドメインを名乗れる状態になります。
症状別の直し方はよくある失敗例と直し方にまとめています。Google Workspaceと配信サービスなど、複数サービスを併用する場合の統合ルールも参考にしてください。
SPFだけでは足りない理由
SPFには弱点が2つあります。①メールが転送されると送信元サーバーが変わり、SPFが不合格になることがある（→転送でSPFが失敗する理由とARC）。②SPFが照合するのは封筒の差出人（エンベロープFrom）で、受信者に見える差出人欄（From）のなりすましは防げない。この弱点を補うのがDKIM（電子署名）とDMARC（取り扱いルール）です。3つそろって「土台」になります。
設定できているか確認する
下のフォームにドメインを入れるだけで、SPFレコードの有無・2本登録・all指定・DNS参照回数（10回制限）までまとめて無料で確認できます。