SPFレコードの確認と作成
SPFレコードをすべてのincludeまでたどり、受信側と同じ「ルックアップ10回まで」のルールで確認できます。そのうえで、各送信サービスの公式includeからレコードを作成したり、複数のレコードを1つに統合したりできます。無料・登録不要で、データは保存しません。
確認するドメイン
SPFレコードの作成・統合
貴社のメールの送信元にチェックを入れてください。各includeは、送信サービスの公式ドキュメントに基づいています。includeが不要な送信サービスには、その旨を表示します。ルックアップ数はその場でカウントします。
カンマまたはスペースで区切ります。IPv6も使えます。
その他のinclude、exists、redirectを入力します。ドメインだけを入力するとincludeになります。
どちらもDMARCと併用できます。Microsoftは-allを推奨し、Googleの例では~allを使っています。
複数のSPFレコードを1つに統合
各メカニズムは1回だけ残し、末尾の指定は1つにまとめます。
SPFとは？
SPF（Sender Policy Framework）は、ドメインに設定するTXTレコードで、そのドメインのメールを送信してよいサーバーを列挙します。受信側は、送信サーバーをReturn-Path（エンベロープ送信者）のドメインと照合します。受信者に見えるFromアドレスを確認するのはDMARCの役割です。
そのため、DMARCを通過するには、Fromと一致するドメインでSPFまたはDKIMが成功している必要があります。Account Engagement（旧Pardot）や多くのメール配信ツールは独自のReturn-Pathで送信するため、この条件を満たすのはDKIMです。
- 設定場所
- ドメイン自体（@）
- 先頭の文字列
v=spf1- 1つの名前あたりのレコード数
- 1つだけ
- ルックアップ上限
- 10回、応答なしは2回
- 規格
- RFC 7208（2014年）
10回のルックアップ上限
受信側の確認は10回で止まります。それを超えるとSPFは恒久的なエラーとなり、レコードがない場合と同じようにSPFの認証に失敗します。
- 101回の確認あたりのDNSルックアップ数（各includeは中身もすべて含めて数えます）
- 2応答のないルックアップ（void lookup）
| 要素 | ルックアップ消費 | 備考 |
|---|---|---|
include: | 消費する（中身もすべて加算） | ルックアップ過多のよくある原因 |
a, mx | 消費する | mxの参照先は10台のメールサーバーまで |
ptr | 消費する | 使用すべきではありません（RFC 7208、5.5） |
exists: | 消費する | Salesforceのincludeのように、マクロと組み合わせることが多い |
redirect= | 消費する | レコードにallがある場合は無視される |
ip4、ip6、all | 消費しない | アドレスはルックアップを消費しない |
応答のないルックアップ（void lookup）は2回までです。
ルックアップ回数超過の直し方
この順番で進めてください。ほとんどのレコードは、最初の3つで10回未満に収まります。
- 1
ルックアップを多く消費する箇所を特定
ページ上部のツールでドメインを確認してください。ツリーに、各includeの単体のルックアップ数と、配下を含めた合計が表示されます。
- 2
使わなくなった送信元を削除
古いメルマガ配信ツールやCRMは、何年もレコードに残っていることがよくあります。Googleは、もう送信していないサービスのincludeを削除するよう勧めています。
- 3
不要なincludeを外す
Pardot、Marketing Cloud Next、Mailchimp、Postmark、Klaviyoは、それぞれのサービスのReturn-PathでSPFを通過します。これらのincludeはルックアップを増やすだけです。
- 4
送信元に専用のサブドメインを割り当てる
サブドメイン（例：news.example.com）は独自のSPFレコードを持てるため、ルックアップ上限も別に10回あります。Microsoftは一斉配信メールにこの方法を勧めています。
- 5
フラット化は最後の手段
includeをIPアドレスに置き換えるとルックアップは減りますが、ベンダーがサーバーを変えると機能しなくなります。貴社のレコードをフラット化した場合の結果は、チェックツールで確認できます。
送信元ごとの正しいinclude
各ベンダーの公式ドキュメントに基づき、2026年10月16日と17日に確認しました。includeがまったく不要な送信元もいくつかあります。
| 送信元 | SPFに追加する内容 | 出典 |
|---|---|---|
| Google Workspace | include:_spf.google.com | Google、2026年10月（新しいタブで開きます） |
| Microsoft 365 | include:spf.protection.outlook.com | Microsoft、2026年7月（新しいタブで開きます） |
| Salesforce（Sales CloudとService Cloud） | include:_spf.salesforce.com | Salesforce、2026年10月（新しいタブで開きます） |
| Account Engagement（旧Pardot） | 不要：単体でSPFを通過 | Salesforce、2026年4月（新しいタブで開きます） |
| Marketing Cloud Next | 不要：バウンスCNAMEでSPFに対応 | Salesforce、2026年9月（新しいタブで開きます） |
| HubSpot | include:<account>.spf0X.hubspotemail.net（アカウントごと） | HubSpot、2026年9月（新しいタブで開きます） |
| SendGrid | include:sendgrid.net（automated securityがオフの場合のみ） | Twilio、2026年8月（新しいタブで開きます） |
| Mailgun、Mailjet | include:mailgun.org、include:spf.mailjet.com | Mailgun（新しいタブで開きます）、Mailjet、2026年7月（新しいタブで開きます） |
| Zoho Mail | include:zohomail.com | Zoho、2026年10月（新しいタブで開きます） |
| Zendesk、Freshdesk | include:mail.zendesk.com（smtp.zendesk.comとsupport.zendesk.comは古い記述です）、include:email.freshdesk.com | Zendesk、2026年10月（新しいタブで開きます）、Freshdesk（新しいタブで開きます） |
| Mailchimp、Postmark、Klaviyo、Brevo | 不要：各サービスのReturn-PathまたはDKIMで対応 | Mailchimp（新しいタブで開きます）、Postmark（新しいタブで開きます）、Klaviyo（新しいタブで開きます）、Brevo（新しいタブで開きます） |
| Amazon SES | ドメインには不要。カスタムMAIL FROMを使う場合は、そのサブドメインにinclude:amazonses.com | AWS（新しいタブで開きます） |
SPFフラット化の本当のところ
ルックアップ数の問題は解決しますが、新しいリスクが生まれます。
- 仕組み
includeの代わりにIPアドレス
フラット化では、includeをその背後にあるIPアドレスに置き換えます。そのため、ルックアップを消費しません。
- リスク
ベンダー側のサーバー変更
フラット化したレコードは、ある時点のスナップショットです。送信元がサーバーを追加すると、レコードを更新するまで、新しいサーバーからのメールはSPFに失敗します。Microsoftは、Microsoft 365をフラット化しないよう、またフラット化したエントリを少なくとも四半期に1回は見直すよう案内しています。
- 私たちのおすすめ
まず削除・省略・分割
ほとんどのレコードは、フラット化しなくても10回未満に収まります。dmarcianは自社のフラット化機能を廃止し、一時しのぎの手段と位置付けています。Salesforceのようにマクロを含むレコードは、そもそもフラット化できません。
末尾は~allか-allか、その他の記述か
レコードの末尾は、レコードに記載されていないサーバーをどう扱うかを示します。DMARCを設定している場合、メールをどう扱うかはDMARCが決めます。
-all：Fail（失敗）。他のサーバーは許可されていません。Microsoftが推奨しています。~all：SoftFail（ソフトフェイル）。おそらく許可されていません。Googleのレコード例はこの形で終わっています。?all：Neutral（中立）。他のサーバーについて何も示しません。避けてください。+all：Pass（通過）。インターネット上のすべてのサーバーが、貴社のドメインとして送信できてしまいます。絶対に使わないでください。
PardotとMarketing Cloud Nextの場合
SalesforceのヘルプページにあるSPFの説明をまとめました（2026年10月17日確認）。
Account Engagement（旧Pardot）
Pardotのメールは、そのままでSPFを通過します。SalesforceはSPFの設定は不要としており、aspmx.pardot.comは現在のヘルプに記載されていません。Return-PathはSalesforceのドメインのため、SPFはFromアドレスと一致しません。DMARCはDKIM（セレクター200608）で通過します。
Marketing Cloud Next
SPFには、認証済みドメインのバウンス用CNAMEが対応します。このCNAMEはSalesforceが管理しており、追加のSPFレコードは不要と案内しています。Sales CloudやService Cloudから送信するメールは別で、include:_spf.salesforce.comが必要です。
SPFレコードのよくある質問
SPFについてよく寄せられる質問に、短くお答えします。
SPFレコードを2つ設定できますか？
いいえ。同じドメイン（ホスト名）にv=spf1で始まるレコードが2つ以上あると、SPFはすべてのメッセージに対して恒久的なエラー（PermError）を返します。1つにまとめてください。
2つのSPFレコードを1つにまとめるには？
作成ツールの「複数のSPFレコードを1つに統合」に両方を貼り付けてください。各メカニズムは1回ずつ残り、末尾は1つになります。そのうえでルックアップ数を確認してください。ルックアップ数6のレコードを2つ合わせると12になります。
「SPF permerror: too many DNS lookups」を解消するには？
利用をやめたサービスのincludeを削除してください。includeが不要な送信元（Pardot、Marketing Cloud Next、Mailchimp）のincludeも外し、送信元を専用のサブドメインに移します。フラット化は最後の手段です。
SPFレコードの末尾は~allと-allのどちらにすべきですか？
どちらもDMARCと併用できます。Microsoftは-allを推奨し、Googleの例は~allを使っています。+allは絶対に使わないでください。
PardotをSPFレコードに追加する必要はありますか？
いいえ。Salesforceによると、Account EngagementのメールはそのままでSPFを通過します。DMARCで重要なのはDKIMキー（セレクター200608）です。
サブドメインには親ドメインのSPFレコードが使われますか？
いいえ。SPFはReturn-Pathのドメインそのものに対してチェックされます。そのため、メールを送信するサブドメインには専用のレコードが必要です。
void lookup（応答のないルックアップ）とは何ですか？
何も見つからないルックアップのことです。たとえば、すでに存在しない名前へのincludeが該当します。2回を超えた場合、受信側はSPFを失敗として扱うことが規格で推奨されています。
確認したドメインは保存されますか？
いいえ。ブラウザがドメイン名を私たちのサーバーに送り、サーバーが公開DNSリゾルバーに問い合わせます。何も保存せず、ドメインを記録することもありません。リゾルバーにお使いのIPアドレスが伝わることもありません。