HubSpotのメール認証は、プラットフォーム内では正常に見えても、DMARCレポートではSPF整合性障害を示すことがあります。
これは、マーケティング、営業自動化、CRMコミュニケーション、顧客オンボーディング、ライフサイクルキャンペーンにHubSpotを使用している組織にとって、最も一般的な盲点の1つです。
ドメインは、HubSpot内で接続済み、検証済み、または認証済みと表示される場合があります。DKIMが設定されているかもしれません。DMARCがほとんどのメッセージで通過しているかもしれません。配信は安定しているように見えるかもしれません。
しかし、ドメイン所有者がDMARC集計レポートを確認すると、HubSpotストリームは異なる状況を示すことがあります:
- SPFは技術的には通過するが、DMARC整合性では失敗する
- HubSpotトラフィック全体でSPF整合性が非常に低い
- DMARCは主にDKIMを通じて通過している
- DKIMが唯一の信頼できる認証パスである
- HubSpotメッセージの一部は、DKIMが失敗するか正しく適用されていない場合にDMARCで失敗する可能性がある
これは必ずしもHubSpotが広範囲に失敗していることを意味するわけではありません。
これは、組織がHubSpotインターフェース内だけでなく、実際の受信者側データでHubSpot認証がどのように機能しているかを理解する必要があることを意味します。
I. 核心的な問題:HubSpotはSPFではなくDKIMを通じてDMARCを通過する可能性がある

DMARCは、SPFとDKIMの両方が通過する必要はありません。
DMARCは、少なくとも1つの認証方法が通過し、表示されるFromドメインと整合性がある場合に通過します:
- SPFが通過し整合性がある
- DKIMが通過し整合性がある
HubSpotが整合性のあるDKIMでメールに署名すれば、SPFが整合性を持たない場合でもDMARCは通過できます。
そのため、多くの組織は、HubSpotトラフィックが全体的にDMARCを通過しているのを見る一方で、SPF整合性が弱いことも示しています。
問題は、DKIMが維持されない場合に現れます。
DKIMが失敗し、SPFが整合性を持たない場合、DMARCにはバックアップ認証方法がありません。その特定のメッセージはDMARCで失敗する可能性があります。
これが、小さな失敗率でも重要である理由です。
ドメインが失敗したHubSpotトラフィックをわずか0.31%しか示していない場合でも、その失敗はより深い依存関係を明らかにする可能性があります:HubSpotメールは主にDKIMを通じて通過しており、SPFは信頼できるバックアップとして機能していません。
II. SPF通過はSPF整合性と同じではない
SPFは、送信サーバーがリターンパスドメインの送信を許可されているかどうかをチェックします。
DMARCはより具体的なことを行います。
SPFがDMARCの通過を支援するには、SPF認証されたリターンパスドメインが表示されるFromドメインと整合性がある必要があります。
その違いは重要です。
HubSpotの簡略化された例:
表示されるFrom: [email protected]
Return-Path: [email protected]
SPF結果: 通過
example.comとのSPF整合性: 失敗
DKIM結果: d=example.comで通過
DMARC結果: DKIMを通じて通過この場合、SPFは技術的には通過する可能性がありますが、SPFドメインが表示されるFromドメインと整合性がないため、DMARCの支援にはなりません。
DKIMがDMARC結果を支えています。
DKIMが安定している場合は許容できますが、依存関係が生じます。
III. 多くのHubSpot顧客がこれを見逃す理由
多くのHubSpot顧客は、プラットフォーム認証とDMARC整合性が同じものではないことを知りません。
HubSpot内では、送信ドメインが認証済みと表示される場合があります。これにより、SPF、DKIM、DMARCがすべての送信シナリオで完全に整合性があるという印象が生まれる可能性があります。
しかし、DMARCレポートはより詳細な現実を示す可能性があります。
顧客はしばしば次のように想定します:
- HubSpotがドメインが認証済みと言っているので、SPFとDKIMの両方が整合性がある
- 接続された送信ドメインは、すべてのHubSpotトラフィックが保護されていることを意味する
- DMARC失敗量が少ないということはリスクがないことを意味する
- DMARCが通過している場合、SPF障害は問題ない
- 共有インフラストラクチャは認証の可視性に影響しない
- 専用IPは自動的にすべての認証問題を修正する
- DKIMが通過していれば、SPF整合性を監視する必要はない
これらの想定は誤りである可能性があります。
HubSpotドメインは認証済みと表示される一方で、DMARCレポートは実際の送信ストリームの大部分でSPFが整合性を持たないことを示すことがあります。
IV. これが送信に影響を与える可能性がある理由

低いSPF整合性は、HubSpotメールの配信が自動的に失敗することを意味するわけではありません。
しかし、送信リスクを生み出す可能性があります。
リスクは、HubSpotメッセージがDMARCを通過するためにほぼ完全にDKIMに依存している場合に現れます。DKIMが正常なままであれば、メッセージは通過します。DKIMが失敗、破損、または特定のストリームで欠落している場合、DMARCを通過させるための整合性のあるSPF結果がない可能性があります。
これは次のような結果につながる可能性があります:
- 特定のHubSpotキャンペーンでのDMARC失敗率の上昇
- ドメインが
[p=quarantine]またはp=rejectの場合のフィルタリングまたは拒否 - 転送やメッセージ変更時の耐性の低下
- HubSpotが認証済みと表示される一方で受信者側レポートが障害を示すため、トラブルシューティングが困難
- HubSpotのドメイン認証ステータスと実際のDMARC整合性結果の間の混乱
- 受信メールボックスプロバイダーによる顧客向けメッセージの異なる扱い
これは特に以下の場合に重要です:
- リードナーチャリングキャンペーン
- 営業自動化
- 顧客オンボーディングメール
- 請求リマインダー
- サポートコミュニケーション
- ウェビナー確認
- 製品アップデート
- セキュリティまたはアカウント通知
問題は、HubSpotが送信できないということではありません。
問題は、多くの顧客が、HubSpotのDMARC通過結果が主にDKIMに依存しており、SPFが信頼できるフォールバックパスを提供していないことを認識していないことです。
V. HubSpotメール認証の仕組み

HubSpotは、組織がメール送信ドメインを接続し、メール送信のための認証レコードを設定することを可能にします。
HubSpotの認証フローでは、組織はセットアップに応じてDKIM、SPF、DMARCのレコードを設定できます。
DKIMは、顧客の送信ドメインでメッセージに署名できるため、HubSpotにとって最も重要なDMARC通過パスであることが多いです。
HubSpotは、メール送信ドメインのカスタムリターンパス設定も文書化しています。カスタムリターンパスは、DMARCがリターンパスドメインが表示されるFromドメインと整合性があるかどうかをチェックするため、SPF整合性をサポートできます。
つまり、HubSpot SPF整合性は、リターンパスが設定されているか、送信ドメインがどのように設定されているか、アカウントのメール送信設定が必要なリターンパス動作をサポートしているかに依存する可能性があります。
実用的な要点:
HubSpotが認証されているかどうかだけを尋ねないでください。
HubSpotがDMARCレポートで整合性があるかどうかを尋ねてください。
VI. 一般的なHubSpot SPF障害パターン
VII. 1. SPFは通過するが整合性がない
これが最も一般的なパターンです。
SPFはHubSpotのインフラストラクチャドメインで通過する可能性がありますが、リターンパスドメインが表示されるFromドメインと整合性がありません。
結果:
- SPF: 通過
- SPF整合性: 失敗
- DKIM: 通過
- DMARC: DKIMを通じて通過
これは完全な認証失敗ではありませんが、SPFがDMARCを支援していないことを意味します。
VIII. 2. DKIMが通過しDMARCを支える
多くのHubSpot設定では、DKIMがDMARCが通過する主な理由です。
つまり、組織はDKIMを注意深く監視すべきです。
DKIMが安定して整合性がある場合、HubSpotトラフィックは健全である可能性があります。
しかし、DKIMが破損すると、SPF整合性の欠如が明らかになります。
IX. 3. DKIMが失敗しSPFが整合性がない
これがDMARC障害が現れる場所です。
結果:
- SPF: 通過または失敗
- SPF整合性: 失敗
- DKIM: 失敗
- DMARC: 失敗
これはトラフィックのわずかな割合にしか影響しない可能性がありますが、ストリームが顧客向けまたはビジネスクリティカルである場合、これらの障害は重要である可能性があります。
X. 4. HubSpotは認証済みと表示されるが、すべてのストリームが同じように動作するわけではない
企業はHubSpotで1つの送信ドメインを認証し、その後以下を追加する可能性があります:
- 新しいキャンペーン
- 新しい自動化ワークフロー
- 新しいサブドメイン
- 新しい接続ドメイン
- 新しいチームまたは事業部門
- 新しい統合
- 新しいフォームまたはリードフロー
メインドメインが接続されているからといって、すべてのストリームが健全であると想定すべきではありません。
DMARCレポートを使用して、実際に何が起こっているかを検証すべきです。
XI. 5. カスタムリターンパスが欠落または誤設定されている
カスタムリターンパスは、正しく設定されている場合にSPF整合性を支援できます。
欠落している、誤設定されている、または特定の設定で利用できない場合、DKIMが通過していてもSPFは整合性を持たない可能性があります。
これは自動的にDMARCを破壊するわけではありませんが、SPFを信頼できるバックアップパスとして削除します。
XII. 6. 専用IPは完全な修正として扱われる
専用IPは、送信レピュテーションとリターンパス動作をより細かく制御できます。
しかし、専用IPだけではDMARC整合性を保証しません。
組織には依然として正しい以下が必要です:
- SPF認証
- リターンパス整合性
- DKIM署名
- DKIM整合性
- DMARCポリシー
- DNSレコード
- 監視
専用IPは制御を改善します。認証監視を置き換えるものではありません。
XIII. 共有IPプールとレピュテーション動作
HubSpotは一般的に共有メールインフラストラクチャを通じて運用されます。
共有インフラストラクチャは、自動的に低いレピュテーションを意味するわけではありません。
大規模メールプラットフォームは、不正使用管理、監視、スロットリング、レピュテーション管理を備えた共有送信プールを維持できます。ただし、共有インフラストラクチャは、送信者が送信環境に付随するすべてのシグナルを制御できないことを意味します。
これは認証と配信性を確認する際に重要です。
共有送信は以下のような考慮事項をもたらします:
- 共有IPレピュテーション動作
- プラットフォームレベルの不正使用管理
- 送信者固有のドメインレピュテーション
- DKIM整合性品質
- SPF整合性品質
- 苦情率
- エンゲージメントシグナル
- キャンペーンコンテンツ
- リスト品質
- マーケティングと重要なコミュニケーション間のストリーム分離
目標は必ずしも共有インフラストラクチャを避けることではありません。
目標は、どのストリームがそれを使用しているか、正しく認証されているか、組織が重要な送信ユースケースのためにより多くの制御を必要とするかどうかを理解することです。
XIV. 低い失敗率が依然として重要である理由
低いHubSpot DMARC失敗率は、大きな障害を示していない可能性があります。
たとえば、失敗したトラフィックが約0.31%の場合、全体的な認証状況は依然として安定している可能性があります。
しかし、低い割合が必ずしも低い重要性を意味するわけではありません。
失敗したメッセージには以下が含まれる可能性があります:
- 高価値の顧客コミュニケーション
- 営業機会メール
- サポート返信
- 請求関連リマインダー
- イベント確認
- 収益に関連するキャンペーン
- 特定のサブドメインからのメッセージ
- ワークフローまたはテンプレートの問題の影響を受けたメール
規模が大きい場合、小さな割合でも意味のあるボリュームを表す可能性があります。
さらに重要なことに、小さな失敗率は構造的依存関係を明らかにする可能性があります。
ほとんどのHubSpotトラフィックがDKIMを通じて通過し、SPFが整合性を持たない場合、組織はDKIM失敗を優先事項として扱うべきです。
正しい質問は次のようなものだけではありません:
「HubSpotはDMARCを通過していますか?」
より良い質問は:
「DKIMが失敗した場合、HubSpotには整合性のあるSPFフォールバックがありますか?」
答えがノーの場合、組織はそのリスクを監視すべきです。
XV. HubSpot SPF障害を調査する方法

XVI. ステップ1:HubSpotトラフィックを他の送信者から分離する
ドメイン全体を1つのブロックとして評価しないでください。
HubSpotトラフィックを次のような他の送信者から分離します:
- Google Workspace
- Microsoft 365
- Amazon SES
- Salesforce
- Zendesk
- Mailchimp
- SendGrid
- Postmark
- カスタムアプリケーション
- レガシーサーバー
これにより、HubSpot固有の動作がドメイン平均の中に隠れることを防ぎます。
XVII. ステップ2:SPF通過とSPF整合性を確認する
HubSpotトラフィックについて、次を確認します:
- SPFは通過しましたか?
- どのドメインがSPFを通過しましたか?
- SPFドメインは表示されるFromドメインと整合性がありましたか?
- 整合性は緩和されていましたか、それとも厳密でしたか?
- DMARCはSPFまたはDKIMを通じて通過しましたか?
SPFが通過するだけでは十分ではありません。
SPFが通過しても整合性がない場合、SPFはDMARCを支援していません。
XVIII. ステップ3:DKIMが通過し整合性があることを確認する
HubSpot DKIMがDMARC作業を行っているかどうかを確認します。
以下を確認します:
- DKIMが存在する
- DKIMが通過する
- DKIM
d=が表示されるFromドメインと整合性がある - セレクターが期待されるHubSpot設定と一致する
- すべての関連するHubSpotストリームがカバーされている
DKIMが主なDMARC通過パスである場合、継続的に監視する必要があります。
XIX. ステップ4:リターンパス設定を確認する
HubSpotがFromドメインと整合性のあるリターンパスドメインを使用しているかどうかを確認します。
カスタムリターンパスが利用可能でアカウントに適切な場合は、慎重に設定し、DNSレコードを検証します。
DMARCはリターンパスドメインに対してSPF整合性を評価するため、カスタムリターンパスはSPF整合性を改善できます。
XX. ステップ5:ストリーム固有の障害を探す
メインのHubSpotストリームが理解されたら、小さな失敗率を調査します。
次の条件でパターンを探します:
- キャンペーン
- サブドメイン
- ワークフロー
- 送信IP
- DKIMセレクター
- メッセージタイプ
- 日時
- 転送ルート
- 受信者ドメイン
これにより、問題が広範囲か、孤立しているか、特定の設定に関連しているかを判断するのに役立ちます。
ステップ6:強制前にDMARCポリシーを確認する
ドメインがまだp=noneの場合、HubSpot障害は表示される可能性がありますが、積極的に強制されていません。
ドメインがp=quarantineまたはp=rejectに移行する場合、整合性がないまたは失敗したメッセージは、受信プロバイダーに応じてフィルタリングまたは拒否される可能性があります。
強制に向けて移行する前に、HubSpotおよびその他のすべての正当な送信者が少なくとも1つの整合性のある認証パスを持っていることを確認します。
主要戦略として割合ベースのロールアウトに依存することは避けてください。現在のDMARC対応プログラムは、ドメイン、サブドメイン、送信者グループ、ビジネス機能ごとに強制をステージングすべきです。
HubSpot SPF障害について顧客に何を伝えるか
適切な説明はバランスが取れているべきです。
全体的な失敗量が少ない場合、低いSPF整合性を完全なHubSpot障害として提示しないでください。
しかし、それを却下してもいけません。
明確な顧客向けの説明は次のとおりです:
HubSpotトラフィックは主にDKIMを通じてDMARCを通過しています。HubSpotストリームの大部分でSPF整合性が弱く、これはSPFが信頼できるフォールバックとして機能していないことを意味します。DKIMが有効で整合性がある限り、DMARCは通過します。ただし、HubSpotメッセージのサブセットでDKIMが失敗した場合、SPFが整合性を持たないため、これらのメッセージはDMARCで失敗する可能性があります。現在の失敗量は少ないかもしれませんが、SPF整合性のギャップは耐性と監視の懸念として扱うべきです。
この表現は、不必要な警告を引き起こすことなく問題を説明します。
Skysnag ProtectがHubSpot SPF障害の特定にどのように役立つか
Skysnag Protectは、組織がHubSpotおよび他のSaaS送信者が受信者側データで実際にどのように認証されているかを理解するのに役立ちます。
DNSレコードが存在するかどうかを確認するだけでなく、Skysnagは各送信者がSPF、DKIM、DMARCを整合性をもって通過しているかどうかを示します。
HubSpotについて、Skysnag Protectは以下の特定に役立ちます:
- HubSpotがDKIMまたはSPFを通じてDMARCを通過しているかどうか
- SPFが技術的に通過しているが整合性が失敗しているかどうか
- どのHubSpotストリームがDKIMで失敗しているか
- 特定のキャンペーンまたはサブドメインが障害を引き起こしているかどうか
- リターンパス整合性が正しく設定されているかどうか
- 不正なソースがドメインを使用しているかどうか
- 共有インフラストラクチャの動作が可視性に影響を与えているかどうか
- ドメインがより強力なDMARC強制の準備ができているかどうか
これは、HubSpotがドメインを認証済みと表示する一方で、DMARCレポートが依然として整合性のギャップを明らかにする可能性があるため重要です。
Skysnag Protectを使用して、HubSpot SPF障害、DKIM整合性、リターンパス動作、DMARC強制準備状況を監視します:
重要なポイント
HubSpot SPF障害は、HubSpotメールが広範囲に失敗していることを常に意味するわけではありません。
多くの場合、HubSpotトラフィックは整合性のあるDKIMを通じてDMARCを通過する一方で、SPF整合性は弱いままです。
HubSpotがドメインを認証済みと表示する場合でも、DMARCレポートはSPFが整合性を持たないことを示す可能性があるため、多くの顧客はこれを見逃します。
これは、DKIMが失敗した場合、メッセージが変更された場合、またはドメインがp=quarantineまたはp=rejectに移行された場合に、送信に影響を与える可能性があります。
SPF通過はSPF整合性と同じではありません。SPFがDMARCの通過を支援するには、リターンパスドメインが表示されるFromドメインと整合性がある必要があります。
カスタムリターンパスは、正しく設定されている場合にSPF整合性を改善できます。
専用IPはより多くの送信制御を提供できますが、認証または整合性の問題を自動的に解決するわけではありません。
最も安全なアプローチは、DMARC集計レポートを通じてHubSpotを監視し、DKIM整合性を確認し、リターンパス設定を確認し、失敗するメッセージの小さな割合を特定することです。
Skysnag Protectは、組織がHubSpot SPF障害を検出し、DKIM依存性を監視し、HubSpotトラフィックがより強力なDMARC強制の準備ができているかどうかを理解するのに役立ちます。