BluehostのSPF・DKIM・DMARC設定。
BluehostはNewfold Digital傘下のホスティングブランドです。そのため、ここでいう「ドメイン認証」の対象は、別個のメール製品ではなく、ほぼ例外なくホスティングプランに付属するメールです。具体的には、cPanel/webmailのメールボックスと、サイトのPHPスクリプトやcronジョブが送信するメールです。Bluehostはこれらのメールを共有の送信プールから送り出しており、そのプールはwebsitewelcome.comにプロキシされています（複数の姉妹ブランドを支えるNewfold/HostGatorの共通インフラ）。公開するSPFのincludeがinclude:websitewelcome.comになるのはこのためです。cPanelのEmail Deliverabilityツールを使えばSPFレコードとDKIM鍵を自動生成できますが、DMARCは必ず手作業で追加する必要があります。このガイドでは、従来のcPanelと新しいBluehost portalの両方の手順、正確なTXTレコード、そしてほぼ全員がつまずく点である、websitewelcome.comのincludeが水面下で消費するDNSルックアップの回数を解説します。
Bluehostを認証すべき理由
ホスティングアカウントでは、SPFやDKIMを任意の形式的な作業と捉えがちです。しかし2024年2月以降、GmailとYahooはすべての送信者にSPFまたはDKIMの成功を、すべての大量送信者（1日あたり約5,000通以上）にはさらにアライメントを伴うDMARCポリシーの公開を義務付けています。Microsoftも2025年に、大量送信者に同じルールの適用を始めました。Bluehostが対応するのはその一部だけです。Email DeliverabilityツールでSPFレコードの公開とDKIM鍵の生成はできますが、DMARCレコードは決して作成されません。そのため、「認証済み」のBluehostドメインでも、受信側が今チェックしている要素が欠けていることがよくあります。正しく設定すべき理由はもう1つあり、これはBluehost特有のものです。ホスティングの利用者は、実際のメールボックスのためにMXをGoogle WorkspaceやMicrosoft 365に向けながら、古いinclude:websitewelcome.comをSPFレコードに残したままにしていることが非常に多くあります。この不一致により、SPFレコードはもう送信に使っていないサーバーを許可し、DNSルックアップの10回制限のかなりの部分を無駄に消費するうえ、自社ドメインから実際に送信されるメールには何の役にも立ちません。SPF、DKIM、DMARCのすべてを実際の送信方法に合わせて意図的に設定することで、パスワードリセット、問い合わせフォームのメール、ニュースレターが迷惑メールに振り分けられるのを防ぎ、ドメインのなりすましも阻止できます。
BluehostにおけるSPFの実情
websitewelcome.comは正真正銘の共有SPFのincludeです。これはBluehostの共有プランとCloudプランが中継に使うNewfold/HostGatorの送信プロキシホストで、Bluehost自身のドキュメントでも、PortalとBluerockの両アカウントの標準レコードとしてv=spf1 a mx include:websitewelcome.com ~allを掲載しています。つまり、Bluehostのメールサーバー経由で送信するなら、ルートドメインにある1つのSPFのTXTレコードに追加すべき実在のincludeです。ただし、一般的なincludeより注意が必要な点が3つあります。1つ目は、ルックアップの消費が大きいことです。include:websitewelcome.comは深くネストされており、解決すると約8回のDNSルックアップが発生します（実測）。eig.spf.a.cloudfilter.netとspf.websitewelcome.comを連鎖的に参照し、後者がさらに_spf.nfco-mailout.comとその2つのネットブロック、_spf.google.com、spf.protection.outlook.comを読み込むためです。Bluehostが標準レコードに含めるaとmxのメカニズムを加えると、それだけでRFC 7208の上限である10回に達し、他の送信者を追加する余地がなくなります。より軽量なinclude:spf.websitewelcome.comのルックアップは約4回で済みますが、対象はHostGator/Newfoldの中核となる共有ネットブロックのみで、完全版のincludeに含まれるGoogleとMicrosoftの範囲は外れます。そのため、切り替えるのはBluehostのメールが共有のcPanelプールのみから送信される場合に限り、Bluehostのサーバーをまったく経由しないならincludeごと削除してください。2つ目は、Bluehostがすべてのドメインのゾーンに標準のv=spf1レコードを自動で追加することです。2つ目のレコードを公開するのではなく、そのレコードを編集する必要があります。SPFレコードが2つあると、自動的にPermErrorになります。3つ目は、このincludeが共有プールしかカバーしないことです。VPSプランとDedicatedプランは専用IPから送信するため、ip4:<your dedicated IP>を追加します。また、新しいBluehost Cloud/OXベースのプロフェッショナルメールは、まったく別のinclude:spf.cloudus.oxcs.netを使用します。結論として、include:websitewelcome.comを公開するのはBluehostの共有サーバーから実際に送信されるメールがある場合だけにし、SPFレコードは1行にまとめ、ルックアップ回数に注意してください。
2つの設定方法
Bluehostホスティング上のメールボックス：includeを追加
- MXとメールボックスがBluehost（cPanel/webmail）上にある場合、またはサイトのPHP mail()/cronがメールを送信する場合に該当します
- 送信は共有プールにプロキシされるため、include:websitewelcome.comで許可します。これはPortalアカウントとBluerockアカウント向けのBluehost標準レコードです
- DMARCがDKIMでアライメントを一致させられるよう、cPanelのEmail DeliverabilityでdefaultセレクターのDKIM鍵を有効にします
- VPS/Dedicated：これらのプランは共有プールを使わないため、ip4:<your dedicated IP>を追加します
MXをGoogle Workspace/Microsoft 365に向けている場合
- そのメールを送信しているのはBluehostではないため、include:websitewelcome.comは使っていないサーバーを許可していることになります
- 実際のメールには何の効果もなく、SPFのルックアップ10回のうち約8回を消費します
- 代わりに、利用中のサービスに合わせてinclude:_spf.google.comまたはinclude:spf.protection.outlook.comを使います
- Bluehostのincludeを残すのは、ホスト上のスクリプトやcronが今も直接メールを送信している場合だけにします
設定手順
- 1
ドメインの実際の送信方法を確認
メールボックスの場所とMXの向き先を確認します。メールがBluehostのcPanel/webmailに届く場合（またはサイトのスクリプトが送信する場合）は、websitewelcome.comのincludeが該当します。MXがGoogle WorkspaceやMicrosoft 365の場合は、それらのレコードで認証するため、Bluehostのincludeは不要です。
- 2
Email Deliverabilityを開く（cPanelアカウント）
cPanelベースのプランでは、cPanel > Email > Email Deliverabilityを開き、ドメインを探してManage（またはRepair）をクリックします。cPanelが推奨のSPFレコードとDKIM鍵を生成します。Bluehostがそのドメインの権威を持つ場合は自動的にゾーンへ公開され、そうでない場合はDNSホストに貼り付ける正確なTXTレコードのName/Valueが表示されます。
- 3
またはDNSエディターを開く（新しいBluehost portal）
新しいportalアカウントにはcPanelがありません。Domainsを開いてドメインを選択し、DNSタブを開いてManage Advanced DNS Recordsまでスクロールします（Advanced Tools > Advanced DNS Recordsからも開けます）。SPF、DKIM、DMARCのTXTレコードは、ここに手作業で追加します。
- 4
自動追加されたSPFレコードを編集（重複させない）
Bluehostは、すべてのドメインのゾーンに標準のv=spf1レコードを追加します。2つ目を追加せず、この既存のレコードを編集してください。同じ名前にSPFレコードが2つあると自動的にPermErrorとなり、SPFは完全に失敗します。
- 5
SPFレコードを公開
ホスト@に、v=spf1 a mx include:websitewelcome.com ~allというTXTレコードを設定します。Bluehostのメールが共有プールのみから送信される場合は、より軽量なv=spf1 a mx include:spf.websitewelcome.com ~allならルックアップを大幅に減らせます（ただし、同梱のGoogle/Microsoftの範囲は含まれません）。VPS/Dedicatedでは、サーバーのip4:<dedicated IP>を追加します。portalでは+ ADD RECORD > Single recordを使い、Type TXT、Refers to @とし、TTLは短め（1～4時間）に設定します。
- 6
DKIMレコードを追加
cPanelのEmail Deliverabilityがdefaultセレクターで2048ビットの鍵を生成し、default._domainkeyにTXTレコードとして公開します。値はv=DKIM1; k=rsa; p=<public key>です。BluehostがDNSをホストしている場合は自動で追加されます。外部のDNSの場合は、正確にコピーしてください。実際にはサードパーティ（Google、M365、SendGrid、ニュースレターツール）から送信する場合は、Bluehostのものではなく、そのサービスのDKIMを公開します。
- 7
DMARCポリシーを公開
_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを追加します。Bluehostはこのレコードを作成しません。アライメントを確認している間は何も影響が出ないようp=none（監視のみ）から始め、その後quarantine、rejectへと引き上げます。
- 8
Email Deliverabilityを再確認してテストメールを送信
cPanelのEmail Deliverabilityツールで、SPFレコードとDKIMレコードに緑のチェックが表示されるはずです（まだ問題のある項目はRepairビューに表示されます）。次に実際のメールを送信してGmailで開き、Show originalでSPF: PASS、DKIM: PASS、DMARC: PASSと表示され、すべて自社ドメインとアライメントが一致していることを確認します。最後にQualisendのドメイン診断で、SPFのルックアップが10回未満に収まっていることを確認します。
追加するレコード
正確な値はBluehostのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 a mx include:websitewelcome.com ~allBluehostでホストするメール用のルートドメインのSPF：SPFレコードは1つだけにし、他の送信元はこの1行にまとめてください。このincludeを解決すると、DNSルックアップが約8回発生します。より軽量なinclude:spf.websitewelcome.com（約4回）が使えるのは、メールが共有のcPanelプールのみから送信される場合だけです。同梱のGoogle/Microsoftの範囲が外れるためです。VPS/Dedicatedでは、ip4:<your dedicated IP>を追加します。 |
| TXT | default._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(2048-bit public key from cPanel Email Deliverability)例です。実際の鍵はドメインごとにcPanel > Email > Email Deliverability（defaultセレクター）で生成されます。サードパーティの送信者については、代わりにそのサービスのDKIMレコードを公開してください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCレコードは1つのドメインにつき1つです。Bluehostはこのレコードを追加しません。p=noneから始め、その後quarantine/rejectへと引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。Bluehostの設定がこの上限のうち何回を消費するかは、次のとおりです。
Bluehostは10回のルックアップのうち8回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
BluehostのDKIMはアカウントのインターフェースによって異なりますが、標準の手順はcPanelのEmail Deliverabilityツールです。ツールはセレクターdefaultで2048ビットの鍵を生成し、default._domainkey.yourdomain.comにTXTレコードとして公開します。値はv=DKIM1; k=rsa; p=<public key>です。対応する秘密鍵はBluehostが保持し、その鍵で送信メールに署名します。ドメインがBluehostのネームサーバーを使用している場合（Bluehostが権威を持つ場合）は、ツールがこのレコードを自動で書き込み、修復します。DNSがCloudflareやレジストラなどにある場合は、Email Deliverabilityが貼り付け用の正確なName/Valueを表示するので、手動で追加します。cPanelのない新しいBluehost portalアカウントでは、同じTXTレコードをDomains > DNS > Manage Advanced DNS Records（Advanced Tools > Advanced DNS Records）で追加します。Bluehost特有の注意点は2つあります。第一に、DKIMが証明するのはBluehostのサーバーが実際に送信するメールだけです。Google Workspace、Microsoft 365、SendGrid、またはニュースレタープラットフォームから送信するメールには、Bluehostのdefaultセレクターではなく、そのサービス自身のDKIMセレクター（google._domainkey、selector1/2._domainkey、s1/s2._domainkeyなど）が必要です。第二に、Bluehost Cloud/OXベースのプロフェッショナルメールは別のメール製品で、独自のDKIM鍵とinclude:spf.cloudus.oxcs.netのSPFを使います。従来の共有ホスティングのレコードと混在させないでください。
DMARC
DMARCは、Bluehostが決して作成しない唯一のレコードです。Email DeliverabilityがSPFレコードとDKIMレコードを公開した後でも、自分で追加するまでDMARCポリシーは存在しません。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを公開します。p=noneは監視のみで、配信には何も影響しません。そのうえで受信側に集計レポートの送付を依頼できるので、Bluehostのメール（および自社ドメインとして送信するその他のメール）が、組織ドメインとアライメントが一致した状態でSPFとDKIMに成功しているかを確認できます。1～2週間レポートを確認し、正規の送信元がすべて認証に成功していることを確かめたら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。なりすましを実際に防ぐのはこのポリシーです。送信者がいくつあっても_dmarcレコードはドメイン全体で1つだけにし、SPFレコードやDKIMレコードと同じ場所に追加してください。DMARCレコードはcPanelで設定するものではなく、ゾーン内の通常のTXTレコードです。portalのManage Advanced DNS Records、または外部のDNSホストで追加します。
正しく設定できたか確認する
cPanelの緑のチェックマークで終わりにせず、実際のメールで確認してください。cPanelでは、Email DeliverabilityにそのドメインのSPFレコードとDKIMレコードが有効と表示され、Repairビューにまだ問題のある項目が示されるはずです。次に、BluehostのメールボックスからGmailアカウントへメールを送り、開いてShow originalを選びます。SPF: PASS、DKIM: PASS（signed-byが自社ドメイン、セレクターはdefault）、DMARC: PASSと表示され、いずれもwebsitewelcome.comではなくyourdomain.comとアライメントが一致していれば成功です。dig TXT yourdomain.com、dig TXT default._domainkey.yourdomain.com、dig TXT _dmarc.yourdomain.comで生のレコードをスポットチェックすることもできます。特に重要なのは、websitewelcome.comのincludeが深くネストされているため、SPFのルックアップ総数が10回以内に収まっていることを確認する点です。Qualisendのドメイン診断と送信ドメイン認証チェックでドメインをチェックしてください。どちらもincludeの連鎖全体を解決し、メールプロバイダーより先にPermErrorを検出します。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップし、Bluehostが、アライメントが一致し認証に成功している送信元として表示されることを確認します。
よくある注意点
- DNS設定
websitewelcome.comのincludeはルックアップを大量に消費します。include:websitewelcome.comを解決すると、ネストされたDNSルックアップが約8回発生します（実測）。eig.spf.a.cloudfilter.netとspf.websitewelcome.comを連鎖的に参照し、_spf.nfco-mailout.comとその2つのネットブロック、さらに_spf.google.comとspf.protection.outlook.comを読み込むためです。Bluehostの標準レコードに含まれるaとmxを加えるとRFC 7208の上限である10回に達し、他の送信者を追加する余地がなくなります。より軽量なinclude:spf.websitewelcome.com（約4回、ただし同梱のGoogle/Microsoftの範囲は含まれません）を使うか、Bluehost経由で送信しないならincludeを削除してください。
- 認証失敗の原因
SPFレコードが2つあるとPermErrorになります。Bluehostはすべてのドメインに標準のv=spf1レコードを自動で追加するため、自分のレコードを貼り付けると2つになり、SPFは完全に失敗します。既存のレコードを編集し、2つ目のSPFのTXTレコードは決して公開しないでください。DMARCにも同じルールが当てはまり、_dmarcレコードは1つだけです。
- 認証失敗の原因
MXがGoogle WorkspaceやMicrosoft 365の場合、Bluehostのincludeは送信していないメールを許可していることになります。実際のメールには何の効果もなく、ルックアップを無駄にするだけです。include:_spf.google.comまたはinclude:spf.protection.outlook.comに置き換えてください。
- 適用範囲
VPSプランとDedicatedプランは、共有プールではなく専用IPから送信します。そのメールはinclude:websitewelcome.comではカバーされないため、SPFレコードにip4:<your dedicated IP>を追加してください。
- 適用範囲
Bluehost Cloud/OXベースのプロフェッショナルメールは別の製品です。websitewelcome.comではなく、include:spf.cloudus.oxcs.netと独自のDKIM鍵を使います。レコードをコピーする前に、アカウントが実際にどのメール製品を使っているかを確認してください。
- DNS設定
cPanelが自動で公開するのは、Bluehostが権威を持つ場合だけです。DNSがCloudflareやレジストラにある場合、Email DeliverabilityはSPF/DKIMの値を表示するだけです。そのDNSホストに自分で貼り付けないと、ツールは不足していると報告し続けます。
- DNS設定
ホスト欄の二重化に注意してください。portalのRefers to欄はドメインを自動で付け足すため、ルートドメインのSPFには@を、DKIMにはラベルのdefault._domainkeyだけを入力します。完全修飾ドメイン名（FQDN）を入力すると、default._domainkey.yourdomain.com.yourdomain.comができてしまいます。
- 適用範囲
BluehostはSPFとDKIMを設定しますが、DMARCは決して設定しません。Email Deliverabilityのチェックに「合格」したアカウントでもDMARCポリシーがまったくないことがあります。DMARCポリシーこそ、GmailとYahooの大量送信者向けガイドラインが現在求めているものです。_dmarcレコードは自分で追加する必要があります。
SPFレコードを作成
以下ではBluehostがあらかじめ選択されています。他に利用している送信プラットフォームを追加し、1つにまとめたレコードを公開してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証BluehostのSPFに関するよくある質問
関連記事
ホスティング・Webサイトの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。