## この記事でわかること

- SPFレコードの構文と、`include`・`~all`・`-all` の意味
- Google Workspace や Microsoft 365 などサービス別の具体的な設定値
- 設定の反映確認方法と、10ルックアップ上限でつまずかないためのチェック

「メールが急に届かなくなった」「Gmail側で迷惑メール扱いされるようになった」というご相談の多くは、SPFレコード（エスピーエフ、Sender Policy Framework）の設定ミスが原因です。SPFはDNSにTXTレコードを1行追加するだけの仕組みですが、構文と上限の理解を飛ばして書くと、かえって配信性を落としてしまいます。本記事では、SPFレコードの書き方と設定手順を、実際に使われている値の例とともに順に整理します。メール認証（送信ドメイン認証）の全体像は[メール認証とは？図解でわかる入門](/blog/email-auth-basics)、SPF・DKIM・DMARC の 3 つの位置づけの違いは[SPF・DKIM・DMARCの違いをわかりやすく解説](/blog/spf-dkim-dmarc-difference)をご一読ください。

## SPFレコードの構文と書き方

SPFレコードは、ドメイン直下（`@`）に1つだけ公開するTXTレコードで、**値は `v=spf1` で始まり、末尾の `all` 修飾子で終わる**のが基本形です。

![SPFレコードの構成要素](/blog/spf-setup-guide/spf-record-anatomy.svg)

値の中身は、左から順に「この送信元を許可する」という機構（mechanism）を並べ、最後に「それ以外をどう扱うか」を決める修飾子を置きます。主な機構は次のとおりです。

| 機構 | 役割 | DNSルックアップ |
|---|---|---|
| `ip4:` / `ip6:` | IPアドレスや範囲を直接列挙 | 消費しない |
| `a` / `mx` | ドメインのAレコード・MXサーバーを許可 | それぞれ1回消費 |
| `include:<domain>` | 他ドメインのSPFを取り込み | 1回＋取り込み先の消費分 |
| `exists:<domain>` | 指定ドメインが解決できれば許可 | 1回消費 |
| `redirect=<domain>` | 評価を別ドメインのSPFへ委ねる | 1回＋委譲先の消費分 |

末尾の修飾子は運用段階で使い分けます。新規に公開するときや既存メールフローの全容を把握できていない段階では、いきなり `-all`（hardfail）にせず、まずは `~all`（softfail）で始めるのが安全です。`~all` と `-all` で受信側の扱いがどう変わるかは[SPF Fail と SoftFail の違い・対処早見表](/blog/spf-fail-vs-softfail)にまとめています。Googleも自社Workspace向けの例として `~all` を案内しています（[Set up SPF｜Google Workspace Help](https://support.google.com/a/answer/33786)）。構文と上限はRFC 7208に定められています（[RFC 7208｜Sender Policy Framework](https://datatracker.ietf.org/doc/html/rfc7208)）。

補足として、1つのドメインにSPFレコードを**2行以上書くとPermErrorとなり、SPF評価が丸ごと失敗**します（RFC 7208 §3.2）。既存レコードがある状態で新しいサービスを足すときは、必ず1行に統合してください。

## サービス別の設定例

利用しているメール送信サービスごとに、`include:` で指定すべきホスト名は決まっています。推測で書かず、各サービスの公式ドキュメントに従ってください。

| サービス | include に書くホスト名 | 備考 |
|---|---|---|
| Google Workspace | `_spf.google.com` | 推奨末尾は `~all`（公式ヘルプの例） |
| Microsoft 365（Exchange Online） | `spf.protection.outlook.com` | 公式は `-all` を例示 |
| Resend | `_spf.resend.com` | 送信用サブドメイン側に設定するケースもあり |
| さくらインターネット | `spf.sakura.ne.jp` | 契約プランで変わる場合あり |

### Google Workspaceのみを使う場合

```
ホスト名: @
種別: TXT
値: v=spf1 include:_spf.google.com ~all
```

### Microsoft 365のみを使う場合

```
ホスト名: @
種別: TXT
値: v=spf1 include:spf.protection.outlook.com -all
```

Microsoft 365 は SPF だけでなく DKIM・DMARC まで設定して初めて認証が揃います。通しの手順は[Microsoft 365 SPF DKIM DMARC 設定手順](/blog/microsoft-365-email-auth)で解説しています。

### Google WorkspaceとResendを併用する場合

```
ホスト名: @
種別: TXT
値: v=spf1 include:_spf.google.com include:_spf.resend.com ~all
```

複数サービスを組み合わせるときの考え方は、「どのサーバーから何のメールが出ているか」を洗い出すところから始めます。会計システムの通知、マーケティングツール、CRMからの自動送信など、**普段意識していない送信元が漏れやすい**ので、社内ヒアリングと送信ログの確認をセットにしてください。

## 設定手順と反映確認

SPFレコードの設定は、DNS管理画面にログインできれば15分程度で完了します。

![SPFの受信側判定フロー](/blog/spf-setup-guide/spf-check-flow.svg)

### ステップ1｜現状のSPFを確認する

まず既存のSPFレコードがあるかを確認します。お使いのPCで次のコマンドを実行します。

```
nslookup -type=txt example.co.jp
```

`v=spf1 ...` で始まる行があれば、その1行だけを編集対象にします。2行以上見つかった場合は統合が必要です。

### ステップ2｜DNSにTXTレコードを追加または編集する

Cloudflare、お名前.com、Xserverなど、ご利用のDNS管理画面でTXTレコードを追加または編集します。既存レコードに新しいサービスを足す場合は `include:` をスペース区切りで追記します。

### ステップ3｜反映を待つ（通常数分から数時間）

DNSの変更はTTLに従ってキャッシュが切れたあとに反映されます。通常は数分から数時間、長くても48時間以内には世界中から引けるようになります。

### ステップ4｜送信テストと判定結果の確認

Gmail宛てにテスト送信し、受信したメールの「メッセージのソース」を表示すると、ヘッダーに `spf=pass (...)` のような行が見えます。ここが `pass` になっていれば設定成功です。`softfail` や `fail` のときは、送信元IPがSPFに含まれていないか、構文エラーが考えられます。

## 10ルックアップ上限とよくあるつまずき

SPF運用で最も多いトラブルは、**DNSルックアップが上限の10回を超えてPermErrorになる**ケースです。RFC 7208 §4.6.4は、1回のSPF評価で消費できるDNSルックアップを10回以内に制限しており、超過した瞬間にSPF全体が無効化されます。

![10ルックアップ上限の数え方](/blog/spf-setup-guide/spf-lookup-limit.svg)

数え方で気をつけるべきは、`include:` した先のレコードが内部でさらに `include` を持っていると、**その分も合算される**点です。`_spf.google.com` のように1つのincludeが内部で4つ以上消費するケースもあり、メール送信サービスを3〜4種類束ねるとすぐに上限に届きます。加えてRFC 7208 §4.6.4は、NXDOMAINや空回答となる「void lookup」が2回を超えた場合もPermErrorとすると規定しています。

上限に近づいたときの対処は、次の順で検討します。

1. 使っていないサービスの `include:` を削除する
2. 小規模な送信元は `include:` の代わりに `ip4:` で直接列挙する
3. それでも収まらなければSPF flattening（動的にip4へ展開するサービス）の利用を検討する

もうひとつ頻出するのが、**SPFだけに頼ってなりすまし対策ができたつもりになる**誤解です。SPFは転送やメーリングリストで失敗しやすく、From欄のドメインとの一致（アラインメント）も保証しません。同じドメインから送られる正規メールでも迷惑メール扱いされることが増えてきたら、DKIMとDMARCまで整える段階に入っています。具体的な手順は[DMARC設定方法を徹底解説](/blog/dmarc-setup-guide)にまとめています。

## まずは自社のSPFを確認しましょう

要点を整理します。

- SPFは1ドメイン1レコード、`v=spf1 ... ~all`（または `-all`）の形で公開する
- 利用中の送信サービスをすべて `include:` で列挙し、公式のホスト名を使う
- DNSルックアップは合計10回まで。超えるとSPF全体がPermErrorで失敗する
- 運用開始時は `~all` で様子を見て、送信源が固まってから `-all` への切り替えを検討する

[無料のドメイン診断ツール](/diagnose)で、自社ドメインのSPFレコードの有無・内容・ルックアップ数をまとめて確認できます。「今書かれている SPF レコードの記号一つ一つが何を意味するか」を逐語で読みたい方は、[SPF / DKIM / DMARC 設定確認・日本語解説ツール](/tools/dns-auth-explainer)を使うと `~all` `include:` `redirect=` などのトークンごとに日本語で解説が出ます。設定の書き換えに不安がある方は、[お問い合わせフォーム](/contact)から現状をお知らせください。専門家が内容を確認したうえで、手順と反映タイミングをお伝えします。