%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
送信ドメイン認証は、DNSに3種類の記録を置いて「このドメインからHubSpotが送ってよい」と証明する作業です。接続手順と確認方法、既存SPFの統合を整理します。
HubSpotのメール送信ドメイン認証とは、自社のドメインのDNSにDKIM・SPF・DMARCの記録を追加し、「このドメインのメールをHubSpotから送ってよい」とメール受信側へ証明する設定です。 設定画面は［設定］＞［コンテンツ］＞［ドメインとURL］の「Eメール送信」タブにあり、HubSpotが生成した記録をDNSプロバイダーに貼り付けて、ステータスが「認証済み」になれば完了します。
マーケティングメールを送り始めてから「迷惑メールに入る」「届いているのか分からない」と気づく例は少なくありません。要因の1つとして、メール文面ではなく、送信元ドメインの認証が済んでいないことが挙げられます。しかも、この設定はHubSpotの画面だけでは終わらず、DNSを管理している情報システム部門や外部業者との調整が必要になるため、依頼の段取りで止まりやすい作業です。
この記事では、HubSpot公式ナレッジで確認できた手順を軸に、事前に決めておく項目、既存のSPFがある場合の統合、ステータスの読み方、確認ツールの使い方までを整理します。
- 3つの認証の役割 ── SPFは送信元の許可、DKIMは改ざんされていない署名、DMARCは認証に失敗したときの扱いです
- GoogleとYahooの送信者要件との関係 ── 要件のうち、どれがHubSpotの設定で満たせるかを切り分けます
- 接続前に決める項目 ── 使うサブドメイン、DNSの担当者、既存SPFの有無を判断表で確認します
- 接続手順と確認方法 ── 画面の順番どおりに進められる番号付きの手順と、ステータス3種類の読み方です
- つまずきの切り分け ── 反映待ち・SPFの重複・プロキシ設定など、よくある原因と対処を表にしました
送信ドメイン認証で証明している3つのこと
メール認証は、受信側のサーバー（Gmailなど）が「このメールは本当にそのドメインの持ち主が送ったものか」を機械的に確かめる仕組みです。名乗っている送信元と実際の送信元が一致するかを、DNSに公開された記録で照合します。
SPF・DKIM・DMARCの役割の違い
3つは別々の問いに答えます。1つだけ設定しても、残りの問いには答えられません。
| 認証 | 答える問い | DNSでの形 |
|---|---|---|
| SPF | このサービスは、そのドメインの代理で送信してよいか | TXTレコード（1件） |
| DKIM | メールは途中で書き換えられていないか。署名はドメインの持ち主のものか | CNAMEレコード（2件） |
| DMARC | SPFやDKIMの確認に失敗したメールを、受信側はどう扱うか | TXTレコード（1件） |
レコードの種類と件数は、HubSpot公式ナレッジの手順に記載されている形です。HubSpotの接続画面では、ここにMXレコードも含めた4種類が案内されますが、MXレコードの具体的な値や手順は公式ナレッジの該当ページでは詳しく説明されていません。MXの扱いは、画面に表示された内容に従ってください。
認証がないと何が起きるのか
認証がない、あるいは不完全なドメインから送ったメールは、受信側で「なりすましの可能性がある」と判断される材料が増えます。結果として迷惑メールフォルダへの振り分けや受信拒否につながり、メールが届かない状態でも送信側では気づきにくい場合があります。
送信ドメイン認証は「届くようにする機能」ではなく、「届かない理由を1つ消す設定」です。本文の品質や配信リストの質は別に整える必要があります。
配信そのものの設計については、HubSpotのメール配信ガイドで、テンプレートやA/Bテストを含めて整理しています。
GoogleとYahooの送信者要件と、HubSpotの設定が関わる範囲
Googleは2024年2月から、Gmailアドレスへメールを送る送信者に認証などの要件を適用しています。Yahooも同じ時期から、段階的に送信者の基準を運用しています。ここでは、要件のうち送信ドメイン認証に関わる部分を、公式の記載に沿って整理します。
全送信者と大量送信者で求められるものが違う
| 区分 | 認証に関する要件 | 補足 |
|---|---|---|
| 全送信者 | SPFまたはDKIMのどちらかを設定する | 迷惑メール率を0.3%未満に保つことも求められる |
| 1日5,000件を超える大量送信者 | SPFとDKIMの両方を設定し、DMARCも設定する | DMARCのポリシーは「none」でもよい |
| 大量送信者（マーケティング・購読メール） | ワンクリックの登録解除に対応する | 本文にも分かりやすい解除リンクが必要 |
Googleの公式ヘルプでは、From ヘッダーのドメインがSPFまたはDKIMのドメインと一致すること（DMARCのアライメント）も大量送信者の要件に含まれています。Yahooの公式ページも、SPFとDKIMの両方、DMARCポリシーの公開、Fromドメインとの整合を大量送信者に求めています。
出典は、Gmail 送信者のガイドライン（Googleヘルプ）と、送信者のベストプラクティス（Yahoo）です。基準の細部は更新されることがあるため、設定の前に最新の記載を確認してください。
「5,000件以下だから関係ない」とは言えない
大量送信者の区分に入らなくても、全送信者の要件（SPFまたはDKIMの設定、迷惑メール率の管理）は適用されます。また、HubSpotの送信ドメインを接続すると、自社のドメイン名でメールを送れるようになります。接続する意味は、要件を満たすことだけではなく、自社ドメインとしての送信実績を積み上げていくことにもあります。
なお、ワンクリック登録解除は、DNSの認証とは別の要件です。この記事の設定では満たせない部分として切り分けておき、配信設定の側で確認します。日本の法令側の考え方は、特定電子メール法の解説にまとめています。
接続を始める前に決める4つのこと
接続の手順そのものは数分で終わります。時間がかかるのは、手順に入る前に決めておくべきことが決まっていないために、途中で止まるケースです。次の4点を先に決めておくと、DNSの担当者への依頼も一度で済みます。
判断表：事前に決める項目と判断の基準
| 決めること | 選択肢 | 判断の基準 |
|---|---|---|
| 認証するドメイン | サブドメイン／ルートドメイン | 公式ナレッジでは、サブドメインはマーケティングメールの「送信元」アドレスのドメインと一致させる必要があると案内されている。ルートドメインも使えるが、コンテンツのホスティング（Webサイト等）に使われていないことが条件 |
| 送信元アドレス | 既存の代表アドレス／新しい専用アドレス | 接続の入力画面でメールアドレスを入れると、そこから送信ドメインが決まる。後で変えにくいので、配信用の送信元を先に決める |
| DNSを触れる人 | 自社の情報システム／外部の業者／ドメインの管理会社 | DNSプロバイダーのログイン情報を持ち、レコードを編集できる人を特定する |
| 既存のSPFレコード | ある／ない | すでにSPFがあるドメインは、新しく作らず既存のレコードに追記する（後述） |
使えないドメインに注意する
公式ナレッジには、ウェブサイトのホスティングなど他の用途で使用中のドメインは認証できない、という制限が記載されています。自社サイトをルートドメインで公開している場合、ルートドメインそのものではなく、配信専用のサブドメインを使う設計が現実的です。
また、同じドメインを複数のHubSpotアカウントに同時に接続することはできます。複数の事業部や子会社でポータルを分けている場合も、ドメインの持ち主が同じなら、認証の考え方を共通にできます。1アカウントにつき最大2,000件のドメインを接続できると記載されています。
必要な権限とプラン
公式ナレッジでは、対象製品は Marketing Hub・Sales Hub・Service Hub・Content Hub で、Starter・Professional・Enterprise のいずれでも利用できると案内されています。操作には、ドメイン設定の権限が必要です。権限の設計は、HubSpotの権限・チーム管理ガイドで整理しているため、管理者以外に任せるときは先に確認してください。
HubSpotでメール送信ドメインを接続する手順
ここからは、公式ナレッジに記載されている操作順を、画面の流れに合わせて並べます。画面の文言は、HubSpotの更新で変わることがあります。
接続の手順（番号付き）
- HubSpotの上部ナビゲーションバーにある設定アイコンをクリックします
- 左サイドバーで［コンテンツ］＞［ドメインとURL］の順に進みます
- 「Eメール送信」タブを開きます
- 右上の「送信ドメインを接続」をクリックします
- マーケティングメールの送信に使うメールアドレスを入力し、「次へ」をクリックします
- 表示されたメール送信ドメインが意図したものか確認し、「次へ」をクリックします
- DNSプロバイダーが対応している場合は「［プロバイダー］を使用してサインイン」を選びます。手動で設定する場合は「いいえ、手動でセットアップします」を選びます
- HubSpotが生成したDNSレコードを、DNSプロバイダーの管理画面に追加します
- 各レコードの「ホスト」と「必須のデータ」の横にある「コピー」をクリックし、DNSプロバイダーに貼り付けます
手順7でサインイン連携が使えるかどうかは、DNSプロバイダー次第です。使えない場合は手動のセットアップになり、HubSpotの画面とDNSの管理画面を行き来することになります。
DNSの担当者に渡す依頼文の要点
DNSを自分で触れない場合は、レコードの一覧を表にして依頼します。口頭やチャットで一件ずつ伝えると、貼り付けの誤りや抜けが出やすくなります。
| 依頼に含める項目 | 内容 |
|---|---|
| 対象ドメイン | 認証するドメイン（サブドメインかルートドメインか） |
| 追加するレコード | 種類（CNAME／TXT）、ホスト、値を、HubSpotの画面からコピーした原文のまま一覧にする |
| 既存SPFの有無 | あれば、新規作成ではなく既存への追記であることを明記する |
| 希望期限と確認方法 | 反映の確認は設定の20分後以降に行うこと |
既存のSPFレコードがあるときの統合
SPFは、1つのドメインにつき1つのTXTレコードにまとめるのが原則です。すでに別のメール送信サービスや社内のメールシステムのためのSPFがあるドメインで、HubSpot用に2件目のSPFを作ると、どちらも正しく評価されなくなるおそれがあります。
統合の考え方
公式ナレッジでは、既存のSPFレコードがある場合は、新しいレコードを作成せず、既存のレコードにHubSpotの指定を追加するよう案内されています。追加した後も、SPFのバージョン指定と「-all」の指定が、レコード全体で1回ずつだけになるようにします。他社サービスのincludeとHubSpotのincludeを、同じTXTレコードの中に並べる形です。
| 状況 | 対応 |
|---|---|
| SPFレコードがない | HubSpotが生成したSPFのTXTレコードを新規に追加する |
| SPFレコードがすでにある | 既存のTXTレコードを編集し、HubSpotの指定を追記する。2件目は作らない |
| 追記後に判定がおかしい | バージョン指定や「-all」が重複していないか確認する。外部ツールでレコードの中身を読む |
SPFには、名前解決（include等の参照）の回数に上限があるという仕様もあります。送信サービスを増やし続けたドメインでは、追記の際にこの上限を超えないか、規格（RFC 7208）の記載を踏まえて点検してください。
DKIMとDMARCの扱い
DKIMはCNAMEレコード2件で、他のサービスのDKIMと衝突しません。サービスごとに別の名前（セレクター）で署名するためです。DMARCはTXTレコード1件で、ドメイン単位で1つだけ公開します。すでに自社でDMARCを公開しているドメインでは、ポリシーの内容を変えてよいかを、メールを送っている他の部署も含めて確認してから進めます。
ルートドメインにDMARCレコードがある場合、サブドメインはそのポリシーを継承して認証済みとみなされる、と公式ナレッジに記載されています。つまり、ルートドメインのDMARCが整っていれば、配信用のサブドメインの確認が軽くなる場合があります。
認証ステータスの読み方と確認ツール
レコードを追加した後は、反映を待ってからHubSpotの画面で状態を確認します。
反映時間の目安
DNSの反映には、通常10〜70分、最長で48時間かかることがあります。公式ナレッジでは、変更後20分以上たってから確認するよう推奨されています。設定した直後に「未認証」と出ても、すぐに設定を疑って作り直さず、まず時間を置きます。
3つのステータスの意味
確認場所は、接続時と同じ［設定］＞［コンテンツ］＞［ドメインとURL］の「Eメール送信」タブです。
| ステータス | 意味 | 次の行動 |
|---|---|---|
| 未認証 | DKIM・SPF・DMARCの3つのどれも完了していない | DNSにレコードが入っているか、貼り付けの誤りがないかを確認する |
| 一部認証済み | DKIMは検証済みだが、SPFまたはDMARCが未完了 | 未完了のレコードを特定する。SPFの重複や統合ミスが多い |
| 認証済み | DKIM・SPF・DMARCのすべてが完了 | 完了。以後は送信元の変更やDNSの変更のたびに再確認する |
レコードに問題がある場合は、「設定を続ける」をクリックすると、追加すべきDNSレコードの値が再表示されます。
外部ツールでレコードの中身を確かめる
HubSpotの画面で原因が見えないときは、DNSに公開されている記録を外部ツールで直接読みます。公式ナレッジでは、次の確認方法が案内されています。
| 確認する認証 | 方法 | 正常な状態の目安 |
|---|---|---|
| SPF | MXToolboxのSPFチェックで対象ドメインを検索する | 「include:shared.hubspot.com」が含まれている |
| DKIM | MXToolboxのDKIM検索で、対象ドメインとセレクター「smtpapi」を入力する | 「k=rsa; t=s; p=MIG…」で始まる値が表示される |
| DMARC | dmarcianのDMARCレコードチェッカーで対象ドメインを検査する | DMARCレコードが存在する |
なお、SPFの値は、HubSpotの画面に表示されるものと、公式ナレッジの確認手順に書かれた目安（include:shared.hubspot.com）とで表記が異なる場合があります。判定は、画面に表示された値を基準にしてください。
出典は、メール送信ドメインの接続手順（HubSpotナレッジベース）です。日本語版は自動翻訳を含むため、判断に迷う箇所は英語版でも確認することをお勧めします。
つまずきやすい点と切り分けの順番
認証が終わらないときは、原因を1つずつ切り分けます。順番を決めておくと、DNSの担当者とのやり取りも短くなります。
よくある失敗と回避策
| 症状 | 考えられる原因 | 回避策 |
|---|---|---|
| 何時間たっても「未認証」 | ホスト名の貼り付けで、ドメイン名が二重に付いた（DNSプロバイダーが自動でドメイン名を補う場合がある） | DNSの管理画面でレコード名を確認し、HubSpotの表示と照らす |
| 「一部認証済み」から進まない | SPFが2件ある、または既存SPFへの追記が漏れている | 既存SPFを1件に統合する。バージョン指定と「-all」を1回ずつにする |
| DKIMが検証されない | CNAMEの値を取り違えた。Cloudflareのプロキシがオンのまま | Cloudflareを使う場合は、ドメイン全体のCNAMEフラット化とプロキシーをオフにする（公式ナレッジの記載） |
| ドメインを接続できない | ウェブサイトのホスティングなど、他の用途ですでに使用中のドメインを選んだ | 配信専用のサブドメインを使う設計に切り替える |
| 認証済みなのに届かない | 認証以外の要因（配信リストの質・迷惑メール率・本文）が残っている | 認証は条件の1つとして切り分け、配信設計の側を見直す |
変更のたびに再確認する習慣
送信ドメインの認証は、一度通れば終わりではありません。DNSプロバイダーの移管、メール送信サービスの追加、ドメインの付け替えがあると、既存の記録が失われたり、SPFの統合が崩れたりします。そうした変更の依頼が出る運用では、「HubSpotの送信ドメインのステータスを変更後に確認する」を完了条件に入れておくと、気づかないまま未認証になる事態を避けられます。
開封率の改善に取り組む場合も、認証が整っていることが前提になります。到達してから開かれるかという次の段階は、メルマガの開封率を高める施策で整理しています。
設定を運用に定着させるための進め方
送信ドメイン認証は、設定の手順としては短い作業です。ただし、配信の運用全体のなかでは、「誰がDNSを管理するか」「送信サービスが増えたときに誰が気づくか」という責任の置き場所の問題でもあります。
StartLinkはHubSpotゴールドパートナーとして、設定の代行だけでなく、運用が回る状態までを支援の範囲として考えます。工程ごとに行うことは、次のとおりです。
| 工程 | 行うこと | この設定での具体例 |
|---|---|---|
| 現状の整理・要件定義 | 現在の送信元、使っている送信サービス、DNSの管理者を洗い出す | 既存SPFの有無、配信に使うサブドメイン案、HubSpot以外の送信元一覧 |
| 設計・構築 | 接続するドメインとレコードの方針を決め、DNSの変更を依頼する | 事前に決める4項目の確定、レコード一覧の作成、依頼書の準備 |
| テスト・検証 | ステータスと外部ツールで認証を確認する | 3つの認証の確認、テスト配信の受信確認 |
| 定着・運用改善 | 変更時の再確認の手順を運用に組み込む | DNS変更時のチェック項目、配信担当と情報システムの連絡経路 |
スモールスタートで始めるなら、まず配信用のサブドメイン1つで認証を完了させ、問題がないことを確認してから、他の送信元や事業部へ広げる進め方が安全です。準委任で伴走する形では、DNSの担当者と配信の担当者の間に入り、依頼の文面から確認まで調整する役割を担います。企業様（チーム）によって最適な形は異なりますので、現状に合わせて範囲を決めます。
HubSpot導入全体の支援は、HubSpot導入・活用支援のサービスページで案内しています。
よくある質問
Q1. SPF・DKIM・DMARCは、どれか1つだけ設定すればよいですか。
Googleの要件では、全送信者はSPFまたはDKIMのどちらかが必要で、1日5,000件を超える大量送信者はSPFとDKIMの両方に加えてDMARCも必要です。HubSpotの接続画面は3つをまとめて案内するため、基本的にはすべて設定し、「認証済み」の状態にしておくのが確実です。
Q2. 設定したのに「未認証」のままです。何を確認すればよいですか。
まず、変更から20分以上たっているかを確認します。DNSの反映は通常10〜70分、最長48時間かかることがあります。それでも変わらない場合は、レコードのホスト名と値がHubSpotの表示と一致しているか、SPFが2件になっていないか、Cloudflareのプロキシがオンのままになっていないかを順に確認します。
Q3. すでにSPFレコードがあります。HubSpot用に新しく追加してよいですか。
新しいSPFレコードは作らず、既存のレコードにHubSpotの指定を追記します。SPFのバージョン指定と「-all」は、レコード全体で1回ずつだけにします。2件のSPFがあると、受信側で正しく評価されないおそれがあります。
Q4. サブドメインではなく、ルートドメインを使ってもよいですか。
ルートドメインも使えますが、コンテンツのホスティングに使われていないことが条件です。自社のウェブサイトをルートドメインで公開している場合は、配信専用のサブドメインを使う設計が一般的です。サブドメインを使う場合は、マーケティングメールの送信元アドレスのドメインと一致させる必要があります。
Q5. 認証済みになれば、迷惑メールに入らなくなりますか。
認証は、迷惑メールと判断される要因の1つを減らす設定で、到達を保証するものではありません。配信リストの質、本文の内容、迷惑メール報告の率なども評価に影響します。Googleは迷惑メール率を0.3%未満に保つことを求めています。
まとめ：認証の完了を、配信運用の入口に置く
送信ドメイン認証は、HubSpotの画面操作とDNSの変更が一体になった設定です。要点は次のとおりです。
- 3つの認証は役割が違う ── SPFは送信元の許可、DKIMは署名、DMARCは失敗時の扱いで、「認証済み」は3つがそろった状態です
- 事前に4つを決める ── 使うドメイン、送信元アドレス、DNSの担当者、既存SPFの有無を先に決めます
- 既存SPFは統合する ── 新しい2件目は作らず、既存のレコードに追記します
- 反映を待ってから確認する ── 変更後20分以上たってからステータスと外部ツールで確かめます
- 変更のたびに再確認する ── DNSやメール送信サービスの変更を、ステータス確認の契機にします
最初の一歩は、現在メールを送っているサービスの一覧と、DNSを管理している担当者を書き出すことです。この2つが分かれば、接続の手順は一度で進められます。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
