2026年版 GoDaddy SPFレコード設定ガイド

GoDaddyでレコードを設定し、前回のキャンペーンを送信したにもかかわらず、Gmailでは依然として送信メールの半分が知らない人からのメールのように扱われてしまう。さらに、CRMやニュースレターツール、決済プラットフォームなどを追加していくと、設定全体がまるで絡まった配線のように機能しなくなります。GoDaddyのSPFレコードが、単なるチェックリストの項目から、メールの到達性を維持するための生命線へと変わるのは、まさにこのような時です。

厄介なのは、SPFの失敗が明確に通知されることがほとんどないという点です。送信者が追加され、DNSが一度編集され、数週間後にチームがスパム判定や認証エラーに気づいたり、あるプラットフォームは機能しているのに別のプラットフォームがリストから外れていたりすることに気づきます。もしこれが聞き覚えのある状況なら、それは単なる「メールの問題」ではなく、DNSの所有権、レコード構造、そして10件のルックアップ制限という問題に直面しているのです。

なぜGoDaddyのSPFレコードが重要なのか

SPFは概念としては単純ですが、運用は非常に過酷です。受信側のサーバーは、DNSで公開されているドメインのポリシーを確認し、その送信サーバーが当該ドメインの代わりにメールを送信することを許可されているかどうかを問い合わせます。回答が一致しなければ、送信者が正当であっても、メッセージは不正なものとして扱われる可能性があります。

そのため、壊れたGoDaddyのSPFレコードは、多くの人が考える以上に深刻なダメージを与えます。Microsoft 365とGoogle Workspaceはどちらも、メールボックスプロバイダーが裏側で評価する認証シグナルに依存しています。そのため、SPFレコードが欠落していたり、形式が間違っていたりすると、目に見える失敗に気づくずっと前から受信トレイへの到達に影響が出ます。ここでhardfailとsoftfailの違いが重要になります。末尾の修飾子が、不正なメールを即座に拒否すべきか、それとも疑わしいものとして扱うべきかを、受信側に伝えているからです。

多くのチームが見落としていること

SPFは単に「このドメインはあなたのものか」を問うものではありません。「この送信者はDNSで公開されている承認リストに載っているか」を問うものです。ここでSPFアライメントが重要になります。なぜなら、DMARCが後に、表示上のFromドメインと認証されたソースが一致しているかどうかを確認するからです。

実践ルール: 元のSPFレコードを作成した後に送信者がスタックに追加された場合、DNSレコードも修正されていない限り、その送信者が問題の原因となっている可能性が高いです。

GoDaddy自身のガイダンスは、SPFを個別のSPFタイプではなくTXTレコードとして公開する現代的なアプローチを反映しており、ワークフローはドメインのポートフォリオ内でのDNS編集を中心としています。その設定は平凡に聞こえますが、SPFが頻繁に壊れる理由はまさにそこにあります。レコードは一度追加するのは簡単ですが、次のツールが承認された後に忘れ去られやすいのです。

GoDaddy DNSで最初のSPFレコードを追加する

ドメインポートフォリオから開始し、DNSを開き、レコードをTXTとして追加します。GoDaddyのヘルプでは、SPF設定のためにこの手順が示されています。SPFポリシーを値フィールドに入力し、ポリシーがドメイン全体に適用される場合はホストをルートに設定します。関連するメールレコードのドキュメント例では、TTLはデフォルトのままにします GoDaddyのSPFレコードヘルプ GoDaddyのメール認証用DNSレコードフィールド。

重要なフィールド

タイプはSPFではなくTXTである必要があります。GoDaddyのドキュメントでTXTが使用されているのは、それが現代のDNSにおけるSPFの標準的な公開形式であり、バリデーター間での曖昧さを回避できるためです。

名前は、ルートドメインのポリシーであれば通常**@**にします。これはGoDaddyに対し、レコードがサブドメインではなくドメインのトップに属していることを伝えます。値はSPF文字列が入る場所であり、ここにポリシー自体を貼り付けます。

トラブルシューティングの最中でない限り、GoDaddyのドキュメント通りの設定に従うのであれば、TTLはデフォルトのままで構いません。正確なフィールド名は見落としがちですが、ドメインのルートに存在するレコードと、どこか役に立たない場所に配置されたレコードとの違いを生むのはこれらのフィールドです。

GoDaddyで管理されるメールの単純な例は v=spf1 include:secureserver.net -all であり、これはGoDaddyがホスティングメール用に示している形式です。送信元を1つだけ承認する場合は、この形式が理想的です。1つのレコード、1つのポリシー、1つの場所で管理します。

Gmail固有のバリエーションについては、こちらのGmailユーザー向けSPFガイドでも、同じTXT優先のロジックが実践されています。

レコードタイプをTXT以外で入力したり、ポリシーをルートに配置する必要があるのにホストを空欄のままにしたりすると、レコードはUI上では存在していても、DNSレイヤーでは失敗する可能性があります。

プロセスの後半では、GoDaddyのインターフェースよりも権威あるDNSゾーンの方が重要になりますが、最初の成功は、正しいホストで、正しいタイプを使用して、正しいフィールドにレコードを入力することです。

使用する送信者のためのSPF構文

多くの組織は1つの送信者だけを運用しているわけではありません。プライマリのメールボックス、マーケティングプラットフォーム、CRM、そしてトランザクションシステムを運用しています。SPFレコードはこれらすべてを承認する単一のステートメントであるため、実際の作業は適切なメカニズムを選択し、GoDaddyのDNSが機能しなくなる前に検証できるようリストを短く保つことです。

一般的な送信者スタック用のSPF文字列（コピー＆ペースト用）

送信者設定	SPF値	使用ルックアップ数
Google Workspace	v=spf1 include:_spf.google.com -all	1つのinclude、その後の最終ポリシーチェック
Microsoft 365	v=spf1 include:spf.protection.outlook.com -all	1つのinclude、その後の最終ポリシーチェック
Google Workspace + マーケティングツール	v=spf1 include:_spf.google.com include:servers.mcsv.net -all	2つのinclude、および含まれるレコード内のネストされたルックアップ
Microsoft 365 + トランザクション送信者	v=spf1 include:spf.protection.outlook.com include:amazonses.com -all	2つのinclude、および含まれるレコード内のネストされたルックアップ

これらの文字列は、1つのレコード、1つのポリシー、GoDaddyで管理する1つの場所というパターンを示しているため便利です。スタックがGoogle WorkspaceやMicrosoft 365から始まり、マーケティングやトランザクションメールへと拡大する場合、レコードは構文の問題ではなく、各プロバイダーが裏側でどれだけのDNSルックアップを消費しているかという問題に変わります。

各メカニズムの役割

includeは、別のドメインのSPFポリシーを確認し、その承認を継承するように指示します。これはGoogle Workspace、Microsoft 365、Mailchimp、SendGridなどのプラットフォームにとっての主力メカニズムです。

ip4は固定の送信アドレス用であり、ソースIPを制御しており、他のプロバイダーのポリシーチェーンに依存したくない場合に役立ちます。末尾のallは、まだ承認されていないすべてのものに対するルールを設定し、修飾子が失敗の厳格さを決定します。

実践ルール: 送信者リストが安定している場合はより厳格な末尾を使用し、スタックを整理している間のみ緩やかな末尾を使用してください。

送信者計画に関する外部からの有用な視点として、中小企業のメールキャンペーン向けアドバイスがあります。キャンペーンチームはDNSへの影響を確認せずにツールを追加することが多いためです。

実際のGoDaddy設定でつまずくのは、ルックアップの予算です。includeを追加するたびに予算が消費され、レコードは一見きれいに見えても、チェーンが深すぎて失敗することがあります。理想のスタックではなく、実際に運用しているスタックに合わせて構文を構築してください。

ルックアップ制限に達せずに複数の送信者を統合する

GoDaddyのSPFレコードにおける最大の問題は構文ではなく、蓄積です。ドメインは1つの送信者から始まり、マーケティングが別の送信者を追加し、営業がCRMを追加し、運用がトランザクションプラットフォームを追加します。その結果、SPFが標準で許可されている数以上のシステムを検証しようとしていることに誰も気づかなくなります。

ルールは単純明快です。同じ名前で複数のSPFレコードを公開してはいけません。 同じドメインに対して2つのSPF TXTレコードが存在する場合、受信側は結果を無効または曖昧なものとして扱う可能性があります。つまり、役立つと思っていたレコードが、認証を壊している可能性があるのです。

統合プロセスの仕組み

まず、すべての正当な送信者をリストアップします。次に、プロバイダーが独自の送信インフラストラクチャを管理している場合はincludeステートメントを使用して、それらを1つのTXTポリシーにまとめます。GoDaddyに既にレコードがある場合は、2つ目を作成するのではなく、既存のレコードを編集してください。

2つ目の罠はネストです。1つのincludeの中に、プロバイダー自身のSPFポリシー内の複数のルックアップが隠れている可能性があり、チームの予想よりも早く予算が枯渇する原因となります。GoDaddyに特化したガイダンスでは、10件のDNSメカニズムルックアップ制限を下回るように警告されており、この制限は事後ではなく評価中に適用されます GoDaddyドメインのSPF設定ベストプラクティス GoDaddyドメインの2026年版SPFガイダンス。

よりクリーンな運用モデル

• すべての送信者を先に監査する: 古いツールは予算を消費し続けるため、メールを送信しなくなったものは削除します。
• 1つのポリシーに統合する: すべての承認を、正しい名前の単一のTXTレコードに保持します。
• 保存前にルックアップ数を確認する: ネストされたincludeによって制限を超えてしまうと、一見整ったレコードでも失敗する可能性があります。

Mail Merge for Gmailはこのロジックにうまく適合します。Googleの認証済みインフラストラクチャを通じて送信されるため、個別のincludeは不要であり、既にGoogle Workspaceを承認している場合、SPF予算を消費することもありません。

これが非常に重要な理由は単純です。チームは数ヶ月間制限内に収まるかもしれませんが、新しいベンダーが1つ追加されただけでレコードが限界を超え、GoDaddyのUI上ではDNSエラーが表示されないままSPFが失敗し始めるのです。

レコードが実際に機能しているか検証する

GoDaddyでレコードを保存しただけでは証明になりません。それは変更が入力されたことを意味するだけであり、権威あるゾーンがそれを配信していることや、キャッシュが更新されたこと、ポリシーが正常に解析されることを意味するわけではありません。

3つのチェック、3つの異なる回答

最初のチェックは、ライブゾーンに対するDNSルックアップです。digまたはnslookupクエリを実行すると、権威あるネームサーバーが何を返しているかがわかります。GoDaddyのインターフェースは伝播が完了する前に値を表示する可能性があるため、これは重要です。また、別のDNSホストがゾーンを所有している場合も教えてくれません。

2番目のチェックは、MXToolboxのSPFチェックのようなSPFパーサーです。このようなツールは、構文を読み取ると同時にルックアップ数をカウントできるため便利です。ネストされたincludeや制限を超えたチェーンは、ここで明らかになります。

3番目のチェックは、メッセージレベルの証拠です。Gmailにテストメールを送信し、元のメッセージを開いてヘッダーを検査します。Authentication-Results行には通常、送信ドメインに対してSPFが合格したか失敗したかが表示されます。これはDNSが何を言っているかだけでなく、メールボックスプロバイダーがメッセージをどのように評価したかを示しています。

実践ルール: DNSは正しく見えるのにヘッダーで失敗する場合は、問題は通常GoDaddyのUIではなく、検証レイヤーにあります。

チームが無視してはならない伝播の現実もあります。GoDaddyのTTL動作は通常高速ですが、エッジケースのDNS変更はリゾルバー全体に反映されるまで時間がかかることがあります。プロバイダー間でレコードを移動する場合は、まず権威あるネームサーバーを確認し、使用したコントロールパネルではなく、実際のゾーンに対して検証してください。メッセージをエンドツーエンドで追跡するには、こちらのメール追跡ガイドが役立ちます。

SPF合格から完全なメール認証へ

SPFの合格は安心感を与えますが、問題のすべてを解決するわけではありません。SPFは送信元を承認するだけであり、メッセージに署名したり、送信後にメッセージが改ざんされるのを防いだりするわけではありません。そのため、SPF単体では転送時のエッジケースやなりすましの穴が残る可能性があります。

DKIMとDMARCの役割

DKIMはメッセージ自体に暗号署名を追加します。GoDaddyで管理されるDNSでは、通常、セレクターホストの下にあるTXTレコードを意味し、Google Workspaceでは一般的にgoogle._domainkeyがその設定の一部として使用されます。

DMARCはSPFとDKIMの上に位置します。認証が失敗したときに何をすべきか、レポートをどこに送信するかを受信システムに指示するもので、通常はドメインの_dmarcにあるTXTレコードを通じて行われます。DMARCがなければ、SPFやDKIMが一致しない場合にメールボックスプロバイダーが従うべき共通のポリシーが存在しません。

重要なポイントは、SPFは信頼の1つのレイヤーに過ぎないということです。DKIMが設定されていない場合、偽造されたメッセージは弱いアライメントを悪用する可能性があり、転送されたメッセージは、ソースでSPFがクリーンであっても、元の送信とは異なる動作をする可能性があります。

実践的なスタックは単純です。SPFが送信者を承認し、DKIMがメッセージに署名し、DMARCが両者が一致しない場合の行動を受信側に指示します。すべての正当な送信者が認証されていると確信する前にポリシーを厳格化すべきではないため、前述の検証セクションが重要になります。

フルスタックの詳細については、こちらのメール認証ガイドが、SPF、DKIM、DMARCを1つのワークフローに統合します。

メールの差し込みキャンペーン中にSPFをクリーンに保つ

メールの差し込みキャンペーンは、DNS作業に急速なプレッシャーをかけます。営業、採用、イベントチームがある日はGmailからクリーンなシーケンスを送信し、翌週には返信が減ったことをコンテンツのせいにすることがありますが、根本的な問題は認証のドリフト（乖離）である場合があります。

Mail Merge for GmailはGoogleの認証済みインフラストラクチャを通じて送信されるため、独自のSPF includeを必要とする別の送信者を作成することはありません。より大きなリスクは、周囲のスタックが変更され、ドメイン所有者が別のプラットフォームを追加し、メールボックスプロバイダーがもはや一貫性がないように見えるメッセージ履歴を評価し始めることです。

実際に役立つキャンペーン前のチェックリスト

• 送信元のGoogleアカウントでSPFが合格することを確認する: ランダムなエイリアスではなく、キャンペーンを送信する正確なメールボックスをテストします。
• Google Workspace管理でDKIMが有効になっていることを確認する: SPF単体では、転送されたメールや再ラップされたメールに対して脆弱すぎます。
• DMARCが少なくともp=noneでレポートが有効になっていることを確認する: これにより、ポリシーを強化する前に可視性を確保できます。

SPFの結果が緑色であること自体は、キャンペーンを開始しても安全であることを意味しません。それは単に、送信者がその瞬間の現在のDNSポリシーと一致したことを意味するだけです。

最善の習慣は、SPFレコードを配管のように扱うことです。キャンペーン前、新しい送信者が追加されたとき、そしてプラットフォームが送信経路を変更したときに再確認してください。そうすることで、GoDaddyのSPFレコードが到達性の問題へと劣化するのを防ぐことができます。

---

Mail Merge for Gmailは、チームがGmailからパーソナライズされたキャンペーンを送信しつつ、送信経路をGoogle Workspaceに結びつけておくことを支援します。これにより、ドメインスタックが混雑している場合でもSPFの論理的な判断が容易になります。次回の配信前にGoDaddyのDNS設定を整理する場合は、Mail Merge for Gmailにアクセスし、SPF、DKIM、DMARCをクリーンに保つワークフローへの適合方法を確認してください。