GoDaddyのSPF・DKIM・DMARC設定。
GoDaddy Professional Email（現在は「Professional Email, powered by Titan」として販売）は、ウィザードではなく3つの通常のDNSレコードでドメインを認証します。GoDaddy共通のinclude:secureserver.netを含むSPFのTXTレコード、GoDaddyに委任する2つのDKIMのCNAME（secureserver1._domainkeyとsecureserver2._domainkey）、そして_dmarcのDMARCポリシーです。GoDaddyならではの事情もあります。2025年4月以降、GoDaddyで購入またはGoDaddyに移管したドメインには、DKIMとデフォルトのDMARCレコードが自動で追加されるため、何も操作しないうちに設定の一部が完了している場合があります。DNSとメールボックスの両方をGoDaddyでホストしていれば、GoDaddyがレコードを代わりに適用できます。DNSが別の場所にある場合は、Email & Office Dashboardから値をコピーして手動で追加します。
GoDaddyを認証すべき理由
GoDaddyでホストするメールが受信トレイに届くかどうかは、認証で決まります。2024年2月以降、GmailとYahooはすべての送信者にSPFまたはDKIMの成功を、すべての大量送信者（1日あたり約5,000通以上）にはさらにアライメントを伴うDMARCポリシーの公開を義務付けています。Microsoftも2025年5月に、Outlook.comとHotmail宛ての大量メールに同じ要件の適用を始めました。SPFとDKIMの両方で自社ドメインとのアライメントが一致するまでは、GoDaddy経由のメールが自社から送られたものだと示す根拠は弱く、DMARCにも成功できず、転送されたメールは認証が崩れます。GoDaddy自身が原因で、正しく設定すべき理由がもう1つ加わります。新規および移管したドメインには、現在p=quarantineのデフォルトDMARCレコードが公開されます。そのため、認証しないままCRM、問い合わせフォームのプラグイン、またはニュースレターツールで自社ドメインを使い始めると、その日からそれらのメールは自社のポリシーによって迷惑メールに振り分けられます。SPF、DKIM、DMARCを正しく設定すれば、実際の送信元のアライメントが一致し、quarantineポリシーが逆効果にならず自社の役に立ち、自社ドメインで送信レピュテーションを築けます。
GoDaddyにおけるSPFの実情
GoDaddy Professional Emailは、まさに「include」型のサービスです。共通のメカニズムinclude:secureserver.netを、ルートドメインの1つのSPFのTXTレコードに追加します。GoDaddyはこれをv=spf1 include:secureserver.net -allとして公開しています。GoDaddyのメールボックスからの送信でも、エンベロープ（Return-Path）は自社ドメインのものになるので、DKIMだけでなくSPFも実際にアライメントが一致し、DMARCの成功に貢献します。GoDaddyのSPFが特殊な点は2つあります。1つ目は、ルックアップの消費が多いことです。secureserver.netはIPアドレスの範囲に直接展開されず、secureserver.net → include:spf-0.secureserver.net → include:spf.protection.outlook.comとネストしています。そのため、SPFのDNSルックアップ10回のうち3回を消費します。Google WorkspaceとMicrosoft 365はそれぞれ1回です。他の送信元を追加していくと、RFC 7208の10回制限にすぐ近づきます。超えるとPermErrorになります。2つ目は、include:secureserver.netが許可するのはGoDaddyでホストするメール（Professional Email／TitanとGoDaddyのLinux/cPanelホスティング）だけで、それ以外は対象外だということです。「GoDaddy」のドメインの多くは、実際にはMicrosoft 365（サブスクリプションをGoDaddy経由で購入した場合も含む）またはGoogle Workspaceで送信しています。これらに必要なのはinclude:spf.protection.outlook.comまたはinclude:_spf.google.comで、secureserver.netを残すとルックアップを3回無駄にするうえ、送信に使っていないサーバーを許可することになります。もう1点、GoDaddy自身のメールマーケティング製品（GoDaddy Digital Marketing／キャンペーン）は、別のフラットなinclude、include:spf.em.secureserver.netを使います。メールボックスのメールとは別物です。どのような組み合わせでも、SPFレコードは1つだけにし、すべてのメカニズムをこの1行のv=spf1にまとめてください。
設定手順
- 1
GoDaddyが実際にメールを送信しているか確認
include:secureserver.netをドメインに置くのは、メールボックスがGoDaddy Professional Email／Titanの場合、またはGoDaddyのLinux/cPanelホスティングから送信している場合だけです。Microsoft 365やGoogle Workspaceに移行した場合は（GoDaddy経由で購入したものでも）、secureserver.netは使わず、代わりにinclude:spf.protection.outlook.comまたはinclude:_spf.google.comを使います。ここでincludeを間違えることが、GoDaddyの認証で最も多いミスです。
- 2
GoDaddyが公開済みのレコードを確認
2025年4月以降にGoDaddyで購入またはGoDaddyに移管したドメインには、2つのDKIMのCNAMEとデフォルトのDMARCレコード（p=quarantine）が自動で追加されます。何かを追加する前にManage DNSを開き、既存のsecureserver1._domainkey／secureserver2._domainkeyのCNAMEと_dmarcのTXTレコードを探してください。競合する重複レコードを作らず、これらを編集するためです。
- 3
正確なレコードの値を取得
GoDaddyのユーザー名とパスワードでEmail & Office Dashboard（email.godaddy.com）にサインインします。GoDaddyがDNSをホストしていれば、SPFレコードとDKIMレコードを自動で適用できます。DNSが別の場所にある場合は、ダッシュボード（およびGoDaddyのProfessional Emailのヘルプ記事）に、SPFの値と2つのsecureserver._domainkeyのCNAMEターゲット（アカウント固有）が示されるので、コピーして手動で追加します。
- 4
DNSエディターを開く
GoDaddyでホストするDNSの場合は、サインインしてDomain Portfolio（古いアカウントではMy Products）を開き、送信ドメインを選択して、Domain → DNS（Manage DNS）を開きます。既存のレコードの一覧が表示されるので、Add New Recordで各レコードを作成します。GoDaddyのNameの書き方に注意してください。ドメインが自動で付加されるので、その前の部分だけを入力し（ルートドメインは@）、完全なホスト名は入力しません。
- 5
SPFレコードを追加（既存なら1つにまとめる）
TypeはTXT、Nameは@（GoDaddyでのルートドメインの略記）、Valueはv=spf1 include:secureserver.net -allです。SPFレコードがすでにある場合は、2つ目を追加しないでください。既存のレコードを編集し、include:secureserver.netをその1行のv=spf1にまとめます。SPFレコードが2つあるとPermErrorになり、SPFが気づかないうちに失敗します。
- 6
DKIM CNAMEを2つ追加
どちらもTypeはCNAMEです。1つ目のレコードはNameがsecureserver1._domainkey、Valueがダッシュボードに表示された1つ目のターゲットです。2つ目のレコードはNameがsecureserver2._domainkey、Valueがダッシュボードに表示された2つ目のターゲットです。TTLは1 Hourに設定します。2025年4月以降のドメインでGoDaddyが事前に作成している場合は、重複させず、値が一致することだけを確認してください。GoDaddyに委任するCNAMEなので、秘密鍵はGoDaddyが保持し、自社でDNSを編集し直さなくてもGoDaddyがローテーションできます。
- 7
DMARCレコードを設定（または取り戻す）
TypeはTXT、Nameは_dmarc、Valueはv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとし、監視モードから始めます。GoDaddy特有の重要な注意点があります。GoDaddyが追加するデフォルトのDMARCは、集計レポートをrua=mailto:dmarc_rua@onsecureserver.netに送るので、レポートは自社ではなくGoDaddyに届きます。ruaが自社のメールボックスまたはDMARC解析ツールを指すようレコードを編集してください。p=quarantineを維持するのは、すべての送信元が認証済みの場合だけです。送信元のアライメントを調整している間は、正当なメールを隔離しないようp=noneに下げます。
- 8
反映を待ち、実際のメールでテスト
GoDaddyのDNSの変更は通常1時間以内に反映されますが、最大48時間かかることがあります。GoDaddyのメールボックスからGmailのアカウント宛てにメールを送り、開いて⋮ → Show originalを選びます。SPF: PASS、yourdomain.comで署名されたDKIM: PASS（セレクターはsecureserver1またはsecureserver2）、DMARC: PASSと表示され、すべてsecureserver.netではなく自社ドメインとアライメントが一致していれば成功です。
- 9
レコードを確認し、ルックアップ数を監視する
Qualisendのドメイン診断と送信ドメイン認証チェックでドメインをチェックし、すべてのレコードが解決されることを確認します。SPFのルックアップ数に注意してください。secureserver.netだけで10回のうち3回を消費するので、他のツールからも送信していると上限に達することがあります。フラット化するか、使っていないincludeを削除してください。自社のruaアドレスにDMARCレポートが届くようになったら、DMARCレポート解析に読み込み、GoDaddyが、アライメントが一致して認証に成功している送信元として表示されることを確認します。
追加するレコード
正確な値はGoDaddyのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 include:secureserver.net -allGoDaddy Professional Email／Titan用のルートドメインのSPFレコードです。SPFレコードは1つだけにし、他の送信元はこの行にまとめます。このincludeはDNSルックアップを3回消費します（secureserver.net → spf-0.secureserver.net → spf.protection.outlook.comとネストしています）。 |
| CNAME | secureserver1._domainkey | <unique-target-1>.dkim.secureserver.net例です。正確なCNAMEターゲットはGoDaddyがアカウントごとに生成します。実際の値はEmail & Office Dashboardからコピーしてください。TTLは1 Hourです。 |
| CNAME | secureserver2._domainkey | <unique-target-2>.dkim.secureserver.net例です。2つ目のDKIMセレクターで、これもアカウント固有です。正確なターゲットはダッシュボードからコピーしてください。TTLは1 Hourです。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCレコードはドメインごとに1つです。GoDaddyがp=quarantineとrua=mailto:dmarc_rua@onsecureserver.netで事前に追加している場合があります（レポートはGoDaddyに届きます）。ruaが自社のアドレスを指すよう編集してください。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。GoDaddyの設定がこの上限のうち何回を消費するかは、次のとおりです。
GoDaddyは10回のルックアップのうち3回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
GoDaddy Professional EmailのDKIMは、貼り付けるのではなく委任する方式です。secureserver1._domainkeyとsecureserver2._domainkeyの2つのCNAMEレコードを公開します。それぞれ末尾がsecureserver.netのアカウント固有のターゲットを指し、対応する秘密鍵はGoDaddyが保持して送信メールに署名します。自社で持つTXTレコードではなくGoDaddyに委任するCNAMEなので、自社でDNSを編集し直さなくても、GoDaddyがこの2つのセレクターの裏で公開鍵をローテーションできます。従来のProfessional Emailと新しいProfessional Email powered by Titanは、どちらも同じsecureserver1／secureserver2セレクターを使います。2025年4月以降にGoDaddyで購入またはGoDaddyに移管したドメインでは、Professional Email用にこの2つのCNAMEが自動で追加されます。作成する前にManage DNSを開いて、すでに存在しないか確認してください。存在する場合は値を確認し、重複して作成しないでください。DNSとメールボックスの両方をGoDaddyでホストしていれば、すべて自動で適用されることもよくあります。DNSが別の場所にある場合に限り、Email & Office Dashboardから2つの正確なターゲットをコピーして手動で追加します。Nameフィールドに完全なホスト名を入力しないでください。GoDaddyがドメインを付加するので、入力するのはsecureserver1._domainkeyで、secureserver1._domainkey.yourdomain.comではありません。
DMARC
DMARCは_dmarc.yourdomain.comに置く別のポリシーレコードで、GoDaddyはこれを代わりに公開する数少ないレジストラの1つです。2025年4月以降、GoDaddyで購入またはGoDaddyに移管したすべてのドメインのゾーンには、p=quarantineのデフォルトDMARCレコードが追加されます。つまり、認証に失敗したメールはすでに迷惑メールに振り分けられています。しかも集計レポート（rua）の送信先は自社ではなく、GoDaddy自身のアドレスdmarc_rua@onsecureserver.netです。（GoDaddyはp=rejectで展開を始め、途中でp=quarantineに緩めたので、古いドメインには強いポリシーが残っている場合があります。確認してください。）ここからやるべきことが2つあります。1つ目は、レポートを取り戻すことです。ruaが自社のメールボックスまたはDMARC解析ツールを指すようレコードを編集してください。そうしないと、誰がドメインを使って送信しているのかを把握できません。2つ目は、ポリシーを意図的に選ぶことです。正当な送信元がすべて認証され、アライメントが一致しているなら、p=quarantineを維持し、後にp=rejectへ引き上げるのが適切です。まだ送信元のアライメントを調整している最中なら、完了するまでの間、デフォルトのquarantineが正当なメールを気づかないうちに迷惑メールに振り分けないよう、一時的にp=noneに設定します。送信元の数にかかわらず、_dmarcレコードはドメイン全体で1つだけにしてください。また、GoDaddyが追加したレコードはロックされたものではなく、通常どおり編集できるTXTレコードであり、完全な制御権は自社にあることも覚えておいてください。
正しく設定できたか確認する
GoDaddyのダッシュボードや自動追加されたレコードだけで判断せず、実際のメールで確認してください。GoDaddyのメールボックスからGmailのアカウント宛てに送信し、メールを開いて⋮ → Show originalを選びます。SPF: PASS、signed-by: yourdomain.com（セレクターはsecureserver1またはsecureserver2）のDKIM: PASS、DMARC: PASSと表示され、すべてsecureserver.netではなく自社ドメインとアライメントが一致していれば成功です。詳しいレポートが必要なら、check-auth@verifier.port25.comにテストメールを送ると、内訳がメールで返ってきます。レコード自体は、dig TXT yourdomain.com、dig CNAME secureserver1._domainkey.yourdomain.com、dig TXT _dmarc.yourdomain.comで簡単に確認できます。GoDaddyでのDNSの反映は通常1時間以内ですが、最大48時間かかることがあります。最後に、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決されること、そしてGoDaddyで特に重要な点として、secureserver.netの3回のルックアップによってSPFが10回の上限を超えていないことを確認します。自社のruaアドレスにレポートが届くようになったら、DMARCレポート解析にレポートをドロップし、GoDaddyが、アライメントが一致して認証に成功している送信元であることを確認します。
よくある注意点
- 認証失敗の原因
include:secureserver.netが消費するSPFのルックアップは1回ではなく3回です。secureserver.net → spf-0.secureserver.net → spf.protection.outlook.comとネストしているためです。他の送信元（Google、Mailchimp、メール配信サービス（ESP）など）と組み合わせると、このチェーンだけで10回制限に近づき、超えるとPermErrorとなって、SPFは気づかないうちに機能しなくなります。
- 適用範囲
実際にMicrosoft 365（GoDaddy経由で購入したサブスクリプションも含む）やGoogle Workspaceで送信している場合、secureserver.netは誤ったincludeです。代わりにinclude:spf.protection.outlook.comまたはinclude:_spf.google.comを使ってください。secureserver.netを残すと、送信に使っていないサーバーを許可することになり、実際のメールのアライメントも一致しません。
- 適用範囲
2025年4月以降、GoDaddyは新規および移管したドメインに、p=quarantineでruaがdmarc_rua@onsecureserver.netを指すデフォルトのDMARCレコードを通知なく追加します。つまり、認証に失敗したメールはすでに隔離されており、レポートは自社ではなくGoDaddyに届きます。レコードを編集して自社のruaを追加してください。
- 適用範囲
デフォルトのp=quarantineにより、正当でも未認証のメール（CRM、フォームのプラグイン、忘れていたニュースレターツールなど）が、気づかないうちに迷惑メールに振り分けられることがあります。デフォルトのポリシーに任せる前に、すべての送信元を洗い出し、それぞれのアライメントを一致させてください。
- 認証失敗の原因
SPFレコードは1つのドメインにつき1つだけです。2つ目のv=spf1のTXTレコードはPermErrorとなり、SPFが完全に失敗します。並行して追加せず、必ず既存のレコードにまとめてください。
- 適用範囲
GoDaddyのName／@の書き方に注意してください。ドメインは自動で付加されます。ルートドメインのSPFには@、DKIMにはsecureserver1._domainkey（完全なFQDNではなく）、DMARCには_dmarcを入力します。完全なドメインを入力すると二重に付加されます（例：_dmarc.yourdomain.com.yourdomain.com）。
- 認証失敗の原因
ネームサーバーがGoDaddy以外（Cloudflare、Route 53、Webホスト）を指している場合、GoDaddy内でDNSを編集しても何も変わりません。レコードは、ネームサーバーが実際に指している先に追加してください。最初にドメインのネームサーバーを確認します。
- 適用範囲
GoDaddyのデフォルトのSPFは-all（hard fail）で終わります。これが安全なのは、secureserver.netが唯一の送信元である場合だけです。先に他の送信サービスをすべてレコードに追加するか、整理が終わるまで~allを使い、正当なメールがhard failにならないようにしてください。
SPFレコードを作成
以下ではGoDaddyがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証GoDaddyのSPFに関するよくある質問
関連記事
ホスティング・Webサイトの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。