メールプロバイダー切り替え後に SPF が動作しなくなった — マイグレーション修正（2026）

公開日 2026-07-08

データ基準日：2026-06-29 · 方法論 v7。 261 百万件のグレード済みドメインに対する集計センサスデータ。グレード方法についてはこちら。

SPF はメールプロバイダーの切り替え後に通常壊れます。新しいプロバイダーのレコードが古いものの隣に追加されたためです。2 つの v=spf1 レコードは永久エラーです — SPF が完全に無効化されます。Defaults.Exposed による 261 百万件のドメインセンサスによると、1,013,416 件のドメイン — SPF を試みているドメインの約 138 件に 1 件 — がこの状態にあります。1 つにマージしてください。

修正には約 10 分かかります：ドメインをスキャンしてマイグレーションが残したものを正確に確認し、権威ネームサーバーですべての SPF レコードをリストアップし、新しいプロバイダーのみを含む 1 つのレコードにマージし、dig で再確認します。このガイドでは各ステップと、ほとんどのマイグレーションが忘れる DKIM とネームサーバーの確認について説明します。

マイグレーション直後に SPF が壊れたのはなぜか？

新しいプロバイダーのセットアップガイドが「この TXT レコードを追加してください」と言い — あなたはそれを古いものの隣に追加しました。これが SPF 標準が許可しない唯一のことです。RFC 7208（§3.2、§4.5 で規定されたエラー結果）はドメインごとにちょうど 1 つの v=spf1 レコードのみを許可します；2 つ以上を見つけた受信者は、どちらが権威を持つかを推測するのではなく、PermError を返さなければなりません。PermError は SPF が無効であることを意味します：古いレコードではなく、新しいレコードでもなく、SPF は全くないのです。

そしてそれだけでは終わりません。DMARC は PermError を SPF レッグの失敗として扱うため、メールは完全に DKIM に依存します。新しいプロバイダーの DKIM もまだセットアップされていない場合 — マイグレーション中によくあること — インフラを変更したまさにその瞬間に未認証で送信しています。これは受信者が最も厳しく精査するタイミングです。

これはプロバイダーを切り替えるときに保護を無効化するコピー・ペーストであり、稀ではありません：1,013,416 件のドメインが現在 2 つ以上の SPF レコードを公開しています — Defaults.Exposed による 261 百万件のドメインセンサスによると、SPF を試みる 139 百万件の母集団の約 138 件に 1 件（2026-06-29 時点のデータ）。2 レコードトラップの完全な数字には独自のレポートがあります；このページは手続き上の修正です。

マイグレーションが残したものは何か？

5 つの残存物がほぼすべてのマイグレーション後の SPF 失敗の原因です。この順番で確認してください：

残ったもの	見える症状	修正
古い SPF レコードが DNS に残り、新しいものの隣にある（2 つの `v=spf1` レコード）	チェッカーが「複数の SPF レコード」または PermError を報告；SPF が完全に停止	1 つのレコードにマージし、残りを削除 — 以下のステップ
1 つのレコード内の古いプロバイダーの `include:`	SPF は機能するが、DNS ルックアップを無駄にしており、古いプロバイダーのサーバーが引き続きあなたとして送信できる	古いシステムからメールが完全に引き抜かれたら削除
新しいプロバイダーの `include:` が追加されていない	新しいプロバイダーからのメールが受信者で SPF に失敗	既存の 1 つのレコードに追加 — 新しいレコードとしては絶対に追加しない
新しいプロバイダーの DKIM セレクターが作成されていない	`dkim=fail` またはプロバイダーのデフォルトドメインからの署名；DMARC に 2 番目のレッグがない	新しいセレクターを公開 — 以下のステップ 6
古いネームサーバーのみでレコードが更新された	質問する人によって異なる回答；断続的な失敗	権威ネームサーバーでゾーンを修正；カットオーバー中に両方のセットを確認

修正方法：マイグレーションチェックリスト

まずdefaults.exposedの無料スキャンを実行する。 ライブ DNS を読み取り、複数の SPF レコード、欠落した include、または DKIM のギャップがあるかを教えてくれます — 何かに触れる前に診断します。
権威ネームサーバーですべての SPF レコードをリストアップする。 dig +short NS yourdomain.com、次に dig +short TXT yourdomain.com @<nameserver> でその 1 つに対して。v=spf1 で始まる文字列を数えます。安全なカウントは 1 のみです。
1 つのレコードにマージする。 1 つのレコード、v=spf1 で始まり、新しいプロバイダーの include と今でも使っている他の送信者（請求ツール、CRM、ニュースレタープラットフォーム）を含み、1 つの終端 -all または ~all。例 — 古い Google Workspace、新しい Microsoft 365、引き抜き中：
```
Before:  "v=spf1 include:_spf.google.com ~all"
         "v=spf1 include:spf.protection.outlook.com -all"

After:   "v=spf1 include:spf.protection.outlook.com include:_spf.google.com -all"
Later:   "v=spf1 include:spf.protection.outlook.com -all"
```
プロバイダーの値と DNS パネルの特性は Google Workspace と Microsoft 365 のセットアップガイドにあります。
余分なレコードを削除する。 削除せずにマージしても何も修正されません — PermError はカウントから来ます。
古いシステムがまだ送信している間だけ古いプロバイダーの include を保持する — スケジュールレポート、古い CRM コネクタ、忘れられたメールボックス。引き抜きが終わったら削除してください：古い include は古いインフラがあなたとして送信することを許可し続け、各 include は SPF の 10 という上限に対して DNS ルックアップを消費します — 少なくとも 797,263 件のドメインがその上限を超えて SPF を無効化しています（センサス、2026-06-29）。
新しいプロバイダーの DKIM をセットアップする — そして古いセレクターをまだ削除しないでください。 新しいセレクターは新しいメールに署名します；古いセレクターはそれらで署名されたすべてのメッセージが配信されて転送が落ち着くまで公開したままにする必要があります。完全なウォークスルーはメールツール切り替え後の DKIM 失敗にあります。
ネームサーバーも変更した場合は、両方を確認する。 DNS マイグレーションはメールマイグレーションに伴うことがよくあります。古いと新しい NS セットの両方に直接クエリします（dig TXT yourdomain.com @old-ns と @new-ns）— レジストラの委任が完全に伝播するまで、一部の受信者はまだ古いサーバーに問い合わせるため、修正されたレコードが回答する方のセットに存在する必要があります。
再スキャンを実行し、SPF が有効な 1 つのレコードでパスを示すことを確認します。

SPF は実際にどのドメインを確認するか？

受信者はReturn-Path（RFC5321.MailFrom）ドメイン — バウンスアドレス — に対して SPF を評価します。受信者が見る From ヘッダーではありません。マイグレーション後、これは 2 回重要です：新しいプロバイダーはカスタムドメインを設定するまで自分のバウンスドメインを使うことがあり、あなたのドメインでない Return-Path での SPF「パス」は DMARC にアライメントしません。それに対する修正は新しいプロバイダーの DKIM であり、あなたのドメインで署名されます。

同時にリブランドもしているか？

ドメインもプロバイダーと一緒に変更した場合？ 2 つの別々の仕事として扱ってください。新しいドメインは初日から完全なスタック — SPF、DKIM、DMARC — が必要です；新しいドメインのメールチェックリストを使用してください。古いドメインは転送または返信トラフィックが流れる限り認証されたままで、駐車されたら（単に放棄するのではなく）明示的にロックダウンされます。残存した半分壊れた SPF を持つ古いドメインはあなたの旧名を持つなりすまし標的です。

よくある質問

マイグレーション中に 2 つの SPF レコードを保持できるか？ いいえ。標準には猶予期間がありません — 2 つの v=spf1 レコードは 2 番目が存在した瞬間から PermError であり、センサスによると 1,013,416 件のドメインが（2026-06-29）その状態にいます。マイグレーション安全なパターンは、重複期間中に両方のプロバイダーの include を持つ 1 つのレコードです。

古いプロバイダーの include をどのくらい保持すべきか？ 古いプロバイダーを通じて何も送信しなくなるまで — 通常は重複ウィンドウの長さ、数日から数週間。まだ古いシステムを通じて届いているものの Return-Path を見て；そのトラフィックが止まったら include を削除してルックアップ数を再確認します。

修正後もチェッカーが古いレコードを表示するのはなぜか？ DNS キャッシュはレコードの TTL に従い、ネームサーバーが変わった場合は一部のリゾルバーがまだ古いセットにクエリします。権威ネームサーバーで直接 dig TXT yourdomain.com @<ns> で確認してください — そこで回答が正しければ修正は完了し、キャッシュが追いつきます。1 つの NS セットで間違っている場合は、「SPF レコードが見つからない」 — 本当の原因を参照してください。

プロバイダーを切り替えるとき DMARC も変更する必要があるか？ 通常はレコード自体には不要です — レポートメールボックスとポリシーを記載しており、プロバイダーではありません。しかし DMARC の結果は今移行した SPF と DKIM に依存します：カットオーバー中はレポートの落ち込みを予期し、ポリシーを強化する前に両方のレッグがパスすることを確認してください。スキャンが SPF レッグが失敗していることを示す場合は SPF の修正から始めてください。

オーナーにレポートを送る

このマイグレーションをクライアントのために行っている場合は、証拠で作業を終えてください。マージが有効になったら無料スキャンを再実行し、採点済みレポートをビジネスオーナーに転送してください：新しいプロバイダーで SPF、DKIM、DMARC がパスしている、平易な言葉、日付付き。これがサイバー保険の更新と次のサプライヤーセキュリティアンケートに必要なアーティファクトです — マイグレーションが開始時よりもドメインを良く認証した状態で残したという証明です。

ドメインを確認 → · メールツール切り替え後の DKIM 失敗 → · 「SPF レコードが見つからない」— 本当の原因 → · グレード方法について → · 集計データのみ。データは EU で保存・処理されます。