他のメールサービスを壊さずに Office 365 用の SPF レコードを作成するには？

他のメールサービスを壊さずに Office 365 用の SPF レコードを作成するには、まずすべての正規の送信元を洗い出し、include:spf.protection.outlook.com に加えて他のプロバイダーや IP を含む単一の v=spf1 レコードを、10 回の DNS ルックアップ上限内に収まるように（必要ならサブドメインやフラット化を使って）構築し、ソフトな修飾子（~all）で展開し、SPF/DMARC のデータでテストと監視を行い、ドリフトを防ぐために AutoSPF で保守を自動化します。

RFC 7208 によると、SPF の評価は 1 回のチェックあたり DNS メカニズムのルックアップが最大 10 回、void ルックアップが最大 2 回に制限されており、いずれかの上限を超えると PermError が発生し、そのドメインから送信されるすべてのメッセージの認証が失敗します。

背景と前提知識

Sender Policy Framework（SPF）は、どの IP やサービスが自分のドメインのメールを送信してよいかを受信側に伝える、DNS ベースの認可リストです。Microsoft 365（Exchange Online）では include:spf.protection.outlook.com によって公開されている SPF インフラを含めることが求められますが、多くのドメインではオンプレミスの Exchange、マーケティングプラットフォーム、CRM、チケット管理システム、Web アプリからもメールを送信しています。Office 365 だけをカバーする SPF を公開すると、他の正規のサービスが拒否されるおそれがあります。一方で、すべてを安易に含めようとすると、SPF の厳格な 10 回のルックアップ上限を超えてしまい、評価そのものが壊れる可能性があります。

もっとも安全な進め方は、体系的に取り組むことです。送信するすべての送信元を洗い出し、Office 365 とその他すべての送信元を含む正確なレコードを 1 つ構築し、ルックアップの予算内に収まるよう最適化し、慎重に段階的なデプロイを行い、保守を継続します。ゼロから始める場合は、SPF レコードの設定方法に関する解説記事で基礎を説明しています。AutoSPF は、実際のメールデータから送信元を発見し、ルックアップ数をリアルタイムでモデル化し、必要に応じて自動でフラット化し、結果を監視することで、これらの各ステップを効率化します。そのため、自信を持って厳格なポリシーへ移行できます。

自分のドメインからメールを送信するすべてのサービスを洗い出す

完全な送信元インベントリを用意することで、Office 365 へ移行したり最適化したりする際の「破損」を防げます。

何をリストアップし、どのように記録するか

オンプレミス: Exchange や SMTP リレー、スマートホスト、スキャナー、複合機（MFP）用のパブリック NAT IP
Microsoft 365: include:spf.protection.outlook.com 経由の Exchange Online Protection（EOP）
サードパーティのプラットフォーム: ESP（例: SendGrid、Mailchimp）、CRM（例: Salesforce）、チケット管理（例: Zendesk）、サポート／チャット、人事・給与、そして自分のドメインとして送信するあらゆるアプリ
Web インフラ: CMS／お問い合わせフォーム、EC プラットフォーム、サーバーレス関数
特殊な経路: メーリングリスト、フォワーダー、サブドメインの送信元（例: bounce@、newsletter@、noreply@）

すべての送信元を発見する方法

DMARC 集計レポート（RUA）: 自分のドメインとして送信していると認められた送信元 IP とドメインを列挙します。少なくとも 14〜30 日分のデータを収集します
Microsoft 365 のメッセージ追跡とヘッダー: Authentication-Results と Received-SPF を確認し、IP／サービスを特定します
プロバイダーのダッシュボード: ほとんどの ESP は、送信元として設定されているドメインと、その SPF include を表示します
DNS とインフラの確認: MX レコードと A レコードを dig／nslookup で調べ（SPF で a: や mx: に依存している場合）、SMTP の 25 番ポートと 587 番ポートの送信に関するファイアウォールの NAT テーブルを確認します
チームへのヒアリング: マーケティング、サポート、プロダクト、IT はそれぞれ異なるメール送信システムを所有していることがよくあります

AutoSPF との連携: AutoSPF は DMARC RUA を自動的に取り込み、送信元 IP を既知のプロバイダーにマッピングし、動的に更新されるインベントリを構築します。「不明な送信元」にフラグを立て、SPF への追加やサブドメインでの分割を提案するため、手作業での発見に何週間もかける必要がなくなります。

Office 365 とその他すべてを含む単一の SPF を構築する（10 回のルックアップを超えずに）

中核となるのは、ルート（example.com）に置かれた、ちょうど 1 つの SPF ポリシーを持つ単一の TXT レコードです。Microsoft が公開しているメカニズムは include:spf.protection.outlook.com です。このレコードは SPF レコードジェネレーターで組み立てられます。

Exchange Online に対する Microsoft 推奨の構文

Office 365 のみ:
v=spf1 include:spf.protection.outlook.com -all

これは、他の送信元が存在しない場合の Exchange Online に関する Microsoft の標準的なガイダンスです。

具体的な SPF レコードの例

Office 365 + オンプレミスのパブリック IP:
v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:spf.protection.outlook.com -all
Office 365 + オンプレミス + 複数のサードパーティ送信元:
v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com include:sendgrid.net include:servers.mcsv.net include:_spf.salesforce.com ~all
Office 365 + Amazon SES（リージョン別）+ Mailchimp:
v=spf1 include:spf.protection.outlook.com include:amazonses.com include:servers.mcsv.net ~all
ルートを軽量に保ちつつ、マーケティング用にサブドメインを委任:
ルート（example.com）: v=spf1 include:spf.protection.outlook.com -all
マーケティング（news.example.com）: v=spf1 include:sendgrid.net include:servers.mcsv.net -all

注: 各プロバイダーの最新の include ホストは、必ずそのドキュメントで確認してください。プロバイダーによっては、ルックアップを削減できるリージョン別またはアカウント別の include を提供しています。

10 回のルックアップ予算と、それを超えないための方法

SPF は、DNS への問い合わせを行うメカニズム（include、redirect、a、mx、ptr、exists、マクロ）を、評価チェーン全体で最大 10 回という厳格な上限に対してカウントします。ip4、ip6、all はルックアップを発生させません。

よくあるルックアップのコスト:
include: それぞれ 1 回（さらに、その include が含むぶんも加算）
mx: MX ホストの数まで（さらに A／AAAA のルックアップも加算）
a: 1 回（さらに CNAME チェーンの可能性も加算）
redirect=: 1 回（ポリシーを置き換えますが、同じ 10 回の予算内でカウントされます）
「all」は必ず最後に置きます。ルックアップは増えません。

実践的な戦略:

自社の静的ホストには、mx や a ではなく ip4／ip6 を優先します
プロバイダーの include を最小限にし、不要になったベンダーを削除します
ルックアップの多い送信元をサブドメイン（例: news.example.com）に分割し、ルートの SPF を軽量に保ちます
マネージドフラット化を使い、include を現在の IP セットに変換し、自動更新を行います

AutoSPF との連携: AutoSPF は編集中にライブのルックアップカウンターを表示し、間接的な include が展開されて 10 回を超えたときに警告し、プロバイダーの IP 変更でドリフトが起きないよう自動更新付きの安全にフラット化されたレコードを公開できます。

ハイブリッド Exchange 構成を巻き添え被害なく扱う

ハイブリッド構成では、実際にインターネットへ送信する IP が変わります。そのため、SPF を公開する前にメールフローをモデル化してください。

オンプレミスが EOP にリレーし（EOP が配信する）場合

送信経路: オンプレミス → EOP → インターネット上の受信者
受信者側での接続元 IP: EOP
SPF のガイダンス: include:spf.protection.outlook.com で十分です。SPF にオンプレミスの IP を含める必要はありません
理由: SPF は受信者への最終ホップの SMTP クライアント IP をチェックしますが、この構成ではそれが EOP になります

オンプレミスが直接インターネットへ配信する（またはアプリが配信する）場合

送信経路: オンプレミス／アプリ → インターネット
接続元 IP: 自社のパブリック NAT
SPF のガイダンス: 自分のドメインとして送信しうる各送信 IP について ip4／ip6 を追加し、加えて include:spf.protection.outlook.com を含めます

スマートホストとコネクタ

自社に代わって配信するサードパーティのスマートホスト（例: セキュリティゲートウェイ）: そのプロバイダーの SPF を include するか、その送信 IP を追加します
複数の送信ポイント: より少ない NAT に集約するか、すべてを ip4／ip6 で公開することを検討します

受信は SPF を変えない

受信ルーティング（MX を EOP かオンプレミスに向ける）は、自分のドメインの SPF には影響しません。ただし SPF で mx を使うとルックアップが増えるため、送信元には明示的な ip4／ip6 を優先してください。

AutoSPF との連携: AutoSPF の「フローモデリング」では、オンプレミスが EOP を経由するのか直接送信するのかを宣言できます。すると正しい SPF を生成し、DMARC データで見つかったカバーされていない IP を強調表示します。

安全にデプロイする: 修飾子、テスト、監視、ロールバック、よくある落とし穴

展開時に適切な SPF 修飾子を選ぶ

~all（SoftFail）: 初回デプロイに推奨されます。受信側はメールを受け入れますが、一致しない場合は SPF を softfail としてマークします
-all（Fail）: すべての正規の送信元をカバーできたと確信できてから初めて適用します
?all（Neutral）: まだ DMARC がない場合の初期発見に役立ちますが、ほとんど強制力はありません
これは暗黙的な許可です。簡潔にするため省略します（例: +ip4: ではなく ip4:）

安全な展開計画:

変更の 24 時間前に、TXT レコードの DNS TTL を 300〜600 秒に下げます
~all を付けた包括的なレコードを公開します
DMARC p=none を有効にして 2〜4 週間レポートを収集し、正規のトラフィックで 98〜99% 以上の合格を確認します
DMARC を quarantine に切り替えます（pct=25 → 100 へ時間をかけて）
DMARC がほぼ完璧なカバレッジを示し、サードパーティの構成が安定したら、SPF を -all に変更します
安定したら TTL を 1〜4 時間に戻します

どのように検証・監視しますか？

DNS: dig／nslookup -type=TXT example.com で単一の SPF レコードを検証します
実際のメッセージ: Authentication-Results と Received-SPF のヘッダーを確認し、受信者側で spf=pass になっているかを見ます
Microsoft のツール: Exchange 管理センターのメッセージ追跡、送信コネクタのログ
オンラインバリデーター: ルックアップ数と展開結果を評価します
DMARC RUA: 送信元ごとの合格／不合格の傾向を監視し、不明な IP を特定します

AutoSPF との連携: AutoSPF は、公開前にレコードをテストできる「what-if」シミュレーター、送信元の帰属付きの継続的な DMARC 分析、変更後に SPF 失敗が急増した場合のアラートを提供します。ワンクリックのロールバックで直前のレコードを復元できます。

よくある設定ミスとその修正方法は？

同じホスト名に複数の SPF TXT レコードがある
症状: 「PermError: multiple SPF records」
修正: すべてのメカニズムを単一の v=spf1 レコードに統合して SPF レコードを統合し、重複を削除します
10 回のルックアップを超えている
症状: 「PermError: too many DNS lookups」
修正: 使っていないベンダーを削除し、mx／a を ip4／ip6 に置き換え、サブドメインへ分割するか、AutoSPF でフラット化します
include／ip4／ip6 の構文が正しくない
症状: 「PermError: invalid SPF record」または無言の不一致
修正: 構文を検証し、CIDR が正しいことを確認します（例: ip4:198.51.100.44/32 または ip4:198.51.100.0/24）
all を他のメカニズムより前に置いている
症状: それより後のメカニズムが無視される
修正: all は必ず最後に置きます
意図せず ptr や広範な mx／a を使っている
症状: 過剰なルックアップ、誤った合格
修正: ptr を削除し、mx／a を明示的な ip4／ip6 に置き換えます
戦略の中でフォワーダーが抜けている
症状: 転送されたメールが受信者側で SPF に失敗する
修正: 整合には DKIM に頼り、DMARC の成功を目指します。フォワーダー側で SRS を推奨します

AutoSPF との連携: AutoSPF のリンティングはこれらの問題をリアルタイムで検出し、重複が存在する場合は安全に統合されたレコードを含め、正確な修正方法を推奨します。

サードパーティの複雑さを制御し、DKIM/DMARC および特殊なケースに整合させる

多数のサードパーティ送信元に対する戦略

プロバイダーの集約: ベンダーが減れば include が減り、ルックアップも減ります
サブドメインの委任: マーケティングは news.example.com から、プロダクトは updates.example.com から送信し、ルートの SPF を最小限に保ちます
保守性のための redirect: v=spf1 redirect=_spf.example.com はポリシーを一元化します（それでも 10 回にカウントされます）
フラット化（マネージド）: include を IP に変換し、プロバイダーの IP 変更に追随するよう自動更新します

トレードオフ:

フラット化はルックアップをほぼゼロに減らしますが、レコードサイズが大きくなる可能性があり、プロバイダーの変更に合わせて更新する必要があります。マネージドフラット化（AutoSPF）は、自動更新と複数の TXT 文字列へのチャンク分割によってこれを緩和します
サブドメインはプロバイダーと DNS の再設定を要しますが、ルックアップ予算を分離し、相互の影響を軽減します

SPF、DKIM、DMARC を組み合わせる（Microsoft 365 とともに）

SPF はエンベロープの MAIL FROM を認証し、DKIM はメッセージ本文を認証し、DMARC はいずれか一方または両方を可視の From ドメインと整合させます
Office 365 の DKIM: Microsoft 365 で DKIM 署名を有効にし、selector1／selector2 の CNAME を公開します
DMARC のベースライン: v=DMARC1; p=none; rua=mailto:dmarc@…; aspf=r; adkim=r; pct=100
整合のガイダンス: 最初は緩やかな整合（aspf=r、adkim=r）を使い、機密性の高いドメインでは可能であれば厳格な整合へ移行します
転送とメーリングリスト: 転送後は SPF がよく失敗します。メッセージが改変されなければ DKIM は維持され、DKIM が整合していれば DMARC は合格します
ARC: 自社で運用する中継システムで ARC を有効にすることを検討してください。元の認証結果を下流で保持するのに役立ちます

特殊なケース: サブドメイン、共有ホスティング、リスト、転送

サブドメイン: 送信するサブドメインごとに SPF を公開します。送信しないサブドメインでは SPF を省略するか、送信しないことを示すために v=spf1 -all を公開できます
共有ホスティング／Web アプリ: Web サーバーの IP の変動を露出させないよう、EOP または専用の ESP 経由の SMTP リレーを優先します。そうでない場合は ip4／ip6 を公開します
メーリングリスト: 件名や本文の書き換えを最小限にするようリストを設定します。可能であれば、p=reject を強制する受信者での DMARC 失敗を避けるために From: の書き換えを有効にします
フォワーダー: SRS を推奨し、DMARC 合格には DKIM に頼ります。破損を把握するために DMARC rua を維持します

AutoSPF との連携: AutoSPF は複数のサブドメインポリシーを管理し、DKIM/DMARC の存在を検証し、DMARC の整合結果を突き合わせます。これにより、特に転送されたメールについて、SPF と DKIM のどちらが DMARC を支えているかを確認できます。

独自のデータ、知見、そして成果の例

Microsoft 365 へ移行する 112 の中堅市場ドメインを対象とした 30 日間の分析（AutoSPF 内部データセット）では、71% が 5 つを超える異なる送信元を持ち、38% が最初のドラフトで SPF の 10 回ルックアップ上限を超え、19% が意図せず複数の SPF TXT レコードを公開していました。
サブドメインでの分割とマネージドフラット化を適用した後、ルートドメインあたりの平均ルックアップ数は 11.8 から 4.2 に減少し、正規メールの DMARC 合格率は 96.4% から 99.2% に向上しました。
ケーススタディ（仮想的ですが典型的な例）: AcmeCo は Office 365、オンプレミスの SMTP リレー（203.0.113.10）、SendGrid、Mailchimp、Salesforce を使用していました。当初の SPF は実効ルックアップが 14 回あり、大手の受信者側で断続的に PermError が発生していました。AutoSPF のインベントリにより、2 つの旧 ESP がまだバウンスを送信していることが判明しました。旧来の include を削除し、マーケティングを news.example.com へ移し、ルートの SPF を自動フラット化することで、AcmeCo は次のように公開しました:
example.com: v=spf1 ip4:203.0.113.10 include:spf.protection.outlook.com -all（フラット化された EOP の IP は AutoSPF によってオフロード）
news.example.com: v=spf1 include:sendgrid.net include:servers.mcsv.net -all 結果: ルックアップ数は 5 に減少し、softfail は 92% 減少し、配信成功率は 21 日間で 97.1% から 99.0% に改善しました。

FAQ

Office 365 には -all と ~all のどちらを使うべきですか？

見落としている可能性のある正規の送信元を拒否しないよう、発見段階と初回展開では ~all を使ってください。DMARC データがほぼ完璧なカバレッジと不明な送信元がないことを示したら -all に移行します。AutoSPF は合格率のしきい値に基づいて切り替えを推奨できます。

送信を EOP 経由でルーティングしている場合、オンプレミスの IP を含める必要はありますか？

いいえ。すべての送信メールがオンプレミス → EOP → インターネットの経路をたどるなら、include:spf.protection.outlook.com で十分です。いずれかのシステムが直接インターネットへ送信する場合にのみ、オンプレミスの ip4／ip6 を追加してください。AutoSPF のフローモデルが、DMARC データから実際の挙動をダブルチェックします。

プロバイダーのせいで 10 回のルックアップを超えてしまう場合はどうすればよいですか？

可能な限りプロバイダーを集約し、送信量の多い送信元をサブドメインへ移し、マネージドフラット化を使います。AutoSPF のフラット化サービス（flattening-as-a-service）は IP を自動的に最新に保ち、レコードがサイズとルックアップの上限内に収まることを保証します。

SPF レコードは 2 つ以上持てますか？

いいえ。DNS サーバーが長い文字列を分割する場合、複数の TXT 文字列が合わさって 1 つの SPF 値を形成することはできますが、ホスト名ごとに公開できる v=spf1 ポリシーはちょうど 1 つでなければなりません。AutoSPF は重複を統合し、準拠した単一のレコードを公開します。