cPanel / WHM shared hostingのSPF・DKIM・DMARC設定。
cPanel/WHMの共有ホスティングは、メール配信サービス（ESP）とは異なります。「authenticate your domain」ウィザードも、貼り付けるだけの共有のSPFのincludeもありません。メールを送信するのはホスティングサーバー自身のメールサーバー（Exim）なので、認証はホスティング型サービスのレコードではなく、サーバーの送信IPアドレスをもとに構成します。最新のcPanelには、EmailセクションにEmail Deliverabilityインターフェースがあり、3つのレコードすべてを自動生成します。サーバーIPから作られるSPFレコード、defaultセレクターのDKIM鍵、そして新しいバージョンでは初期設定用のDMARCです。ホスティング会社がDNSも運用している場合は自動でインストールされ、それ以外の場合は、実際に利用しているDNSホストに貼り付ける正確なName/Valueが表示されます。
cPanel / WHM shared hostingを認証すべき理由
共有ホスティングのメールは最も迷惑メールに振り分けられやすい部類ですが、cPanelなら簡単に解決できます。2024年2月以降、GmailとYahooはすべての送信者にSPFまたはDKIMの成功を義務付け、すべての大量送信者（1日あたり約5,000通以上）には、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、一般消費者向けメールサービス宛ての大量メールに同じ要件の適用を始めました。cPanelでは、Eximサーバーがすべてを自社ドメインとして送信します。IMAPのメールボックス、ウェブメール、アカウント上のあらゆるスクリプト（WordPressのwp_mail、問い合わせフォーム、WooCommerceの領収書）のいずれも、サーバーのIPから送信されます。SPFとDKIMを公開するまで、これらのメールが自社のものであることは証明できません。受信側はメールを自社ドメインに結び付けられず、メールはDMARCにも成功しません。また、サーバーのIPを共有しているためレピュテーションは同じサーバーの他のテナントすべてとまとめて扱われます。認証を行うと、SPF（レコードでサーバーのIPを許可）とDKIM（Eximがd=yourdomain.comとして署名）のアライメントが自社ドメインと一致します。そのためDMARCに成功し、築いた送信者レピュテーションは共有プールではなく自社に蓄積されます。
cPanel / WHM shared hostingにおけるSPFの実情
cPanelはincludeで認証するサービスではなく、「専用IP」型の構成です。追加すべき共通のinclude:cpanel.netはありません。cPanelはサーバーソフトウェアであり、メールサービスではないためです。メールはホスティングサーバー自身のMTA（Exim）から送信されるので、SPFではそのサーバーの送信IPを直接許可する必要があります。cPanelのEmail Deliverabilityがレコードを作成し、形式はv=spf1 +mx +a +ip4:<your server's IPv4> ~allです（サーバーにIPv6がある場合は+ip6:メカニズムが追加されます）。実際に重要なのは+ip4:の部分です。これはサーバーの実際の送信IPなので、値はホストやサーバーごとに異なり、新しいサーバーへの移行、専用IPへの切り替え、ホスティング会社によるIPの変更があると一致しなくなります。+mxはMXホストの解決先を、+aはドメイン自身のAレコードを許可します。どちらもcPanelが便宜上追加するもので、それぞれSPFのDNSルックアップ10回のうち1回を消費します。ホスティング環境に特有の注意点は2つあります。（1）cPanelを使うホスティング会社には、直接送信しないところもあります。送信メールをスマートホストや送信スパムフィルター（SpamExperts、またはNewfold/EIGのゲートウェイ）経由にしている場合、正しいSPFはサーバーIPではなくそのサービス自身のinclude（例：include:websitewelcome.comやSpamExpertsのa:ホスト）で、cPanelの推奨レコードにもそれが反映されます。（2）他のサービス（Google Workspaceのメールボックス、マーケティング用ESP）からも送信する場合は、そのメカニズムをこの1つのv=spf1レコードにまとめる必要があります。2つ目のSPFのTXTレコードは決して公開しないでください。SPFレコードが2つあると、それ自体がPermErrorになります。
2つの設定方法
cPanelがDNSを運用している場合：自動インストール
- ドメインがホスティング会社のネームサーバーを使っているため、cPanelがゾーンの権威を持ちます
- Email DeliverabilityのRepairまたは「Install the Suggested Record」で、SPF、DKIM（とDMARC）を1クリックで書き込みます
- ホスティング会社がサーバーを移動またはIP変更した場合、cPanelがSPFレコードのIPを同期します
- コピーするものはありません。ステータスがValidに変わるまで更新するだけです
DNSが別の場所にある場合：手動でコピー
- ドメインのDNSがレジストラ、Cloudflare、またはRoute 53を指しているため、cPanelは権威を持ちません
- Install/Repairは誰も参照しないローカルゾーンに書き込むだけで、実際のゾーンは管理できないと警告が出ます。これはバグではなく想定どおりの動作です
- Manageをクリックし、推奨のNameとValueをそれぞれコピーして、実際のDNSホストにTXTレコードとして追加します
- サーバーを移行する場合は、SPFレコードの+ip4:の値を自分で最新の状態に保つ必要があります
設定手順
- 1
Email Deliverabilityを開く
cPanelにログインし、Emailセクションの中のEmail Deliverabilityを開きます。アカウント上のすべてのドメインがステータス付きで表示されます（Valid、または赤いフラグ付きの「Problems Exist」）。タイル自体が見当たらない場合は、ホスティング会社がこの機能を無効にしています。WHM » Home » Packages » Feature Managerで有効にするよう依頼してください。
- 2
送信ドメインのManageをクリック
送信に使うドメインの横にあるManageをクリックします。cPanelに、DKIM、SPF（新しいバージョンではDMARCも）の個別のパネルが表示され、推奨される正確なレコードと、現在のDNSがすでに一致しているかどうかが示されます。
- 3
DNSの管理元を判断
ドメインがホスティング会社のネームサーバーを使っている場合、cPanelが権威を持ち、「Install the Suggested Record」またはRepairボタンで直接修正できます。クリックしたら「確認」へ進んでください。ネームサーバーがレジストラ、Cloudflare、またはRoute 53を指している場合、cPanelは権威を持ちません。Install/Repairは誰も参照しないローカルゾーンに書き込むだけなので、代わりに実際のDNSホストへレコードをコピーします（次の手順）。この違いは、cPanelの認証で最も混乱を招く点です。
- 4
SPFのTXTレコードを公開（既存なら1つにまとめる）
推奨のSPF値（v=spf1 +mx +a +ip4:<server IP> ~all）をコピーし、ルートドメイン（ホストは@または空欄）にTXTレコードとして追加します。そのドメインにSPFレコードがすでにある場合は、2つ目を追加せず、+ip4:/includeをその1つのレコードにまとめてください。ホスティング会社がスマートホストやフィルター経由でメールを送っている場合は、生のIPではなく、cPanelが提案するincludeを使います。
- 5
DKIMのTXTレコードを公開
cPanelがdefaultセレクターで鍵を生成します。ホストをdefault._domainkey、値をv=DKIM1; k=rsa; p=<long public key>としてTXTレコードを追加します。現行のcPanelの鍵は2048ビットで、255文字の単一TXT文字列より長いため、cPanelが引用符で分割したとおりに正確に貼り付けてください。
- 6
DMARCのTXTレコードを公開
ホスト_dmarcに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comというTXTレコードを追加します。新しいcPanelは最小限のv=DMARC1; p=none;を提案しますが、レポートを実際に受け取れるよう、ruaアドレスを必ず追加してください。_dmarcレコードはドメイン全体で1つだけにしてください。
- 7
ホストの二重化とCloudflareのプロキシを修正
レジストラがドメインを自動で付け足す場合は、二重化を避けるため、ラベルだけを入力します（default._domainkey.yourdomain.comではなくdefault._domainkey）。TXTレコードはプロキシされないため、Cloudflareでは自動的に「DNS only」（グレーのクラウド）のままです。オレンジのクラウドのプロキシが適用されるのはA/AAAA/CNAMEレコードだけです。
- 8
cPanelで再確認してヘッダーを読む
Email Deliverabilityに戻って更新します。DNSが反映されると（通常は数分、最大で数時間）、ステータスがValidに変わるはずです。次に、実際のテストメールをGmailアドレスに送り、⋮ → Show originalを開いて、SPF: PASS（サーバーのIP）、DKIM: PASS（signed-by: yourdomain.com、セレクターはdefault）、DMARC: PASSを確認します。
- 9
逆引きDNS（PTR）を確認
cPanelではPTRを設定できません。設定するのはIPの所有者（ホスティング会社またはデータセンター）です。サーバーの送信IPを調べ、PTRが解決するホスト名を正引きすると同じIPに戻ることを確認してください。共有ホスティングでは通常、ホスティング会社の汎用メールホスト名を指しており、一貫していれば問題ありません。専用IPの場合は、メールホスト名に一致するPTRの設定をホスティング会社に依頼してください。
追加するレコード
正確な値はcPanel / WHM shared hostingのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。
| タイプ | ホスト | 値 |
|---|---|---|
| TXT | @ | v=spf1 +mx +a +ip4:192.0.2.10 ~allルートドメインのSPFレコード：+ip4はお使いのサーバーの送信IPです（ホストやサーバーごとに異なります）。+mxと+aは、それぞれDNSルックアップを1回消費します。SPFレコードは1つだけにし、他の送信元はこれにまとめてください。ホスティング会社がスマートホストやフィルターを使っている場合、cPanelは代わりにinclude（例：include:websitewelcome.com）を提案します。 |
| TXT | default._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A…(public key from Email Deliverability)例です。cPanelはセレクター「default」で鍵ペアを生成し、秘密鍵をサーバー上に保持します。2048ビットの鍵は、引用符で囲んだ分割文字列として公開します。cPanelが表示する正確な値をコピーしてください。 |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com1つのドメインにつき1つです。cPanelは最小限のv=DMARC1; p=none;を提案することがあります。レポートを受け取れるようruaアドレスを追加してください。p=noneから始め、その後quarantine/rejectへと引き上げます。 |
ルートドメインのSPF（v=spf1）のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。
DNSルックアップの10回制限
SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。cPanel / WHM shared hostingの設定がこの上限のうち何回を消費するかは、次のとおりです。
cPanel / WHM shared hostingは10回のルックアップのうち2回を消費します。ip4:とip6:のメカニズムはルックアップを消費しません。
DKIM
DKIMの鍵ペアはcPanelが生成するため、サービスから鍵を貼り付ける必要はありません。Email Deliverability → ManageのDKIMパネルでは、秘密鍵がサーバー上に保持され、Eximがこの鍵で送信メールに署名します。対応する公開鍵は、defaultセレクターのTXTレコードとして表示されます。ホストはdefault._domainkey、値はv=DKIM1; k=rsa; p=<public key>です。cPanelがゾーンの権威を持つ場合は、「Install the Suggested Record」で公開されます。そうでない場合は、NameとValueを外部のDNSホストにコピーします。cPanelならではの注意点がいくつかあります。セレクターは文字どおり「default」なので、レコードは常にdefault._domainkeyです。別のサービスがすでにそのドメインでこのセレクターを使っていると競合するため、再生成するか、そのツールのセレクターを使ってください。古いcPanelでは1024ビットの鍵が生成されていましたが、現行バージョンの標準は2048ビットです。255文字という単一文字列のTXT制限を超えるので、cPanelが表示するとおり、引用符で囲んだ分割形式で公開する必要があります。「正しい」はずの鍵が検証に失敗する原因の多くは、連結の崩れです。ホストを移行する場合、秘密鍵は古いサーバーに残るため、新しいサーバーでDKIMを再生成し、default._domainkeyを公開し直します。DKIMはd=yourdomain.comとして署名するので、メールが転送されてSPFが崩れても、DMARCの成功を維持できます。
DMARC
DMARCは別のポリシーレコードです。新しいcPanelのEmail Deliverabilityはレコードを提案します（多くは最小限のv=DMARC1; p=none;）が、古いバージョンでは自分で追加する必要があります。cPanelのZone Editorまたは外部のDNSホストで、_dmarc.yourdomain.comにTXTレコードとして追加してください。v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comから始めます。cPanelの提案に含まれていなくても、ruaアドレスは必ず追加してください。ないとレポートが届かず、状況を把握できません。p=noneは監視のみのため、サーバーのメールが自社ドメインとアライメントが一致した状態でSPFとDKIMに成功しているかを確認している間、配信には何も影響しません。1～2週間、集計レポート（rua）を確認します。特に、不一致のエンベロープで送信している可能性のあるサーバー上のスクリプト（WordPress、問い合わせフォーム、WooCommerce）に注意してください。アライメントが安定したら、p=quarantine、最終的にp=rejectへと段階的に引き上げます。サーバーから送信するメールボックスやアプリがいくつあっても、_dmarcレコードはドメイン全体で1つだけにしてください。サブドメインは、個別に上書きしない限り親のポリシーを継承します。
正しく設定できたか確認する
cPanelの「Valid」バッジだけで判断しないでください。これはDNSが提案内容と一致しているかを確認するだけで、メールが実際に認証されるかどうかは確認しません。ドメインのメールボックスからGmailアドレス宛てに実際のメールを送り（またはテスト用の問い合わせフォーム送信など、メールを送るスクリプトを動かし）、届いたメールを開いて⋮ → Show originalを選びます。SPF: PASS（サーバーのIPを表示）、DKIM: PASS（signed-by: yourdomain.com、セレクターはdefault）、DMARC: PASSと表示されていれば成功です。次に、サーバーの送信IPの逆引きDNSを確認します。共有ホスティングでは、PTRの欠落や不一致は、気づかないうちに迷惑メール判定を招くよくある原因です。逆引きDNS確認を使い、正引きでも一致することを確かめてください。Qualisendのドメイン診断でドメインをチェックし、SPF、default._domainkeyのDKIM、_dmarcがすべて解決され、SPFレコードが10回の上限内に収まっていることを確認します（cPanelの+mx +aだけですでに2回消費しています）。集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップし、サーバーが、アライメントが一致し認証に成功している送信元として表示されることを確認します。
よくある注意点
- 適用範囲
Repairが書き込めるのは、cPanelが管理するDNSだけです。ネームサーバーがレジストラ、Cloudflare、またはRoute 53を指している場合、cPanelサーバーは権威を持ちません。Install/Repairをクリックしても誰も参照しないローカルゾーンに書き込むだけで、実際のDNSは変わりません。これは想定どおりの動作です。ManageのName/Valueをコピーし、実際のDNSホストにレコードを追加してください。
- 適用範囲
使うのは共有includeではなく、お使いのサーバーのIPです。cPanelはサーバーの送信IP（+ip4:）からSPFを作成するため、値はサーバーごとに異なります。ホストの移行、専用IPへの移行、ホスティング会社によるIP変更があると、古いip4:は一致しなくなるので、レコードを更新してください。他のサイトのcPanelのSPFレコードをそのままコピーしないでください。
- 適用範囲
共有IPはレピュテーションも共有です。共有ホスティングでは、他の多くのテナントと共有するIPから送信します。隣のテナントがスパムを送ってIPがブラックリストに載ると、SPFとDKIMが完璧でも、自社のメールにも影響が出ます。送信IPを監視し、配信量が多いなら専用IPを検討してください。
- 認証失敗の原因
cPanelの+mx +aは、他に何も追加しないうちからSPFのルックアップ10回のうち2回を消費します。Google Workspaceとマーケティング用ESPを重ねると、RFC 7208の上限に達してPermErrorになることがあります。送信にmx/aを使っていないなら、v=spf1 +ip4:<server IP> ~allに絞ることで2回分を取り戻せます。
- 認証失敗の原因
SPFレコードを2つにしないでください。cPanelがローカルゾーンにSPFレコードを書き込み、実際のDNSが外部にある場合、誤って2つ目のSPFのTXTレコードを公開してしまうことがあります。SPFレコードが2つあると、それ自体がPermErrorになります。1つだけにして、すべてをまとめてください。
- 適用範囲
PTR（逆引きDNS）はcPanelにはありません。管理するのはIPの所有者（ホスティング会社またはデータセンター）です。PTRが欠落している、または正引きで一致しない汎用のものだと、GmailやOutlookでの到達率が気づかないうちに低下します。特に専用IPでは、一致するPTRをホスティング会社に依頼してください。
- DNS設定
2048ビットのDKIM鍵は、引用符で囲んだ複数の文字列に分割されます。cPanelの現行の標準鍵は長すぎて255文字の単一TXT文字列に収まらないため、パネルが分割したとおりに公開してください。公開済みなのに「無効」と判定されるDKIMの原因の多くは、断片の欠落や結合ミスです。
- 適用範囲
スマートホストやフィルター経由でメールを送るホスティング会社もあります。Newfold/EIGブランドや送信スパムフィルター（SpamExperts）を使うホスティング会社はゲートウェイ経由で送信するので、正しいSPFはサーバーIPではなくそのinclude（例：include:websitewelcome.com）です。+ip4と決めつけず、Email Deliverabilityの提案に従ってください。
SPFレコードを作成
cPanel / WHM shared hostingでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。
送信元
メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。
上の検索欄で利用中のメールサービスを検索するか、してください。
このドメイン自身のサーバー
ドメインが（上記のサービスを経由せず）直接メールを送信する場合は、ドメイン自体を許可します。
その他の送信元・IP
リストにないもの（別のサービスのSPFホストや特定のIPアドレス）を追加します。
接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。
その他すべての送信元へのポリシー
上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します（allメカニズム）。
送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。
- ルートドメインにTXTレコードとして公開します。ホストは@（ドメインそのもの）、値は上記の文字列全体です。
- SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
- DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。
送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。
リストを検証cPanel / WHM shared hostingのSPFに関するよくある質問
関連記事
ホスティング・Webサイトの他のサービス
すべてのSPFガイド公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。
認証の次は、リストをクリーンに保つ
SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。