SPFレコードにIPアドレスを追加する方法（ステップバイステップガイド）

SPFレコードにIPアドレスを追加するには、DNSでドメインの既存のSPF TXTレコードを編集し、「all」メカニズムの前に「ip4:」（または「ip6:」）メカニズムを追加します。例：

v=spf1 ip4:192.0.2.1 include:_spf.google.com -all

重要： 2つ目のSPFレコードを作成しないでください。既存のレコードを編集する必要があります。また、IPアドレスを直接追加する前に、送信サービスが代わりに「include:」値を提供しているかどうかを確認してください。通常、これは長期的に見てより良い選択肢となります。

このガイドでは、現在のレコードの確認、ip4とincludeの選択、主要なプロバイダーでのDNS設定の編集、結果の検証、そして毎年何千ものドメインでメール配信を静かに妨げているミスを回避する方法など、全プロセスを順を追って解説します。

SPFレコードとは何か？そして2026年にそれがなぜ重要なのか？

SPF（Sender Policy Framework）は、特定のドメインからメールを送信する権限を持つIPアドレスとサービスを列挙したDNS TXTレコードです。サーバーのIPアドレスがこのリストに含まれていない場合、受信側のメールサーバーはそのメッセージを拒否したり、フラグを立てたりすることがあります。

Googleは2024年2月より、 2024年2月より、大量送信者に対する認証要件の適用を開始しました、1日あたり5,000通以上のメッセージを送信するすべての送信者に対し、SPFまたはDKIMに加えDMARCの導入を義務付けました。 

2025年11月現在、規定に準拠していないメールは、一時的な配信保留ではなく、恒久的な配信拒否（ハードバウンス）の対象となります。Yahoo!も同様のスケジュールのタイミングで、これと同一の要件を導入しました。Microsoftも2025年5月にこれに追随し、 認証されていない大量メールを550エラーで即座に拒否するようになりました。

正しいSPFレコードが設定されていないと、ドメインがなりすましの危険にさらされ、正当なメールでさえGmail、Yahoo、Outlookで受信拒否される可能性があります。SPFレコードに不備があると、何の警告もなくメールが届かなくなってしまいます。受信側では何の前触れもなく配信に失敗し、顧客や同僚から「メッセージが届かなかった」と指摘されて初めてその事実を知るという事態になりかねません。

SPFレコードの構文解説（例付き）

レコードに何かを追加する前に、各部分の役割を理解しておく必要があります。以下に、一般的なSPFレコードの構成を示します：

v=spf1 ip4:192.0.2.1 ip4:203.0.113.0/24 include:_spf.google.com -all

ここでは、複雑さの程度が異なる3つの実例をご紹介します：

シンプル（単一メールサーバー）：

v=spf1 ip4:198.51.100.25 -all

一般的な中小企業（Microsoft 365 ＋ マーケティングツール1つ）：

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net -all

複合企業（複数サービス）：

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:spf.brevo.com -all

重要なルール： 1つのドメインにSPFレコードは1つしか設定できません。すでにSPFレコードがある場合は、必ずそれを編集してください。「v=spf1」で始まる2つ目のTXTレコードを追加しないでください。同じドメインに2つのSPFレコードが存在すると、PermErrorが発生し、すべてのメール認証が機能しなくなります。

一からレコードを作成する必要がありますか？ 

使用方法 PowerDmarcの無料SPFレコードジェネレーター を使って、文法的に正しいレコードを即座に作成しましょう。

SPFレコードにIPアドレスを追加する方法（手順解説）

SPFレコードにIPアドレスを追加することは、送信元を認証する最も直接的な方法の一つです。これは通常、専用サーバー、トランザクションメールシステム、または自身が管理するインフラストラクチャを使用している場合に必要となります。

変更自体は単純ですが、誤った入力やフォーマットの問題は認証や配信率に影響を与える可能性があるため、正確さが重要です。以下の手順では、既存の設定を乱すことなく、SPFレコードにIPアドレスを正しく追加する方法を説明します。

ステップ1：現在のSPFレコードを確認する

多くのドメインでは、以前の設定でSPFレコードがすでに設定されています。確認せずに新しいレコードを作成すると、2つ存在することになり、その結果、システム全体が機能しなくなってしまいます。

現在の記録は、2つの方法で確認できます。 

利用方法 PowerDMARCの無料SPFチェッカーツール を使用して、即座に視覚的な結果を確認するか、コマンドラインクエリを実行してください：

nslookup -type=TXT yourdomain.com

dig TXT yourdomain.com

v=spf1 で始まる TXT レコードを探してください。そのようなレコードがあれば、それが SPF レコードです。ステップ 3 でこれを編集することになります。v=spf1 で始まるレコードが 2 つある場合は、すでに問題が発生しています。他の操作を行う前に、これらを 1 つに統合してください。

ステップ 2: IP アドレスを特定するか、追加が必要な値を入力してください

ここでは2つのケースが考えられますが、どちらを選ぶべきかは、何を許可するかによって異なります：

シナリオA： 特定のIPアドレスを追加する場合です。これは、静的IPアドレスで独自のメールサーバーを運用している場合や、管理している専用の送信用IPアドレスがある場合に該当します。サーバーの正確なIPv4またはIPv6アドレスが必要です。

シナリオ B: サードパーティ製サービスの認証を行う場合です。これは、Mailchimp、SendGrid、HubSpot、Google Workspace、Microsoft 365 などのサービスに適用されます。この場合、そのサービスの IP アドレスではなく、当該サービスのドキュメントに記載されている「include:」の値が必要です。

生のIPアドレスを追加する前に、以下の「ip4」と「include」に関する説明をお読みください。ほとんどのサードパーティ製サービスでは、長期的に見て「include:」の方が適しています。

ステップ3：DNSでSPFレコードを編集する

DNSプロバイダー（ドメイン登録業者またはホスティングプロバイダー）にログインし、ドメインのTXTレコードを探して、既存のSPFレコードを編集してください。「all」メカニズムの直前に、新しい「ip4:」または「include:」メカニズムを追加してください。

主なプロバイダーでの設定方法は以下の通りです：

• Cloudflare: 「DNS」→「レコード」に移動します。ドメイン（@またはルート）の既存のTXTレコードで、v=spf1 で始まるものを探します。「編集」をクリックします。「all」タグの前に新しいメカニズムを追加します。「保存」をクリックします。
• GoDaddy: 「マイプロダクト」→「DNS」→「DNSレコード」に移動します。「v=spf1」を含むTXTレコードを探し、「編集」をクリックします。「値」フィールドを編集し、すべての先頭に新しいメカニズムを追加します。保存します。
• Namecheap: 「ドメイン一覧」→「管理」→「詳細DNS」に進みます。「TXTレコード」の下にあるSPFエントリを探します。編集して新しいメカニズムを追加し、保存します。
• AWS Route 53: 「ホストゾーン」を開き、ドメインを選択します。v=spf1 の TXT レコードを探し、「編集」をクリックします。値を更新します（周囲の引用符はそのまま残してください）。保存します。
• cPanel: 「メール配信」に移動し、ドメインの横にある「管理」をクリックします。「推奨SPFレコード」までスクロールし、「カスタマイズ」をクリックします。「IPアドレス」セクションに新しいIPアドレスを追加します。「インストール」をクリックします。

プロのヒント： SPFの設定を変更する前に、TTLを300秒（5分）に設定してください。これによりDNSの伝播が早まり、ミスを素早く修正できるようになります。まず古いTTLが切れるのを待ってから変更を行ってください。レコードが正常に機能していることを確認した後、TTLを通常値に戻してください。

ステップ4：更新したSPFレコードを確認する

スペースの配置ミス、コロン（:）の抜け、あるいは重複レコードが1つあるだけで、ドメイン全体のメール機能が知らぬ間に機能しなくなる可能性があります。検証には30秒しかかかりませんが、それによって何時間にも及ぶトラブルシューティングの手間を省くことができます。

SPFを変更するたびに、以下のチェックリストを確認してください：

1. ドメインをSPFチェッカーツールでチェックし、レコードにエラーがないことを確認してください。
2. SPFレコードが1つだけ表示されていることを確認してください（v=spf1で始まるTXTレコードが2つある場合は除きます）。
3. DNSの総照会回数を確認してください。10回以下である必要があります。
4. すべてのメカニズムがレコードの最後にあることを確認してください。
5. GmailまたはYahooのアカウントにテストメールを送信し、メッセージを開いて元のヘッダーを確認し、「spf=pass」と表示されているか確認してください。

SPF以外のセキュリティ監査を徹底的に行うには、PowerDMARCのドメインアナライザーでドメインを分析してください。SPF、DKIM、DMARC、MTA-STS、BIMIを一度にチェックします。

ステップ5：SPF認証の結果を長期的に監視する

IPアドレスを追加するのが第一段階です。実際に機能しているかを確認し、後で不具合が発生した際にそれを検知するのが第二段階です。

DMARCの集計レポートは、送信元ごとのSPFの合格率・不合格率を継続的に把握するための主要な手段です。監視を行わなければ、手探りの状態になってしまいます。多くの管理者は、顧客が正当なメールをスパムとしてマークし始めたり、請求書発行ツールが許可されていないIPアドレスから何週間もメールを送信し続けていても誰にも気づかれなかったりして、初めてSPFレコードに不具合があることに気づくのが実情です。

自社ドメインからメールを送信しているすべてのIPアドレスを常に把握したいですか？  PowerDMARCのDMARCレポートダッシュボード は、すべてのドメインについて送信元ごとのSPF合格/不合格率を、生のXML形式ではなく、人間が読みやすいダッシュボード形式で表示します。15日間の無料トライアルを開始する → powerdmarc.com/free-dmarc-trial/

ip4 対 include：どちらを使うべきか？（選択ガイド）

IPv4（生のIPアドレス）を使用するタイミング：

• ご自身が管理する固定IPアドレス上で、独自のメールサーバーを運用しています。
• お客様が所有するESPから、専用送信IP（共有ではない）が割り当てられています。
• 固定アドレスを使用したオンプレミスSMTPリレーを許可します。

ルール： IPv4は、そのIPアドレスを自身が管理しており、変更されることがない場合にのみ使用してください。

「include: (delegated SPF)」を使用するタイミング：

• Google Workspace、Microsoft 365、Mailchimp、SendGrid、HubSpot、Salesforce、Zendesk、またはその他のクラウドベースのメールツールなど、あらゆるサードパーティ製SaaSサービスへのアクセスを許可することになります。
• このサービスでは、共有IPアドレスまたはローテーションIPアドレスを使用しています。
• このサービスは、独自に管理するSPFレコードを公開しています。

「Why include:」は、サードパーティ製サービスの場合、ほぼ常に推奨されます：

クラウドサービスは定期的にIPアドレスを変更します。もし現在のIPアドレスを「ip4:」で固定して設定してしまうと、インフラが移行された際にSPFレコードが古くなり、何の警告もなくメールの配信が停止してしまうことになります。 

「include:」メカニズムは、サービス側が動的に管理するSPFレコードに委ねられます。サービス側がIPアドレスを更新すると、貴社のSPFレコードにはその変更が自動的に反映されるため、貴社側でのメンテナンス作業は一切不要です。

[画像：決定木フローチャート — 「これはあなたが所有・管理しているサーバー／IPアドレスですか？」 → はい → IPv4を使用 / いいえ → 「サービスは『include:』値を提供していますか？」 → はい → includeを使用（推奨） / いいえ → IPv4を使用 + 四半期ごとの見直しリマインダーを設定]

[代替テキスト：SPFレコードにおいてIPv4とインクルードのどちらを使用すべきかを示す決定フローチャート]

include構文とベストプラクティスについてさらに詳しく知りたい場合は、SPF includeガイドの全文をご覧ください。

一般的なサードパーティ製SPFのインクルード値（クイックリファレンス表）

この表があれば、各サービスのSPFに関する資料を個別に探す必要がなくなります。マーケティング部門が新しいツールを導入する際に備えて、ぜひブックマークしておいてください。

表：主要なメールサービスのSPFインクルード値のクイックリファレンス。各サービスの公式ドキュメントで最新の値を確認してください。プロバイダーはこれらの値を随時更新する場合があります。

重要： 各インクルードは、少なくとも1回のDNSルックアップとしてカウントされます。また、多くのサードパーティ製SPFレコードにはネストされたインクルードが含まれており、さらにルックアップ数を増やします。5つ以上のサービスを利用している場合、10ルックアップという制限に近づいている可能性があります。この対処方法については、次のセクションを参照してください。

DNS検索の10回制限と、上限に達した際の対処法

RFC 7208 では、SPF の評価対象となる DNS クエリのメカニズムは 10 個までに制限されています。評価対象となるメカニズムは、include、a、mx、redirect、および exists です。評価対象とならないメカニズムは、ip4、ip6、および all です。これらは DNS クエリを行わずにローカルで評価されます。

レコードの照会回数が10回を超えると、SPFはPermErrorを返します。多くの受信サーバーは、PermErrorをSPFの失敗として扱います。その結果、メールの配信率が低下しますが、その事実に気づくための通知は一切届きません。

あまり知られていない制約として、「2回以上のDNSクエリ失敗制限」というものもあります。SPFの評価中に、3回以上のDNSクエリがNXDOMAIN（ドメインが見つかりません）を返した場合、SPFは失敗となります。

以下に、実用性の順に並べた3つの解決策をご紹介します：

選択肢1：使用していない機構を取り外す

まずは監査から始めましょう。使用しなくなったサービスに関する`include:`ステートメントを削除してください。ドメインのAレコードまたはMXレコードのIPアドレスからメールを送信していない場合は、AレコードとMXレコードを削除してください。これが最も手っ取り早い対策であり、多くの場合、すぐに2～3件のルックアップを解放できます。

オプション 2：手動による SPF のフラット化

インクルードのメカニズムを、その基盤となるIPアドレスまで特定し、それらをip4:エントリとしてハードコードしてください。これにより、それらのインクルードによって発生していたDNSルックアップが不要になります。

これにより、継続的なメンテナンスの負担が生じます。メールサービスプロバイダーは、事前の通知なしにIPアドレス範囲を変更したり追加したりすることがあります。そうなると、フラット化されたレコードが古くなり、正当なメールの配信に失敗するようになります。手動でのSPFフラット化は、芝刈りのようなものです。効果はありますが、数週間ごとに繰り返し行う必要があります。

オプション 3：SPF マクロまたは自動フラット化

現代的なアプローチでは、SPFマクロ（RFC 7208 第7節で定義）を使用します。これは評価時に動的に展開されるため、手動でIPアドレスを管理することなく、レコードをルックアップの上限内に収めることができます。 

自動フラット化ツールはこれを継続的に処理し、スケジュールに従ってプロバイダーのIPアドレスを再解決し、公開レコードを更新します。

10件の検索制限に達しましたか？  PowerSPFはSPFマクロを活用し、レコードを常にルックアップ上限値内に自動的に維持します。手動でのフラット化作業も、古いIPアドレスの残存も、メンテナンスも不要です。また、PowerDMARCでは、よりシンプルな設定のための従来のSPFフラット化にも対応しています。15日間の無料トライアルを開始する

SPFだけでは不十分：DKIMとDMARCが全体像を完成させる理由

SPFは、送信者（MAIL FROM）のIPアドレスを、許可リストと照合します。これは、メールが送信者から受信者へ直接送信される場合には機能しますが、メーリングリスト、自動転送ルール、共有メールボックス、または中継サーバーを介してメールが転送されると、送信元のIPアドレスが変更されます。転送サーバーのIPアドレスはSPFレコードに含まれておらず、そもそも含まれるべきではないため、SPFの検証は失敗します。

DKIM（DomainKeys Identified Mail）の仕組みは異なります。DKIMはメール本文に暗号署名を付加します。この署名は、どのサーバーを経由して転送されてもメッセージと共に保持されます。DKIMは転送後も有効ですが、SPFはそうではありません。

DMARC（Domain-based Message Authentication, Reporting, and Conformance）がこれらを統合する役割を果たします。メッセージがDMARCを通過するためには、SPFまたはDKIMのいずれか1つが有効であり、かつ送信元ドメインと一致していれば十分です。 

実際には、DKIMは転送の影響を受けないため、より信頼性の高い整合性確保の仕組みである。

だからこそ、両方を兼ね備えていることが重要なのです：

• Googleでは、すべての送信者に対してSPFまたはDKIMの導入を義務付けており、大量送信者（1日あたり5,000通以上）にはDMARCの導入も求めています。2025年11月以降、これらの要件を満たさないメールは永久に受信拒否されます。
• マイクロソフトは2025年5月から、認証されていない一斉送信メールの受信を拒否し始めました。
• Yahooは、Googleと同じ要件を同じスケジュールで適用しています。

SPFが唯一の認証メカニズムである場合、ドメインは転送されるすべてのメール経路においてなりすましのリスクにさらされたままとなり、2026年の受信メールプロバイダー要件を完全に満たすことはできません。

次に何をすべきか：

1. ドメインからメールを送信するすべてのサービスでDKIMを設定してください。
2. DMARCレコードを公開します（監視目的で最初は p=none から始め、その後 p=reject に移行します）。
3. DMARCの集計レポートを監視し、どの送信元がSPFおよびDKIMの検証に合格または不合格となっているかを確認します。

メール認証の全体像を把握する準備はできていますか？  PowerDMARCは、すべてのドメインにおけるDMARC、SPF、DKIMを監視し、どのメールが通過し、どのメールが失敗したか、そしてその理由を明確に示すダッシュボードを提供します。

メールを送信しないドメインのSPFレコード

パーキング中、非アクティブ、またはウェブサイト専用としてのみ使用されているドメインを所有している場合でも、それらにはSPFによる保護が必要です。攻撃者は、まさに保護されていないことが多いという理由から、使用されていないドメインを積極的になりすまそうとするのです。

解決方法は簡単です。以下のSPFレコードを公開してください：

v=spf1 -全て

これは、受信サーバーに対し、このドメインからメールを送信する権限を持つ者はいないことを伝えます。このドメインから送信されたと主張するメッセージはすべて拒否されるべきです。

最大限の保護を確保するため、拒否ポリシーを設定したDMARCレコードも公開してください：

v=DMARC1; p=reject; rua=mailto:[email protected]

この組み合わせにより、メールを送信するかどうかに関わらず、所有するすべてのドメインにおいてなりすましを完全に防ぐことができます。

SPFに関するよくある間違いとその対処法

SPFの構文エラーは頻発しており、最も厄介なのは、エラーが発生しても何の警告も出ないことです。ここでは、最もよくある8つの間違い、それらが引き起こす問題、そしてそれぞれの修正方法について説明します：

表：SPFレコードで最もよくある間違い、その影響、およびそれぞれの対処法。

SPF検証エラーのトラブルシューティングについてさらに詳しく知りたい場合は、SPF検証エラーとその解決方法に関するガイドをご覧ください。

結論

SPFレコードにIPアドレスを追加するのは、単純なDNS設定の変更ですが、正しく設定するには、構文を理解し、「ip4:」と「include:」のどちらを使用するかを選択し、DNSルックアップの制限である10件以内に収め、変更のたびに結果を確認する必要があります。

SPFは、包括的な電子メール認証スタックを構成する要素の一つです。2026年には、 Google、Yahoo、Microsoft が送信者認証の要件を積極的に適用するようになるため、SPFだけでは不十分です。完全な保護とコンプライアンスを確保するには、DKIMとDMARCも同様に不可欠です。

組織で送信サービスが増えるにつれ、SPFレコードも増えていきます。手動での管理はスケールせず、たった一つのミスでドメイン全体のメール配信が知らぬ間に停止してしまう恐れがあります。SPFの管理を自動化することは、もはや贅沢な話ではありません。それは運用上の基本です。

SPFレコードの手動管理はもうやめましょう。PowerDMARCなら、すべてのドメインを対象に、SPFの自動フラット化（PowerSPF）、DMARCの監視、DKIMの管理、そしてわかりやすいレポート機能を1つのプラットフォームで提供します。15日間の無料トライアルを今すぐ始めましょう 

 

よくあるご質問

1) 同じドメインに2つのSPFレコードを設定することはできますか？

いいえ。RFC 7208 では、ドメインごとに SPF TXT レコードは 1 つだけと規定されています。ドメインに v=spf1 で始まるレコードが 2 つ存在する場合、受信サーバーは PermError を返し、すべてのメッセージについて SPF 検証に失敗したとみなします。追加の送信元を認証する必要がある場合は、既存のレコードを編集して追加してください。新しいレコードを作成しないでください。

2) -all と ~all の違いは何ですか？

-all はハードフェイルであり、受信サーバーに対して、許可されていない IP アドレスからのメールを拒否するよう指示します。~all はソフトフェイルであり、許可されていないメールにフラグを立てますが、拒否を強制するものではありません。実際には、DMARC を p=quarantine または p=reject で適用する場合、DMARC ポリシーが SPF クォリファイアよりも優先されるため、両者の違いはほとんどありません。DMARC を適用している場合は、どちらでも問題ありません。まだ DMARC を導入していない場合は、-all の方がより強力な保護を提供します。

3) SPFレコードには、最大でいくつのIPアドレスを追加できますか？

ip4: または ip6: メカニズムの数に厳格な制限はありません。これらは、DNS 検索の制限（10 回）にはカウントされません。ただし、SPF レコード全体は、DNS TXT レコードのサイズ制限（1 文字列あたり 255 文字、複数の文字列を連結して最大約 4,096 文字）内に収まる必要があります。 大規模な IP リストの場合は、CIDR 表記（例：ip4:192.0.2.0/24）を使用して、範囲を効率的にカバーしてください。

4) SPFの変更が反映されるまで、どのくらいかかりますか？

これは、DNSレコードのTTL（Time to Live）によって異なります。TTLが3600（1時間）の場合、ほとんどのリゾルバーは1時間以内に変更を反映します。反映を早めるには、変更を行う前にTTLを300（5分）に設定し、以前のTTL期間が切れるのを待ってから編集を行ってください。これにより、反映時間が大幅に短縮されます。

5) 現在、自分のドメインからメールを送信しているIPアドレスを確認するにはどうすればよいですか？

最も信頼性の高い方法は、DMARCレポート機能です。ruaタグ付きのDMARCレコードを公開すると、受信サーバーから毎日集計レポートが送信され、そのドメインからメールの送信を試みたすべてのIPアドレスと、SPFおよびDKIMの合格・不合格結果が一覧表示されます。DMARCがなければ、推測に頼るしかありません。PowerDMARCは、これらのレポートを人間が読みやすい明確なダッシュボードに加工するため、どの送信者がそのドメインからメールを送信しているかを正確に把握することができます。

6) IPv4およびIPv6の処理は、DNS検索の10回という制限に含まれますか？

いいえ。制限の対象となるのは、DNSクエリを必要とするメカニズムのみです。具体的には、include、a、mx、redirect、およびexistsが含まれます。ip4、ip6、およびallの各メカニズムはローカルで評価されるため、DNSルックアップは一切行われません。