Eメール認証の概要

Eメール送信ドメインをHubSpotに接続することで、主要なEメール受信トレイプロバイダー（Gmail、Yahoo!メールなど）によって適用されている認証基準と送信ポリシーに準拠したマーケティングEメールを送信できるようになります。ドメインを接続するプロセスには、DNSプロバイダーの設定で3種類のDNSレコード（DKIM、SPF、DMARC）を設定する作業が伴います。

この記事では、これらのレコードの概要と、それぞれのレコードに関連付けられている認証プロトコルの仕組みについて説明します。

ご使用のEメール送信ドメインの認証準備が整ったら、HubSpotでDNS設定プロセスを開始するか、現在の認証ステータスを確認します。

注：担当のHubSpotアカウントマネージャーまたはHubSpotサポートのメンバーは、必要に応じてHubSpotで認証を設定する際のベストプラクティスやHubSpotツールの使い方をご案内いたしますが、ドメイン接続に関する意思決定やDNS設定の管理については対応いたしかねますのでご了承ください。Eメール認証の設定を完了するには、貴社のITチームまたはEメール管理者と連携していただく必要があります。また、サードパーティーのDMARCコンサルティングサービスやレポート関連サービスのご利用もご検討ください。

Eメール認証による影響について

未認証のEメールとEメール可変ドメイン

Eメール送信ドメインが接続されていなければ、HubSpot経由で送信されるマーケティングEメールおよびトランザクションEメールはいずれもHubSpotが管理する可変ドメインの対象となります。これにより、未認証のドメインを自動的に検出して削除できるため、送信がキャンセルされることがなくなります。ただし、このプロセスは受信者のEメールへのエンゲージメントに悪影響を及ぼす恐れがあります。

例えば、user@yourcompany.comなどの未認証のドメインからEメールを送信しようとすると、HubSpotにより、HubSpotが管理するドメイン（hs-domain.comなど）を使用するようにEメールアドレスが修正されます。そのため、生成される送信元アドレスはuser=yourcompany.com@hs-domain.comと表示されます。

認証済みの「送信元アドレス」が必要かどうかを判断するために自動配信Eメールを確認する方法について詳細をご確認ください。

HubSpotアカウントへの影響

HubSpot経由でEメールを送信するには必ずしもDKIM、SPF、DMARCが必要になるわけではありませんが、DKIMを設定してそのドメインをHubSpotに接続するまで、送信元Eメールアドレスに自社のドメインが含まれるEメールを送信することはできません（例：employee@example.com）。この設定を行うと、そのドメインのEメール到達性も向上します。

ご使用のアカウントでEメール送信ドメインとして接続されていないドメインは、HubSpotがホスティングする可変ドメインに変更されます。認証されていないEメールについては、こちらの記事をご参照ください。

Eメールのパフォーマンスへの影響

ほとんどのEメール受信トレイプロバイダーでは、DKIMで認証されたEメールを優先しています。DKIM認証が行われずに送信されるEメールは、拒否されて直帰したり隔離されたりする可能性や、迷惑メールに分類される可能性が高くなります。隔離されたEメールはHubSpotでは配信済みとして表示されますが、ほとんどの受信者には表示されません。したがって、Eメール到達性を向上させるために、DKIMを設定することを強くお勧めします。

注：GoogleやYahooなどのEメール受信トレイプロバイダーでは、ユーザーにEメールを一括送信するドメインにはDMARC、DKIM、SPFの全てを完全に設定することを要件としています。この要件を満たしていない場合、ご使用のドメインから送信されるEメールは拒否されて直帰します。このような直帰は、「DMARC」または「ポリシー」による直帰として分類されます。

DKIMの概要

DKIM（DomainKeys Identified Mail）は、悪意のある行為者が送信元アドレスを偽装してEメールを送信する、Eメールのなりすましを防止することを目的としたEメール認証方法です。

HubSpotでDKIMを設定する際は、DNSプロバイダーで2つのCNAMEレコードを使用してDKIMを設定するように案内されます。HubSpotから提供された公開鍵を使用してDNSプロバイダーでDKIMレコードを設定すると、受信メールサーバー（Gmailなど）で、ご使用のドメインに関連付けられて送信されたEメールの署名を検証できるようになります。

これらのレコードを追加する方法については、こちらの記事をご確認ください。

DNSレコードを追加して、これらのレコードがHubSpotとDNSプロバイダーによって検証されると、送信されるEメールのヘッダーに、DKIM署名が組み込まれるようになります。この署名は、設定したCNAMEエントリーに関連付けられています。

SPFの概要

SPF（Sender Policy Framework）は、送信メールサーバーが特定のドメインに代わってEメールを送信することを許可されているかどうかを確認するために使用されるEメール認証規格です。

従来、SPFはエンベロープ リターン パス ドメイン（直帰Eメールの送信先アドレス）に必要とされてきました。HubSpotでは、共有サーバー経由で送信されるマーケティングEメールに対して、すでにこの設定を行っています。専用IPをご利用のお客さまは、IPの初期設定の一環としてエンベロープ リターン パス ドメインにSPFを設定する必要があります。

また、送信元アドレスのドメインにもHubSpotのSPFレコードを追加することを強くお勧めします。これは、HubSpotのドメイン設定プロセスで提供される値を使用して、DNSプロバイダーでTXTレコードとして設定します。このレコードによって、お使いの送信元アドレスのドメインからHubSpot経由でマーケティングEメールを送信する際に使用されるIPアドレスのリストが定期的に更新されます。

HubSpotをSPFレコードに追加する方法については、こちらのガイドをご確認ください。

SPFレコードを追加した後、検証プロセスが完了すると、送信したEメールをEメールサーバーが処理する際に、ご使用のドメインの有効な送信元許可リストにHubSpotが登録されていることが確認されるようになります。

DMARCの概要

DMARC（Domain-based Message Authentication, Reporting and Conformance）は、Eメールのなりすましやその他のドメイン不正使用に対するEメールドメイン所有者の保護を強化するためのEメール認証プロトコルです。

DMARCレコードを設定すると、受信トレイプロバイダーが、SPFとDKIMのチェックを通過していないドメインから送信されたEメールの処理方法を確認できるようになります。また、ドメイン所有者はDMARCのレポートメカニズムを通じて、自分のドメインから世界中の受信サーバーに送信されたEメールが受信されている頻度と、適切に認証されている割合を把握できます。

以降のセクションで、利用可能なポリシーの値といくつかの例を紹介します。DMARCレコードを設定する準備ができたら、こちらの記事に従って進めてください。

ポリシーの値

DMARCポリシーを定義するには、DNSプロバイダーの設定でTXTレコードを追加します。ポリシーの値としては、以下のプロパティーをセミコロンで区切って指定できます。

• v：DMARCのバージョン。
• p：ポリシータイプ。これによって、通過しなかったEメールの処理方法が決まります。ポリシーは、次のいずれかのタイプに設定できます。
  
  • none：既存のフローに影響を与えることなくフィードバックを収集して、Eメールストリームについて把握するには、このタイプを使用します。
  • quarantine：認証を通過しなかったEメールをフィルタリングして受信側で隔離します。
  • reject：認証を通過しなかったEメールの受信を拒否して直帰させるには、このタイプを使用します。
• sp：DMARCレコードのサブドメインにポリシーを適用するには、このタイプを使用します。
• pct：認証に失敗した固有の送信の合計のうち、このポリシーの適用対象とする送信の割合。例えば、DMARCレコードにp=reject; pct=25が含まれている場合、100通のメールが認証に失敗したとすると、そのうちの25通だけが直帰し、残りの75通は受信者に配信されます。
  
  • このプロパティーを利用して認証ポリシーを徐々に強化することで、想定通りのポリシーの動作にすることができます。
  • ただし、Eメール受信サービスプロバイダーによってはこのパラメーターが無視されることがあるのでご注意ください。
• rufおよびrua：DMARCレポートデータの送信先Eメールアドレスを指定する2つのオプションパラメーター。これらは、URI mailto形式で指定する必要があります（例：mailto:reporting@example.com）送信されるレポートデータはパラメーターに応じて異なります。
  • rua：ご使用のドメインの全てのトラフィックの集計レポート。
  • ruf：認証に失敗した個々のメッセージのコピーが、機密情報を削除した状態で記載される失敗レポートデータ。
• adkimおよびaspf：DKIMとSPFのアラインメントモードを指定します。いずれもr（つまり、緩やかな（relaxed）アラインメント）に設定する必要があります。「緩やかな」アライメントは、DNSサービスのDMARCでデフォルトの設定となっているはずです。

DNSプロバイダーでのDMARCレコードの追加と検証が完了すると、全ての受信メールサーバーで、ご使用のドメインからの受信Eメールを認証し、検証に失敗したEメールを指定されたポリシーに従って処理できるようになります。

ポリシーの例

DMARCポリシーは個別のビジネスニーズに合わせてカスタマイズできます。以下に、いくつかの例を取り上げます。

中立的なポリシー

v=DMARC1; p=none;

この例は、追加パラメーターが設定されていない中立的なDMARCポリシーを示しています。DMARCについて習得し始めたばかりの送信者には、中立的なポリシーが役立ちます。これは、DMARCを機能させるための必要最小限のポリシーです。

集計レポートを提供する厳格なポリシー

v=DMARC1; p=reject; rua=mailto:reporting@example.com;

上記の例では、認証に失敗したEメールの受信を拒否して直帰させる厳格なDMARCポリシーを定義し、集計レポートデータの送信先とするEメールアドレスを指定しています。

失敗レポートを提供する隔離ポリシー

v=DMARC1; p=quarantine; pct=25; ruf=mailto:reporting@example.com;

この例では、認証に失敗したEメールの25%を隔離し、残りの75%のEメールの配信を許可するポリシーを定義しています。このポリシーでは、認証に失敗したEメールごとに個別の通知Eメールを送信できる、レポート送信先アドレスも指定しています。

pctプロパティーの値を定義することで、DMARCに失敗したメッセージをランダムに抽出してテストし、正当なメールが引き続き適切に配信されることを確認できます。

注：HubSpotサポートでは、DMARCレコードの設定をお手伝いいたしかねますのでご了承ください。設定するDMARCポリシーは、お客さまのビジネスニーズとご利用のDNSプロバイダーによってそれぞれ異なります。DMARC設定のサポートが必要な場合は、貴社のIT管理者またはDNS設定を管理する担当者にご相談ください。また、サードパーティーのDMARCコンサルティングサービスやレポート関連サービスのご利用もご検討ください。