SaaS ツールで SPF が失敗する？なぜ起きるか、修正の優先順位 — ヨーロッパ版（2026）

公開日 2026-07-08

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

SaaS ツールが「SPF 失敗」と言う場合、あなたのレコードが問題ではないことがほとんどです：メールが DMARC アライメントに失敗しているか、include チェーンが SPF の 10 回 DNS ルックアップの上限を超えています。Defaults.Exposed による 261,086,232 件のドメインセンサスによると、2,119,539 件の 138,927,207 件の SPF 公開ドメインが 9〜10 ルックアップの崖っぷちにいます — SaaS の include 1 つで崖から落ちます。

以下では、2 つの問題のどちらを持っているかを判断する方法と、修正の順序を説明します — まずスキャン、ツールが実際に送信するドメインを見つけ、ベンダーをカスタムドメイン DKIM に切り替え、本当に助けになる場合のみ SPF include を追加 — さらに HubSpot、Salesforce、Mailchimp、SendGrid の具体的な方法を説明します。

なぜ SaaS ツールからのメールが SPF に失敗するのか？

ほぼすべてのケースをカバーする 3 つのパターンがあります：

レポートやバウンスの内容	実際に何が問題か	修正
SPF パス、DMARC はまだ失敗	*アライメント：ツールがあなたのドメインではなく自分のバウンスドメインで SPF をパスした*	ベンダーのカスタムドメイン DKIM（CNAME）を有効にする
SPF `permerror`	include チェーンが SPF の 10 回 DNS ルックアップの上限を超えている	include を削減；ルックアップ過多の修正を参照
SPF `fail` / `softfail`	ツールが実際にあなたの return-path であなたのドメインから送信しているが、レコードに含まれていない	ベンダーの include を追加するか、カスタムバウンスドメインを有効にする

データ基準日：2026-06-29。

太字の行がほとんどの人が立っている場所です。すべてのツールに include: 行を追加しても解決しません — そして各行は 2 番目の行に近づけます：少なくとも 797,263 件のドメインがすでに 10 ルックアップの上限を超えており、SPF が PermError を返し、何も保護していません。詳細な数字は SPF PermError レポートをご覧ください。

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

From ヘッダーのドメインではありません。受信者は Return-Path ドメイン（RFC5321.MailFrom、バウンスまたはエンベロープ From アドレスとも呼ばれます）に対して SPF を評価します — 受信者が見る From ヘッダーは SPF チェック自体には関係しません。

この 1 つの事実がほとんどの「SaaS SPF 失敗」を説明します。マーケティングプラットフォームが [email protected] のような Return-Path で送信します；SPF は vendor.com に対して確認されてきれいにパスします。次に DMARC が、その SPF 確認済みドメインがあなたの From ドメインと一致するかを確認します。一致しないため、DMARC の SPF レッグが失敗し、ダッシュボードが「SPF 失敗中」と表示します。自分の SPF レコードを編集しても修正できません — あなたのレコードは参照されていませんでした。

修正の順序は？

まず無料スキャンを実行する。 SPF が欠落・重複・ルックアップ上限超過・問題なしのどれか、そして DMARC の状況を、DNS に触れる前に一度に教えてくれます。
ツールが実際に使う Return-Path を見つける。 ツールからテストメールを送り、生メッセージの Return-Path ヘッダー（と Authentication-Results）を読んでください。これで上の表のどの行にいるかがわかります。
ベンダーのカスタムドメイン DKIM を有効にする。 すべての真剣な SaaS ツールは「ドメイン認証」を提供しています：あなたのドメインで DKIM 署名できるようにする数件の CNAME レコードです。この署名はあなたの From ドメインとアライメントされるため、転送されても DKIM 経由で DMARC がパスします。これが持続する修正です。
ベンダーの SPF include は、return-path にあなたのドメインを使う場合のみ追加する — カスタムバウンスドメインを有効にしているか、実際にエンベロープであなたのドメインから送信している場合。自分のバウンスドメインでバウンスするベンダーへの include は何も買わず、ルックアップ予算を消費するだけです。
保存前に DNS ルックアップ数を数える。 上限は 10 解決ルックアップで、include は再帰的にカウントされ、2,119,539 件のドメインがすでに 9〜10 にいます — センサスの p99 は 9 です。上限に近い？まず使わなくなったツールの include を削除してください。メールプロバイダーを切り替えたばかり？残った 2 番目のレコードを確認してください — 2 つの SPF レコードは PermError に等しい。
再スキャンして確認する。 正しいドメインで SPF パス、DKIM アライメント済み、DMARC パス。完全なリファレンスは SPF の修正方法にあります；GoDaddy の SPF や IONOS の DMARC のようなプロバイダーのウォークスルーは DNS パネルのクリックをカバーしています。

HubSpot、Salesforce、Mailchimp、SendGrid はどうすべきか？

HubSpot。 HubSpot の設定で送信ドメインを接続し、発行される 2 件の DKIM CNAME（hs1-… / hs2-…）を公開してください。これで DKIM が From ドメインとアライメントされます。カスタムバウンスドメインを使うよう HubSpot を設定していない限り、HubSpot の SPF include は不要です。

Salesforce。 Salesforce Setup で DKIM キーを作成し、生成される CNAME ペアを公開してください。Salesforce が組織の return-path で送信する場合、include:_spf.salesforce.com を追加しバウンスドメインを設定してください — これは SPF include が実際に必要とされることが多い大きな CRM です。

Mailchimp。 ドメインを認証し、k2 / k3 の DKIM CNAME を公開してください。Mailchimp のアライメントは DKIM のみです — 追加すべき SPF include はもうありません。古いチュートリアルの include を追加するとルックアップを無駄に消費するだけです。

SendGrid。 ドメイン認証（「自動セキュリティ」）を完了してください：DKIM と独自サブドメインの return-path の両方を処理する 3 件の CNAME。SPF include は不要です。sendgrid.net を SPF で承認している 740,321 件のドメインのうち、強制的な DMARC（2026-06-29 時点のデータ）を持つのはわずか 18.0% です — ほとんどの SendGrid 送信者があと 1 ステップのところで止まっています。

Zendesk その他：同じパターンです。ツールの「ドメイン認証」ページを見つけ、DKIM CNAME を公開し、ツールがあなたの return-path を使うとドキュメントに書いてある場合のみ SPF に触れてください。

EU のビジネスにとって SPF は違うのか？

いいえ — SPF、DKIM、DMARC はどこでも同じように動作します。ヨーロッパで違うのは文脈です：誰が尋ねているか、そして隣人がすでに何をしているか。

ccTLD がローカルの基準を設定する。 ヨーロッパの ccTLD は .com レートを上回る SPF 採用率を公開していますが、その上に強制的な DMARC ポリシーを持つドメイン — 仕事を完成させるもの — はどこでも少数派です：

TLD	SPF 採用率（グレード済みドメインのうち）	強制 DMARC（グレード済みドメインのうち）
.nl	75.91%	29.43%
.ie	70.89%	8.79%
.de	64.67%	21.38%
.dk	50.42%	19.88%
.com	54.14%	9.50%

データ基準日：2026-06-29。フランス：13.65% が DMARC を強制；イタリア：5.24%。

ヨーロッパのホストのデフォルトが重要。 4,346,526 件のドメインが IONOS の EU メールサーバー（_spf-eu.ionos.com）を SPF で承認しています — 厳格な -all で終わるのはわずか 0.3%、DMARC 強制は 1.0% のみ。OVH の 2,132,049 件は厳格さでより良い成績（43.7%）を示していますが、DMARC を強制するのは 2.2% のみです（2026-06-29 時点のデータ）。レコードに触れたことがない場合、これらのデフォルトの上に立っています。

規制当局は今これに言及しています。 NIS2 第 21 条(2)(j)は、対象エンティティに通信の安全確保を求めており、委員会実施規則（EU）2024/2690 はメールおよび DNS セキュリティ対策を詳述しています。メール認証は具体的で確認可能な部分です — そして珍しいことに、コンプライアンスとして無料で修正できます。

データ保存について： Defaults.Exposed スキャナーとセンサスは AWS eu-west-1 で実行されており、集計データのみを公開し、スキャンはあなたが尋ねるドメインのみを確認します。

よくある質問

SPF チェッカーが「パス」と言うのに、ツールのダッシュボードが SPF 失敗と言う — なぜか？ チェッカーはあなたのレコードをテストしました；受信者はツールが実際に使った Return-Path ドメインをテストし、次に DMARC がそれをあなたの From ドメインと比較しました。これはレコードの失敗ではなくアライメントの失敗です — SPF の編集ではなく、ベンダーのカスタムドメイン DKIM で修正されます。

使っているすべてのツールに SPF include を追加すればいいか？ いいえ。各 include は SPF の 10 ルックアップ予算の一部を再帰的に消費します：2,119,539 件の 138,927,207 件の SPF 公開ドメインが 9〜10 ルックアップにおり、少なくとも 797,263 件が超えています — SPF が PermError を返し何も保護していません（2026-06-29 時点のデータ）。

include は DMARC も修正するか？ ツールがあなたの return-path で送信する場合のみ、SPF がパスしアライメントされます。ほとんどの SaaS ツールにはそれがありません — これが、SPF ではなくアライメントされた DKIM が SaaS メールの DMARC パスを実現するレッグである理由です。

EU ではこれは法的要件か？ NIS2 の対象エンティティにとって、第 21 条(2)(j)と実施規則（EU）2024/2690 はメールセキュリティを義務にしています。対象外でも、保険会社や顧客アンケートがますます尋ねるようになっています — そして 2026-06-29 時点で、EU の ccTLD はどれも 3 分の 1 のドメインすら強制的な DMARC ポリシーに至っていません（.nl で最良の 29.43%；.it で 5.24%）。

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

CNAME が有効になったら、再スキャンを実行してビジネスオーナーまたはクライアントに採点済みレポートを転送してください。何が失敗していたか、何を修正したか、ドメインが現在どの状態にあるかを平易な言葉で示します — 保険の更新や顧客のセキュリティアンケートに必要な証拠を文書として提供します。

ドメインを無料で確認する

SPF、DKIM、DMARC のどのレッグが失敗しているかを、プライベートにオーナーのみで確認できます。

ドメインを確認 → · SPF を修正 → · SPF PermError: DNS ルックアップ過多 → · グレード方法について → · 集計データのみ。データは EU で保存・処理されます。