Defaults.Exposed › 修正 › Guides

転送メールが SPF に失敗する — 修正できない理由と本当に機能する方法（2026）

公開日 2026-07-08

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

転送されたメールの SPF をパスさせることはできません — 転送は設計上 SPF を壊し、正直な修正は転送後も生き残るアライメントされた DKIM です。規模はセンサス全体に及びます：Defaults.Exposed による 261 百万件のドメインセンサスによると、7,355,985 件の 138,927,207 件の SPF 公開ドメインが Namecheap の転送 include のみを承認しており、厳格 SPF の割合は <0.1% です。

以下では、あなたが書くどんな SPF レコードも転送に生き残れない理由、SRS と ARC があなたがコントロールするツールでない理由、そして持続する修正 — あなたの DMARC パスとして自分のドメインで DKIM 署名 — を説明します。さらに DKIM も壊すケース（メッセージを書き換えるメーリングリスト）とその残余に対する対処法を説明します。

なぜ転送は SPF を壊すのか？

受信者は Return-Path（RFC5321.MailFrom）ドメイン、From ヘッダーではなくに対して SPF を評価します。直接送信する場合、あなたのサーバーの IP は SPF レコードにあり、チェックがパスします。受信者がメッセージを自動転送すると — 個人の Gmail へ、大学のエイリアスを通じて、レジストラの転送製品経由で — 転送者のサーバーが再送信し、通常は Return-Path にあなたのドメインを保持します。最終受信者は今問います：この転送サーバーはあなたの SPF レコードで承認されているか？

されていませんし、永遠にそうはなりません：あなたは転送者を選択しませんでした、それが存在することを知りませんでした、そして明日別のサービスを通じて転送された同じメッセージは別の IP から失敗するでしょう。SPF は 1 つの質問に答えます — 「この IP は Return-Path ドメインが承認したサーバーから来たか？」— そして転送されたメールに対する本当の答えはノーです。失敗は SPF が仕様通りに機能しており、あなたのレコードが間違っているのではありません。

センサスはこのパスがいかに主流かを示しています：7,355,985 件のドメインが Namecheap のメール転送 include（spf.efwd.registrar-servers.com）を承認しています — 139 百万件の SPF 公開者から引いた、1 つのプロバイダーの転送製品 — 厳格 SPF の割合は <0.1%、DMARC を強制するのはわずか 0.2%。この軟らかいテンプレートは不注意ではありません：転送は厳格な -all が誤作動する場所であり、製品が転送であるプロバイダーはそれに応じて出荷します。完全な修飾子の話は ~all vs -all レポート、プロバイダーごとの画像はどのメールプロバイダーが最も強い SPF を提供するかにあります。

転送者のサーバーを SPF レコードに追加できないか？

いいえ — そしてその理由がこの記事全体です：

1. 転送者を列挙できません。 どこにいても誰でも、どんなサービスを通じてもメールを転送できます。SPF レコードは事前に知ることができないサーバーをリストする必要があります。
2. リストすることは目的を無効にします。 大きな転送サービスは何百万もの顧客のためにメールを中継します。あなたのレコードにその範囲を入れると、そのユーザーの誰でも中継するすべてのメッセージ — なりすましを含む — があなたとして SPF をパスします。

同じ論理が、修飾子を緩めて「転送を機能させる」ことを排除します：修飾子は転送されたメールが失敗する理由ではありませんし、DMARC が有効な場合、ほとんどのガイドが主張するよりも変わりません — 修飾子のデータを参照してください。レコードはここではレバーではありません。引っ張るのをやめてください。

SRS と ARC — 転送を修正しないか？

対処しています — しかしどちらもあなたが展開するものではありません：

データおよびメカニズムの状況：2026-06-29 時点。

SRS は転送者の SPF 問題を解消しますが、あなたのものではありません：Return-Path を書き換えることで誰の SPF が確認されるかが変わりますが、DMARC が守る From ヘッダー — あなたのドメイン — は変わりません。ARC はインフラ事業者間の信頼決定です。ガイドがドメインオーナーとして「SRS を実装する」よう言っているなら、あなたを転送プロバイダーと混同しています。

メールを転送後も生き残らせる方法

あなたのドメインにアライメントされた DKIM を、DMARC パスにしてください。DKIM 署名はメッセージヘッダーに運ばれる暗号化です：署名されたコンテンツが変更されていない限り、何台のサーバーが中継しても、どこにメッセージが届いても確認できます。DMARC は一方のアライメントされたパス — SPF または DKIM — のみが必要なため、転送が SPF レッグを殺すと、アライメントされた DKIM がメッセージを認証した状態に保ちます。

1. DNS に触れる前にdefaults.exposedの無料スキャンを実行する。 DKIM があるかどうか、あなたのドメインで署名されているか、そして DMARC がどこにあるかを確認します — SPF レコードと戦うのではなく実際のギャップを修正するためです。
2. 転送が実際にあなたの問題であることを確認する。 影響を受けたメッセージの Authentication-Results ヘッダーで、直接メールは SPF をパスするが転送されたコピーは転送サービスの IP から失敗します。SPF と DKIM の両方がパスするが DMARC が失敗する場合は、代わりにアライメントの問題があります — DMARC が失敗するが SPF と DKIM はパスするを参照してください。
3. すべての送信サービスで自分のドメインで DKIM 署名を有効にする — まずメールボックスプロバイダー、次に ESP とトランザクション送信者。プロバイダーのデフォルトはプロバイダーのドメインで署名することが多く、アライメントされません；あなたは d=yourdomain を望みます。DKIM の修正方法から始め、Google Workspace と Microsoft 365 のクリックパスを参照してください。
4. パスだけでなくアライメントを確認する。 署名の d= ドメインが From ドメインと一致している必要があります；他人のドメインの dkim=pass は DMARC に対して何もしません。
5. SPF レコードをそのままにする。 直接メールに対して正確に保ちます — それでもほとんどのトラフィックを認証し、2 番目の DMARC レッグとして残ります。転送者をカバーしようとするのをやめるだけです。
6. 再スキャンし、次に DMARC 強制を意図的に段階的に進める — 次のセクション、そして p=none から p=reject へのロールアウトガイドを参照してください。

この組み合わせ — アライメントされた DKIM に乗った SPF と強制 DMARC — が転送に強いパターンであり、稀です：~all を公開している 77.5 百万件のドメインのうち、強制 DMARC ポリシーを持つのはわずか **9.2%（7,116,774）**で、センサス（2026-06-29）によると完全な SPF + DKIM + 強制 DMARC のトライアドを完成させるのは 261 百万件のグレード済みドメインのわずか **3.87%（10,092,481）**です。

メッセージを書き換えるメーリングリストはどうするか？

アライメントされた DKIM が生き残れない 1 つの転送パス：メッセージを変更するメーリングリスト — [list-name] 件名タグ、購読解除フッター、削除された添付ファイル。署名されたコンテンツを変更するとボディハッシュが一致しなくなり、DKIM も失敗します（dkim=fail: ボディハッシュが確認されなかったがその失敗専用のガイドです）。これで DMARC の両方のレッグが死に、リストのみがそれを緩和できます（From 書き換え、ARC シーリング）。

この残余はまさに段階的な DMARC 強制のためのものです。集計レポートを見ながら pct ランプで p=quarantine を進めることで、p=reject ポリシーがバウンスを始める前に実際のメールのどのくらいが書き換えるリストを通じて流れるかが示されます。メーリングリストに住むユーザーを持つドメインで reject に飛ばないでください；永遠に p=none に停滞もしないでください。段階的ロールアウトガイドがランプを解説しています。

よくある質問

転送は DKIM も壊すか？ プレーンな転送は壊しません：署名はメッセージとともに移動し、最終受信者で確認されます。DKIM は署名されたコンテンツが途中で変更された場合のみ壊れます — メーリングリストの件名タグとフッターが古典的なケースです — これがリストの残余が DNS の何かではなく DMARC ポリシーのステージングによって処理される理由です。

転送の失敗を止めるために -all から ~all に切り替えるべきか？ 修飾子を変更しても転送者をパスさせません — それが失敗する理由ではありません。Namecheap の転送 include、7,355,985 件のドメインとセンサスの最大の専用転送集団（2026-06-29）が厳格 SPF の割合 <0.1% で出荷していることは興味深いです：軟らかい SPF は転送製品に正しいテンプレートかもしれません。修飾子が実際に変えるものについては ~all vs -all レポートを参照してください。

なぜメールは直接送信した場合は SPF をパスするのに、誰かが転送するとパスに失敗するのか？ 受信者は Return-Path ドメインの SPF レコードで最後の送信サーバーの IPが承認されているかを確認します。直接：あなたのサーバー、あなたのレコードにある、パス。転送：転送者のサーバー、あなたのレコードにない、失敗。あなたのレコードは変わっていません — 送信 IP が変わりました。

SRS をセットアップして修正できるか？ あなたが転送者の場合のみ。SRS は転送を行うサーバーで実行され、そこで実行されても、結果として得られる SPF パスは転送者のドメインに属し、あなたの From にはアライメントしません — あなたの DMARC はまだ DKIM レッグが必要です。

転送が壊すなら SPF は意味がないか？ いいえ。ほとんどのメールは直接配信され、SPF は意図通りに機能し、2 つの DMARC レッグの 1 つとして残ります。センサス（2026-06-29）の 261,086,232 件のドメインのうち、138,927,207 件が SPF を公開しています — SPF 修正ページで正確に保ち、DKIM に転送された残りを任せましょう。

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

クライアントまたは雇用主のためにこれを修正している場合は、証拠でループを閉じてください。カスタムドメイン DKIM が有効になり DMARC がステージングされたら、無料スキャンを再実行してビジネスオーナーに採点済みレポートを転送してください：日付付き、平易な言葉、メールが転送されても認証された状態を保つことを示す。これがサイバー保険の更新と次のサプライヤーアンケートのアーティファクトです — 「何かをオンにしました」ではなく文書化された前後の比較です。

ドメインを確認 → · DMARC が失敗するが SPF と DKIM はパスする → · DKIM を修正 → · グレード方法について → · 集計データのみ。データは EU で保存・処理されます。