メールの差出人アドレスは、技術的には簡単に詐称できてしまいます。取引先や自社を装ったなりすましメールを受信側で見抜く土台になるのが、SPF（Sender Policy Framework）を中心とした送信ドメイン認証です。この記事では、SPFがDNSのTXTレコードで送信元IPアドレスを検証する仕組み、v=spf1から始まるSPFレコードの書き方と主要メカニズム、10回のDNSルックアップ上限といった実務でつまずく箇所、そしてDKIM・DMARCと組み合わせる理由までを、設定を社内で内製するか外部に委託するかの判断とあわせて解説します。GmailとOutlookが大量送信者に認証設定を求めるようになった以降の前提も含めて整理します。
まとめ：SPF設定で押さえる送信ドメイン認証の要点と現在の到達点
SPFは、送信側ドメインの管理者がDNSに「このIPアドレスからのメールは正規のもの」と宣言し、受信側のメールサーバーがエンベロープFromのドメインと実際の送信元IPを突き合わせて正当性を確かめる仕組みです。RFC 7208（2014年4月発行）で標準化された、なりすましメール対策の第一層にあたります。ただしSPF単体では、メール転送で認証が壊れる、受信者が実際に目にするヘッダFromの詐称は防げない、といった穴が残ります。
実務での結論はシンプルにまとまります。SPF・DKIM・DMARCの三点をセットで導入し、SPFレコードのDNSルックアップは10回以内に収め、最終的な運用ポリシーはDMARCで宣言する——この形が現在の到達点です。さらに2024年2月以降のGmail、2025年5月以降のOutlookが、大量送信者に対してこの三点の設定を配信条件として求めるようになりました。設定は任意の改善策ではなく、届けるための前提条件へ位置づけが変わっています。自社の送信経路が複数のSaaSに分散し、SPFレコードの管理が破綻しかけているなら、DNSとメールインフラの設計を外部の開発会社に委ねる判断も現実的な選択肢になるでしょう。以下で仕組み・設定・判断基準を順に見ていきます。
SPFとは何かをDNSのTXTレコードと送信元IP照合の仕組みから理解する
まずSPFが何を検証し、何を検証しないのかをはっきりさせます。ここを取り違えると、後述の「SPFを設定したのになりすましが届く」という誤解につながります。
DNSのTXTレコードに登録した送信元IPで正当性を検証する流れ
SPFの動作は3ステップです。送信側ドメインの管理者が、自ドメインのDNSに「正規の送信元IPアドレスの一覧」をTXTレコードとして公開する。メールを受け取った受信側のメールサーバー（MTA）が、そのドメインのSPFレコードをDNSに問い合わせる。実際にメールを届けてきたサーバーのIPアドレスが一覧に含まれていればpass、含まれていなければfailと判定する。この判定結果は受信側のスパム判定やDMARCの評価材料になります。SPFはメール本文を一切見ず、あくまで「どのサーバーから来たか」だけを照合する点が特徴です。DNSへの問い合わせがどう解決されるかの基礎は名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法で扱っています。
エンベロープFromとヘッダFromの違いとSPFが照合する宛先
メールには2種類の差出人があります。SMTPの通信中にやり取りされるエンベロープFrom（Return-Path、仕様上は5321.MailFrom）と、メールソフトの画面に表示されるヘッダFrom（5322.From）です。SPFが照合するのは前者、エンベロープFromのドメインだけだとMicrosoftの SPF 設定ドキュメントも明記しています。ここが実務上の落とし穴です。攻撃者はエンベロープFromに自分が管理する正規ドメインを使ってSPFをpassさせつつ、ヘッダFromには有名企業のアドレスを詐称できます。受信者が目にするのはヘッダFromのほうです。SPFだけでは「表示上のなりすまし」を止めきれない構造的な理由がここにあります。
SPF・DKIM・DMARCの三層で構成する送信ドメイン認証の全体像
この弱点を補うため、送信ドメイン認証は3つの技術を層にして使います。SPFがIPアドレスの正当性を、DKIMが電子署名でメールの改ざん有無と発信元を、DMARCがそのSPF・DKIMの結果とヘッダFromの整合（アライメント）を検査し、認証に失敗したメールの扱い方を宣言する仕組みです。DMARCの仕様はRFC 7489にまとまっています。3つの役割分担を整理すると次の通りです。
| 技術 | 何を検証するか | 転送への耐性 |
|---|---|---|
| SPF | 送信元IPとエンベロープドメイン | 転送で壊れやすい |
| DKIM | 電子署名による真正性 | 転送後も維持されやすい |
| DMARC | SPFとDKIMの整合と方針 | 認証失敗時の扱いを宣言 |
SPFは三層の入口であり、これ単独で完結する対策ではありません。国内でも総務省が迷惑メール対策のページで送信ドメイン認証技術の設定状況を継続的に公表しており、JPドメインでの普及状況を確認できます。DKIMの署名検証は別途詳しく整理します。DMARCの設定手順まで踏み込みたい場合は、DMARCとは？その仕組みと設定方法、SPFやDKIMとの関係で全体像を確認してください。
SPFレコードの書き方と主要メカニズムをDNS公開まで一気に通す手順
仕組みが分かったら、実際のSPFレコードの読み書きに移ります。構文は短く、覚えるべき要素も限られています。
v=spf1で始まるSPFレコードの基本構文とall修飾子の使い分け
SPFレコードはDNSのTXTレコードとして1行で書き、必ずv=spf1から始めます。末尾にはallメカニズムを置き、一覧に該当しない送信元をどう扱うかを修飾子で指定します。-allは「一覧外は拒否（hardfail）」、~allは「一覧外は疑わしいが受信は許容（softfail）」、?allは「判定しない（neutral）」の意味です。1つの文字列は255文字までという制約もあり、RFC 7208はレコード全体を512オクテットに収まる大きさに保つよう求めています。送信元が多いと分割や参照でまとめる必要が出てきます。
運用開始直後は~allで様子を見て、正規メールの取りこぼしがないと確認できてから-allへ絞り込むのが定石です。ただしMicrosoftは自社ドキュメントで、DKIMとDMARCを併せて設定する前提なら-allを推奨しています。DKIM署名が無いまま~allにすると、DMARCのポリシーが実質的に効かなくなるためです。?allはテスト用で、本番運用では選びません。
includeやa・mxなどDNSルックアップを伴うメカニズムの役割
SPFレコードの中身は「メカニズム」の組み合わせで表現します。よく使うのは、IPアドレスを直接指定するip4・ip6、別ドメインのSPFレコードを取り込むinclude、自ドメインのAレコードやMXレコードを参照するa・mxです。Google WorkspaceはSPF設定の案内でinclude:_spf.google.comを、Microsoft 365はinclude:spf.protection.outlook.comを指定するよう案内しています。実際のレコードは次のような形になります。
; Google Workspace だけを使う場合
example.co.jp. IN TXT "v=spf1 include:_spf.google.com ~all"
; Microsoft 365 だけを使う場合
example.co.jp. IN TXT "v=spf1 include:spf.protection.outlook.com -all"
; 自社MTA（IPv4アドレス指定）と Microsoft 365 を併用する場合
example.co.jp. IN TXT "v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all"
; メール送信に使わないドメイン（パークドメイン）
example.net. IN TXT "v=spf1 -all"末尾の例のように、メールを送らないドメインにはv=spf1 -allだけを置いて送信を全面的に否定します。放置したドメインが踏み台にされる筋道はパークドメインとは？意味・仕組みと危険性、なりすまし対策のDNS設定で整理しました。なおinclude・a・mxなどは受信側でDNSへの問い合わせを発生させ、この回数に後述の上限がかかります。メール配信サービスそのものの仕組みと選び方はメール配信システムの仕組みと導入判断の解説で扱っています。
SPFレコードをDNSのTXTレコードとして公開する具体的な設定手順
設定の流れは次の順序で進めます。
- 自ドメインからメールを送る全経路（自社サーバー、Google Workspace、配信サービス等）を洗い出す
- 各経路の指定に沿って
v=spf1から始まるSPFレコードを1本組み立てる - DNSの管理画面でTXTレコードとして登録し、反映を待つ
- コマンドやチェックサイトでレコードが引けるか、意図通りにpassするかを確かめる
SPFレコードは1ドメインにつき1本が原則です。複数のTXTレコードにSPFを分けて書くと、受信側は評価すべきレコードを決められずPermErrorになります。サブドメインは親のSPFレコードを継承しないため、marketing.example.co.jpから送るなら、そのサブドメイン用のSPFレコードが別に必要です。TXTレコードのTTLは、DNS参照のタイムアウトを避ける観点から3600秒（1時間）以上が目安になります。クラウド側のメール送信基盤を新設する場合の手順はAmazon SESとは｜メール送信の仕組み・SMTP/API・サンドボックス解除と料金で具体的に追えます。
digやnslookupでSPFレコードを引いて評価結果を確かめる方法
公開後の確認はコマンドで完結します。反映にはDNSのキャッシュ有効期間（TTL）ぶんの時間差が出るため、変更直後に旧レコードが返ることも珍しくありません。パブリックDNSを明示的に指定して引くと、自社の内部DNSのキャッシュに惑わされずに済みます。
# SPFレコードを引く（Linux、macOS）
dig +short TXT example.co.jp
# 出力例
"v=spf1 include:spf.protection.outlook.com -all"
# include 先の実体をたどって中身を確認する
dig +short TXT spf.protection.outlook.com
# Windows の場合はパブリックDNSを指定して引く
nslookup -type=TXT example.co.jp 8.8.8.8
# 受信したメールのヘッダで実際の判定結果を読む
# Authentication-Results の spf= の値を見る
# spf=pass smtp.mailfrom=example.co.jp実際に届いたメールのヘッダに出るAuthentication-Results行が、受信側の最終的な判定です。spf=passと併記されるsmtp.mailfromのドメインが、自分の意図した送信ドメインになっているかまで見ます。ここが自社ドメインではなく配信サービスのドメインになっている場合、SPFはpassしていてもDMARCのアライメントは通りません。
GmailとOutlookの送信者要件でSPF設定が事実上の前提になった経緯
SPFの設定を先送りできた時期は終わりました。大手の受信側事業者が、認証の有無を配信可否の判断材料として明文化したためです。
Gmailが2024年2月から一括送信者に課した認証要件と判定基準
Googleはメール送信者のガイドラインで、Gmailアカウント宛てに1日5,000件以上を送信する一括送信者に対し、2024年2月から追加の要件を適用しています。求められるのは、送信ドメインへのSPFとDKIMの設定、送信ドメインへのDMARCの設定、Postmaster Toolsで報告される迷惑メール率を0.30%未満に保つこと、マーケティングメールと購読メールへのワンクリック登録解除の実装です。件数のしきい値は受信側から見た1日あたりの通数で判定されるため、複数の配信ツールを併用していても合算で超える点に注意します。
この基準は加点項目ではなく、満たさないメールが迷惑メール扱いや拒否になる下限の要件です。到達率を論じる前に、SPFレコードが1本正しく引けるかどうかが問われます。
Outlookが2025年5月から適用した大量送信者向け要件の影響範囲
Microsoftも同じ方向へ動きました。同社はOutlookの高ボリューム送信者向け要件の告知で、Outlook.comなどのコンシューマー向けメールサービス宛てに1日5,000件を超えて送るドメインを対象に、SPF・DKIM・DMARCの設定を求めると公表しました。2025年5月5日以降、要件を満たさない大量送信ドメインからのメッセージは迷惑メールフォルダへ振り分けられ、将来的には拒否へ移行すると案内されています（2026年9月時点）。
実務上の影響が大きいのは、しきい値を一度でも超えた実績のあるドメインには、その後の送信量が5,000件以下でも要件が適用される点でしょう。年に数回だけ大規模な案内メールを出す企業も対象に入ります。GmailとOutlookで基準がほぼ揃い、自社ドメインからメールを出す組織はSPFの整備を避けて通れなくなりました。
SPF単体で防げない範囲とDKIM・DMARCを組み合わせて塞ぐ理由
SPFの限界を正しく把握しておくと、なぜ三層セットが標準になっているのかが腑に落ちます。順位を分ける実務知識はここに集まっています。
メール転送でSPF認証が壊れる仕組みとDMARCで補う回避策
SPFが最もつまずくのが「転送」です。利用者がメールを別アドレスへ自動転送すると、転送サーバーが新たな送信元IPになります。エンベロープFromのドメインは元のままなのに送信元IPだけが入れ替わるため、元ドメインのSPFレコードには載っておらずfailになります。正規メールなのに転送を経ると認証に落ちる、これがSPFの構造的な弱点です。回避策はSPFの中では完結せず、転送後も生き残るDKIM署名と、SPFかDKIMのどちらか一方が通れば認証成立とみなすDMARCの評価で補います。この事実こそ、SPFを単独運用しない最大の理由です。
10回のDNSルックアップ上限とPermErrorを避ける設計
RFC 7208は4.6.4で、受信側が1回のSPF評価で行えるDNSルックアップを最大10回までと定めています。include・a・mx・exists・redirectが1回ずつDNS問い合わせを消費し、include先がさらにincludeを抱えていれば入れ子で加算されていきます。上限を超えるとSPF評価はPermErrorとなり、そのメールはSPF的に無効と扱われてしまう。SaaSを複数includeする構成では、気づかぬうちに上限へ近づく事故が起きがちです。数え方は次のように整理できます。
; DNSルックアップ 3回（include が3つ・ネストが無い場合）
"v=spf1 include:_spf.google.com include:servers.example-mail.jp include:spf.example-crm.jp -all"
; ip4 と ip6 と all はルックアップを消費しない（この例も3回のまま）
"v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com include:servers.example-mail.jp include:spf.example-crm.jp -all"
; include 先がさらに3つの include を持つ場合は 1 + 3 = 4回を消費する設計段階では、使っていないincludeを削る、送信を主要経路へ集約する、ルックアップ回数を数えるツールで可視化する、といった手当てで10回以内に収めておきます。Microsoftのドキュメントが指摘する通り、includeの記述が10個未満でもネストで超えることがあるため、実測が要ります。
なりすましの完全防止にDMARCのアライメント判定が要る理由
先に触れた通り、SPFはエンベロープFromしか見ないため、受信者が目にするヘッダFromの詐称を単独では止められません。ここを塞ぐのがDMARCのアライメント判定です。DMARCは、SPFがpassしたドメインとヘッダFromのドメインが一致しているか（identifier alignment）まで検査し、一致しなければ認証失敗とみなして拒否や隔離を指示します。宣言できるポリシーはnone・quarantine・rejectの3段階で、それぞれの防御力の差はDMARCの仕組みとnone・quarantine・rejectが分けるなりすまし防御の差で比較しています。フィッシングメールの多くは有名ブランドのヘッダFromを詐称するため、フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策で扱うような組織的対策と、DMARCによる表示ドメインの保護は表裏一体の関係です。業界のガイドラインが求める水準はフィッシング対策ガイドライン2026年度版が示すDMARC強化の全体像にまとめました。
void lookupの上限とptrメカニズムを避ける設計上の理由
10回の上限ほど知られていない制約が2つあります。1つはvoid lookupで、RFC 7208は応答が空、または名前が存在しないDNS問い合わせを2回までに抑えるべきだとしています。使わなくなったサービスのincludeを消し忘れ、参照先のドメインごと消滅している状態は、このvoid lookupに該当する状態です。棚卸しの際は、記述が残っているかだけでなく参照先が生きているかまで確かめます。
もう1つがptrメカニズムです。RFC 7208は逆引きDNSに依存するこのメカニズムを、遅く信頼性に欠けるとしたうえで公開すべきではないと明記しました。古い設定手順書にptrが残っているなら、ip4やincludeへ置き換えます。
SPFの設定と運用を社内で内製するか外部へ委託するかの損益分岐点
ここからは判断を言い切ります。SPFの設定自体はTXTレコードを1本書くだけで、単純構成なら情シス担当者が自力で完結できます。問題は「単純構成に収まっているか」です。
-allと~allのどちらを採用すべきかを判断する運用上の条件
採用条件は明確です。送信経路を完全に洗い出せていて、DKIMの署名も済み、レポートで取りこぼしゼロを確認済みなら-allで締める。少しでも把握しきれない送信元が残るなら、無理に-allにせず~allで運用しながらDMARCのレポートで実態を集めるべきです。最も多い失敗パターンは、送信経路の棚卸しを終えないまま最初から-allを設定し、請求書メールや予約通知など業務に直結するメールが受信側で弾かれる事故でしょう。この場面では-allは見送り、可視化を優先します。判断材料が揃うまでは緩めに運用する、これが安全側の選択です。
順序としては、DMARCをp=noneで先に立ててレポートを集め、実際の送信元が出そろってから-allへ締めるのが手戻りの少ない進め方になります。
SaaS乱立でincludeが膨張する組織が委託を選ぶ分岐点の目安
内製で回るのは、送信ドメインが少数で、送信元が1〜2のサービスに収まり、DNSを管理できる担当者がいる場合に限られます。逆に、部門ごとに配信ツールやマーケティングSaaSを導入してincludeが膨れ、10回のルックアップ上限に触れ始めた組織は、すでに内製の限界を超えています。DNSゾーンの再設計、送信経路の集約、SPFとDKIMとDMARCの一貫した設計は、メールインフラ全体を俯瞰しなければ片手間では破綻するでしょう。こうした段階に来たら、DNSやメールサーバーを含むインフラ構築（AWS・Google Cloud・Azure）の設計から外部の開発会社に委ねる判断が、事故対応の総コストを下回る分岐点になります。境目の目安は、送信SaaSが5つを超え、担当が実質1名という状態です。
現状のSPFレコードが規格の制約に触れていないか、なりすましに使える隙が残っていないかを外部の目で確かめたい段階なら、脆弱性診断・セキュリティ診断で送信ドメインの設定不備を洗い出すところから着手できます。
サブドメイン分割とSPFフラット化のどちらで参照回数を削るか
ルックアップ回数が上限に近づいたときの打ち手は2つに分かれます。第一がサブドメイン分割です。マーケティング配信をmarketing.example.co.jpへ移すと、そのサブドメインは独自のSPFレコードを持ち、10回の参照枠も別建てになります。本体ドメインの評判を配信メールの成績から切り離せる副次効果もあり、Microsoftのドキュメントでも、直接管理していないメールサービスにはサブドメインが推奨対象です。まずこちらを検討します。
第二がSPFフラット化で、includeを解決済みのIPアドレスへ置き換えて参照を減らす方法です。ただし送信元IPが頻繁に変わるクラウドサービスに対しては採るべきではありません。Microsoftは自社の送信基盤について、動的なIPアドレスを使うためフラット化しないよう明記しました。この手を選べるのは、ベンダーが安定した送信IPレンジを文書で公開していて、サブドメイン分割や経路統合が現実的でない場合に限られます。採用時は置き換えた時期を記録し、四半期ごとに追随を確認する運用まで込みで設計してください。
よくある質問
SPFの設定・運用で実際に検索されることの多い疑問に、実務の観点から答えます。
SPFレコードは1つのドメインに複数設定できますか？
いいえ、1ドメインにつきSPFのTXTレコードは1本だけにします。複数のSPFレコードを別々に登録すると、受信側は評価対象を決められずPermErrorになり、かえって認証が無効化されます。複数のサービスから送信する場合は、1本のレコードの中にincludeを並べて記述してください。
SPFを設定すればなりすましメールは完全に防げますか？
防げません。SPFはエンベロープFromの送信元IPを照合するだけで、受信者が見るヘッダFromの詐称や、転送経由のなりすましには単独では対処できません。ヘッダFromを保護するにはDMARC、改ざん検知にはDKIMが必要で、三点をセットで運用してはじめて実用的な精度になります。
SPFレコードの反映にはどのくらい時間がかかりますか？
DNSのTTL（キャッシュ有効期間）に依存し、数分から長い場合は24〜48時間ほどかかります。反映前は受信側に旧レコードが残るため、変更直後の検証で意図と違う結果が出ても、TTLの経過を待ってから再確認するのが確実です。事前にTTLを短くしておくと切り替えが読みやすくなります。
~allと-allは結局どちらで運用するのが安全ですか？
送信経路を完全に把握できるまでは~all（softfail）で運用し、DMARCのレポートで取りこぼしがないと確認できてから-all（hardfail）へ移行する順序が安全です。いきなり-allにすると正規メールが弾かれる事故が起きやすくなります。DKIM署名まで整っているなら-allが推奨側です。
SPFレコードの書き方でよくある構文ミスは何ですか？
ドメイン名の末尾に余分なピリオドを付ける、includeの後をコロンではなく等号にする、コロンとドメイン名の間に空白を入れる、の3つが典型です。いずれも文法として成立しないため検証は失敗します。登録後は必ずdigやnslookupで引き直し、意図した1行が返るかを目で確かめてください。
サブドメインから送るメールにもSPFレコードは必要ですか？
必要です。SPFの評価は完全修飾ドメイン名ごとに行われ、サブドメインは親ドメインのSPFレコードを継承しません。marketing.example.co.jpから配信するなら、そのサブドメイン用のTXTレコードを別に用意します。逆に言えば、サブドメインごとに10回の参照枠を持てるという利点にもなります。
SPFの設定や運用を外部の開発会社に依頼できますか？
依頼できます。送信経路が複数SaaSに分散していたり、DNSルックアップの上限に触れていたりする場合は、DNSとメールインフラの設計ごと委託するほうが確実です。一創ではSPF・DKIM・DMARCを含むメール認証基盤の設計や、クラウド上のインフラ構築の相談を受け付けています。
関連記事
- DMARCとは？その仕組みと設定方法、SPFやDKIMとの関係：SPFの上位に立つDMARCの設定を詳しく知りたい方へ。
- DMARCの仕組みとnone・quarantine・rejectが分けるなりすまし防御の差：DMARCポリシー3段階の実装差を実装者向けに解説。
- 名前解決とは？DNSの仕組み・正引き/逆引き・dig/nslookupでの確認方法：SPFの検証に使うDNSコマンドの基礎。
- フィッシングとは？手口の種類・見分け方と企業が取るべき組織的対策：SPF/DMARCが守ろうとするなりすましメールの手口側を解説。
- スパムとは？迷惑メール・SMS・SNSの手口と企業が取るべき対策：送信ドメイン認証がスパム判定に効く背景を整理。
- パークドメインとは？意味・仕組みと危険性、なりすまし対策のDNS設定：送信しないドメインを守る設定の考え方。
- VPNとは？仕組み・種類・メリットとデメリット、企業導入の判断基準：ネットワークセキュリティ基礎の親記事。
