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

- SPF レコードがどういう仕組みかを比喩でイメージできる
- なぜ Web サイト運営者でも SPF が必要なのか
- Google Workspace を使う場合の最小の設定例
- もう一歩深く知りたい場合の次の一歩

## SPF レコードを「玄関の表札」で理解する

メール認証の話で最初に出てくる言葉が「SPF レコード」です。SPF は Sender Policy Framework（センダー・ポリシー・フレームワーク）の略で、読み方は「エスピーエフ」。難しそうな名前ですが、やっていることは意外とシンプルです。

イメージとしては、SPF レコードは **「うちの会社のメールは、これらのサーバーから送りますよ」と DNS に貼り出した宣言文** のようなものです。

たとえると、玄関の表札に「この家からの郵便はヤマト運輸と佐川急便を使います」と書いておくのに似ています。受け取り側（メールの受信サーバー）は、その表札を見て「この差出人は本当にこの家の人か？」を判断します。

![SPF レコードの仕組みを表す図](/blog/spf-basics-smb/how-spf-works.svg)

差出人ドメイン（@example.co.jp）を名乗ったメールが届いたとき、受信サーバーはそのドメインの DNS を確認して SPF レコードを読み取り、「このメールは登録された送信サーバーから来ているか？」を機械的に照合します。一致すれば認証 OK、一致しなければ「なりすましかもしれない」と判断する材料になります。

## なぜ Web サイト運営者にも SPF が必要なのか

「うちはメール送信量が多くないから関係ない」と思われがちですが、SPF が必要な理由は送信量とは別のところにあります。

### 1. 受信側が「本物の差出人か」を判定するため

Gmail や Microsoft 365 をはじめとする現代のメールサービスは、届いたメールを **必ず** 認証情報でチェックしています。SPF レコードが設定されていないドメインからのメールは「正体が確認できない送信元」として扱われ、迷惑メールフォルダに振り分けられたり、最悪の場合は受信拒否される可能性があります。

### 2. 自社ドメインのなりすまし対策

SPF を設定しておくと、第三者が `@example.co.jp` を装って送ったメールが受信側で弾かれやすくなります。請求書詐欺や取引先への詐欺メールは、ドメインのなりすましから始まるケースが多く、SPF はその第一歩を防ぐ役割を担います。

### 3. 配信性の維持（業務インフラとしての安心）

SPF が無いと「届くはずのメールが届かない」というトラブルが起きやすくなります。請求・受注・予約確認などのメールが届かない事態は、事業に直接影響します。SPF はセキュリティ対策であると同時に、メールという業務インフラを守る基本設定でもあります。

## 最小の設定例（Google Workspace を使う場合）

具体的な書き方を 1 つだけ紹介します。Google Workspace のみでメールを送っている会社の場合、SPF レコードは次の 1 行で十分です。

```
v=spf1 include:_spf.google.com ~all
```

意味を分解するとこうなります。

- `v=spf1`: 「この行は SPF バージョン 1 の宣言です」という決まり文句
- `include:_spf.google.com`: 「Google が公開している送信サーバー一覧を取り込んでください」
- `~all`: 「上記以外から来たメールは怪しいので、ソフトに弾いてください」

`~all`（ソフトに弾く）と `-all`（はっきり弾く）の違いと、どちらを選ぶべきかは[SPF Fail と SoftFail の違い・対処早見表](/blog/spf-fail-vs-softfail)で整理しています。

Microsoft 365 のみを使う場合は `include:spf.protection.outlook.com`、Resend の場合は `include:amazonses.com` のように、利用しているメールサービスごとに `include` 部分が変わります。

![代表的な SPF レコードの例](/blog/spf-basics-smb/common-examples.svg)

実際の設定では、複数のサービス（メール配信、CRM、フォーム送信ツールなど）を併用していることも多く、その場合はそれぞれの `include` を 1 行に並べます。詳細な設定手順や注意点は、関連記事の [SPF 設定ガイド](/blog/spf-setup-guide) で解説しています。

## まとめと次のステップ

最後に、入門段階で 1 つだけ覚えておきたい落とし穴に触れます。SPF には **「include の参照は 10 個まで」** という制限があります（RFC 7208）。`include:` を増やしすぎると、技術的には正しい記述でも認証が「永続エラー（Permerror）」となり、せっかく書いた SPF が機能しなくなります。サイト運営者でも、メールサービス＋メール配信ツール＋フォームサービス＋営業ツール…と積み上がっていくと、気づかないうちに上限を超えていることがあります。「include を足すたびにカウントが増える」「上限を超えると全部止まる」という 2 点だけ頭に入れておけば、入門段階としては十分です。10 ルックアップ超過の具体的な対処は [SPFレコード10ルックアップ超過の対処](/blog/spf-flattening) にまとめています。



ここまでの内容をまとめると、SPF は次のような技術です。

- 「うちのメールはこれらのサーバーから送ります」という DNS 上の宣言
- 受信側はこの宣言を使って、なりすましかどうかを機械的に判定する
- サイト運営者でも、配信性確保となりすまし対策のために必須レベルの設定
- include は 10 個まで、というルールだけは押さえる

SPF は、メール認証の 3 本柱（SPF・DKIM・DMARC）の入口です。SPF だけでは完全ではなく、DKIM（電子署名による改ざん検知）と DMARC（受信側にどう扱ってほしいかの指示）を組み合わせて初めて、現代のメール環境で安心して使える状態になります。社内で「メール認証ってよく聞くけど何から始めればいい？」と聞かれたら、まずは SPF の存在確認から、と答えるのが王道です。

次の一歩としては、[DMARC の読み方と意味](/blog/dmarc-pronunciation-meaning) で DMARC の概要をつかみ、続けて [SPF 設定ガイド](/blog/spf-setup-guide) で具体的な手順を確認するのがおすすめです。社内に DNS の管理権限を持つ担当者がいない場合や、複数のメールサービスをまたいでいる場合は、無理に独力で進めず、まずは現状把握から始めるとリスクを抑えられます。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。