Eメール認証の問題のトラブルシューティング
更新日時 2024年 4月 25日
以下の 製品でご利用いただけます(別途記載されている場合を除きます)。
Marketing Hub Starter , Professional , Enterprise |
Sales Hub Starter , Professional , Enterprise |
Service Hub Starter , Professional , Enterprise |
Content Hub Starter , Professional , Enterprise |
HubSpotでEメール認証を設定しているときに問題が発生した場合は、以下のセクションのステップに従って、よくあるSPFとDMARCの問題を修正できます。
SPFのトラブルシューティング
SPFを正しく設定するには、DNSプロバイダーにTXTレコードを追加し、HubSpotのinclude文をコピーする必要があります。よくあるSPFの設定エラーについて、以下のセクションで詳しく説明します。
複数のSPFレコード
HubSpot以外のEメールプロバイダーでもEメールを送信している場合、DNSプロバイダーに別のSPFレコードがすでに設定されている可能性があります。この場合、同じTXTレコード内で、既存のinclude:
ステートメントに続けてHubSpotのSPFレコードを追加します。
以下に、GoDaddyのようなプロバイダーを使用していてTXTレコードに複数のSPFを設定する場合の例を示します。
レコードタイプ | ホスト | 必須のデータ |
TXT | @ | v=spf1 include:anotherprovider.com include:123456.spf03.hubspotemail.net -all |
複数のSPFレコードを組み合わせる際には、以下の点に注意してください。
include:
の各ステートメントはスペースで区切る。- 任意のドメインまたはサブドメインに対して、
include:
ステートメントを10個まで追加できる。 - SPFのバージョン(
v=spf1
)を指定する必要があるのは、レコードの最初に1回だけ。 -all
フラグは一度だけ入れる必要がある。このフラグは、SPFレコードに記載されているサーバーだけが、そのドメインを代表してEメールを送信することを許可されていることを示します。リストにないサーバーからのEメールは拒否されることになります。
ハードコーディングされたIPアドレス
Eメール送信ドメインの設定ページに表示されるHubSpotのSPFレコードは、ご使用のアカウントのEメール送信元となる全てのIPアドレスを自動的に取得するように作成されています。そのため、設定が完了したら、DNSプロバイダーでレコードを更新する必要はありません。
SPFレコードに、他のEメール サービス プロバイダーからのハードコーディングされたIPアドレスが含まれている場合、SPF認証でエラーが発生する可能性があります。SPFレコードにIPアドレスやCIDRをハードコーディングすることは、ベストプラクティスとはみなされません。SPFレコードにハードコーディングされたアドレスまたはCIDRがある場合:
- SPFレコードの内容を監査し、ハードコーディングされたHubSpot IPアドレスまたはCIDRを全て削除します。この記事の指示に従って、相互参照に使用できるHubSpotの送信アドレスとCIDRのリストを見つけることができます。
- 他のハードコーディングされたIPアドレスを管理する必要がある場合(別のサードパーティのEメール サービス プロバイダーを利用している場合など)、HubSpotの
include:
ステートメントをハードコーディングされたEメールアドレスの末尾に追加し、その後に-all
フラグを追加してください。構文は、プレースホルダー値を持つ以下のSPFレコードの例を参照してください。
v=spf1 ip4:.../24 ip4:.../24 include:123456.spf01.hubspotemail.net -all
DMARCのトラブルシューティング
DMARCレコードは、SPFおよびDKIMチェックに失敗した、ご使用のドメインのEメールをEメール事業者でどのように処理するかに基づいてカスタマイズできるTXTレコードで構成されます。以下のセクションでは、よくあるDMARCの設定の問題について概説します。
複数のレコード
DMARCが正しく設定されるようにするには、バージョンフラグで始まるTXTレコードを1つのみ作成する必要があります(例:v=DMARC1
)。複数のDMARCレコードが存在する場合、受信Eメールサーバーは即座にポリシー検出プロセスを終了し、DMARCポリシーは適用されません。
必要なDMARCタグの不足
一部のDMARCポリシータグはオプションですが、バージョンタグとポリシータグの指定は必須です(例:v=DMARC1; p=YOUR_POLICY_VALUE;
)。
全ての利用可能なDMARCタグおよびそれらに定義できる値は、Eメール認証の概要で確認できます。
無効なDMARCポリシー値
HubSpotでEメール送信ドメインを設定中に、「無効なDMARCポリシー」エラーが表示された場合は、おそらく、p
タグまたはsp
タグのポリシー値が無効であることが原因です。有効な値はnone
、reject
、quarantine
のみです。これらの値では大文字と小文字が区別され、小文字である必要があります。
誤 | 正 |
p=Quarantine; |
p=quarantine; |
無効なレポート送信先アドレス
ruf
タグおよびrua
タグは、DMARCレポートデータの送信先のEメールアドレスを指定するためのオプションパラメーターです。いずれかのタグに値を指定した場合、指定したEメールアドレスは有効で、適切な形式である必要があります。
- 指定するEメールアドレスは、URI mailto形式である必要があります。この場合、Eメールアドレスの前に
mailto:
(例:mailto:reporting@example.com
)を付ける必要があります。 rua
およびruf
のどちらのタグでも、カンマで区切って指定することで、レポート送信用の複数のEメールアドレスを指定できます。以下の例では、レポート送信用に2つの異なるEメールアドレスを指定しています。
rua=mailto:reporting@example.com,mailto:analytics@example.com;
rua
タグまたはruf
タグの有効な値は、1つまたは複数のEメールアドレスのみです。ドメイン名(例:rua=example.com
)のみを指定した場合は、有効とはみなされません。
誤 | 正 |
rua=reporting@example.com; |
rua=mailto:reporting@example.com; |
無効なDMARC位置合わせモード
adkim
フラグおよびaspf
フラグは、DKIMおよびSPFの位置合わせモードを指定します。「relaxed」位置合わせモードの場合は、両方のフラグをr
に設定する必要があります。ほとんどのDNSサービスでは、これがDMARCの既定の設定になっているはずです。
誤 | 正 |
adkim=s; aspf=s; |
adkim=r; aspf=r; |
無効なDMARCパーセンテージ形式
pctフラグは、ポリシーを適用する、認証に失敗した一意の送信の合計の割合を指定するために使用されます。指定する値は数値でなければならず、その他の文字は全て除外する必要があります(つまり、%記号を含めることはできません)。
誤 | 正 |
pct=25%; |
p=25; |